Deliver Project on Time 敏捷專案管理實務心得 2014/06/13

Purpose and background: 
小妹身為PM一枚,公司規模大約200人,後端研發分為4,5 個team,分屬不同產品線,但彼此之間的開發關係又錯綜複雜,開發一項功能時常需要喬過來喬過去,近半年公司開始導入redmine系統,希望能整合前端sales request與後端開發,更重要的是resource 使用效率與deliver project on time! 因此報名此課程。

User story: 
過去在mainconsole team有使用user story方式去釐清request,好處是: 
1. 客人要的feature,不見得能解決他的問題。 User story有效的幫助釐清功能與需求 但這個方式會比較適合在project 開發,在一個有roadmap的product來說,使用user story來釐清需求就會比較不具效益。
2. 切割feature中task,提升估算schedule準確度,以及降低因人腦容量過低miss掉的task機率
不過,user story還是必須搭配SRS服用,才能有Whole picture of product,而MC team過去能這樣做,主因還是他們Allocate 人力在SRS上,如果是其他Team的PM也導入user story,則變成user story and SRS都由pm寫,PM端的planning與討論時間會再拉長,省下研發的development切割task 和評估時間,這樣的比例權衡我不確定會不會比較合適。

另外XDite強調在初期的討論,prototype不宜過於精美,否則會迷失在細節上,這一點我雖能了解,實際上帶案子的經驗卻是相反,XDite以”過場動畫”為例,強調不該在前期討論nice to have,但我這裡實際案例則會是,因為沒有完整的prototype,成品連icon都會是歪的,然後「spec沒有定」這句話,就會出來了XD;且如果prototype不夠細節,也比較不好叫客人畫押。

專案管理tool:
目前小妹使用Microsoft project 管理project,好處為
1. 同樣有task (切票)概念: schedule估計與不遺漏task
2. 有前置作業概念:那些是必須在那些完成之後才做,如同Block
3. 有時間連續性:哪個task滑掉1天,可以馬上清楚知道對於整個project影響
4. 有resource bottle neck:任務分配上誰會是整個project的bottle neck一目了然
 

不過這樣的管理工具,對於開發時哪一個task中間發生甚麼變化,會不清楚,對於pm來說可能足夠,但對於DM來說,則會無法利用這樣的工具highlight risk。
而redmine 相較之下,會是比較適合與整合後端開發的一個平台。

本部門使用Redmine約莫半年多,痛苦不堪,主因是redmine技巧和concept錯誤,造成輔助工具成為負擔,包括:
1. 害怕開ticket: ticket本來就應該開多、開細,不應該害怕開,如果不開、只開大項,造成task不知道應該註記在一項task,每每想用時都遇到疑惑,最後使得大家覺得redmine好難用。
2. 誤把tracker 當Activity 用:目前我們為了區分工作內容,把tracker分得很細,用以同時記錄工時,導致ticket怎麼開怎麼怪; ticket 應按照project的task開,tracker只是分ticket種類,細項的activity 拿來記錄工時種類
3. Ticket永遠開給自己: 目前公司有三個redmine,各自為政,導致自己開了ticket, 後續有任何問題,都只能透過別的平台例如email, google doc等等了解狀況後,再自己update回去redmine,頗silly。

這次上課的主要收穫就是,我們應該大破大立,整合各team 的redmine,並重新設置tracker和activity,讓remine更好用,第二階段則開始整理wiki,把所有project資訊藉由每次的milestone整理出來,讓所有文件一目了然。
Photo
Shared publiclyView activity