02《構建之法》閱讀筆記02

個人感受：

過去我的做法：

1、以前每個部分都是分開各做各的，

做好自己的事情就好了

，不需要管其他的。獨立開發，想做什麼做什麼，只要實現布置的任務就行。

這樣做的缺陷：

無法做到團隊快速開發，很難提公升速度。

問題解決方法：

1、要自己挑選任務；每次sprint結束之後，還要總結不足，提出改進，並且自己要實施這些改進。

2、每個人要聯合起來對專案負責，有人工作落後了還要幫助他改進，專案缺少某類資源還要自己頂上去。

3、每個人都全面負責，自己搞定規格說明書，和別人溝通，同時自己搞定測試。

重點記錄：

軟體專案的團隊各式各樣，假設乙個團隊做得還不錯，現在要變成敏捷流程，那團隊要做下面的改變：

1、自主管理

：以前領導布置了任務，我們實現就可以了，現在要自己挑選任務；每次sprint結束之後，還要總結不足，提出改進，並且自己要實施這些改進。「自主管理」不等於「沒有管理」。

2、自我組織：

以前做好自己的事情就好了，安心下班。現在每個人要聯合起來對專案

負責，有人工作落後了還要幫助他改進，專案缺少某類資源還要自己頂上去。

3、多功能型：

以前規格說明書由pm來寫，測試由測試人員來做，現在每個人都全面負責，自己搞定規格說明書，和別人溝通，同時自己搞定測試。

如果你的團隊很弱，那麼強行把敏捷套在上面也沒有用，也許還會適得其反，往往需要多次sprint才能讓scrum走上正軌。換句話說，如果你的團隊已經有這麼厲害的一幫人，那麼用不用scrum都能寫好軟體！

敏捷不是萬能的。敏捷的方法能

幫助你更早地知道你是否能如期完成任務，僅此而已

。敏捷的方法能幫你盡快讓使用者看到專案的部分價值。當你盡早交付

部分價值時，也許使用者對你目前交付的東西已經很滿意了，這樣你就不用再花時間來實現其他需求。另一種可能是，使用者看到了部分系統，他們有新的需求，這樣你就可以實現新的需求，而不用再浪費時間實現過時的需求了

。需要敏捷的開發流程，但是不需要匆忙或忙亂的開發流程。在實際情況下，有許多號稱敏捷的專案好像也敏捷不到**去。要記住，有許多最佳實踐在各種開發方式下都在使用，所以各種開發方式並不是井水不犯河水、老死不相往來的那種關係

。