GDS Digital Service Manual 中文翻譯網站 (beta)
by HPX-GOV 英國政府數位服務研究小組 GDS Study Group
Home » 英國政府數位服務設計手冊 » 敏捷方法 (Agile) » 什麼是敏捷方法的樣子 (What agile looks like)

什麼是敏捷方法的樣子 (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

請留言

你的email信箱不會被發布出來. Required fields are marked *

*