敏捷軟件開發之Scrum/Sprint(3)

　　Self-managing: 以前領導布置了任務，我們實現就可以了，現在要自己挑選任務;每次sprint 結束之后，還要總結不足，提出改進，并且自己要實施這些改進。“自我管理”不等于“沒有管理”。

　　Self-organizing: 以前做好自己的事情就好了，安心下班?，F在每個人要聯合起來對項目負責，有人工作落后了還要幫助他改進，項目缺少某類資源還要自己頂上去。

　　cross-functional: 以前spec 由PM 來寫, test 由測試人員來做, 現在每個人都全面負責，自己搞定spec, 和別人溝通, 同時自己搞定測試。

　　如果你的團隊很弱, 那么強行把Scrum (或者其它高級方法)套在上面也沒有用, 也許還會適得其反，往往需要多次Sprint 才能讓Scrum 走上正軌。換句話說, 如果你的團隊已經是這么厲害 (self-managing, self-organizing, cross-functional)的一幫人, 那么用不用Scrum 都能寫好軟件!

　　經驗:

　　這里有一些實踐者的經驗教訓:

　　ScrumMaster 不是一個官，而是一個沒有行政權力的溝通者，就像微軟的PM 那樣。她同時還要在團隊中做具體的工作。直接把原來的 “經理”變成 ScrumMaster 大多行不通。

　　在一些公司中，不少項目需要很多暗箱操作和政治角力才能搞定, Scrum 會把這些矛盾都擺到明處。這有好處，也有風險。

　　在復雜的項目里，要讓一線團隊成員做決定。

　　創業公司的團隊其實經常是運行在 Scrum 的模式中 (只不過大家太忙，沒功夫論證到底多么Scrum)。

　　在Scrum 計劃階段的估計不是一個“合同”, 領導們不要把它當成一個合同。估計總是不準的。 堅持短期的Sprint，即使不準的估計也不會有大的損害。

　　不要和管理層談 “流程”, 他們只關心 “結果”。

　　在大型團隊，復雜項目中，Scrum 并沒有非常完美的答案，Scrum 的創始人也承認這一點。 (我曾看到30多人擠在會議室里搞 Daily Scrum，一嘆! )

　　總結:

　　Sprint/Scrum 對項目的眾多需求采取分而治之的辦法, 能讓相關人員集中精力, 在一定期限內解決部分問題。

　　它強調短時間的迭代 (iteration)， 在多次迭代中不斷總結, 改進團隊的流程和產品功能。

　　它明確地指出不同人在一個項目中的投入和責任的不同 (豬和雞), 并堅持讓全身心投入的“豬”來主導項目。

　　它通過 daily scrum, ScrumMaster 等方法和角色，鼓勵團隊內部交流并優化團隊和其他人員的交流方式。

　　它對團隊成員提出了很高的要求, self-managing， self-organizing， cross-functional。 一般人不能馬上做到這一點。

　　它不是 “銀彈”，不能解決軟件開發的所有問題，至于具體項目進度如何跟蹤, 如何管理測試工作， 如何管理復雜項目, 還要靠戰斗在一線的團隊成員見招拆招，想出合適的辦法。

　　SCRUM 視頻: Scrum 看似容易, 門道挺多, 這里是一個視頻系列，大家可以觀賞: http://blogs.collab.net/agile/scrum-training-series

　　思考題:

　　在一個沖刺中, 團隊預計每天的進度為 30 小時。當項目完成了一半的工作量的時候, 大家發現實際的進度為15小時/天, 問: 在余下的時間中, 團隊的進度要到多少, 才能在項目結束時讓整個項目的平均進度恢復到每天30 小時?

原文轉自：http://www.kjueaiud.com