敏捷項目管理的終極介紹

簡要

您負責提供公司最新、最偉大的計劃，這將永遠改變“Widgets International”的面貌。 這是一個軟件項目，它將吸引和吸引您的客戶，讓您的同事的生活更輕鬆，並使公司獲得數百萬美元的收入。 有很多期待，熱情，興奮和期待。 您需要盡快完成它，這樣您的企業才能開始獲得收益。 公司未來的成功取決於你。 所有的目光都集中在你身上。 你不能失敗。

起初，你在想，“太棒了，我已經準備好迎接挑戰了。 讓我們把這件事做好！” 你停頓片刻，退後一步，對自己說：“好吧，那我們怎麼做呢？” 您開始與您的同事和同行交談。 您花時間尋找最佳實踐軟件開發和項目管理技術，但選項和方法是無數的。 有很多首字母縮略詞和方法。 著名的上升到頂部。 懷疑蔓延。我們應該使用哪一個？ 如何保證成功？ 如果我做出錯誤的決定怎麼辦？

在管理軟件項目時，有無數意見支持的選項組合令人興奮。 房間角落里傳來的聲音在低語：“試試這個方法”； 其他人大喊：“這是唯一的方法”； 其餘的只是嗚咽，“根本不要管理它，繼續它。” 實際上，所有這些聲音都說了一些實話。 但重要的是找出適合您的需求、您的團隊、您的業務和您的客戶的方法。

設置場景

曾經有一段時間，軟件項目管理完全屬於三個陣營之一。 有一些繁重的框架可以讓你決定如何執行和交付，同時提供一個結構來維持控制和治理。 有像瀑布這樣的規定性順序方法，迫使您計劃冗長的項目，理解並滿足您的所有需求，設計和簽署複雜的系統，編寫大量代碼，然後進行測試（所有這些都在您的客戶第一次看到它之前）時間）。 最後，較少規範但迭代的軟件開發生命週期 (SDLC) 鼓勵快速原型設計或更大的系統以增量步驟進行設計、構建和交付，每個構建在另一個之上。

敏捷軟件開發和敏捷項目管理源於瀑布的不足和軟件交付迭代方法的好處。 他們可以追溯到 1950 年代、70 年代的思想領導力、90 年代的成熟以及 00 年代的採用。 2001 年，一群從業者和專家創建了敏捷宣言，旨在定義 4 種價值觀和 12 條指導原則，旨在體現敏捷軟件開發的精神並鼓勵其發展。 它肯定已經進化了。

現在，簡單地調用敏捷並不是特別有用。 這個詞，即使在軟件環境中，對不同的人或組織也有不同的含義。 有許多方面、定義、實現和解釋。 每個擁抱敏捷的機構都傾向於嘗試給它自己的定義。

可以這麼說，敏捷軟件開發和項目管理是一組相關的行為、框架、技術和概念，它們從根本上支持盡可能早且盡可能頻繁地交付正確的工作軟件。

我之前提到過，應用於軟件開發或項目管理的敏捷可以是不同的東西。 簡而言之，敏捷軟件開發負責在照常業務 (BAU) 或項目環境中開發出色的軟件。 另一方面，敏捷項目管理負責交付複雜項目（包括但不限於軟件）所需的治理和控制。

有許多可用的敏捷軟件開發方法，例如 Scrum、看板、XP 和精益軟件開發。 但正如橄欖球比賽不僅僅是 Scrum 一樣，敏捷也是如此。 孤立地看，這些敏捷範式並沒有解決複雜項目中所需的項目管理的整個生命週期，例如治理、資源、財務、顯式風險管理和許多其他重要的項目管理概念。 對於這些，您可能需要考慮 PMI 敏捷或 PRINCE2 敏捷——將其視為“治理敏捷”。

為什麼我們需要敏捷？

很久以前，我們在這片土地上漫遊以收集食物和住所以求生存。 它們是簡單的需求，但非常靈活。 一段時間後，國家和經濟體在工業革命的支持下發展壯大。 這就是管控的誕生和敏捷性的喪失。 現在我們處於信息時代或革命，企業僱傭知識工作者。 知識工作者是您、您的合作夥伴以及您的同事和同行，他們努力為客戶、商業、社會、經濟和世界問題創造出色的解決方案。 知識工作者將分析、知識、推理、理解、專業知識和技能應用於通常定義鬆散且不斷變化的需求。 這些企業和工人需要舊工業時代流程和程序無法滿足的方法和技術。 敏捷支持交互。

幾乎沒有一個軟件項目可以自信地從一開始就開始並了解它所需要的一切，以便在不改變的情況下交付有價值的工作軟件。 變革為項目的成功帶來機遇和風險。 不受管理的機會可能意味著一家偉大的公司和一家很棒的公司之間的區別。 不受管理的風險意味著災難和毀滅。 敏捷管理變革。

採用敏捷可以讓您響應不斷變化的或新的需求。 它使開發團隊成為專家，並在參與、信任和知情的業務支持下做出決策。 它使您能夠向客戶提供他們真正想要的東西。 最終，它使您和您的組織能夠控制交付高質量、有價值的軟件，從而滿足客戶的需求和期望，同時儘早獲得投資回報。 敏捷創造價值。

採用敏捷是有代價的。 它不是免費的。 轉變為軟件交付的敏捷方法可能是一條艱難的道路。 但是，如果您將敏捷哲學內化，謹慎行事，以正確的態度與正確的團隊合作，分解事情，使其可實現和現實，並響應反饋，您將獲得回報。 敏捷強調協作。

以下列出了您可以期待的一些好處：

• 上市速度
• 較早的創收
• 定期交付實際價值
• 保護您的投資
• 數據，數據，數據
• 更好的產品質量
• 可管理的期望
• 更高的客戶滿意度
• 更高績效的團隊
• 提高進度可見性
• 可預測性、透明度和信心
• 可控風險

成功不是最終的，失敗也不是致命的：重要的是繼續前進的勇氣。

