6.1 敏捷的流程

現有的做法	敏捷的做法
流程和工具	個人和交流
完備的文檔	可用的軟件
為合同談判	與系統合作
執行原定計劃	相應變化

?

?

?

?

? ? ?

? ? ? 敏捷開發的原則：1.盡早并持續地交付有價值的軟件以滿足顧客需求。

　　　　　　　　 ? ? 2.敏捷流程歡迎需求的變化，并利用這種變化來提高用戶的競爭優勢。

　　　　　　　　　 3.經常發布可用的軟件，發布間隔可以從幾周到幾個月，能短則短。

　　　　　　　　　 4.業務人員和開發人員在項目開發過程中應該每天共同工作。

　　　　　　　　　 5.以有進取心的人為項目核心，充分支持信任他們。

　　　　　　　　　 6.無論團隊內外，面對面的交流始終是最有效的溝通方式。

　　　　　　　　　 7.可用的軟件是衡量項目進展的主要指標。

　　　　　　　　　 8.敏捷流程應能保持可持續的發展。領導、團隊和用戶應該能按照目前的步調持續合作下去。

　　　　　　　　　 9.只有不斷關注技術和設計，才能越來越敏捷。

　　　　　　　　　 10.保持簡明——盡可能簡化工作量的技藝——極為重要。

　　　　　　　　　 11.只有能自我管理的團隊才能創造優秀的架構、需求和設計。

　　　　　　　　　 12.時時總結如何提高團隊效率，并付諸行動。

? ? ? 敏捷流程概述（在這里剖析Scrum這個方法論）：

　　　　　　　　　 第一步：找出完成產品需要做的事情——Product Backlog。

　　　　　　　　　 第二步：決定當前的沖刺需要解決的事情——Sprint Backlog。

　　　　　　　　　 第三步：沖刺。

　　　　　　　　　 第四步：得到軟件的一個增量版本，發布給用戶。然后在此基礎上又進一步計劃增量的新功能和改進。

6.2 敏捷流程的問題和解法

6.3 敏捷的團隊

? ? ? 敏捷對團隊的要求很簡單：自主管理、自我組織、多功能型。

6.4 敏捷總結

? ? ? 敏捷流程的經驗教訓：

　　　　　　1.敏捷宣言表明的是一些優先級，不必當作圣旨或者教條來爭論。

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

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

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

　　　　　　5.創業公司的團隊其實經常是運行在Scrum的模式中（只不過大家太忙，沒工夫論證自己到底有多么Scrum）。

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

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

　　　　　　8.在大型團隊、跨地區的團隊，或者復雜項目中，Scrum并沒有非常完美的答案，Scrum的創始人也承認這一點。

6.5 敏捷的問答

? ? ? 敏捷（Agile）是一種思潮，又或者說是一種價值觀，它涵蓋了好幾種軟件開發的方法論（Methodology）；這些方法論有事建立在許多行之有效的最佳實踐方法（Best Practices）之上的。

轉載于:https://www.cnblogs.com/shuaideyib/p/6917763.html

總結

以上是生活随笔為你收集整理的第六章 敏捷流程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。