本區為《EZ敏捷開發術-兩日班》學員專屬授權內容,非授權學員無法檢閱影片,尚請見諒!
什麼是「忙而不急」的上乘職場功夫?跟敏捷方法又有什麼關係?
一件「重要卻不緊急」的事情,被我拖了好一陣子,在死期將至之時,這件事情終於變成了「重要又緊急」的狀態(XD)!原本一直培養不出來的熱血,終於在自己逼自己設下目標,進入閉關衝刺的狀態之後出現了!連續幾天把自己的所有時間都聚焦在這個單一目標之後,終於在端午節連續假期之前完成了這件重要的任務!
團隊合作的工作複雜度怎麼來的?敏捷方法又是怎麼簡化這些複雜度,讓團隊效能大躍進的?
即便昨天加班加得很晚,小明今天還是得一早就爬下床,帶著尚未完全甦醒的身軀到公司去上班。到了辦公室之後,打開 Email 信箱的瞬間,一、兩百封的 email 就陸續湧入了小明的收件匣!對於同時參與兩、三個專案的小明來說,這樣的情形早就已經見怪不怪,差不多都麻痺了!
如何運用 Scrum 敏捷式專案管理到 IC 設計產品開發專案(下)
[上一篇]
前兩篇文章所提的瀑布式和階段式方法,都是傳統的專案管理方法,有人鼓吹,為了要讓專案工作的時間估得準一點,那就多估幾個時間值好了,分別叫它們為「最樂觀」、「最悲觀」、「最可能」,也就是所謂的「三點估計法」。關於這一點,我的提問是,如果一個人對一項他沒做過的工作都「猜」不準所需要的時間了,那叫這個人多「猜」兩組時間,這樣就會比較準嗎?這不是畫蛇添足,脫褲子放屁嗎?
前兩篇文章所提的瀑布式和階段式方法,都是傳統的專案管理方法,有人鼓吹,為了要讓專案工作的時間估得準一點,那就多估幾個時間值好了,分別叫它們為「最樂觀」、「最悲觀」、「最可能」,也就是所謂的「三點估計法」。關於這一點,我的提問是,如果一個人對一項他沒做過的工作都「猜」不準所需要的時間了,那叫這個人多「猜」兩組時間,這樣就會比較準嗎?這不是畫蛇添足,脫褲子放屁嗎?
如何運用 Scrum 敏捷式專案管理到 IC 設計產品開發專案(中)
看到前一篇文章提到的瀑布式方法的缺點,我相信多數組織都可能感同身受。接下來的問題是,組織當中有沒有人有膽識、有魄力,而且還有權力可以推動專案管理的改革。
很慶幸地,本案例的公司就有這樣有遠見的主管群。該公司的主管們痛定思痛、下定決心去做專案管理的變革,開始採用階段式開發方法。整個流程大致演化為像下圖這樣:
如何運用 Scrum 敏捷式專案管理到 IC 設計產品開發專案(上)
「老師,聽說 Scrum 敏捷式產品開發方法比較適合軟體產品開發,可是我們公司的產品是 IC,硬體的成分居大部分,軟體開發人員大都是在最後階段才參與產品的開發,這樣還適合導入 Scrum 敏捷式產品開發方法嗎?」
敏捷方法的成功密技(15):未完成的用戶故事的進度怎麼算?
在運用敏捷式產品開發與專案管理方法時,我們知道,應該以「對用戶的價值」的角度來對工作(用戶故事 User Story)的優先級做排序(參考《能讓需求簡化,還能更省時、更省錢,提供更多價值,這…可能嗎?》一文),然後,將這些工作,「依序」安排到固定週期的各個衝刺(Sprints)去,並且盡可能地將每個衝刺都塞滿、都最佳化(參考《敏捷方法的成功密技(十一):Scrum 如何最佳化利用衝刺的容量?》一文)。
但是,就算規劃得再完美,一定還是會有意外狀況,導致這些規劃好的事情生變。例如,在衝刺結束時,某些該完成的用戶故事,卻無法被驗收!這該怎麼辦?
訂閱:
文章 (Atom)