這個年度會有很多的事情需要處理,應該會是個爆忙的一年。所以一直想規劃一個好的工作流程。這幾年下來,其實根據自身的狀況,自行規畫了好幾個工作方式,雖然這些自己規劃的工作方式都可以讓自己的「執行效率」大增。但事情的完成度卻沒什麼改變。也就是事情是可以做的很快,但做錯方向的問題可能存在。

這時候就在想,軟體工程界一直有句名言:「別人已經做好的輪子,就別再重新再做了」,意思是有現呈的,拿來用就好了。所以在程式開發時,才會有這麼多的框架(Framework)可以引用,可以大大省去系統開發的時間。

所以我在想,會不會工作流程也有框架的概念,而且已經早就有很多人在用了。我Google了一下,發現,軟體專案管理界,就有一個開發模式常被拿來做一些非軟體開發領域上的使用。

敏捷開發(Scrum),以下先做介紹,因為個人接案的關係,一個人必需同時接多個案子,接下來在來研究跟記錄一下自己該怎用在「一人多專案上」。

好了,開始吧。

當一個專案在開始之前,需要至少找到三個角色的人,分別是產品管理者、Scrum顧問、執行者。產品管理者是最清楚專案的人,Scrum顧問是最清楚Scrum規則的人,執行者才是真正去執行或開發的人(通常這角色的人數最多)。

以下,角色名稱:

  • 產品管理者(Product Owner),我們簡稱PO
  • Scrum顧問(Scrum Master),我們簡稱SM
  • 執行者(Development Team),我們簡稱DV

找到這三個角色的人之後,這幾個人需要聚在一起開個會。這時候,因為專案的執行方式會走Scrum的方式,所以主持人通常會是SM。SM這時會先出來講解Scrum的規則。

今天,我們大概會花2個小時來討論這個專案。這個會議的內容將有「初步的專案截止日」、「確認工作清單事項」。

接著,主持人會請PO來為大家講解這個專案的方向及需求,未來如果方向不對,需求有問題,PO才是那位該負責的人。這時候PO將會拿出他會議前就準備好的需求項目(Story)。每個需求項目都有備註著「為什麼」會有這樣的需求,為什麼要這麼做。以及如何驗證屆時這個需求是否被正確完成的檢核條件等…。

在大家聽完PO的專案方向及需求說明後,可以一同討論哪些功能是否真的有需要,是否可以調整或刪除的。確認好需求項目之後,DV便可以為每個需求項目條列工作任務。每個工作細項建議是幾小時或一天內就能完成的工作範圍。

接著全部的人一同討論有哪些項目需要借由外部的力量(外包、其他部門)才能完成的。

以上工作都完成之後,PO便可把這些需求項目(Story)歸納到專案的「產品待辦清單(Product Backlog)」當中。接著SM需要協助PO制定出一個「衝刺期(Sprint)」。第一個衝刺期要完成多少個需求項目。

在經歷完一個衝刺期之後,便可以瞭解這個團隊在解決任務的過程,需要花費多少時間、有哪些問題可能阻礙著DV們完成任務。一方面可以更清楚瞭解這個團隊的能耐,推導出專案真正可以完成的截止日。另一方面,PO或更高層的管理者需要盡可能的協助DV們清除阻礙,讓DV在處理任務上能更順暢。

如果在過程中,如果高層臨時要做需求上的修改,必需讓PO知道並評估調整,千萬不可以直接對DV下達令命,這會導致整個專案變得混亂。因此,這個狀況如果發生了,請DV自覺,通報PO一下,以免釀成災害。

當專案開始進行了,SM需協助PO準備一個「看板」:

需求(Story)未開始進行中已結束
會員登入(Story)#Task1
#Task2
#Task3
#Task5#Task4
加入購物車(Story)#Task1
#Task2
#Task3
#Task5#Task4

只要被完成的任務,就將任務(Task)移動到下一個狀態(例如:從進行中移到已結束),任務的狀態也可以視專案來做調整。例如,完成的任務被發現有Bug了,或許可以在「進行中」以及「已結束」中間再增加「測試中」、「Bug修改中」的狀態。

這可以讓專案的所有成員們,一眼就瞭解目前專案的狀況。如果真有熱血DV的存在,也可以請有空的DV協助卡關的人。

每完成一次的衝刺期(Sprint),就要開一次會議,檢討上一個衝刺期有哪些需要改善的,例如:

  • 解決任務時發生了哪些阻礙需要管理者支援的
  • 有哪些需求項目(Story)可以調整, 像是需求改變、順序改變等
  • 工作任務清單(Tasks)是否需要調整
  • 下一個衝刺期還要做哪些需求項目(Story)

直到專案完成。在每次衝刺期之後都開個小會進行討論與調整,最大的好處是,專案所處理的需求,會越來越貼近使用者或客戶。因為在專案的過程中,會不斷的跟客戶做討論與確認。如果一開始所訂的需求與客戶所想的有所差異,那也來得及在過程中做調整。真是完美的開發模式呀…

不過台灣的客戶,心態多變,有時連自己要什麼都不知道…今天要A,明天想換B、後天懷念A…,好吧,這是之後的課題。

只是,這個用在接案上,一人分飾多角倒還簡單。但Scrum好像挺強調要專注在一個專案上。那我一個人必需接多個案子,同時有很多專案在進行呀,加上其實上面辛苦打的內容,我想只是Scrum的皮毛,還是讓我再來研究研究吧。

最後修改日期: 2021 年 3 月 19 日

作者

留言

撰寫回覆或留言

發佈留言必須填寫的電子郵件地址不會公開。