溫斯頓丘吉爾可能從未真正說過這句話，但我認為這是對敏捷的一個很好的總結。 我們知道敏捷是大多數項目的最佳選擇。 它鼓勵您為成功而奮鬥，但我們始終在迭代並不斷發展。 敏捷會鼓勵你失敗，但儘早失敗並繼續前進。 有勇氣繼續並根據客戶提供的洞察力構建正確的解決方案是帶來回報的原因。

要記住的是，您可以根據自己的需求定制敏捷。 使用適合您業務的方法和治理。 無論你從哪裡開始，都要忠於所用方法的內容、背景和精神——保持原樣。 如果您剛剛開始，請學習. 如果您已經這樣做了一段時間，請理解。 如果你變得很棒，請申請。 最後，如果您的業務和項目複雜且相互依賴，請治理. 隨著時間的推移，您和您的團隊將找出最適合您的業務的方法。

可行性

所以現在你在想，“好吧，我明白了。 我該如何開始？ 我從哪裡開始？” 好吧，有了所有美好的事物，我們從頭開始。 使用敏捷，就是問自己“我想提供什麼商業價值？” 畢竟，這就是我們開展項目以產生商業價值的原因。 為了確定該項目是否值得進行以獲得商業價值，您需要了解它是否可行。

想像

您的項目是否預計會增加收入、進入新市場、獲得更多客戶、提高客戶認知度或讓您發現的特定問題變得更輕鬆？ 考慮到這一點，您可以陳述您的“願景”。

• 你的願景可能來自不同的來源——你自己的大膽創業來解決一個常見問題、業務管理策略、你的 CEO 的寵物項目、特定的產品團隊，甚至你的客戶的需求。
• 試著從你自己的鞋子中退後一步，“看看”你的新產品或服務在你的客戶手中的未來會是什麼樣子。
• 讓您的利益相關者——CEO、產品人員和客戶參與進來。 討論它，不要孤立地嘗試。 挑戰假設並驗證論點。
• 寫下來，保持簡短。 專注於商業價值。
• 完善它，直到你們都同意該願景與每個人產生共鳴，並符合說明您前進方向的共同解釋。
• 你的願景，如果有效的話，很少改變。 你如何到達那里肯定會。

人們不會買你做什麼，或者你怎麼做。 他們購買“為什麼”你這樣做。 這就是在您的企業和客戶之間建立情感聯繫的原因。 願景將有助於說明這一點。

可行嗎？

可行性至少有幾個方面。 通常，您會想了解您對企業和客戶更美好未來的願景在技術上是否可行，並且對您的企業來說是否可行。

• 如果您的願景是在一小時內到達世界任何地方，您可能會遇到技術可行性問題。 由於科學、物理和技術還沒有完全趕上這個夢想，你的技術解決方案可能在理論上不可行。 此外，如果您的解決方案是新的，這將遠遠超出最小可行產品 (MVP) 的想法。

• 要測試您的產品的技術可行性，請考慮在 Discovery 原型項目中進一步探索它，或者在項目的早期階段運行一個峰值。 通過考慮您所考慮的解決方案的規模或複雜性，您將知道使用哪種方法。

  “我的團隊在理解技術可行性方面獲得的一些最佳知識來自執行峰值。 通常，最簡單的解決方案會勝出！”

• 要考慮的第二種可行性是您、您的團隊或您的企業是否具有使其發揮作用的技能和動力。 舉個例子，如果你很擅長在家里為你的孩子做生日蛋糕，那就太好了。 但是，如果您想將其轉變為向世界銷售最好的蛋糕的企業，您需要了解您是否可以使其規模化、處理業務和生產、管理分銷和履行以及照顧客戶服務。
• 從長遠來看，這種願景可能是可以實現的。 但就目前而言，可能不會。 因此，縮小規模，從小處著眼，取一小塊看起來很現實的東西，並專注於實現盡可能小的願望。 如果這設法吸引並取悅您的客戶，讓他們回來更多並告訴他們的朋友，然後使用您的客戶反饋作為您的指南和指南針從那裡擴大規模。
• 此外，您需要知道您的項目在預算和時間框架方面是否可行。 您的企業能否負擔得起這個項目？ 時間表是否可以實現？ 時間和金錢是敏捷項目中固定的三個約束中的兩個。 我們的目標是在給定的固定時間和給定的固定預算內交付。
• 產品的質量是指您的客戶使用的最終產品以及您的團隊用來交付出色、強大和可靠軟件的工程實踐。 質量也是我們不會改變的東西。 另一方面，質量標準可以改變。 如果您不打算製造法拉利，則該產品可能沒有高質量的感知。 如果您不製造太空火箭，那麼在生產方面達到的公差可能要高得多。 儘早設定適當的基調和期望。

所以現在你已經確認你的夢想不僅僅是巧克力幻想，開始測試你的假設並向人們證明這項努力是值得投資的。

理由

現在，根據你的情況，稱義將以不同的形式出現。 但本質上，您想證明該項目將滿足客戶成功標準，有成功的機會，將提供價值，並且是負擔得起的。

• 根據您的客戶需求陳述您的假設，然後驗證它們。 精益創業為識別和證明客戶需要您的產品並將創造價值提供了很好的指導。

• 編寫、測試和驗證您的商業計劃。 現在這看起來不像你的銀行或你的商業和金融專業告訴你生產的那些。 不要使用它們——在墨水乾之前它們就會過時。 相反，請查看商業模式畫布。 這本質上是一個簡短的商業計劃，讓您專注於您的價值主張、客戶、收入和成本。 使用它來驗證您是否有可以運作的業務。

  “我曾經忽略了這個建議，並花了很長時間編寫一份冗長的傳統 50 頁商業計劃。 它讓我無處可去。 我所做的所有假設都是沒有根據的，我所做的所有預測都無法驗證。 這是一次痛苦而昂貴的經歷，教會我再也不要這樣做了。”

