敏捷方法的成功密技(九):Scrum 的衝刺目標怎麼訂?
綜合本系列之前的文章,Scrum 其實就是一個小團隊(約5-9人),利用一個個固定短週期的衝刺(Sprint),跟客戶一同逐步漸進地,完成一個產品,而這個產品的功能,就是由一個個,由客戶主導、撰寫的用戶故事(User Story)來呈現需求的(關於用戶故事的簡要陳述,有興趣的朋友可以先參考一下《能讓需求簡化,還能更省時、更省錢,提供更多價值》這篇短文,容日後有空再專文細述之)。
敏捷方法的成功密技(八):Scrum 的衝刺時間長短怎麼訂?
一個衝刺(Sprint)的時間長短到底應該是多少才是最好的呢?如果衝刺的時間設定得太長,那麼,應變的彈性就會變得比較小,而如果衝刺的時間設定得太短,那麼,又容易讓開發團隊能產出的成果出問題。怎麼說呢?
敏捷方法的成功密技(七之二):Scrum 的夢幻開發團隊該怎麼來建置?
[承上一篇]
接續上一篇文章《敏捷方法的成功密技(七之一)》,除了新領域、新團隊,最有機會嚐試新作法之外,我們也談到了,只要開發團隊夠紮實,產品的開發就能夠打帶跑,因為品質才能夠被掌控得好。怎麼說呢?
敏捷方法的成功密技(七之一):Scrum 的夢幻開發團隊該怎麼來建置?
在上一篇文章《敏捷方法的成功密技(六):Scrum Master 並非你想像的那般卑賤!》中,我們談到了 Scrum Master 這個角色,其實最好是由一位開發和管理經驗豐富的人來擔任,工作經歷不足的菜鳥,是很難勝任得好,更很難以服眾的。
敏捷方法的成功密技(五):Scrum 的三種角色
在上一篇文章《敏捷方法的成功密技(四):Scrum的理想與現實的障礙》中,我們談到了Scrum明確定義的三種角色,Product Owner產品負責人、Scrum Master 大師,以及Development Team開發團隊,接下來我們就一一來看看。
敏捷方法的成功密技(四):Scrum 的理想與現實的障礙
在上一篇文章《敏捷方法的成功密技(三):Scrum如何擺脫「產品客戶不愛,團隊熱情不再」的窘境?》中,我們談到了Scrum架構可以協助「部份」解決溝通斷層的問題。若是想徹底一點改善溝通斷層的問題,則還需要把在更前端「產品定義階段的相關活動」也都納入Scrum的架構內來運作才行。
敏捷方法的成功密技(三):Scrum 如何擺脫「產品客戶不愛,團隊熱情不再」的窘境?
理由其實很簡單,在這個溝通的鴻溝沒有被妥善處理、弭平之前,所有後續的努力與投入都會事倍功半,形成「產品客戶不愛,團隊熱情不再」這個賠了夫人又折兵的窘境。那該怎麼做才能「盡可能」地弭平這個溝通鴻溝呢?(注意,我沒說能完全弭平!)
敏捷方法的成功密技(二):專案管理的「溝通斷層」
在上一篇文章《敏捷方法的成功密技:Scrum 為何對你很重要?》中,我們談到了Scrum這個在敏捷開發方法中頗受歡迎的一派,也談到了敏捷式與瀑布式,在產品開發和專案執行成功率上的巨大差異。可是,既然這個東西這麼讚,又簡單易懂,那為什麼還是有很多公司和組織在導入這個方法的時候,不盡人意,東卡西卡的,無法體驗到敏捷法的巨大好處呢?
敏捷方法的成功密技(一):Scrum 為何對你很重要?
最近一位認識多年的朋友,讀完了Jeff Sutherland大師所撰寫的《SCRUM,用一半的時間做兩倍的事》之後,找我問了些有關敏捷方法的問題,我發現,大多數的人可能都把敏捷方法想得太過於簡單了,以至於在組織內施行的時候,到處碰壁。
這本書,我在它剛出版的時候就讀完了,讀後我並沒有太多的驚奇,原因是,自己過去二十年的軟體產品開發經驗中,其實早就隱含了許多敏捷(Agile)的思維、技術和實作了。
這本書,我在它剛出版的時候就讀完了,讀後我並沒有太多的驚奇,原因是,自己過去二十年的軟體產品開發經驗中,其實早就隱含了許多敏捷(Agile)的思維、技術和實作了。
不過,Jeff在這本書當中,雖然沒有談論到太多的Scrum細節,他卻想藉由此書,來把原本軟體產業所獨享的好處,推廣到各種非軟體的產業領域去應用,企圖讓大家用對的方法做事,讓工作更有效率,讓生活更快樂,讓世界更美好,這個理念倒是讓我著實地佩服!
接下來,我想來跟大家談談,我的敏捷實務經驗和思維,以及,敏捷實務和傳統實務之間的關係和差異,應用敏捷方法到底有哪些大多數人所不知道的密技,敏捷方法又該如何應用在生活之中。
訂閱:
文章 (Atom)