響應計畫變更
—敏捷宣言
防止過多的計畫。
計畫軟體專案很困難。 我們每個人都想知道他們會成功就啟動專案，但是我們如何確定呢？
客戶是否真的想要此產品或功能？ 我們可以在需要的時候生產產品嗎？ 如果計畫合理，我們可以預見產品中是否存在技術複雜性？ 我們完成交易時市場會發生變化嗎？
一些企業嘗試在開始乙個專案之前回答所有這些問題，所以他們不會將開發時間浪費在注定要失敗的專案上。
但是許多企業未能意識到要進行多少計畫取決於專案：
· 您的開發團隊可以多快發布一些內容並獲得客戶的反饋？
· 您從客戶和產品中獲得了多少現有反饋？
· 如果您發布不良產品，將會有多大損害？
· 發布後，您如何衡量客戶參與度？
儘管每個專案都進行了上述更改，但許多公司仍對每個專案遵循相同的計畫模式。 這意味著不可避免地有些專案計畫太多，而另一些專案則不夠。
為什麼計畫有時是一件壞事？
· 計畫延遲了mvp的交付，市場可能會繼續發展-您可能會錯過視窗，競爭對手的產品可能會在交付之前搶占您的市場份額（延遲上市時間）。
· 規劃可能會浪費時間討論在實際實施時可能不相關的事情。
· 規劃會延遲來自真實使用者的真實反饋，這比猜測他們想要的東西重要得多。 （提前發布，經常發布）
· 計畫可以引起沉沒成本謬誤。 您花在制定計畫上的時間越多，說服企業更改或放棄計畫就越困難。
· 規劃使業務分散了資料驅動力。 資料驅動的決策涉及交付功能，然後檢查資料是否參與。 使用者是否按預期使用此功能？ 他們喜歡嗎？ 他們在要求令人驚訝的事情嗎？ 如果您的決策過程與專案前的計畫密切相關，那麼用於專案中期分析的資源將更少。
一些計畫仍然不錯：
· 市場研究仍然是乙個好主意。 如果您不檢查競爭對手的產品，則可能會打造出並非唯一但已經落後的產品。 就是說，許多企業已經開發出落後於市場的產品，但最終仍會保持領先地位。因此請注意，您的計畫不會消除您的創新。
· 有時，最好勾勒出您要構建的系統的輪廓，並充實元件。 但是，在啟動專案的過程中，開發團隊通常可以自己完成此操作。 此外，這有過度設計的危險，而不是試圖盡快使mvp失效的危險。 考慮12-18個月的專案時，容易想到您需要額外的元件和抽象層，而這正是我們在敏捷交付中應避免的思維方式。
· 您業務中的某些部分可能需要排隊，例如準備市場發布，廣告活動。 這將在很大程度上取決於您的業務型別。 我的建議是盡可能地使這些部門脫鉤，以便軟體開發可以敏捷，並且您不會在專案開始之前就開始同意時間表和截止日期。一旦專案開始，就使用基於資料的**（而不是直覺）。 專案已經開始，您有關於速度和範圍的硬資料。 執行實驗：假設專案出錯了，只要您認為需要花費4倍的時間，甚至中途放棄，這將如何迫使其餘業務發生變化？ 通常，您可以採取一些措施來保護業務，而不是在多年的路線圖和聯合交付中將部門**在一起（這不可避免地會失敗）。
擁抱不確定性和變化
如果您要少做計畫，則必須擁抱不確定性和變化。 這意味著您對今天的專案的任何想法明天都可能完全錯誤。 可以說，即使您做了很多計畫，這仍然適用。
實際上，擁抱不確定性意味著：
· 您的公司應該準備非常迅速地改變方向。 如果某人在專案的中間有乙個更好的主意，那麼企業應該能夠立即適應並改變以實現。 不要僅僅因為專案開始後就擁有了好主意而忽略了好主意！ 您是否曾經想過"等一下，如果我們只是……"會更簡單嗎？ 這些認識不應引起下沉的感覺，"哦，不，這個專案浪費時間"。 而是"我有個好主意，下一步我們可以做什麼！"
· 您的公司應該準備完全取消/放棄專案。 您的企業是否曾經取消過專案？ 還是當每個人都知道自己在浪費時間時才繼續進行專案？ 如果您是敏捷的人，則應該謙虛，不要指望客戶想要什麼，無論您建造什麼，都可能浪費時間。 每當您收到反饋時，這都是有價值的資訊-現在該資訊業務將如何處理？ 像以前一樣繼續，還是改變？ 真正敏捷的公司應該盡快發布mvp，然後立即問：mvp成功了嗎？ 我們還有更好的工作要做嗎？ 我們應該取消這個專案
嗎？ 您做的計畫越少，建立mvp的速度就越快，則取消專案時浪費的錢就越少。
· 您的企業將需要對產品使用情況的資料收集進行投資，以便在mvp交付後，您可以分析客戶使用情況，以確定下一步要在專案中做什麼以及是否取消它。 文化轉變是從前期計畫到中期專案資料分析。
· 產品所有者和設計師將需要與開發團隊更緊密地合作。 在瀑布式世界中，您可能有乙個設計/產品團隊來建立設計文件，這些文件可能會在技術領導者的陪同下進行反覆嘗試，以設計出可行且有用的內容。 在敏捷世界中，發布mvp後，您的開發團隊可能需要設計師在轉向新方向後非常快地設計新功能。 一些公司通過擁有跨職能的團隊並將產品所有者和設計師嵌入團隊內部來完全擁抱這一點。
接受您將運送原型和技術債務
製作快速，易受攻擊的mvp產品的危險在於，其中可能包含快捷鍵，低質量的**和技術欠債。 對於開發團隊之外的人來說，很難理解有漏洞的mvp可能是一種一次性解決方案，並且可能需要進行一些重寫才能長期安全和穩定。
通常應故意和戰術上承擔技術債務，以便更快地釋放給客戶。 例如，如果您有機會放棄該專案並刪除所有**，則可能不值得花時間將其完善後再發布。
停止按文件發出訂單
向開發團隊內部傳遞資訊的最有效方法是面對面的交談。 —敏捷原則
有時，預先計畫會導致將設計文件"全部"扔給開發團隊。 這是一種極其緩慢且效率低下的通訊方式。 您是否曾經通過電子郵件引用文件而對文件注釋中或更糟的內容進行了長期辯論？ （幾天甚至幾周？）
最糟糕的辯論是所涉及的兩方根本不了解另一方的思維方式，並且似乎在談論完全不同的波長—例如，乙個人想要乙個較低的要求，而另乙個人則認為該專案是 浪費時間。 通過在流程的早期和專案期間定期進行合作來阻止這種情況的發生：
在整個專案中，業務人員和開發人員必須每天一起工作。 —敏捷原則
通過面對面的討論，通常可以更快地解決這些討論，同時建立人際關係通常是成功專案的基礎。
通常，開發團隊需要知道的不是開始在設計文件中找到的專案，並且在專案中間需要回答的問題通常過於具體，無法在文件中回答，因此文件是 在開始時過於投機，在整個專案中過於模糊/過時。
更好的方法是召開面對面的會議以啟動專案，然後在專案本身進行頻繁的會議。 響應變化，不遵循計畫！
從一開始就讓開發人員參與進來，激勵他們
圍繞有積極性的人建立專案。
最佳的體系結構，要求和設計來自自組織團隊。
—敏捷原則
激勵開發團隊的一種簡單方法是：給他們一大堆設計文件，然後說"構建此文件。 12個月後見。"
成功的開發團隊不會像外包的"編寫此**"團隊那樣工作，而是要競標未來的全能大師。 成功的開發團隊通常從一開始就參與專案計畫，他們會感到對整個專案的所有權感，而不僅僅是**。 專案開始時的開發應該與探索需求，技術風險以及找出客戶是否想要您的產品有關。
不要猜測專案何時完成
專案開始是猜測何時完成的最壞時間。 為什麼？ 因為那是您最不了解的時候！ 您沒有資料。
例外：如果您的團隊已經完成了多個先前的專案，並且這些專案足夠相似，那麼有時您可以使用該資料進行一些預先的**。 關鍵是（a）以資料為依據，不要（b）給出乙個日期範圍而不是乙個日期（c）該日期範圍應足夠寬，以使專案中的資料縮小而不是擴大
不用猜測，您應該使用資料來計算幾次衝刺（約4-6周）後的投影範圍，然後應該定期更新投影。 如果您使用的是專案管理工具，那麼通常可以自動進行。
注意：您必須注意專案的積壓範圍。 如果待辦事項的增長速度快於完成工作的速度，那麼您將無法在專案結束時進行計畫。
如果您看到結束日期越來越遠，那麼這是個停止，分析專案並討論原因的好時機。 你的速度下降了嗎？ 您承擔過多的技術債務嗎？ 您的範圍在增加嗎？ 是否新增了太多功能？
對於企業而言，可**性通常比速度更重要。
警告：每家公司都不一樣
軟體領域極為廣泛且正在發展。 並非所有公司和專案都應使用相同的做法。 例如，一家資金有限的新創公司可能會更多地專注於在產品用盡之前快速嘗試不同的產品。 乙個成熟的公司可能會更專注於保留現有客戶，並且可能更不願意推出低質量或實驗性的**。
一些公司，尤其是那些構建大型企業軟體的公司，可能會限制於他們從客戶那裡獲得反饋的速度。 如果客戶需要2年的時間才能使用您的軟體，那麼很難獲得快速的反饋！ 在這種情況下，獲得客戶的"贊助人"以在整個專案中進行合作，或者組織遠端使用者測試/演示會議是很有用的，在這些會議中，您可以要求客戶在軟體還在開發中時使用它。
業務不應簡單地從他人那裡複製敏捷實踐。 相反，他們應該嘗試理解建立敏捷宣言的原因，以便可以將其與自己的業務聯絡起來並進行相應的調整。 明智地決定要做多少計畫由您決定！
敏捷世界中的合規性
合規性 compliance 是指確保人們正確地做事，並能夠證明做事的正確性。在實施敏捷和頻繁交付的情況下，人們需要為交付過程建立合規性。融入了合規性義務 compliance obligation 的devops團隊將更有可能取得成功。在atlassian 2018歐洲峰會 summit euro...
敏捷世界中的合規性
合規性 compliance 是指確保人們正確地做事，並能夠證明做事的正確性。在實施敏捷和頻繁交付的情況下，人們需要為交付過程建立合規性。融入了合規性義務 compliance obligation 的devops團隊將更有可能取得成功。在atlassian 2018歐洲峰會 summit euro...
敏捷世界中的合規性
合規性 compliance 是指確保人們正確地做事，並能夠證明做事的正確性。在實施敏捷和頻繁交付的情況下，人們需要為交付過程建立合規性。融入了合規性義務 compliance obligation 的devops團隊將更有可能取得成功。在atlassian 2018歐洲峰會 summit euro...