• 如果您從事成熟的業務，並且在復雜環境中交付項目組合，那麼財務建模可能是必要的。 如果必須，請僅在您證明了上述內容後才執行此操作。
• 一旦你建立了你的 MVP，就有可能創建一個更傳統的商業計劃——例如，如果你必須在公司的競爭項目和資源組合中尋求資金或選擇。 但這將是一個基於上述工具並由上述工具提供信息的商業計劃。 也會輕一些。
• 在任何情況下，將這些工具用作活生生的、會呼吸的人工製品。 將它們用作您的指南和領頭羊。 它們從來都不是靜態的。 隨著您的項目或業務的發展，參考並修改它們。

一旦你有你的理由並且你所有的利益相關者都在船上，你就會著火了。

可行性階段通常在項目的生命週期中執行一次。 您可能會發現您重新審視了項目的願景和可行性，尤其是在您的數據、客戶、市場或業務表明如此的情況下。 至少，它們將成為您的指路明燈。

引發

驚人的。 決定已經做出，項目獲得了綠燈，您可以開始構建了。 嗯，差不多。 我知道你在想，“來吧，真的嗎？ 如果我們現在不這樣做，我們永遠不會這樣做。 讓我們在路上看到這個節目！” 但請考慮這一點——如果不是儘早交付價值，並且經常在此過程中取悅您的客戶，那麼敏捷就毫無意義。 花一些時間找出交付項目的最佳方式是成功的最佳基礎。

團隊

在體育運動中，通過思考您最喜歡的團隊遊戲，您將能夠識別出使團隊能夠發揮作用的關鍵角色。 傳統上，你會找到一名經理、一名隊長和球隊的其他成員。 除此之外，您還可以找到教練、理療師、營養師和各種支持人員。 但如果我們看看橄欖球比賽，就會發現球隊中的球隊：組成 scrum 的球員。 這個包由指定的球員組成，他們的工作是贏回球並繼續比賽。 當 scrum 進行時，雙方的球員在沒有領導的情況下作為一個單一的單位盡可能協作、溝通和高效地工作，以使球重新獲得控制權。 正是橄欖球比賽激發了 Jeff Sutherland 將他的軟件開發方法論命名為“Scrum”。

• Scrum 並不是敏捷劇本中唯一的軟件開發方法。 但它最能描述敏捷概念和團隊工作、激勵個人、建立信任關係、自組織、僕人式領導、溝通、透明度和協作的行為。
• 您的團隊將主要由您所處的環境組成。您可能有開發人員可供您使用。 有些人、沒有人或全部人可能在不同程度上熟悉敏捷。 您可能想聘請新團隊或與第三方合作。
• 其他角色也將是必需的，但我們稍後會討論這些角色。
• 有人說，如果你組建了你的開發團隊，那麼你就選擇了你的技術。 根據您將團隊從何處聚集在一起，他們將具有特定的技能組合。 因此，請仔細考慮您如何組建您的開發團隊，以及您是否需要在您的旅程到達這一點之前進行技術評估。
• 這將我們帶到了跨職能團隊。 當團隊一起工作時，當個人投入以完成工作而不管他們的頭銜如何時，他們的工作效果最好。 嘗試建立一個自給自足的團隊和承擔多個角色的個人。
• 建立一個環境、文化和關係中心——一個團隊可以交付、不受約束或限制的地方。 為團隊提供有效和高效的工具、人員、資源和空間。
• 保持團隊規模不超過七八個人。 如果您需要更多開發人員，請將團隊拆分為多個新團隊。 然後，每個團隊可能負責給定的職能領域。 如果您在多個地點有多個團隊，請考慮舉行 Scrum of Scrums。 如果在復雜環境中這些問題很多，請使用敏捷項目管理。
• 確保團隊、業務、利益相關者甚至客戶可以相互訪問。 確保他們進行溝通和協作，並消除任何阻礙進展的東西。 日常溝通是治療項目病痛的最好方法。 當人們說話時，他們會做事。

可以通過多種方式組建團隊來交付軟件。

項目簡介

在可行性步驟中，您找出了您的項目的“原因”，並建立了與您的創業公司一起前進的信心，或者獲得了繼續進行的支持。 項目簡介是將“為什麼”與“什麼”、“何時”和“誰”結合在一起的活文檔。 它是“活的”，因為隨著你的進步，你的知識、理解和道路可能會發生變化。 把這份文件寫完就離開，再也不回來，只是把你的想法寄託在一個時間點上。 在敏捷世界中，您的時間點參考可能會在早期每週甚至每天都發生變化，因此保持最新很重要。

• Jonathan Rasmusson 在他的《敏捷武士》一書中將其稱為“初始甲板”，這是封裝和維護項目簡介的一個很好的工具。 在這裡，您會找到很好的建議，以確保對您的項目感興趣、受其影響或參與的每個人都在同一頁面上。
• 交付項目的最大敵人是對項目是什麼以及要滿足哪些“要求”有一個不清楚、不一致或只是完全不同的理解。 如果即使是一個重要的利益相關者對你正在做的事情有不同的理解或看法，後果可能是巨大的。
• 一個好的項目簡介可以傳達：
  1. 利益相關者和團隊成員之間達成共識的共同期望。
  2. 對項目的理解，各方的理解一致。
  3. 目標、願景、目的、範圍和項目背景。
• 您將從可行性中收集到很多有用的信息。 項目簡介將幫助您定義和找到搜索問題的答案。 它將把利益相關者、你存在的理由、高層次的範圍、風險、目標解決方案、預算、時間表、期望和優先事項匯集在一起。

有一次，一位同事在走廊裡攔住了我，問我在哪裡可以獲得項目的項目簡介。 我打趣道：“我們不需要簡報，我們很敏捷”。 他看起來很困惑，好像他在質疑我的理智或權威。 他這樣做是對的。

在你繼續之前，確保你讓每個人都在同一個頁面上，討論它，提出困難的問題，然後把它釘在人們可以停下來、閱讀、評論和幫助修改它的地方。

文化和工作方式

