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

前段時間，我們發現開發過程有些混亂并且不容易管理。為了團隊更好的協作，我們在顧問的引導下，開始嘗試使用Scrum敏捷開發。（Scrum相對官方的資料，附在文章最后）

幾輪Sprint下來，有點個人體會，和大家share之。立場當然是是不褒不貶，純客觀描述啦！不過，每個團隊情況不一致；因此，這個“客觀”針對的是我們團隊。啊哈~

首先，Scrum的官方流程如下：

我們的Scrum流程如下：

接下來會詳細講解每個步驟中應當注意的點：

開發前：

闡述&調整需求：

產品要在這之前需要考慮清楚每個需求的邏輯、頁面交互展示，不然在這一步就會造成很多討論，延長開會時長，影響效果。至于如何思考清楚內在邏輯，有多鐘方法，這又是一個topic；

對于優先級的確認，一定要明確，這是后面實現的先后基礎；

如果程序猿們對某個需求邏輯提出質疑的話，最好不要太任由發散討論，能立刻調整的，那么就調整；不能立刻確認調整的，先保留，然后在真正開發前要確認；

如果產品汪在闡述需求的同時，開發人員們開始相互溝通如何實現的問題，那么建議開發們先聽完所有內容，在后面的需求分解中再進行詳細討論，不然在需求源頭錯過就容易有需求上的認知偏差；

需求分解為任務：

小團隊沒有項目經理的情況下，建議項目負責人（Scrum Master）是經驗比較豐富的技術人，這樣對項目進度比較容易有把控，同時對需求的分解以及后期的追蹤會有很大的幫助；

要強化需求追蹤人（Owner）追蹤需求的意識，不要流于形式：有個這么個角色，但是并沒有發揮作用這種情況。owner的存在可以分擔SM的責任的同時讓開發人員之間關聯性更強，因為一般某個需求會同時涉及到前端、后端、API、移動端，讓開發去推動開發；

開發人員們要適當把需求拆的細一些，這樣在拆的過程中更容易吃透需求、理清邏輯，發現邏輯上的問題。針對需求，相關的人進行技術討論，有疑問的地方要及時和產品這邊溝通，問題越早發現越好。最后，要把每個任務對應的人以及需要的完成時間都記錄下來。

有關于時間預估問題，我暫時還不知道哪種方法比較好。在文末最后有個敏捷估算的方法，乃們可以參考看看。

在拆分的過程中，SM最好能夠根據需求的難易程度，進行輔助溝通。這樣，能夠相對避免因為具體代碼人員因為經驗/能力不夠而導致的拆分、預估問題；

產品汪要在討論過程中，時刻穿插在其中，盡量保證需求理解的正確性；

確認該期目標：

• 完整過一遍每個需求的分解情況，看是否有遺漏或者誤差，有疑問即刻提；
• 必須按照需求的優先級來確認目標；
• 要明確目標，確認哪些一定要做完（這里有個argue/挖坑的地方，會在下文“開發中”-“3其他”-2中進行描述）；

開發中：

有關中期會議：

一定要在一期sprint的中間進行進度回顧和確認，如果進度偏差很大的話，要適當的調整目標，以免最終跟預期相差太大；

中期的時候，可以check下人力分配，如果有相對空閑，那么可以再安排一些任務?？床煌闆r，是安排產品線的新任務還是基礎建設任務或是代碼優化任務等等；

有關測試：

在開發過程中，建議開發完一個功能就跟進一個功能的測試，以免最終測試任務都堆積起來；

提測可以在項目結束的前2-3天開始，這樣可以保證有足夠的時間進行修正；

如果功能和業務強關聯，可以讓業務人員在提測階段使用測試版本，一起發現問題；

開發人員在開發新功能過程中，可能會遇到之前存在的bug或者突然發現了之前沒發現的bug，這時候應該要告訴測試人員跟進，而不是自己直接修掉。因為你以為的修掉并不一定真正沒問題，一定要進行回測，同時留下記錄，可能會給以后的追溯帶來幫助；

其他：

團隊每天開站會，目的在于描述自己的進度情況。一定要明確！要明確！要明確！如果不明確表述，其實等于沒有開站會；

在適應新開發流程的初期，SM最好能夠每天or每兩天確認下組員們的真實開發情況，包括進度and需求理解上；

一開始嘗試Scrum敏捷開發時，容易預估（目標、時間）不準確，導致2周一個迭代版本比較困難，可能會經常延遲。面對這種情況，我目前是傾向砍掉部分需求，先滿足2周一個版本，讓團隊先形成這么一個周期慣性，再去優化慣性內的效率問題（也就是之后再提高目標的要求)；

Scrum要求是：

1. 目標、質量驗收標準不能改變；
2. 完成目標的要求不能過低；（文末有相關資料）

關于如何解決這個問題，也還在摸索狀態 T_T，大家如果有好的建議和想法，求溝通呀~

開發后：

1. 組員們要一定總結下這期開發中存在哪些問題，如何解決或者減弱這些問題的影響，不要流于形式。畢竟對團隊來說，這是新的開發流程，不適應或者做的不好很正常，不要怕說不要的地方，大家在錯誤中磨合、改善、成長才是最重要的；
2. 結合上一點，每期也要對上期提出來的問題進行回顧，看在這期中是否有改善這個問題。只記錄不回顧，等于什么都沒干；

以上，是目前的一些體會和總結，希望在不斷實踐中，能夠得到新的解決方法和體會…

最后附Scrum的官方資料:

什么是Scrum？

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html

Scrum團隊的三個角色？

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-5

Scrum的三個工件？

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-6

Scrum的五個活動？

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-7

敏捷估算？

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-14

sprint？

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-15

每日站會？

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-16

完成的“定義”？

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-17

本文由華爾街見聞產品經理 @梁露瑤（微信公眾號killifer） 原創發布于人人都是產品經理?，未經許可，禁止轉載。