顯示具有 Agile 標籤的文章。 顯示所有文章
    顯示具有 Agile 標籤的文章。 顯示所有文章

    《敏捷方法的成功密技》系列文章總覽

    敏捷團隊衝刺老失敗,人才也是難留下,問題到底出在哪?

    敏捷團隊在「衝刺規劃會議(Sprint Planning Meeting)」中所做的工作計畫,是對該次衝刺的一種承諾,也是衝刺的目標。因此,「衝刺工作的完成度」也常被當作是敏捷團隊的績效衡量指標之一。

    這個指標本身並沒有什麼問題,問題在於,當敏捷團隊無法達成衝刺目標的時候,公司會讓他們面臨什麼樣的後果?這個後果,對敏捷方法是好的?還是不好的影響?

    專案團隊加班的藝術

    有同學問我,「老師,用敏捷方法做專案,是不是就可以不用再加班了呢?」

    參與過「專案」工作的人,對「加班」這件事肯定都不陌生,而且老實說,真的遇到狀況,應該也很難可以躲得掉,不管你是用傳統式的還是用敏捷式的專案管理方法都一樣。

    只是說,有些人加班加得很開心,有些人卻加班加得很傷心;有些人只需偶爾加個班,有些人卻常被迫要加班。為什麼會有這樣的差異呢?加班又怎麼可能會讓人覺得開心呢?

    此外,加班對傳統式專案管理的專案團隊,或對敏捷式專案管理的敏捷團隊而言,又會有什麼樣的影響呢?

    什麼樣的專案適合使用敏捷式專案管理


    前陣子有位學員來電,「老師,我是以前上過您敏捷式專案管理課程的學員,我在您的網站上有看到,您有在輔導企業導入敏捷式專案管理,我想邀請您到我們公司,輔導我們用 Scrum 敏捷方法來做專案...」

    對方向我介紹完他們公司後我才知道,原來他是這家新創軟體公司的共同創辦人。

    用戶故事時間老是估不準?三大技巧助你敏捷團隊一臂之力!


    「老師,我們公司有在使用敏捷方法做專案,可是團隊在估算用戶故事(User Story)時間的時候,老是估不準,有的時候會多留很多 buffer,有時候又少估很多時間,導致衝刺的工作做不完,這該怎麼辦才好?」 

    我在《Scrum 敏捷方法裡,渾然天成的九大風險管理把關設計》一文中談過,敏捷方法的框架其實隱含了不少巧妙的風險管控設計,其中當然包含了管控「因時間錯估而延誤」的風險。這裡我們先假設,這位學員提及的敏捷團隊,有確實遵守敏捷方法要求的原則來運作,沒有自行偷斤減兩,可是團隊對於時間的估算,卻依然不夠準確。在這樣的前提背景下,我們還有什麼其他的招數,可以來改善這樣的問題。 

    優秀敏捷大師(Scrum Master)應具的能力和特質有哪些?

    下課後一位學員來提問,「老師,我們公司想要開始導入敏捷方法做專案,我現在是工程師,我想轉換跑道做敏捷大師Scrum Master),您覺得這樣好嗎?」

    「好不好,我不知道,不過,如果你想做敏捷大師,除了剛剛課堂上談的之外,你還可以先想想這些問題,例如...」

    敏捷式專案管理的導入輔導,該怎麼找教練?


    「老師,上課前,我以為 Scrum 很簡單,自己上網看就好了,根本沒必要來上課,今天上完課才知道,原來還有這麼多實務上的眉角(台語)要配,敏捷方法才會有明顯成效,而且,這些都是在網路上沒看過的!還好當初我沒有拒絕老闆派我來上課

    「恭喜你有收穫啊!Scrum 敏捷方法的原創,只有描述一些非常簡潔的框架(framework)和原則(guidelines),讓很多人誤以為,任何團隊都可以立刻上手,馬上見效,可是事實上,就像上課時談的,事情並沒有這麼簡單!」

    「老師,我可以參加你接下來的『敏捷式專案管理輔導案』嗎?」

    干擾退散,創建跨領域職能敏捷團隊,關鍵在哪裡?


    日前到某企業授課,午餐時,業主 IT副總向我表示,關於敏捷方法「一人專注於一個專案」的設計,施行起來實在是有困難。因為實務上,其轄下專案眾多,人力明顯不足,而且總是會有偶發事件,需要把敏捷團隊中的開發人員拉出來,緊急支援處理,這該如何是好?

    野蠻國度下,蒼狗幫團隊的敏捷生存之道


    非洲大草原,一個動物必須不擇手段才能生存下來的野蠻國度!這些動物,有的仰仗天生強健體魄,有的倚靠集體智慧合作,孰優孰劣,看看數萬年的演化後,誰還在這草原上稱霸,便可知曉!

    身材瘦弱的,無法單挑對手,可以想辦法撂人一起打。若是幫手再多也沒轍,那也可以轉身快速落跑,不被對方逮到就好。無論是哪種策略,只要能讓族群存活下來,就是一個好策略

    在大草原旱季來臨之時,水,成了極度珍貴的資源,各動物族群,無不想盡辦法爭奪那烈日下僅存的幾個小水窪。六隻瘦小非洲野狗組成的小團隊,竟能搶下十數隻大型鬣狗大團隊的地盤,這到底是怎麼做到的?這跟敏捷方法又能扯上什麼關係?

    【矽谷最夯.產品專案管理全書】推薦序

    照片由商周集團提供

    於過去二十年的科技業職涯期間,我非常有幸地能在不同規模、不同文化的公司裡,歷練產品開發團隊中的多種職務角色,並與許多優秀的夥伴們一起合作,打造出影響全球千百萬使用者的產品。

    這些我參與打造過的產品有純軟體產品,也有軟硬體緊密整合的產品;有PC平台的產品,也有手持式裝置產品;有個人使用的消費性電子產品,也有企業應用的高規要求產品。這些產品當中有些很成功,有些則是無疾而終,而且很多時候,公司並不是很清楚,自己的產品究竟為什麼會出乎意料地大賣,或為什麼產品會莫名其妙地就死掉。

    敏捷方法的成功密技(二):專案管理的「溝通斷層」


    在上一篇文章《敏捷方法的成功密技:Scrum 為何對你很重要?》中,我們談到了Scrum這個在敏捷開發方法中頗受歡迎的一派,也談到了敏捷式與瀑布式,在產品開發和專案執行成功率上的巨大差異。可是,既然這個東西這麼讚,又簡單易懂,那為什麼還是有很多公司和組織在導入這個方法的時候,不盡人意,東卡西卡的,無法體驗到敏捷法的巨大好處呢?

    「用戶故事 User Story」能讓需求簡化,還能更省時、更省錢,提供更多價值,這…可能嗎?

    回歸原點的設計就是好設計,需求的蒐集也是一樣的道理(圖片來源:www.ptbus.com)
    日前在EMBA的課程當中,老師談到了一個設計上的個案。這個設計個案是,一個只能往前推開的門,門上有個把手,把手旁有個「推」的字樣。這樣的設計到底有什麼問題呢?這和專案管理又能扯上什麼關係呢?