2023年1月24日
2023年春，專案做的對敏捷有了點興趣，花了兩個晚上瀏覽了《敏捷迭代開發——管理者指南
》，理念式的書，看起來比較輕鬆，摘錄一些自己的體會。
有些需求在開始的時候是提不出來的，或者說沒法細化的，強行的過渡需求分析是浪費時間的行為，到後來多半還是要改。
瀑布（其實royce大大提出的瀑布模型
初衷裡也是有迭代思想的，不過被後人誤讀了）的問題是最後集中暴露矛盾，當然對需求固定的專案還是不錯的。
敏捷迭代開發，如果斷章取義是極其危險的，比如沒有迭代的測試跟上，到最後發現問題的時候就已經晚了。
介紹了四種敏捷的模式：scrum、xp（極限程式設計）、up（統一過程）、evo（evolutionary project management），他們的共同點如下：
ø 擁抱變化，大問題分而治之，先解決最核心的，風險最大的部分。
ø 會議室中集體工作，每日例會（<20min），站立會議，充分利用白板和牆壁。
（iamsujie補：每日例會每個人說三句話：昨天做了什麼，今天要做什麼，碰到什麼問題。）
ø較短的迭代週期，通常一周到乙個月，團隊人數不要太多（小於十幾人），太多了可分割為多個團隊。
ø乙個迭代週期內絕不再加任務，有多的需求放入以後的迭代，如果迭代週期內任務無法完成，可以為了時間點的要求，移出一部分任務到下乙個迭代。
ø 把迭代週期內的事情列出來，很小時間粒度（天為單位）的跟蹤。
ø不停的發布/交付，讓需求方看到結果，獲取反饋。
ø 需求方充分投入，包括需求人員一起辦公，驗收測試的迭代。
ø需求方代表要有話語權，不然半途殺出個老闆說三道四是極其鬱悶的。
ø輕文件，通過開發和測試來細化和糾正。
ø 程式設計師自主選擇任務點，安排時間點。
ø反對加班，這點其實很難做到，特別是在中國，呵呵。
ø極其多的口頭溝通，其實這點對團隊成員要求很高，特別是對中國的技術人員。
ø強調測試，更早的測試（tc編寫早於coding），重度的測試，測試驅動專案。
先敏捷再規範
先敏捷再規範，先做到再寫到，先短期利益再長遠利益，先實效再完備。這個策略源於實踐。因為一步到位直接採用規範的方法，阻力比較大，效果難以持久，很可能事倍功半，敏捷方法以其短期內可以見效 對已有的開發過程調整幅度小等特點易於開發人員接受，所以可以先敏捷再規範，將敏捷作為通向規範的乙個階段。芸芸眾生，大都...
先敏捷再規範
先敏捷再規範，先做到再寫到，先短期利益再長遠利益，先實效再完備。這個策略源於實踐。因為一步到位直接採用規範的方法，阻力比較大，效果難以持久，很可能事倍功半，敏捷方法以其短期內可以見效 對已有的開發過程調整幅度小等特點易於開發人員接受，所以可以先敏捷再規範，將敏捷作為通向規範的乙個階段。芸芸眾生，大都...
遞迴再理解
其實關於遞迴，我也是比較模糊的，至今能理解和能用的遞迴演算法，基本是靠記憶和經驗，要是讓我自己設計乙個遞迴，估計又得難半天，很早都想總結一下，喜歡瀏覽技術網 站，總是能找到好東西，現在將遞迴演算法總結如下，也不是多麼深刻，多麼高大上，可以說還是拙見吧 定義遞迴演算法 基本思想 那麼什麼是遞迴演算法呢...