昨天和今天，數節課都是關於敏捷的：迭代開發、迭代管理、adaptive requirements、estimation、stand-up、retrospective……總之，就是這類東西。關於敏捷，冰雲的觀點我認為很正確：it's all about money。客戶之所以認可我們的做法，因為他們
按時間付錢。所以，他們希望在最近的迭代中完成最重要的功能，把不那麼重要的功能先放一放；一旦我們開始迭代，他們就盡量不過來打斷我們，有需求變更也照著我們的流程來做……這樣他們可以早點趕我們走……雖然聽起來怪怪的，不過事實就是如此。如果按專案付錢，客戶就會說「我才不管你們怎麼幹，反正我要所有這些功能」，那麼迭代就很難不成為扯淡了。
不過另一方面，對於真正需要軟體提供業務價值的客戶，迭代確實是有意義的——之所以要加上前乙個定語從句，因為很多客戶（尤其是中國的某些客戶）確實不需要軟體提供價值，他們只是要找個花錢的路子而已。據我的觀察，很多甲方代表——主要是銀行的甲方代表——確實也希望使用迭代方式，因為他們希望盡快看到軟體投資變成收益。
所以敏捷，正如我在spbc上所說，並不是一幫技術狂人（例如thoughtworkers）想出來的玩意，實在是當前這個殘酷的商業環境底下客戶的需求所致——客戶希望更快看到收益、更實時調整需求，那就意味著迭代，就意味著擁抱變化，就意味著更少的冗餘文件和更嚴格的紀律，就意味著敏捷。這是從事敏捷諮詢的另一項奧秘：讓客戶看到是他自己需要敏捷，而不是thoughtworkers要硬塞給他敏捷。（在今天的lego遊戲中，我們——還算不錯的——實現了這個目標。）
西行漫記（3） 敏捷的奧秘
昨天和今天，數節課都是關於敏捷的 迭代開發 迭代管理 adaptive requirements estimation stand up retrospective 總之，就是這類東西。關於敏捷，冰雲的觀點我認為很正確 it s all about money。客戶之所以認可我們的做法，因為他們 按...
西行漫記（11） 數位化敏捷
今天做案例分析，分組討論。乙個問題是說，有個大專案第三期工程，時間大概是20個月。由於第二期狂趕進度，拉下很多技術債 糟糕的設計，重複 等等。現在要考慮，第三期要不要重新做架構，還是在第二期的基礎上接著往上堆。這種類似的問題在國內的論壇就已經討論過很多次。主張繼續堆的說，時間緊任務重，抓緊完成功能交...
西行漫記（11） 數位化敏捷
今天做案例分析，分組討論。乙個問題是說，有個大專案第三期工程，時間大概是20個月。由於第二期狂趕進度，拉下很多技術債 糟糕的設計，重複 等等。現在要考慮，第三期要不要重新做架構，還是在第二期的基礎上接著往上堆。這種類似的問題在國內的論壇就已經討論過很多次。主張繼續堆的說，時間緊任務重，抓緊完成功能交...