敏捷 vs 偽敏捷(2)

　　欣然面對需求變化，即使在開發后期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。

　　敏捷偽敏捷擁抱變化，被看作為項目提交的積極部分。寧愿改變也不愿提交錯誤的東西。持續變更的請求成為計劃糟糕、需求分析糟糕或者設計糟糕的媒介。變更通過任務列表(Backlog)的流程管理，以確保所有變更都是可控的。不會積壓!變更缺乏管理，并影響時間表，交付時間，或者打破團隊工作生活的平衡。變更范圍是為了滿足客戶的經營目標。變更常常因為技術部門差勁表現導致的。原則3：交付更短，收獲更多

　　經常地交付可工作的軟件，相隔幾星期或一兩個月，傾向于采取較短的周期。

　　敏捷偽敏捷致力于分解大系統到更小的可部署可工作的組件特性。致力于發布2周內能完成東西。沖刺(Sprints)的長度能確保一個或者多個完整的用戶故事能被交付開發活動被時間盒(timebox)陷住，并努力在這個時間盒里完成。"完成"(Done-Done)的定義理解得非常透徹，組件只有在符合標準時，才會部署。"完成"是在時間盒的尾聲主觀判斷定義的。原則4：成功需要參與

　　業務人員和開發人員必須相互合作， 項目中的每一天都不例外。

　　敏捷偽敏捷業務人員和技術人員在同一個地方共同工作，并持續協作配合。各個團隊在簡短的每日會議后，又各自回到自己的項目領域。各個團隊視最終產品(交付的軟件系統)為大家共同的交付(而不僅是開發人員的責任)。開發人員主導整個過程，并自己做出決定，因為他們比其他人更知道該完成些什么。沖刺(Sprint)中發現的問題(Issues)會被利益相關者(stakeholders)快速地解決。問題(Issues)會被推遲到任務列表(Backlog)，因為交付至上。每一天都一起工作，以此利益相關者(stakeholders)對解決方案和更優的用法有著直接的了解。利益相關者(stakeholders)沒能投入他們所有時間和團隊一起，他們只在危急時出現并常在此時調整方向。原則5：授權給“合適的”的員工

　　激發個體的斗志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。

　　敏捷偽敏捷成熟的、經驗豐富的員工，能利用這些經驗做出杰出的事情。員工由強有力的領導結構驅使，確保在沖刺(Sprint)的時間表內完成任務。團隊成員由自我管理和自我確立目標而受到激發。團隊成員被強勢的組織結構驅動。團隊成員確立沖刺(Sprint)的大小和范圍，并為質量和完整性而調整其大小。領導確立任務列表(Backlog)的工作量，員工被要求按時完成。分心事宜(Distractions)，例如會議，被面對面的協作配合取代。分心事宜(Distractions)，例如狀態會議，將是必須的，以便“控制”工作任務的完成。嫻熟的角色(Skilled roles)促進確保完全的“我們都在這里一起”的環境。關鍵的角色(如，QA和BA)被“超級”開發人員取代，因為他們能做所有的事情。原則6：協作不只是坐一起

　　不論團隊內外，傳遞信息效果最好效率也最高的方式是面對面的交談。

　　敏捷偽敏捷團隊成員坐在一起，不是把團隊從組織中隔離出來，而是為了更高效的協作。不是所有團隊成員都坐在一起。面對面交流能迅速地分享信息，但這并不能完全拋棄文檔。鼓勵團隊成員所有的工作都通過口頭溝通，并不要浪費時間在文檔上。各個團隊對產品交付的所有方面都負有責任，像一個團隊般一起工作，以確保質量。各個團隊常常在一塊工作，但是對交付產品的質量幾乎沒有責任感。避免電子郵件成為主要交流溝通工具。認為電子郵件是令人滿意的文檔工具。原則7：質量很關鍵

　　可工作的軟件是進度的首要度量標準。

　　敏捷偽敏捷"完成"(Done-Done)的定義理解得非常透徹，組件只有在符合標準時，才會部署。進度是通過沖刺(Sprint)的完成情況和時間來衡量的。質量勝過進度，團隊和領導對其的態度是言行如一的。進度勝過質量，成為潛規則。如果軟件不能工作，那么就不交付它。交付和修復是開發過程中的一個策略。原則8：不是死亡之旅(Not a Death March)

　　敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。

　　敏捷偽敏捷標準和流程，不是限制團隊，而是使其加速和創新?？蚣苁亲杂伸`活的。流程是穩定的。標準和流程，不是過于官僚和限制，就是在解除團隊限制時被完全精簡掉了。項目過程像馬拉松，由很多較小的沖刺(Sprint)組成。避免贏了沖刺，輸了比賽。人員保持新鮮感。團隊努力完成時間盒里的工作量。延長工作時間，周末加班成為常態。人員被視為商品(commodities)。原則9：技術很關鍵

　　堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。

　　敏捷偽敏捷標準和流程并不官僚，反而能保持一致和加速開發。流程被拋棄、被“即興(ad hoc)”的項目執行取代以追求更快的速度。失敗更快。避免為了流程而流程。流程必須有其價值!沒有任何流程。文檔的請求會受到溫和的批評，除非有價值、風險和回報的評估分析?；乇苋魏挝臋n請求。“敏捷不是反方法論的運動;事實上，我們大多數人希望恢復方法論這個詞的可靠性(want to restore credibility to the word methodology)。 我們希望恢復到一個平衡。我們崇尚建立模型，并不是為了把這些文件圖表放置公司布滿灰塵的倉庫里。我們擁抱文檔，但不是幾百頁的、從不維護更新、極少使用到的大部頭文檔。 我們做計劃，同時也知道計劃在混亂環境中的局限。”

　　Jim Highsmith, 敏捷聯盟原則10：簡潔 = 穩定 & 速度

　　以簡潔為本，它是極力減少不必要工作量的藝術。

　　敏捷偽敏捷致力于尋找最簡單且質量足夠的方式滿足業務需要。致力于尋找最快速、最少編碼的方式滿足業務需要。足夠簡單有效的流程，被視為戰勝拖拉，加快持續交付的法寶。精簡流程步驟，比如，測試。經常認為是為交付而簡化。任務列表(Backlog)成為守門員，對所有任務排上優先級再處理。工作量常常變化，因為優先級發生變化顛倒，十分混亂。原則11：讓團隊閃耀吧

　　最好的架構、需求和設計出自自組織團隊。

　　敏捷偽敏捷允許團隊犯錯誤，提出他們的解決方案，交付產品，經常評估(回顧)，并從他們的成功(和錯誤)中學習。錯誤導致項目領導和被視為項目按時完成的詆毀者之間對峙。時間都浪費在“責備的游戲(blame game)”。鼓勵團隊一起工作，并讓他們有權作出決定(界線模糊)。每個人都朝著同一個目標努力。一起工作但傳統界線(如BA，QA，DEV)仍在。沒有共同的目標，每個人看到自己不同的“工作”。做出最好的決定的那個人，是最接近這一決定的原因和影響的那個人。領導堅持復查和調整計劃，以滿足“政治”的時間表，而不是信任那些最接近實際工作的人。原則12：回顧并向前

原文轉自：http://blog.csdn.net/ocean1ee/article/details/8873688