企業專案治理

我的Scrum新體驗 - 測試策略篇

在規劃測試時, 我們一開始面臨的問題是, 整個開發時程分成哪些階段. 也就是說, 是否要都是要由 iteration 組成呢? 可是我們公司有所謂的 alpha 和 beta 階段, 尤其是 beta 階段, 我們必須把產品交給外面客戶去做測試, 這可能是無法廢除的, 那要怎麼配合呢?

我的Scrum新體驗 - 回顧會議篇(Retrospective Meeting)

回顧會議是 Scrum 中最重要的一個會議, 它讓你有機會反省在上個 sprint 所做的一切事情. 老中很努力工作, 可是卻不檢討做事方法, 所以工作的很辛苦,卻不見得有效率.

我的Scrum新體驗 - 每日會議篇(Daily Scrum Meeting)

我的專案開始採用 Scrum 的方法來開發專案, 這是一個新的體驗. 一開始時是工程師們說要這麼做, 我的想法是一則以喜, 一則以憂. 喜的是終於有機會可以嘗試 agile 的方法了, 憂的是在這麼短的時程內, 用新的方法似乎風險很大. 不過既然大家都願意這樣做, 那就豁出去了. 因此, 接下來我將會分享這幾個月來(開始於2009/2中), 使用 Scrum 的風風雨雨.

為什麼我不推薦敏捷開發

當專案成員越多,我越不推薦敏捷開發,原因在於「當連自己要做什麼事、為什麼這樣做、這樣做為了解決什麼問題」都搞不清楚前,就跳下去玩敏捷開發,那和比通靈還慘,通靈起碼還有個目標物在前面,搞不清楚狀況的人只能陪他跳世界迷霧開地圖了。 敏捷開發 - MBA智库百科 最下方有段「對敏捷開發的誤解」。可順便參考 敏捷軟體開發 - 維基百科。 誤解一:敏捷對人的要求很高 說高不高啦,撇開實作技術不談,你覺得要找到清楚專案開發流程、知道每位專案成員的工作內容、職責範圍、產出,並清楚專案目標、需求、使用者需要的開發人員(含設計師)很容易嗎? 如果上述條件無法達成

《超速變革》閱讀心得

這幾日看完了John P. Kotter的最新作《超速變革》這本書。 我之前讀過他《領導人的變革法則》這本書(很不錯的一本,但可惜已經絕版),對於他針對組織變革的概念非常認同。 尤其他提到領導人在變革前要花時間努力建立危機意識,跟我的經驗完全吻合。 我自己在很多企業協助推動專案制度的變革(這類變革通常都會影響整個公司層面),也發現只要公司高層在前期沒有花足夠時間由上而下的溝通「為何要做這類事」、「為何是現在這時間」、「為何這麼急迫」,結果通常就很難讓人滿意。 要不是會因為大家重視的問題不同而在方向上逐漸失焦,再不然就是中階主管因為工作增加而反彈。

專案經理必會拿捏的藝術:關於授權

最近很少接觸技術類的內容,都沒什麼機會撰寫一些深入技術面的內容跟大家分享,只好跟大家分享自己在管理上的一些經驗,讓同為IT人的大家參考參考,在講這個之前,我還是必須要先聲明,管理/領導的手法百百種,不見得我的方法適合用在每個場合,大家可以提出不同的看法與案例一起討論討論。 我想我可以有這麼多機會學習,去碰壁,我都要感謝我的主管R先生跟N小姐,由其是R先生讓我有很多的機會嘗試各種管理手段,在一次又一次的碰壁中學習,這樣的經驗真的很珍貴,而我也希望這樣的經驗可以給各位做為參考。

如何帶領團隊往正確的方向衝?

三年多前我剛進入兵荒馬亂的環境,承受一波又一波的挑戰時,老闆古哥對我們部門說了這麼一段話: 『唯有不斷的進步,超出業務單位的想像,我們才能獲得更多的掌聲,也才不會被業務單位壓著打。』