0 方法論先進(jìn)性問題：來源https://insights.stackoverflow.com/survey/2017#development-practices
1 每日站會（一直在踐行）
昨天為沖刺做了什么
今天為沖刺要做什么
遇到什么阻礙沖刺的事情了
2 sprint == 迭代周期 ==沖刺
每一個迭代周期一般時間固定。
我們在第一次使用Scrum進(jìn)行項目管理時，并沒有看Scrum的規(guī)則姚糊，從直覺上做了以下幾件事舀射，巧合的是扣蜻，跟Scrum中項目的前期準(zhǔn)備sprint0 很多地方是一致的，這讓我們后期切到Scrum更加順滑。
我們在準(zhǔn)備階段，分別讓
1 前王凑、后端包括UED進(jìn)行了架構(gòu)設(shè)計，產(chǎn)品設(shè)計文檔
2 進(jìn)行了一些技術(shù)難點和問題點的調(diào)研
3 也有了第一個release的發(fā)布計劃
4 初步的backlog
5 和測試與產(chǎn)品數(shù)據(jù)的抓取方案
不過還缺少審核檢查表等聋丝。（缺的不多）
3 與產(chǎn)品梳理故事索烹，并對故事的優(yōu)化級進(jìn)行了排序
4 將不同故事安排在不同的sprint中
5 第一次評估故事和開發(fā)時間，是用計劃撲克弱睦，將故事點和開發(fā)人天設(shè)置為一樣百姓，這樣做是為了大家方便理解，先試用一次况木，并且是我自己將story拆分成task的垒拢。從第二次開始，將故事點和開發(fā)時間分開評估焦读，由大家一起將story拆分成task,然后由大家認(rèn)領(lǐng)task子库，交給最適合做這個task的開發(fā)同事舱权。再根據(jù)task矗晃，每人分別評估開發(fā)時間。
6 與測試一起制定測試與開發(fā)周期的結(jié)合點宴倍，這塊并沒有完全按照scrum的方法做张症，我的做法是想盡量讓測試與開發(fā)并行，將測試與開發(fā)的工作周期拉開一周鸵贬，原因是在早期項目的開發(fā)節(jié)奏較快俗他，任務(wù)比較多。
7 與UED一起制定了UED與開周期的結(jié)合點阔逼，UED整體晝早開發(fā)一個周期兆衅，這樣當(dāng)開發(fā)進(jìn)行到一定任務(wù)時，UED已準(zhǔn)備好。
8 通過 6羡亩，7 設(shè)計摩疑、開發(fā)、測試 的工作周期能夠比較好的咬合在一起畏铆，當(dāng)然實際效果要在日后的工作中持續(xù)檢驗雷袋。
9 產(chǎn)品可以持續(xù)在backlog中添加待辦事項，同事們就可以排sprint來進(jìn)行一個又一個周期的安排辞居。然后開發(fā)的同事們來具體實施完成楷怒。
10 “雞”在scrum中不能說話。雞可以觀察每日Scrum瓦灶，但不能夠參與 參考文章：https://cloud.tencent.com/developer/article/1073880
11 在開發(fā)中發(fā)現(xiàn)很多細(xì)節(jié)問題鸠删，這些問題都是在需求及設(shè)計階段沒有講清或更新不及時導(dǎo)致的，所以在流程中又加入了評審過程贼陶。評審分兩塊：
1：需求+設(shè)計 冶共，這部分的評審我們將需求和設(shè)計結(jié)合起來一起做，因為產(chǎn)品和UED是在開發(fā)的前一個周期的每界，所以時間上是有的捅僵，另外，二者合起來對于開發(fā)接收的信息更完整眨层，更利于開發(fā)的順利介入庙楚。評審時間是在開發(fā)拆分story之前。
2：測試評審趴樱，具體就是針對測試用例進(jìn)行評審馒闷，主要目的是使開發(fā)和測試對所做的東西有一個一致的認(rèn)識，讓不同角度的雙方進(jìn)行一輪信息的交流叁征，達(dá)成共識纳账。評審時間是在開發(fā)的中前期，具體時間由測試負(fù)責(zé)人決定捺疼。
12 加入了驗收人和驗收時間疏虫，在每一個sprint結(jié)束后需要驗收人來進(jìn)行驗收，我們并沒做全員的成果演示啤呼，簡化些流程卧秘，只做產(chǎn)品的驗收。但是會在大版本發(fā)布前做一個多功能的成果演示官扣。目的是讓全員對產(chǎn)品成果有概念翅敌，讓參與的同事有成就感。
13 驗收人員由產(chǎn)品改為 產(chǎn)品+UED
14 在提測前加入了UED走查惕蹄，這樣UED在評審蚯涮、走查治专、驗收三個環(huán)節(jié)都有機(jī)會介入校驗開發(fā)的成果是否和設(shè)計一致。
15 召開了敏捷回顧會議遭顶，通過總結(jié)
KEEP（做的好的看靠，要保持的）
CHANGE（做的不好的，需要改進(jìn)的）
-
TRY（可以嘗試的）
產(chǎn)出了 action list ,為后面每一個sprint的行動
keep change try 每人每項最多列舉三項液肌，然后大家匿名貼在白板上（反過來貼挟炬，字在里面）可以消除大家的心理障礙。開會時嗦哆，主持一張一張的讀出來谤祖，然后大家發(fā)言討論下，直到最后一張討論完老速，總結(jié)出ACTION LIST粥喜。
16 將bug fix的修改周期和提測周期粒度拆細(xì)，由原來的按sprint算橘券，改為在一個sprint中分功能多次提測额湘，在重要sprint中，按照當(dāng)時項目的情況靈活掌握旁舰，具體來說就是:bug按優(yōu)先級靈活處理,重要的先處理锋华，排進(jìn)當(dāng)前srint故事中，不重要的暫時擱置箭窜。
17 調(diào)整了故事和任務(wù)的粒度毯焕，因為經(jīng)過了幾次迭代后，大家對開發(fā)的模式很清楚了磺樱，在互相信任的前提下纳猫， 我們提高效率，減少了錄入整理和頻繁的看板操作竹捉，將任務(wù)的粒度變粗芜辕，而故事的任務(wù)變粗可以方便拆分成有意義的任務(wù)，否則如果故事太細(xì)块差，任務(wù)不好拆分侵续，就算拆分了也意義不大。比如一個關(guān)注功能憾儒，雖然可以拆分成數(shù)據(jù)庫設(shè)計询兴、緩存設(shè)計、接口契約制定起趾、實現(xiàn)，前端實現(xiàn)警儒，后端邏輯實現(xiàn)训裆，但如果所有故事都這么干眶根，任務(wù)量太大和對任務(wù)的管理就會比較麻煩。
18 有關(guān)敏捷的思考
敏捷開發(fā)不是偷工減料边琉，不是貪圖速度属百。只是因為每一個人相對獨立后，減少了溝通成本变姨，從效果來講變快了族扰。如果在工作中，不做防范（寫文檔定欧，測試渔呵，測試用例），一味降低成本砍鸠。后來人走了扩氢，接不上，成本更高爷辱。
