每個人都討厭被控制在「流程」下，但是我們必須清楚一個事實：如果沒有既定的工作流，我們的工作將是一團亂麻。

每個軟體開發團隊都有一個用來完成工作的流程。將流程規範化並將其建立為工作流——使其結構清晰且可重複，從而使其具有可伸縮性。我們採用反覆論證的方式來創建和使用工作流，因為它幫助我們更快地實現目標，並體現了我們的團隊文化。

從簡單的開始做起

當為團隊實現工作流時，不要先花費數周時間來設計流程，我們建議從簡單的開始做起。過於複雜的工作流很難理解和採用，更不用說讓團隊來適應了。

對於軟體研發團隊，我們推薦以下基本工作流狀態:

在任務追蹤中，這些狀態的使用構成了工作流的轉換，完成階段性任務並改變狀態後，任務將自動跳轉至下一個工作流。

有些軟體開發團隊在他們的工作流中也會包含額外的任務狀態，以幫助他們更精確地進行追蹤。

在實際應用中，面對眾多產品研發任務，只有基本的工作流程並不能滿足不同研發團隊的需求。所以，在「未開始-進行中-審查中-完成」的基本工作流的基礎上，Worktile還設置了多個任務類型（比如，敏捷任務、測試用例、移動原型設計等）：

並根據實際情況添加了「排隊中」、「阻塞」、「跳過」、「失敗」等細節性任務狀態，針對任務中所有可能涉及到的情況，進一步完善了研發任務工作流。

工作流中的每個狀態不需要由不同的人處理。隨著敏捷團隊的成熟，開發人員要處理從設計到交付越來越多的工作。畢竟，能夠處理內部多樣性的複雜工作是敏捷團隊的特徵之一。

在每次的復盤會中應當多注意團隊遇到的痛點。每個團隊喜歡的項目、掌握的技術和使用的方法都不盡相同，這就是為什麼配置和選擇具有高度靈活性的工作流很重要。

太多的團隊為了適應特定的工具而犧牲了他們的工作風格，這可能會使團隊成員感到沮喪；因此，他們會開始刻意避免使用該工具，這樣就會對工作效率有所影響。我們使用工具的目的是為了簡化操作流程，提高工作效率，而不是為了使用而使用。

因此，除了有通用模板，Worktile還針對項目的多樣性，允許項目管理者在配置中心自定義，從任務階段、狀態、標籤到任務面板，以高靈活性來更好的適用於不同團隊的工作風格，避免出現讓團隊工作習慣來適應工具的情況。

剛接觸敏捷開發或者不具備跨職能技術成員的團隊，工作流程常常會以「迷你瀑布流」的形式告終。例如，設計使用模型啟動工作項、開發負責實現、測試確認質量等，每個任務在前一個狀態完成之前都被停滯，這種描述聽起來是不是很熟悉？沒錯，又回歸了瀑布流開發。但是我們可以用敏捷工作流改善這種情況，讓開發變得更容易。

共享工作流程

當你已經熟悉基本工作流並準備自定義它時，記得為團隊流程中每種類型的工作都創建一個狀態。基本構思、設計、開發、代碼評審和測試在功能上是不同的，都可以是單獨的狀態。我們設定工作流的目標就好比是刻出一座簡潔的雕像，每一個流程節點都可以清晰地傳達出這件作品所處的階段。

在Worktile，項目狀態和任務也可以與公司組織的其他團隊成員共享，用【全局關聯】的方式實現快速一對一溝通。這樣一來，我們在構建工作流時，可以考慮哪些指標是最重要的，哪些非團隊成員也可以借鑒。

一個設計良好的工作流可以反映出以下問題:

  • 團隊完成了哪些工作?
  • 積壓的工作量是在增加還是與團隊同步?
  • 每個狀態中有多少項任務?
  • 是否有瓶頸阻礙了團隊的發展?
  • 完成一項普通任務需要多長時間?
  • 有多少工作項目第一次沒有通過我們制定的標準?

擴展工作流的挑戰

擁有多個敏捷團隊的企業或組織在工作流方面將面臨特殊的挑戰。我們完全可以理解，團隊通常希望優化他們自己的工作流，以反映他們獨特的流程和文化。但是，在同一個項目中，不同的團隊使用不同的流程就可能會出現問題。

共同工作的敏捷團隊可以從共享一致的工作流中獲益。使用相同的工作流可以使敏捷團隊之間的工作轉換更容易，因為它們使用相同的約定來定義和交付工作。而創建一個一致的流程通常涉及到兩個團隊的一些意見交換和討論，不過這也是相互學習的好機會，有助於最終夠創造出更好更適用的工作流程。

無論您團隊的工作流是什麼，開發它的過程應當保持敏捷。後續需要不時在復盤會中討論它，並隨著團隊文化和組織的變化做相應的調整。

文章來自於Worktile官方博客，可前往查看敏捷開發解決方案

推薦閱讀：

相关文章