## 產品設計體會（三六）——再理解“敏捷” 最近項目做的對敏捷有點興趣，花了兩個晚上瀏覽了《敏捷迭代開發——管理者指南》，理念式的書，看起來比較輕松，摘錄一些自己的體會。 ? 有些需求在開始的時候是提不出來的，或者說沒法細化的，強行的過渡需求分析是浪費時間的行為，到后來多半還是要改。 瀑布（其實Royce大大提出的瀑布模型初衷里也是有迭代思想的，不過被后人誤讀了）的問題是最后集中暴露矛盾，當然對需求固定的項目還是不錯的。 敏捷迭代開發，如果斷章取義是極其危險的，比如沒有迭代的測試跟上，到最后發現問題的時候就已經晚了。 ? 介紹了四種敏捷的模式：Scrum、XP（極限編程）、UP（統一過程）、Evo（Evolutionary Project Management），他們的共同點如下： ? ????????? 擁抱變化，大問題分而治之，先解決最核心的，風險最大的部分。 ????????? 會議室中集體工作，每日例會（<20min），站立會議，充分利用白板和墻壁。 ????????? 較短的迭代周期，通常一周到一個月，團隊人數不要太多（小于十幾人），太多了可分割為多個團隊。 ????????? 一個迭代周期內絕不再加任務，有多的需求放入以后的迭代，如果迭代周期內任務無法完成，可以為了時間點的要求，移出一部分任務到下一個迭代。 ????????? 把迭代周期內的事情列出來，很小時間粒度（天為單位）的跟蹤。 ????????? 不停的發布/交付，讓需求方看到結果，獲取反饋。 ????????? 需求方充分投入，包括需求人員一起辦公，驗收測試的迭代。 ????????? 需求方代表要有話語權，不然半途殺出個老板說三道四是極其郁悶的。 ????????? 輕文檔，通過開發和測試來細化和糾正。 ????????? 程序員自主選擇任務點，安排時間點。 ????????? 反對加班，這點其實很難做到，特別是在中國，呵呵。 ????????? 極其多的口頭溝通，其實這點對團隊成員要求很高，特別是對中國的技術人員。 ????????? 強調測試，更早的測試（TC編寫早于coding），重度的測試，測試驅動項目。