您了解您的業務運作方式及其文化，以及牠喜歡完成工作的方式。 就其本質而言，敏捷可能會挑戰您的企業多年來培養的一些工作方式。 不要期望敏捷會被實施，並且每個人都會從一開始就熱情地採用它。 有些人可能會感到困惑，只帶著恐懼和恐懼看待它。 有些人可能會公開拒絕參與其中。 這些是您必須克服的挑戰和看法。 但是在你早期，不要到處揮動敏捷棒毆打任何不聽它的人。 這不會建立信任、採用或參與。

我曾經喜歡揮動眾所周知的大棒，這為我贏得了很多負面新聞。 我把它轉過來，但不是在先遭受相當大的痛苦之前。

當您踏上收養之路時，請謹慎、尊重和同情。 如果您從事的是陳舊的傳統業務，那麼這可能不是讓整個業務保持一致的最佳方法。 從小處著手，逐步贏得尊重和認可。 僅從您的團隊開始。 一旦您開始以比以往更好的質量交付更快的軟件，人們就會開始注意到並願意來玩您的遊戲。 當他們這樣做時，給他們球，帶他們出去喝杯咖啡，然後讓他們輕鬆進入你的新世界。 幫助他們。

與您的團隊一起，既然他們知道項目是關於什麼的，並且您的敏捷採用計劃已達成一致，那麼讓團隊決定他們希望如何作為一個團隊行事和運作。

• 指導您的團隊確定您認為適合您的集體需求的敏捷概念、技術、行為和框架。
• 接受團隊成員的請求，了解他們必須滿足哪些要求才能幫助他們盡其所能。 其中一些請求，您將能夠立即解決。 其他人，您可能需要獲得預算或外部幫助。 盡你所能去實現它。
• 這些是您成為真正的僕人式領導者的第一步。
• 考慮針對您的團隊選擇採用的概念和技術組織一些適當的培訓。 這是確保您的所有團隊成員，甚至是利益相關者，都在同一頁面上並獲得相同信息的最佳方式。 與可以根據您的需求定制產品的供應商組織合作。
• 要謹慎。 在研討會上學習如何成為敏捷之後，沒有人會成為敏捷忍者。 你的路會很長。 “成為”這個詞非常明確。 只有當你真正擁抱敏捷時，你才會看到它的價值。 它應該讓你興奮。 如果它讓你興奮，那麼也讓其他人興奮。
• 現在您的團隊已經就概念和技術達成一致，實現了他們的願望，並且正在接受敏捷培訓，請將您的團隊的注意力轉移到他們自己以及他們對您、業務和彼此的期望上。
• 定義團隊內部和團隊內部的一些工作方式 (WoW) 有助於建立信任、關係和期望。 魔獸世界沒有戰爭與和平。 它應該簡短而中肯，在七到十個重點句子之間。 這些句子清楚地說明了人們如何一起行動、交流、協作、支持、交付和執行。 它還應該說明團隊對業務的期望。

• 敏捷既是一種思維方式，也是指導原則和概念。 它可以幫助您在行為、思考、談判、互動、溝通、執行和改進的方式上發展。 它依賴於有動力的個人相互支持以實現共同目標，作為一個整體。 有一句非洲諺語：

到現在為止，你的團隊應該非常興奮、充滿活力和動力。 現在，通過您積壓的用戶故事進一步吸引他們。

積壓

毫無疑問，您的項目中存在不確定性。 您不可能在客戶生命的早期就確切知道如何為客戶構建合適的產品。 你不能若有所思地凝視水晶球並預測未來。

“待辦事項”或“產品待辦事項”是您的需求所在。 敏捷傾向於編寫能夠抓住“需求”本質的簡短、精練的陳述。 待辦事項只是一長串條目，每個條目定義一個單獨的、離散的“需求”作為用戶故事。 從現在開始，我們將使用用戶故事這個詞，而不是“需求”。 你可能會問“為什麼？” 這是個好問題。 對於似乎永遠存在的情況，說明客戶在軟件項目中所需的功能或方面一直被稱為需求。 這個詞有一個在敏捷中沒有價值的解釋。 牛津詞典將其定義為：

需要或想要的東西。 或者，一件強制性的事情； 一個必要條件。

不幸的是，如果我們開始定義我們的解決方案應該是什麼，並聲明事情是“強制性的”，我們最終會遇到麻煩。 說所有這些用戶故事都是強制性的太容易了。 如果我們採取這種觀點，我們就會冒著超出計劃和超出預算的風險來嘗試交付給定範圍的所有內容。 可以說，對於這個產品來說，這些故事是解決方案可行所必需的，我們只是想避免對那個特定詞的解釋。

• 始終從角色的角度寫故事。 角色代表解決方案的用戶或利益相關者。 在開始積壓之前開發這些角色是個好主意。
• 在這個階段，只寫簡短的陳述，基本上建議在適當的時候就用戶故事進行更深入的對話。
• 真實的人會根據他們為實現目標而需要完成的任務來思考。 從角色的角度和他們需要完成的內容來寫你的故事。
• 你不需要寫完整的待辦事項——只要寫盡可能多的東西，你的客戶將需要你的產品是可行的。
• 您會在產品的生命週期中發現用戶故事會發生變化，或多或少變得重要，或者可以完全刪除。 經常發布、獲得反饋和評估優先級將告知這種行為。
• 不要孤立地寫故事。 讓您的團隊、利益相關者甚至您的客戶參與進來。 故事可以在項目的生命週期中隨時更新，但應避免在開發工作開始後對其進行更改。
• 你的一些故事可能被認為是“史詩”。 這些是涵蓋很多內容的大型故事，並且將在接近交付時間時分解為較小的故事。
• 考慮使用 INVEST 模型，這是一個用於驗證良好用戶故事質量的清單。
• 任何人都可以在待辦事項中添加故事。 它應該放置在底部，或專門創建的“停車場”中。 這個添加的故事可以作為與團隊和業務討論的提示。 如果業務和團隊支持它，則可以對其進行估計和優先排序
• 您還可以考慮系統中風險最大的部分。 如果您有一個複雜、新或技術未知的用戶故事或功能，請將這些優先放在您的待辦事項列表的頂部。 這樣，您就不會在首次發布前幾週嘗試交付產品中具有挑戰性和關鍵的部分。

