Scrum 敏捷(不負責)經驗分享

以下是我過去跑過敏捷(不負責)的經驗分享:

通常,敏捷以兩週為一個sprint,每個sprint 開始前會召開一次會議,拆分工作細項、認領工作內容。到下一個sprint 前預期每個人認領的工作內容應該要能夠完成。這裡不是說你個人到最後一天把工作完成就叫完成了,他是一個整體的完成,因為假如其他人的工作需要等你的工作完成才能進行(例如測試),那你就不能拖到最後一天。

所以認領工作時,要根據你的能力與時間給任務一個"點數",點數越高,完成所需要的時間越長,以此來估計每個人手中的任務需要多少個sprint完成。所以當一項工作太大時,盡可能切成在一個sprint可以完成的小工作,確保認領的人可以順利完成。當然點數也不能亂開,明明一天可以做完的事你開三天,這樣就有問題,所以通常會由有經驗的主管跟大家一起評估每項工作所需要的點數是否合適。如果大家都認同你開出來的點數,你認領了那個工作,就按照該工作的點數估計的時間來完成。

通常sprint 工作分配確定後,接下來的每天固定時間都要舉行「站立會議」,之所以要站著是因為要盡可能縮短時間,以不超過15分鐘為限,簡短報告作天做了甚麼事,就算因為某些原因你昨天甚麼都沒做都在睡覺,或出去玩,或家裡有事...等,也要如實報告。不會也不應該有人在這個每日例會上責備某人,這個例會是用來培養團隊信任,每個人都能對自己和別人誠實,工作沒有做就說沒做。同時也讓大家知道每個人的工作狀況,如果有人遭遇困難,就在例會結束後,由有經驗的同事協助解決該問題,確保團隊成員的工作都能正常執行。

然後每個人也應該在一個公開的看板上,把自己的任務列出來,標上狀態,例如"待處理"、"進行中"、"已阻塞"、"已完成"...等,讓專案管理者能夠一目了然目前工作的進度,如果能在工作狀態加上一些解釋就更好了,例如解釋項目為什麼被阻塞了。

更詳細的解釋,可以參考以下連結:

2020年敏捷开发人员生存指南-InfoQ
正确执行敏捷并非易事,如果能遵循本文的建议,相信它可以帮助你更容易地做到。本文最初发表于medium.com(《TheAgileDeveloper’sSurvivalGuidefor2020》),由InfoQ翻译并分享。我想说,敏捷就像是青少年的性行为,他们口口声声说做过,但却没人真正知道它到底是什么。不过,更严重的是,我们的行业(即软件开发行业)通常都会走敏捷的路线,这意味着开发团队通常采用诸如