中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

Scrum敏捷開發，帶來的不僅僅是敏捷，還有理不清的煩惱。

最近公司開展的Scrum敏捷開發，幾個Sprint下來，碰到了很多煩惱。

比如說：碰到有改交互原型圖，改視覺設計稿，改代碼的情況，因為Sprint?Planning?Meeting（周期計劃會議），就沒有考慮到交互原型圖和視覺設計稿需要改幾次，bug需要修幾次，所以碰到這種情況，一般需要加班或者放到下個sprint再做計劃。

又比如：本來1天可以完成的工作，但是需要計劃成2-3天去安排，因為在某一個sprint之內，在項目的某一環節上，確實是沒有什么事情可以安排的?？偛荒茉谟媱澤蠈懀骸?天上班，2天自由活動。”另外，在Daily?Scrum?Meeting（每日站立會議）上，要求每個團隊成員，都需要口頭說一說自己昨天的工作進度，今天的工作計劃。這個時候，有些同事，只能編造一些無關緊要的事情，或者把1天可以完成的事情，分成2-3天來匯報，因為他這個環節，這幾天本來就沒什么事做嘛。

再比如：臨時有加急事情，需要下單的時候，同事之間就用Sprint?Backlog（周期工作列表）來拒絕工作。“這個sprint計劃里面沒有這個任務啊?！彼裕緛硇枰蛹钡娜蝿站瓦@樣被拒絕了。這時候，只好放到下個sprint再弄，或者自己加班做。其實，本來只需要在1天的工作時間里，擠擠時間，這個急單，就可以完成了。

下面先介紹一下Scrum敏捷開發的流程，然后再針對上面的這些煩惱，提出我個人的改進方案。

什么是Sprint？

Sprint是短距離賽跑的意思，這里面指的是一次迭代，而一次迭代的周期是1個月時間（即4個星期），也就是我們要把一次迭代的開發內容以最快的速度完成它，這個過程我們稱它為Sprint。

如何進行Scrum開發？

1. 我們首先需要確定一個Product Backlog（按優先順序排列的一個產品需求列表），這個是由Product Owner 負責的；
2. Scrum Team根據Product Backlog列表，做工作量的預估和安排；
3. 有了Product Backlog列表，我們需要通過 Sprint Planning Meeting（Sprint計劃會議） 來從中挑選出一個Story作為本次迭代完成的目標，這個目標的時間周期是1~4個星期，然后把這個Story進行細化，形成一個Sprint Backlog；
4. Sprint Backlog是由Scrum Team去完成的，每個成員根據Sprint Backlog再細化成更小的任務（細到每個任務的工作量在2天內能完成）；
5. 在Scrum Team完成計劃會議上選出的Sprint Backlog過程中，需要進行 Daily Scrum Meeting（每日站立會議），每次會議控制在15分鐘左右，每個人都必須發言，并且要向所有成員當面匯報你昨天完成了什么，并且向所有成員承諾你今天要完成什么，同時遇到不能解決的問題也可以提出，每個人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃盡圖）；
6. 做到每日集成，也就是每天都要有一個可以成功編譯、并且可以演示的版本；很多人可能還沒有用過自動化的每日集成，其實TFS就有這個功能，它可以支持每次有成員進行簽入操作的時候，在服務器上自動獲取最新版本，然后在服務器中編譯，如果通過則馬上再執行單元測試代碼，如果也全部通過，則將該版本發布，這時一次正式的簽入操作才保存到TFS中，中間有任何失敗，都會用郵件通知項目管理人員；
7. 當一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，我們要進行 Srpint Review Meeting（演示會議），也稱為評審會議，產品負責人和客戶都要參加（最好本公司老板也參加），每一個Scrum Team的成員都要向他們演示自己完成的軟件產品（這個會議非常重要，一定不能取消）；
8. 最后就是 Sprint Retrospective Meeting（回顧會議），也稱為總結會議，以輪流發言方式進行，每個人都要發言，總結并討論改進的地方，放入下一輪Sprint的產品需求中。

針對本文開篇提到的煩惱，我在這里總結了3個針對性的方案。

1. 在計劃會議的時候，需要給交互設計師預留改原型的時間，給Ui設計師預留改視覺稿的時間，給開發工程師預留修bug的時間。比如：Ui設計師，平均改稿次數，為3次左右。一次就能定稿的情況，幾乎不存在。

根據【Ui中國】發布的《UIweek6》雜志上的一份《上海Ui設計師工作現狀調查》顯示：一般從產品初期到產品上線所需要修改次數的比例為：改稿4-6次的情況占41%，改稿1-3次的情況占40%，改稿7-9次的情況占7%，改稿10次的情況占12%。為了避免后期要求Ui設計師改設計稿的時候，Ui設計師因為怕加班而不改，或隨便修改應付了事的情況，我建議需要在計劃會議的時候，把修改的時間，預留到計劃里面。這樣，Ui設計師就可以大大方方的改。

2. 當臨時有急事，需要布置加急任務的時候，一般就拖到下個Sprint去了。為了避免這種情況，我建議在計劃sprint會議的時候，預留出2/10的時間，作為臨時任務的預留時間。這樣，有任務需要加急的話，就可以大大方方的給出時間嘛。

3. 關于Sprint Star的評選，一般情況，優先被選中的是，誰加班多，誰在這個sprint我接觸比較多，誰被選中的機會就大。這個標準，我建議改成：誰可以在完成這個Sprint任務之外，多做一些Sprint計劃之外的事情，就盡量選誰。

以上是我最近在敏捷開發的實施過程中，碰到的一些煩惱和推薦的方案。具體實施過程中，需要綜合這4種（瀑布式開發，迭代式開發，螺旋開發，敏捷開發）開發方式的優缺點，來運用到具體的項目當中。這樣，敏捷開發就可以做到取長補短的效果。

本文由人人都是產品經理專欄作家 @張云錢（微信號：944352559） 原創發布于人人都是產品經理?。未經許可，禁止轉載。