什麼是敏捷方法的樣子 (What agile looks like)

用敏捷方法工作可以很彈性很自由。它不會阻止你使用現有的技能和知識，但需要團隊、使用者和利益相關人用新的方式一起合作。

了解你的使用者

不只為使用者而做的功能排列優先順序，也要為每一個人排 – 包括你可怕的利益相關人 – 並儘早要求他們反饋，而且整個過程中也要時常詢問他們的意見。真的得傾聽使用者的聲音，甚至當他們的意見是你不中聽或不同意的。

可能的話，使用真人用產品而得到的數據，並讓它影響專案執行的方向。一直把使用者擺在最前方。

「你下週五想要什麼？我們上週學到了什麼？」

要頻繁地迭代。致力於實現最有價值的用戶需求，並顯示給使用者看，聆聽他們的回饋並改進。繼續這樣做，直到你做出非常有用的東西，讓它對使用者來說，是不可或缺的服務。

這可能聽起來像是過度簡化了軟體開發和專案管理，但敏捷式開發就是「你下週五前想要什麼？」

產生增量且生產就緒型的軟體過程中，可以讓你的團隊：

• 對使用者和利益相關人定期增添價值感
• 縮短反饋的循環，因為如果使用瀑布式時間可能會更長（瀑布式：只有當正在處理的階段結束，才可繼續前進到下一階段）
• 想想哪些是最重要的功能，下一個階段要做出來的
• 引導他們打造實用的軟體

在每次交付周期的最後或Sprint的尾聲，開一個回顧會議，檢視有什麼是有效的，什麼是可以改善的。

透過數個交付週期你的團隊將不斷學習，以提升整個專案。

小型敏捷式團隊

5至10人的小團隊往往比大團隊更有效率更可以掌握。不要計算一人一日的工作量，而是把你的團隊視為一個單位。

一個好的團隊，包括所有能成功生產軟體的技能。一個功能完備的團隊主要有3個角色：

• 產品經理- （可能由服務經理擔任 ）為投資回報率（ROI）負責，通常透過創造使用者喜愛的產品達成目的
• 交付經理 （又名的Scrum Master或專案經理） -負責排除障礙（讓團隊速度減慢下來）的敏捷發法專家，他們也在團隊會議充當調解人
• 團隊成員 -自行組織跨領域專長的團隊，他們生產使用者故事， 執行產品經理的願景，並負責評估其產出和速度

鼓勵你的團隊成員兩倆合作，因為一起工作非常有益。 兩人一起做事可以：

• 生產出更好的軟體解決方案
• 鼓勵更好的品質控制
• 在團隊中分享知識

優秀的團隊代表你能非常有效且一致地估計產出或速度，。然後，你可以計劃更準確。

快速失敗

定期發布小型代碼：

• 提高質量
• 提高知名度
• 降低市場成本

敏捷技術並不能保證成功 – 你仍然可能會失敗！

但是，這些技術能讓你更早發現問題並加以解決。你可以解決問題，並且停止問題繼續發生:

• 定期釋出工作軟體給你的使用者- 它可以讓你快速獲得回饋，聽到或看到他們的想法;如果產品方向是錯誤的，你可以很快地改變方向和迭代
• 定期發表展示價值給贊助商了解 – 如果你的軟體很少發表，代表創造出不應被發表的一個不得不成功的服務，但是還是必須被發表
• 檢查你的團隊進程 – 如果你的團隊速度還是最初的4到6 Sprints，那代表有些部分必須修改(可能是未知且複雜著或有時間的限制)
• 使用測試驅動開發（在開發測試功能前先編寫測驗 ) 及早標記出質量問題 – 建立問題及基線度量，並且監控整個計畫

不要害怕失敗或實驗。從失敗中學習，並創造出新的文化。

持續規劃

如果你不做任何的敏捷計畫，那會一直是一個空談或神話。敏捷的自由性並不是憑空出現的，而是你必須去計劃。你需要持續不斷的計畫。

加強堅實敏捷計畫以及歷史資料，而不是理論或是意見。你的計劃必須不斷證明其正確性：沒有人對你的敏捷計畫視為理所當然，且可行的。

你的團隊應該共同制定計劃，至少2個階段：

• 釋出層級 – 定義並排出需要處理的功能的優先順序，並且在截止日期前完成
• 迭代層級 – 按照計畫的優先排序實現下一個功能 ( 如果功能太大，則將其拆解 )

評估每個在Spirt之後的計畫，並根據以下兩點做調整：

• 先前Spirt 的進度
• 任何新的事實和要求

常見的情況

如果你的團隊才剛開始接觸敏捷，先熟悉情控，並從不同的事情中做出應對方式。這些情控可能對你的計劃造成威脅，並且降低成功的機會：

• 你的核心團隊不是全職或正在開發多個計畫 – 你的團隊是交付中的一個單位，需要他們百分之百的付出，所以當團隊非全心全意時，需要向經理或是利益相關者施加壓力
• 與你的團隊坐在一起，最好在你自己的房間，牆上畫著點子及貼著寫滿想法的小卡。
  • 重新安排你的工作區域或以創新的方式來使用工具，藉此提高團隊的工作環境，增加工作效率 – 你會挑戰一些長期的工作實踐計畫，但這是非常重要的
• 沒有一個持續集成/開發的環境 – 如果你的團隊在開始的時候沒有堅持此點，很可能這不是你要的團隊：
  • 在許多領域裡，迭代軟體開發需要依靠不斷地部署和運行自動化測試的能力
• 你有一個獨立的品質保證(QA)部門- 如果你團隊的軟體已通過QA部門的檢驗，他們有錯誤的態度去交付已完成的產品軟體上，在團隊中嵌入品質文化

這絕對不是一個完整的列表，但這些都是最常見的需要注意的東西。

翻譯：
校稿：Richard
原始出處：https://www.gov.uk/service-manual/agile/what-agile-looks-like