almost 10 years ago

為什麼我覺得 User Story 是學會專案控制很重要的一環。是因為我發現長久以來,很多開發者 do project management the wrong way。

事情做不完的根本原因是很難分清楚:手頭上的東西是「異想天開的想法」「也許改天再做也可以的想法」「真正對專案有重大貢獻的想法」還是「完全不需要實作的想法」。

在不把「真正對貢獻的想法」以及「真正對專案有重大貢獻的想法」梳理出來之前,你不可能知道在給定時間內,有多少資源讓自己能夠準時交付對專案有貢獻的 code。更不可能知道,在時間緊迫之下,哪些「想法」是可以被無情地刪除的。

因此專案延遲是相當正常的。

在最近上課後跟學員交流之後,我更從互動中發現,為什麼有些公司導入 Scrum 會失敗,是因為到 RD 手上的時候,其實 Ticket 都已經被切好。而這些 RD 是在「完全不知道原始故事長什麼樣的狀況」的情境去實作這些 Ticket 的。所以就容易做出歪掉的產品,而因為歪掉,就會在 Acceptence Test 被打回去。

許多 delay 或做歪的專案,問題都在原始 requirement 或 goal 並沒有被專案中負責執行的人好好理解,然後再化之為能夠執行的 Tickets。

而 Issue Tracking System 也淪為「掛想做的任務的工具」,而不是「管控」「應該被做」的「管理任務工具」。

在此前提下,更不可能將專案所收斂。

把該做的事情分離出來

所以如果要真正貫徹 Agile。第一件事情就是要把「該做的事情」好好的分出來。

以此為出發點。再去學如何做 Story Valuation,Velocity,Priority 管控。

在這過程中,後續使用更多的 communication tool 、collaboration tool、continuous delivery tool 排除協作中所會遇到的障礙。

然後,你才會開始看得懂: 那些敏捷開發的書到底在講什麼。哪些你可以用,哪些你不需要用。為什麼 scrum 某些方法 work,哪些方法不 work。

為什麼你花時間讀完一本 scrum 教科書,你的團隊卻還是敏捷不起來。

我想真正的關鍵在這裡。

← 有效提升大學生競爭力 -- 用 Git Pull Request 收作業 Deliver Project on Time 的上課心得(六月班) →
 
comments powered by Disqus