一旦你有一個滿足你需求的積壓工作，你就可以估計其中的故事，按優先級排列它們，並製定一個發布計劃。

高級估計和優先級

高級估算是調整積壓工作的過程。 項目有多“大”，它帶來了什麼價值？ 優先排序是決定哪些故事對您最重要、產品的可行性以及客戶的利益的過程。 我們希望儘早交付價值最高的物品，從而為企業帶來最大價值，從客戶那裡獲得反饋，並且不為小事出汗。 輸出將是按優先級排序並適當調整大小的有序積壓工作。

• 頂部的故事被認為是最有價值的。 我們希望儘早交付最有價值的物品。
• 大小和估算的技巧有很多，但在這一點上，您只想對故事的大小有一個良好的指示性感覺。
  • 使用 T 卹尺碼、相對尺碼、理想日子或故事點。
• 此時您也不會擁有所有可用信息，這沒關係。 跟著它跑。
• 讓您的業務利益相關者或產品經理參與（如果有的話），以及將做這項工作的團隊。
• 我們希望那些將要設計、開發和測試工作的人來確定它的規模，因為最好的評估人員是專家。
• 團隊可能會開始將故事分解成更小的部分。 如果發生這種情況，請編寫更細化但離散的故事。
• 團隊也可能開始對一些故事進行排名，因為自然有些東西必須在其他東西之前交付以支持技術或給定的用戶旅程。
• 在你和團隊之間，你也可能開始在積壓工作中發現需要填補的漏洞。 只需用新故事填補這些漏洞，並酌情估計和確定優先級。
• 使用 MoSCoW 分析最容易執行優先級排序。 MoSCoW 是一種簡單的技術，可幫助您確定哪些故事是產品成功的“必備”。
• 您可以在估算開始之前進行優先級排序。 但是，某些元素的大小也可能決定優先級和實際業務價值的決定。 因此，不要互相爭論估計和優先級，但不要爭吵！
• 沒有兩個故事可以像另一個故事一樣重要。 排名 1 的故事比排名 2 的故事更重要或更有價值。
• 展示故事的重要性或價值的一個好方法是為其添加貨幣價值。 例如，如果認為故事 A 會帶來 5000 美元的額外收入，而故事 B 可能會吸引 100 美元，那麼故事 A 更有價值。 同樣，如果故事 C 比故事 D 更能拯救企業，那麼故事 C 更有價值。
• 一旦你確定了你的積壓工作，你就會得到一個數字。 當我們進行發布計劃時，這個數字將幫助我們了解我們的團隊在給定的時間範圍內可以交付多少。

請記住，您不需要事先了解所有用戶故事。 另外，請記住，沒有必要在客戶看到您的產品之前交付您的所有故事。 You want to remain Agile—and that means only creating what you need to when you need to, wasting as little as possible, and responding to changes in customer needs and market conditions. A roadmap will help you lay out your product and plan your objectives for the next 3, 6, 9, and 12 months.

Roadmap and Storymaps

A roadmap is exactly as it sounds, it offers the same as a roadmap of a country. It details the relative position of cities (or in your case, features) to each other and the routes that can be taken to get from city A to city B, or feature X and feature Z. It doesn't tell you which route you should take, or how you should get there. It doesn't tell you which mode of transport to use, but it might illustrate options to take the highway or the train.

In a city, there are many roads, buildings, parks, services, and facilities. All features of a city. This is also true of the roadmap for your product. At this level, your roadmap shows major goals or milestones to be achieved. A goal is a logical grouping of themes, features, and user stories rolled up in a consumable view that demonstrates tangible value. The roadmap of a software product shares this view and communicates your intent. It doesn't necessarily show you how or when features will be delivered; only the relative value of the goals and features to you and your business.

One great way to demonstrate a roadmap is to generate a story map. This tool indicates customer valued prioritization. It lays out the backbone, or essential building blocks of your product. The walking skeleton hangs off the backbone and illustrates the features that make it an MVP. All the other features are what add further value and importance to the system. The story map lays features in relative position to each other and is an awesome visual tool.

It's worth noting that after carrying out a story mapping exercise, your backlog may need to be refined. This will be apparent where stories have been split into multiple stories, identified as redundant, newly created, or as a higher or lower priority than previously thought. The story map is another artifact that is continually revisited and revised.

The Initiation phase is typically performed once in the life of your project. However, many of the tools and documents you created will be revisited and revised throughout the project.

發布計劃

“At last,” I hear you cry, “finally, some planning.” Well, you have essentially been planning all through the feasibility and initiation stages; we just didn't call it as such. This is evidence of iterative or adaptive planning—the art of only planning enough to achieve your immediate and most valuable goals. We'll see later more about adaptive planning, but for now release planning is our focus.

Your release plan may well be determined by external events. Perhaps there is a trade show you want to demonstrate your app at, or your customers will get the most benefit using your app on the run-up to Christmas. These are timeline events that your goals may be aligned with. You would most likely plan to deliver user stories or features that make the most sense to facilitate these events. If there are no external dates that you need to consider, then you can just go with feature prioritization and delivering earliest what makes the most sense and delivers the most value to your customers.

