0 方法論先進性問題：來源https://insights.stackoverflow.com/survey/2017#development-practices

image.png

1 每日站會（一直在踐行）

• 昨天為沖刺做了什么

• 今天為沖刺要做什么

• 遇到什么阻礙沖刺的事情了

2 sprint == 迭代周期 ==沖刺

每一個迭代周期一般時間固定。

我們在第一次使用Scrum進行項目管理時，并沒有看Scrum的規(guī)則，從直覺上做了以下幾件事，巧合的是，跟Scrum中項目的前期準備sprint0 很多地方是一致的，這讓我們后期切到Scrum更加順滑。

image.png

我們在準備階段，分別讓

1 前、后端包括UED進行了架構(gòu)設(shè)計，產(chǎn)品設(shè)計文檔

2 進行了一些技術(shù)難點和問題點的調(diào)研

3 也有了第一個release的發(fā)布計劃

4 初步的backlog 

5 和測試與產(chǎn)品數(shù)據(jù)的抓取方案

不過還缺少審核檢查表等。（缺的不多）

3 與產(chǎn)品梳理故事，并對故事的優(yōu)化級進行了排序

4 將不同故事安排在不同的sprint中

5 第一次評估故事和開發(fā)時間，是用計劃撲克，將故事點和開發(fā)人天設(shè)置為一樣，這樣做是為了大家方便理解，先試用一次，并且是我自己將story拆分成task的。從第二次開始，將故事點和開發(fā)時間分開評估，由大家一起將story拆分成task,然后由大家認領(lǐng)task，交給最適合做這個task的開發(fā)同事。再根據(jù)task，每人分別評估開發(fā)時間。

6 與測試一起制定測試與開發(fā)周期的結(jié)合點，這塊并沒有完全按照scrum的方法做，我的做法是想盡量讓測試與開發(fā)并行，將測試與開發(fā)的工作周期拉開一周，原因是在早期項目的開發(fā)節(jié)奏較快，任務比較多。

7 與UED一起制定了UED與開周期的結(jié)合點，UED整體晝早開發(fā)一個周期，這樣當開發(fā)進行到一定任務時，UED已準備好。

8 通過 6，7 設(shè)計、開發(fā)、測試 的工作周期能夠比較好的咬合在一起，當然實際效果要在日后的工作中持續(xù)檢驗。

9 產(chǎn)品可以持續(xù)在backlog中添加待辦事項，同事們就可以排sprint來進行一個又一個周期的安排。然后開發(fā)的同事們來具體實施完成。

10 “雞”在scrum中不能說話。雞可以觀察每日Scrum，但不能夠參與 參考文章：https://cloud.tencent.com/developer/article/1073880

11 在開發(fā)中發(fā)現(xiàn)很多細節(jié)問題，這些問題都是在需求及設(shè)計階段沒有講清或更新不及時導致的，所以在流程中又加入了評審過程。評審分兩塊：

   1：需求+設(shè)計 ，這部分的評審我們將需求和設(shè)計結(jié)合起來一起做，因為產(chǎn)品和UED是在開發(fā)的前一個周期的，所以時間上是有的，另外，二者合起來對于開發(fā)接收的信息更完整，更利于開發(fā)的順利介入。評審時間是在開發(fā)拆分story之前。

   2：測試評審，具體就是針對測試用例進行評審，主要目的是使開發(fā)和測試對所做的東西有一個一致的認識，讓不同角度的雙方進行一輪信息的交流，達成共識。評審時間是在開發(fā)的中前期，具體時間由測試負責人決定。

12 加入了驗收人和驗收時間，在每一個sprint結(jié)束后需要驗收人來進行驗收，我們并沒做全員的成果演示，簡化些流程，只做產(chǎn)品的驗收。但是會在大版本發(fā)布前做一個多功能的成果演示。目的是讓全員對產(chǎn)品成果有概念，讓參與的同事有成就感。

13 驗收人員由產(chǎn)品改為 產(chǎn)品+UED

14 在提測前加入了UED走查，這樣UED在評審、走查、驗收三個環(huán)節(jié)都有機會介入校驗開發(fā)的成果是否和設(shè)計一致。

15 召開了敏捷回顧會議，通過總結(jié)

• KEEP（做的好的，要保持的）

• CHANGE（做的不好的，需要改進的）

• TRY（可以嘗試的）

  產(chǎn)出了 action list ,為后面每一個sprint的行動

  keep change try 每人每項最多列舉三項，然后大家匿名貼在白板上（反過來貼，字在里面）可以消除大家的心理障礙。開會時，主持一張一張的讀出來，然后大家發(fā)言討論下，直到最后一張討論完，總結(jié)出ACTION LIST。

16 將bug fix的修改周期和提測周期粒度拆細，由原來的按sprint算，改為在一個sprint中分功能多次提測，在重要sprint中，按照當時項目的情況靈活掌握，具體來說就是:bug按優(yōu)先級靈活處理,重要的先處理，排進當前srint故事中，不重要的暫時擱置。

17 調(diào)整了故事和任務的粒度，因為經(jīng)過了幾次迭代后，大家對開發(fā)的模式很清楚了，在互相信任的前提下， 我們提高效率，減少了錄入整理和頻繁的看板操作，將任務的粒度變粗，而故事的任務變粗可以方便拆分成有意義的任務，否則如果故事太細，任務不好拆分，就算拆分了也意義不大。比如一個關(guān)注功能，雖然可以拆分成數(shù)據(jù)庫設(shè)計、緩存設(shè)計、接口契約制定、實現(xiàn)，前端實現(xiàn)，后端邏輯實現(xiàn)，但如果所有故事都這么干，任務量太大和對任務的管理就會比較麻煩。

18 有關(guān)敏捷的思考

 敏捷開發(fā)不是偷工減料，不是貪圖速度。只是因為每一個人相對獨立后，減少了溝通成本，從效果來講變快了。如果在工作中，不做防范（寫文檔，測試，測試用例），一味降低成本。后來人走了，接不上，成本更高。