即便昨天加班加得很晚,小明今天還是得一早就爬下床,帶著尚未完全甦醒的身軀到公司去上班。到了辦公室之後,打開 Email 信箱的瞬間,一、兩百封的 email 就陸續湧入了小明的收件匣!對於同時參與兩、三個專案的小明來說,這樣的情形早就已經見怪不怪,差不多都麻痺了!
如何運用 Scrum 敏捷式專案管理到 IC 設計產品開發專案(下)
[上一篇]
前兩篇文章所提的瀑布式和階段式方法,都是傳統的專案管理方法,有人鼓吹,為了要讓專案工作的時間估得準一點,那就多估幾個時間值好了,分別叫它們為「最樂觀」、「最悲觀」、「最可能」,也就是所謂的「三點估計法」。關於這一點,我的提問是,如果一個人對一項他沒做過的工作都「猜」不準所需要的時間了,那叫這個人多「猜」兩組時間,這樣就會比較準嗎?這不是畫蛇添足,脫褲子放屁嗎?
前兩篇文章所提的瀑布式和階段式方法,都是傳統的專案管理方法,有人鼓吹,為了要讓專案工作的時間估得準一點,那就多估幾個時間值好了,分別叫它們為「最樂觀」、「最悲觀」、「最可能」,也就是所謂的「三點估計法」。關於這一點,我的提問是,如果一個人對一項他沒做過的工作都「猜」不準所需要的時間了,那叫這個人多「猜」兩組時間,這樣就會比較準嗎?這不是畫蛇添足,脫褲子放屁嗎?
如何運用 Scrum 敏捷式專案管理到 IC 設計產品開發專案(中)
看到前一篇文章提到的瀑布式方法的缺點,我相信多數組織都可能感同身受。接下來的問題是,組織當中有沒有人有膽識、有魄力,而且還有權力可以推動專案管理的改革。
很慶幸地,本案例的公司就有這樣有遠見的主管群。該公司的主管們痛定思痛、下定決心去做專案管理的變革,開始採用階段式開發方法。整個流程大致演化為像下圖這樣:
如何運用 Scrum 敏捷式專案管理到 IC 設計產品開發專案(上)
「老師,聽說 Scrum 敏捷式產品開發方法比較適合軟體產品開發,可是我們公司的產品是 IC,硬體的成分居大部分,軟體開發人員大都是在最後階段才參與產品的開發,這樣還適合導入 Scrum 敏捷式產品開發方法嗎?」
敏捷方法的成功密技(15):未完成的用戶故事的進度怎麼算?
在運用敏捷式產品開發與專案管理方法時,我們知道,應該以「對用戶的價值」的角度來對工作(用戶故事 User Story)的優先級做排序(參考《能讓需求簡化,還能更省時、更省錢,提供更多價值,這…可能嗎?》一文),然後,將這些工作,「依序」安排到固定週期的各個衝刺(Sprints)去,並且盡可能地將每個衝刺都塞滿、都最佳化(參考《敏捷方法的成功密技(十一):Scrum 如何最佳化利用衝刺的容量?》一文)。
但是,就算規劃得再完美,一定還是會有意外狀況,導致這些規劃好的事情生變。例如,在衝刺結束時,某些該完成的用戶故事,卻無法被驗收!這該怎麼辦?
敏捷方法的成功密技(14):你不可不知,影響專案開發速度的八大障礙
在《開車旅行跟敏捷式專案管理有什麼關係?》一文當中,我們談到了,只要能掌握團隊的產品開發速度,幾乎就等於掌握了整個專案的進展。
其實,不論是傳統式還是敏捷式的專案管理,道理都是一樣的。但,到底有哪些因素會影響到團隊的開發速度呢?我們還是先來看看開車旅行的例子。
開車旅行跟敏捷式專案管理有什麼關係?
如果你正開車到一個陌生的新景點去旅行,總距離大約是 200 公里左右,而你現在已經開了 160 公里,花掉了你兩個鐘頭,那麼,你知道,過去這段時間,你的平均車速是大約每小時 80 公里左右。現在我們來考慮以下的三種情境。
敏捷方法的成功密技(十二之一):Scrum 如何精準估算用戶故事的點數?
在上一篇文章《敏捷方法的成功密技(十一):Scrum 如何最佳化利用衝刺的容量?》當中,我們談到了怎麼將點數/心力(Point、Effort)大小不一的各個用戶故事,依照用戶故事的優先級先後,排進衝刺(Sprint)內去實做。也談到了如何拆解肥大的用戶故事為數個小故事,以便能繼續將該衝刺的剩餘空檔也能盡量地塞滿,以最佳化該衝刺的負載規劃。
可是,這些作法都必須奠基於「夠精準的用戶故事點數估算」這個前提之下才有意義!那麼,實務上,我們到底應該怎麼來估算用戶故事的點數,才能稱上「夠精準」呢?
敏捷方法的成功密技(十一):Scrum 如何最佳化利用衝刺的容量?
在上一篇文章《敏捷方法的成功密技(十):Scrum 的衝刺目標誰決定?》當中,我們談到了衝刺(Sprint)目標,雖然名義上應該由 Product Owner(產品負責人)來制定,但為免團隊根本就不
buy-in,或是團隊實在是無力可達成,故,實務上 PO 仍應與 Scrum Master 和開發團隊「一起」討論,來制定各個衝刺的目標,這樣才像一個符合
Scrum 精神的「團隊」!
敏捷方法的成功密技(九):Scrum 的衝刺目標怎麼訂?
綜合本系列之前的文章,Scrum 其實就是一個小團隊(約5-9人),利用一個個固定短週期的衝刺(Sprint),跟客戶一同逐步漸進地,完成一個產品,而這個產品的功能,就是由一個個,由客戶主導、撰寫的用戶故事(User Story)來呈現需求的(關於用戶故事的簡要陳述,有興趣的朋友可以先參考一下《能讓需求簡化,還能更省時、更省錢,提供更多價值》這篇短文,容日後有空再專文細述之)。
敏捷方法的成功密技(八):Scrum 的衝刺時間長短怎麼訂?
一個衝刺(Sprint)的時間長短到底應該是多少才是最好的呢?如果衝刺的時間設定得太長,那麼,應變的彈性就會變得比較小,而如果衝刺的時間設定得太短,那麼,又容易讓開發團隊能產出的成果出問題。怎麼說呢?
敏捷方法的成功密技(七之二):Scrum 的夢幻開發團隊該怎麼來建置?
[承上一篇]
接續上一篇文章《敏捷方法的成功密技(七之一)》,除了新領域、新團隊,最有機會嚐試新作法之外,我們也談到了,只要開發團隊夠紮實,產品的開發就能夠打帶跑,因為品質才能夠被掌控得好。怎麼說呢?
敏捷方法的成功密技(七之一):Scrum 的夢幻開發團隊該怎麼來建置?
在上一篇文章《敏捷方法的成功密技(六):Scrum Master 並非你想像的那般卑賤!》中,我們談到了 Scrum Master 這個角色,其實最好是由一位開發和管理經驗豐富的人來擔任,工作經歷不足的菜鳥,是很難勝任得好,更很難以服眾的。
敏捷方法的成功密技(五):Scrum 的三種角色
在上一篇文章《敏捷方法的成功密技(四):Scrum的理想與現實的障礙》中,我們談到了Scrum明確定義的三種角色,Product Owner產品負責人、Scrum Master 大師,以及Development Team開發團隊,接下來我們就一一來看看。
訂閱:
文章 (Atom)