• If you created a story map in initiation, this will help guide your release plan. Use it to identify your MVP, the minimum feature set that will get your product in the hands of your customers, start earning revenue, get feedback, and acquire more customers.
• The story map will help you carve out future releases too. But keep in mind that as you learn, get feedback, inspect, and adapt, future releases may change. So don't plan in great detail.
• You may have from two to four releases in a 12-month period. Don't do less, because your first release is your MVP and gets your foot in your door, after which you'll want to iterate and release more features and bug fixes in a regular cycle. Don't do more unless you're performing well and have plenty of Agile techniques and tools in place to manage continuous delivery.
• Each release is a timebox which is broken down into smaller iterations. An iteration is a timebox. The timebox is one of the most important control measures in Agile.
• To size your release:
  • Divide your release timebox by two. This will give you how many iterations you have. So if you have a release of 12 weeks, you get six two-week iterations.
  • Then remove two iterations—you'll reserve one for a “sprint 0” iteration and another for a “release” iteration. This leaves you with four development iterations.
  • Work with your team and product owner to fill each iteration with stories, starting from the top of the backlog and working down. When the team thinks they've filled an iteration with enough stories they can realistically achieve based on their capacity in the two-week timeframe, repeat for the next iteration(s). Use the release plan and story map to guide what goes into each iteration.
  • Do not plan the next release yet. You'll do that as you near the end of the current release.
  • Take the user stories from each of your iterations and add up the story sizes. So if your iteration 1 has 25 story points, but iterations 2, 3, and 4 have 10, 45, and 65 points, respectively, you will need to refactor. Target an equal number of story points in each iteration. This becomes your anticipated velocity—the amount of valuable “stuff” completed for each iteration.
• The team may not have worked together before. They are almost certainly working on a new problem or product. They will not perform at their best from day one. For this reason, your velocity may be volatile in the first few sprints. But as the team settles down, it should stabilize. Use this data to refactor your release planning which, in turn, helps you plan your product with a known velocity and confidence.
• If necessary, break stories into smaller chunks and resize.
• Your release plan, especially early in the life of a project and a new team, is only ever a guide. Do not treat it as a commitment or guarantee that all or these exact stories will get delivered as planned. As your team matures, work gets done and trust and confidence builds, so will the accuracy of your plans.
• Never force your team to “commit” to more than they are comfortable with. Trust their judgement and their expertise.
• Future release planning exercises will be simpler, because you'll take the release size, multiply the number of iterations by your team's velocity, and fill the release plan with the stories that add up to velocity multiplied by the number of iterations.

Consider this as an example. If you go to a restaurant to eat, you wouldn't go ahead and order all the items on the menu and expect to eat it all in one sitting. You'd never be able to eat it all, you might not afford the cost, you'll be sick of food, and the restaurant may close while you're eating the fifth of 19 courses! You may not leave a happy customer, the restaurant may not find you to be a great customer, and the experience will be bad all around. More likely, if you love the restaurant, it'll be because you enjoyed a lovely meal there once. You'll decide to go back and enjoy a different meal. You'll tell your friends, you'll go there often. The moral of the story is:

• Plan your releases in small chunks.
• Consider your capacity.
• Don't take on more than you can realistically achieve.
• Revisit the plan often to see what you can change and improve.
• Plan, execute, inspect, learn, adapt, repeat .

Release planning takes place often in a software project. Each new release requires a release plan. The release plan can also be refactored at any time during a project. Just take care to not overdo it and fall into zombified planning psychosis. At the end of release planning, you'll want to prepare for the first iteration, which is where we're happily going next!

Product Iterations

Your team is in place, they're motivated, you have an engaged business, your initial planning is done—you're now ready to build your dreams.

We talked earlier about some of the tools, techniques, and concepts that Agile subscribes to. There are many resources already available that do a great job at laying the foundations for delivering an Agile software project. Pick one, keep it vanilla, and grow into your Agile journey. To help shorten the trauma in deciding the right Agile software development methodology to start with, I'd recommend Scrum. And only Scrum. The temptation will be there to use elements of other methodologies. Don't do it yet. Save that kind of change until you have lived and breathed Scrum for 6 or 12 months. Then, if either you've determined it alone does not work for you or you want to mature as a team, steadily introduce new methods, techniques, or frameworks.

I choose Scrum as the recommended approach for new team's adopting Agile because it has all the basics built in. It's very popular and has many good-quality communities and resources online, in books, or in the training room. It will serve you well, even for the smallest of teams. The rest of this post is dedicated to discussing some important aspects of software delivery that you, your team, and stakeholders should always keep in mind.

Adaptive Planning

Planning in an Agile project is an ongoing process. We do some initial planning up front, just enough to understand what we know at a given point. Our initial plans will be loosely defined and flawed. And then we iterate our planning, adapting to new information, planning in greater detail just before we enter into delivery, responding to changing scope. This is one way of minimizing waste—only putting effort into planning when we need to.

• The team and the business, or its informed and authorized representative such as a product manager, actively plan together—the team because they are the experts that will deliver and the product manager because the are the experts who can guide the needs of the business.
• Estimates for user stories will be less accurate the further out they are from being developed. For example, epics will attract high-level estimates that will be based on a lot of unknowns. Well-defined and granular user stories that are estimated just before a sprint starts will be much more accurate.
• There are many estimation “scales” you can use. Use the technique that feels most right for your team and the right stage of planning—wide-band delphi, planning poker, ideal time, relative sizing, story points, or t-shirt sizes.
• When sizing a story, one size really does fit all. All stories should be sized using the same technique and encompass all elements such as design, development, testing, and refactoring. When you come to do iteration planning for a sprint, certain tasks can be created which all contribute to the completion of the story.
• Always factor risk, unknowns, outside influences, your team's capacity, and ever-improving velocity in planning.
• If user stories that were taken into a sprint were not completed, we do not extend the timebox. These unfinished or unstarted items are put back to the top of the backlog and taken into the next sprint.
• Always plan to deliver the least amount required to achieve a given goal. Identify techniques to prune features. Reduce waste and find the real value that can be realistically delivered with your time-constrained resources.

故事創作

Stories get elaborated upon when you need them. You don't need full story explanations for features that are six months away from being delivered. Writing them at the beginning may be wasted effort, when that need disappears from scope. Write your stories at most two iterations before they are needed. Reducing that timeframe to one sprint is preferable.

Let's take your time in sprint 0 to set the scene. In two weeks, you'll start development. It's now time to take enough of the stories from the top of the backlog that could potentially get delivered on sprint 1. You might take 10-15% more if you're unsure on your velocity. These one-liners can now be expanded into truly valuable documents with scenarios, acceptance criteria, and wireframes. If the wireframes haven't been created yet, now's the time to do so. You might find as you review these candidate stories that they need to be broken down. Perhaps they were epics that couldn't possibly be completed in a sprint. If you break stories down, re-estimate them with the team.

