“所以，我想向您介紹一下敏捷和Scrum。”
“在 21 世紀初，人們對編程的看法發生了天翻地覆的變化。”
“每個人都相信長期計劃行不通，所以他們決定完全放棄它。”
“他們是怎麼做到的？”
“就是這樣。”
“他們發明了最靈活的項目管理方法。”
以下是敏捷開發背後的主要思想："
- 人員和溝通比流程和工具更重要；
- 工作產品比詳盡的文檔更重要；
- 與客戶合作比滿足合同條款更重要；
- 願意改變比堅持原計劃更重要。
以下是快速開發的原則：
- 通過儘早和持續地提供有價值的軟件來滿足客戶；
- 即使在開發結束時也歡迎需求的變化（這可以提高最終產品的競爭力）；
- 經常交付工作軟件（每月或每週或更頻繁）；
- 在整個項目期間密切客戶和開發人員之間的日常溝通；
- 該項目由積極進取的個人開展，他們獲得了必要的工作條件、支持和信任；
- 交流信息的首選方法是個人（面對面）交談；
- 可工作的軟件是衡量進步的最佳標準；
- 贊助商、開發人員和用戶應該能夠無限期地保持恆定的步伐；
- 不斷專注於提高技術卓越性和用戶友好的設計；
- 簡單是不做多餘工作的藝術；
- 最好的技術需求、設計和架構來自一個自組織的團隊；
- 不斷適應不斷變化的環境。
“軟件開發的主要問題是，在任何階段，參與者都沒有關於要做什麼的完整信息。”
“客戶可以告訴你他對這個項目的設想，但他會漏掉一些東西或者認為有些東西是理所當然的。”
“經理通常必須將需求從編程術語翻譯成客戶的語言，然後再翻譯回來。”
“有太多的不確定性。”
“通常客戶的要求是這樣的：以某種方式做，然後給我看——如果我不喜歡，你可以重做。”
“呃……太糟糕了。”
“根據新範式，程序員不再開發產品或程序。相反，他們正在實施客戶需要的功能。”
“有什麼不同？”
“好吧，假設程序開發過去需要一年時間。六個月後才能看到任何東西。這就像蓋一座大房子：首先，你為地基挖一個坑，然後澆築地基，建造牆壁、屋頂、裝飾等。”
“但現在程序員試圖盡快發布所需的功能。這就像先蓋小屋，然後是移動房屋，然後是小房子，然後才是大房子——分期付款。”
“考慮到客戶可能並不完全知道他想要什麼，那麼這是一種非常合理的做法。”
“假設顧客想要一個大的狩獵小屋。”
“開發商為他蓋了一個小房子。他在裡面住了一個冬天。然後他決定不喜歡木頭房子。讓我們用磚頭蓋一個吧。”
“他在湖邊住了一個夏天，但蚊子把他活活吃掉了。他聽說哪裡有湖很涼爽，所以他很想擁有一個。但現在他不想要一個湖。而且它會更容易建造房子是這樣的：沒有湖就沒有洪水的威脅，你可以在地面上而不是在高蹺上建造房子，這樣會快 25%。”
“一個有趣的類比。客戶真的經常改變他們的要求嗎？”
“是的，但問題不在於客戶。”
“首先，很難想像未來會怎樣。管理人員、測試人員和程序員都會這樣做。他們也會根據事情的發展情況改變想法。”
“其次，客戶的需求不是最重要的嗎？ 畢竟這一切工作的重點是創造客戶需要的東西，而不是他最初說要創造的東西。”
“確實，它曾經是這樣工作的：業務分析師會列出所有需求。他們會將此列表包含在合同中，然後簽署合同，然後僅根據列表進行工作。”
“如果清單遺漏了客戶真正需要但忘記的東西，沒有人會對此採取任何措施。”
“原來如此，有計劃更容易，但不是所有事情都可以按計劃去做！”
“確切地。”
“這就是發明敏捷開發方法的原因。”
“今天我將向您介紹Scrum——其中最流行的一種。
“Scrum 的主要特徵是將項目開發劃分為小迭代——通常持續 2-4 週。每次迭代稱為衝刺。”
“在衝刺開始時，召開衝刺計劃會議，持續3-4小時。”
“最後，有一個所有完全完成的任務的演示。”
“以下是一切通常的運作方式：”
“在第一次沖刺之前，客戶（或客戶代表）形成了一個需求列表，即程序應該能夠完成的一組事情。這些需求通常稱為用戶故事，而客戶通常是叫產品負責人。”
“他被稱為產品負責人，因為產品是為他編寫的。他，而且只有他，定義了需求列表——什麼、什麼時候、以什麼順序。”
“另外，產品負責人通常會分配任務優先級。優先級最高的任務將首先執行。整個需求列表也稱為產品待辦事項列表。”
“當衝刺開始時，每個人都聚在一起開會。scrum master通常是團隊成員，通常會主持會議。會議的目標是為當前衝刺（開發迭代）選擇任務（用戶故事）。 “
“首先，團隊為每個任務分配一個粗略的估計，以抽象的人日為單位，也稱為故事點。 然後團隊決定他們在衝刺期間有多少任務要完成。”
“同樣，是團隊自己決定他們在衝刺期間將有多少時間完成任務。”
“假設產品負責人希望團隊選擇前 7 個任務，但它只選擇了 5 個，然後任務 6 和 7 被推遲到下一個 sprint。如果這不適合產品負責人，他可以提高任務的優先級6 和 7 以確保它們被選中，但其他一些任務將從衝刺中退出。”
“ scrum master還可以提議將一些任務分解成更小的任務，並為它們設置不同的優先級，盡可能讓產品負責人開心。”
“這就是會議的重點：任務可以改變和拆分，優先級可以改變等等。這是一開始不可見的工作，但帶來了很多價值。”
“明白了，就像開車一樣，即使你一開始以為直走就行了，但事實是，你需要不斷地避開坑洼，左轉右轉，超越別人或者讓別人超越你。”
“是啊，類似的東西。”
“為 sprint 選擇的任務列表稱為sprint backlog。”
“程序員決定誰做什麼，然後他們才開始工作。”為了提高效率，Scrum 建議每天召開 5-15 分鐘的會議，每個人都可以互相告訴對方他們昨天做了什麼以及他們在做什麼今天打算做。”
“團隊合作。我可以尊重這一點！”
“為了使事情更容易可視化，通常建議在特殊板上顯示當前的衝刺狀態：”
“注意左邊的三列。”
“縮寫的任務名稱寫在便利貼上。便利貼根據其狀態（計劃、進行中、完成）放置在不同的列中。”
“在右側，您可以看到一個燃盡圖。對於每一天，該圖表都會列出仍未完成的任務。理想情況下，未完成任務的數量在衝刺期間降至零。”
“當 sprint 結束時，scrum-master會給出一個演示，展示所有已經完成的事情的清單。”
“然後他召開了一個 sprint回顧會議，這也持續了幾個小時。在這次會議期間，與會者通常試圖弄清楚哪些事情進展順利，哪些事情（以及如何）可以做得更好。”
“通常在 2-3 次沖刺之後，您可以識別並消除阻礙團隊更高效工作的主要問題。這可以在不增加團隊工作量的情況下提高生產力。這在敏捷方法論時代之前是不可能的 。 ”
“有時在衝刺期間也會召開梳理會議。其目的是計劃下一個衝刺。參與者通常會在這次會議上明確任務優先級。他們還可以將一些任務拆分成多個部分和/或將新任務添加到產品待辦事項列表中。 ”
“好吧，這基本上是我所有的。這只是一個概述。不可能用幾句話來解釋所有的事情，但你可以在這裡閱讀一篇關於這個主題的好文章：”
GO TO FULL VERSION