A good story follows the following rules: - Written in a common format, eg, AS A <persona> I WANT <to do some task> SO THAT <achieve some result>. - Includes acceptance criteria that the story must meet to be considered acceptable to the business for sign-off. - Uses language that the business and your customers understand. - Follows the INVEST model. - Includes all supporting documents to inform the developer, designer, and tester: wireframes, technical design overview, other assets. - Meets your standard “definition of done” criteria.

短跑

Whether you call it a sprint, an iteration, or a timebox, each incremental delivery of your Agile project is time-constrained. The timebox doesn't shorten and it doesn't lengthen. Focus on two-week iterations at the beginning. You might find that 1, 3 or 4 weeks suits your business model better. Once you choose a length, don't change it. You want to maintain a regular cadence, or a sustainable pace. This means the team and business focus on delivering regular software without mad-dash overtime being employed to get the job done and releasing potentially shippable increments every two weeks.

• 以小增量工作有很大的好處。 這意味著您只關注交付的近期未來，並且通過新的輸入、反饋和學習，您可以在較短的迭代周期內響應變化。
• 在發布開始時，執行 sprint 0。這可以讓團隊、業務和您的項目發布做好準備，並為成功交付設定心態。 繪製出支持發布基礎的基本技術框架和架構。 設置環境、帳戶和工具。 執行尖峰以了解困難或未知的問題。 詳細說明您的用戶故事，為 sprint 1 做好準備。 Sprint 0 就是要做好準備。
• 在發布期間，不斷完善積壓工作。 隨著您了解更多或學到新東西，您的優先級可能會改變，新的需求可能會出現，並且您之前認為是一個很棒的功能可能會被完全刪除。
• 不要開始沒有機會在 sprint 內完成的工作。 如果不能，將其分解成更小的塊。 並且不要在之前開始的工作尚未完成時開始新的工作。 通過開始許多不能被認為是完整的事情，你不會創造任何價值。 此外，避免上下文切換。 這是開始一項任務，受到干擾，開始另一項任務的活動，最有問題的是，兩者都沒有完成。
• 在任何時候限制團隊正在進行的工作量。 例如，如果您有 3 名開發人員和 1 名測試人員，您可以對開發人員和測試人員設置 WIP 限制。
• 在計劃完成後，切勿在 sprint 中添加更多工作。 永遠不要在中途停止衝刺。 例外情況是：
  • 如果你的表現比預期的要快，考慮從積壓的頂部開始下一個故事，只要準備得當。
  • 如果 sprint 表現如此糟糕以至於無法完成。 這通常只發生在發生某種描述的災難的情況下。
  • 如果由於業務需求的即時變化而不再支持 sprint 目標。
• 如果您確實取消了衝刺，請優雅地進行，花時間重新集中精力，然後像其他任何衝刺一樣開始新的衝刺。
• 在發布快要結束時，考慮一個最終的發布衝刺。 沒有編寫新功能，可以清理一些錯誤，並且可以為實際向客戶發布產品的新版本做好準備。 這並不是說您不能同時進行增量客戶發布——只是這是一種受控、可衡量和可持續的發布機制。
• 在發布結束時，您可能會考慮進行為期一周的衝刺。 在這個 sprint 中，你可能會與團隊一起分解一些新想法或找出一些新技術。 這些都是有益於業務的偉大工具，它為團隊提供了一些簡報空間來思考和發揮創造力。 這不是為了偷懶，仍然會創造價值。 同樣，每個人都需要休息。 在這個時候休假有助於在你釋放中期時保持你的節奏和速度處於良好狀態。

定義完成

定義“完成”的真正含義非常重要。 在您的項目生命週期中，“完成”有很多版本——故事、發布或整個項目“完成”意味著什麼。 這一切都歸結為您、您的團隊和企業將認為完整的質量水平，以滿足發貨準備。

對於您的團隊，“完成”故事的定義將類似於所有代碼完整、同行評審、符合定義的驗收標準、單元測試、UAT 並推送到您的代碼存儲庫。 為了使故事能夠從設計師傳遞到開發人員再到測試人員，“完成”的定義必須被鏈條中的下一個人接受。 您的產品負責人會期望這對他們意味著什麼，以便將產品增量發布給您的客戶。 在任何情況下，每個人都必須了解“完成”的含義，並成為確保其含義得到滿足的責任方。 定義你對“完成”的定義，溝通它，就它達成一致，然後發展它。 完成了。

連續測量

如果你無法衡量它，你就無法管理它。 改進也是如此。 在敏捷項目中收集經驗數據的需求幾乎與血液循環一樣重要！ 如果沒有數據，您怎麼知道需要管理、糾正或改進什麼？ 好吧，簡而言之，您將依賴直覺和未經證實的猜測，這些猜測在審查下很快就會分崩離析。 根據誰在進行審查，這可能是一個相當不舒服的地方。 因此，從你的項目一開始，確保你知道你將如何展示你的進步，以及其他人將通過什麼標準來看待你的成功。

幸運的是，敏捷配備了有用的工具和技術。 要做的第一件事是回到敏捷宣言，在你最喜歡的文字處理器中輸入以下文字，將它們放大到 96pt，打印，然後貼在牆上供所有人查看：

在交付軟件方面，你最大的可證明的力量就是向工作的人展示它，做它應該做的事情。 這不僅會讓您的客戶滿意，還會為您的團隊贏得極大的尊重，並為在整個業務中得到更多采用而加油。

以下是一些其他工具：

• 每日站會：這個儀式有一些變化，但本質是讓所有團隊成員面對面交談：保持簡短，保持重點，保持輕鬆。 如果有任何事情需要詳細討論，請將其停在站立後需要的人之間進行更長時間的對話。 如果提出了障礙，請將它們像故事一樣寫下來，將它們添加到您的待辦事項中，並儘快解決它們。 任何阻礙您的團隊的事情都會減慢他們的進度，並且會在速度降低和軟件不符合預期的情況下得到證明。
• 速度：是一種歷史工具。 這有點像你收到的那些財務警告，說過去的表現並不能保證未來的表現。 但在敏捷的案例中，我們確實希望實現一個基本平穩的團隊速度。 正是速度使我們能夠預測未來的績效和對我們計劃的信心。 可能存在您無法控制的影響，這可能會降低給定 sprint 輸出的故事點數。 如果發生這種情況，您可能會康復。 永遠不要用速度作為擊敗你的團隊的一根棍子； 它不會為你贏得任何好處。 可以肯定的是，前 2-4 個衝刺的速度會不穩定。 但是，在那個時間範圍內的某個地方，您應該開始看到一致性和穩定性。 如果您的速度從一個極端波動到另一個極端，那麼您就遇到了需要與您的團隊一起解決的問題。
• 燃盡圖：現在，這種衡量進度的方法很棘手。 出於這個原因，我沒有提供鏈接以了解更多信息 - 您必須自己進行研究並同意作為一個適合您的團隊和企業。 刺的原因是什麼？ 好吧，沒有一種資源可以講述同樣的故事！ 一致同意的一件事是，它將在一個 sprint 或一個版本中顯示你在時間盒內的表現。 如果每天維護，它會顯示您是否處於正軌或偏離軌道。 一些團隊用它來表示還有多少價值需要創造，而其他團隊則用它來顯示還有多少工作需要完成。 前者是對成功和價值創造的慶祝，後者則不那麼鼓舞人心和激勵。
• 燃盡圖：如果您必須顯示工作完成率，請使用燃盡圖。 但是使用燃盡圖可以讓您顯示已經創造了多少價值，以及您計劃在衝刺結束時創造多少價值。 對於團隊來說，這是一種更具激勵性的工具，既可以向企業展示已經完成的工作（如果事情進展不順利的話，也可以展示很少的工作......）以及他們仍然關注的目標。 在任何情況下，使用圖表來發現進度未按預期跟踪的地方，並尋找模式或偏差並掌握它們以盡快解決潛在問題。 每天更新它們以進行沖刺，並在衝刺結束時更新發布版本圖表。
• 任務板：這些是展示所創造價值的絕佳視覺輻射器。 當每天或一天中的任何時候更新時，它們會立即顯示正在取得的進展。 如果與看板結合使用，它們也是可視化系統中的流動和阻塞的絕佳工具。 如果您可以看到已經完成了大量開發，但測試效率不高，那麼您可以看到問題正在發生並做出適當而迅速的響應。

其他需要考慮的工具是敏捷掙值、週期時間和累積流程圖 (CFD)。

保持這些措施、圖表和其他工具可見，最好在牆上響亮而自豪，讓所有人都能看到。 團隊、利益相關者和其他相關方可以立即看到項目的狀態。 它是透明的，是一種有價值的溝通工具。 如果您不能將這些工件放在牆上，請使用可共享和協作的工具，並確保那些想要訪問的人擁有它。

連續的提高

在您的敏捷生活中，尋求識別和學習可以改進的地方。 在項目結束時並沒有吸取和吸取教訓。 這就像通過駕駛考試並在沒有教練的情況下試探性地駕駛您的第一次駕駛。 你會知道什麼是有效的，你應該做什麼，但隨著時間的推移，你會調整你的駕駛技能和能力，學習新技術。 你甚至會養成壞習慣。 尋找他們，了解他們，並找到改進的方法。

有很多機會可以確定什麼不起作用並應用補救措施。 敏捷中內置的方法是回顧。 這是反思和調整的主要工具。 在每個 sprint 結束時，花時間與團隊一起改進工作的完成方式、質量的交付方式、效率的最大化方式、浪費的最小化方式以及容量的增加方式。 當您確定改進措施時，不要試圖立即解決所有問題。 確定影響最大並且可以在下一個 sprint 中實施的那些。 測量和觀察。 如果它產生了預期的影響，就把它鎖起來，把它寫進你的工作方式和完成的定義中。 如果它不起作用，請再考慮一下。 任何沒有被投入到即將到來的 sprint 中的經驗教訓都可以被擱置並在下一個 sprint 中優先考慮。

定制流程。 刪除任何不起作用的東西。 消除障礙。 如果您允許，您作為敏捷團隊的成熟度將是無限的。

超越敏捷項目管理

了解項目交付後會發生什麼很重要。 支持和維護是確保項目在客戶手中後保持性能的關鍵； 客戶反饋可以考慮到未來的版本中； 並妥善處理客戶問題。 項目是一項獨特的、受時間限制的工作。 它交付的產品在項目團隊解散後還有生命。 確保您能夠在產品上線後支持該產品。

敏捷項目與更傳統的方法共存。 平衡預算控制和利益相關者可見性的要求與敏捷的靈活性和響應性目標。

治理框架或敏捷治理模型與標準敏捷流程（例如 Scrum）結合使用。 它們以兩種特定方式工作：

• 它們通過闡明在開發迭代（衝刺）之外發生的過程，為敏捷項目提供了一個包裝。 這包括為成功完成項目啟動和正確驗證決策和計劃提供明確的標準。
• 他們轉移了標準敏捷過程特定部分的重點，並突出了需要治理或支持治理的特定原則和技術。

在當今瞬息萬變的世界中，組織和企業熱衷於採用更靈活的方法來交付項目，並希望變得更加敏捷。 然而，對於交付項目和計劃的組織，並且已經存在現有的正式項目管理流程，許多敏捷方法的非正式性令人生畏，有時被認為風險太大。 這些以項目為中心的組織需要一種成熟的敏捷方法——項目交付概念中的敏捷——敏捷項目管理。

通過採用敏捷來學習和成長。 只做你的團隊感到舒服的事情，確保聽到他們的聲音，並按照他們的要求採取行動。 鼓勵您的團隊在適當的時候採用新的和更有價值的技術。 與業務部門協商並鼓勵他們了解成為敏捷組織意味著什麼。

旅行愉快。