裁員下的敏捷

Adrian Carr提到在裁員下如何讓團隊能繼續以Scrum方式運作。原本團隊有四個開發人員，一個測試人員，一個產品負責人，以及一個Scrum Master。在裁員下，團隊只剩下四人，Adrian當上了兼職的Scrum Master，並沒有產品負責人。相關的業務單位也同樣面對裁員，所以只能提供一個“明白該業務並且已受權對專案作決定的高階聯絡人”。Adrian所面對的問題是：儲存Scrum的哪些部分？Adrian的初步想法是： 

• 保持Scrum中在小團隊中有意義的部份：每日站立會議、短迭代、檢討、回顧、Burndown
• 團隊分別承擔產品負責人的工作，如跟各方有關人事、使用者等會議，但Adrian會維護產品Backlog，以及作出最後決定
• 減少浪費
• 把事情保持得儘量簡單
• 只考慮現行運作系統上的故事點數（story points），使團隊只付運較少點但易管理的功能，也縮短開發週期，提高回饋密度
• 同一時間只處理兩三個工作任務
• 集中先做最有價值的專案
• 清楚是為誰做軟體，知道他們的名字，職位角色，知道他們為什麼想這樣做
• 留意及抵抗一切拖慢團隊的外在因素

Innovel公司的Robin Dymond關注一個主要問題：欠缺一個專職的產品負責人。他指出讓開發人員當上產品負責人的角色，會使他們變成了業務專家，佔據了他們應該用來做開發的時間。他建議：

如果業務人員沒有時間的話，可以讓開發隊伍跟他們緊密地開短會議，業務人員可以同意接受條件而不用親自去寫，他們只專注於優先次序。但他們一定要承擔這責任，開發團隊不能當上這角色，因為開發團隊難免對要求有其他的理解，有不同的優先考慮，作出跟商業世界不一樣的決定。

Mary Poppendieck（"Implementing Lean Software Development"一書的作者）則認為，產品負責人常常都不是必需的，甚或都用不到去考慮這個角色的存在，因為如果開發人員明白客戶所要的東西，那 產品負責人就是兩者之間多出的層次，而資訊亦可能因為多了一層而流失。Mary認為，關鍵在於找出各方都能同意的簡易衡量方式作為目標，然後所有功能都能 以它對這目標所帶來的價值作出衡量。

Ron Jeffries認為要小心潛在團隊、產品負責人、業務部門之間不清晰的可能性，如果產品最後未必符合客戶所要，業務部可能會責難開發團隊所作出的決定，Ron指出，傳統產品負責人或顧客角色的好處是在於，如果產品未能滿足顧客期望時，業務部門對自己負責，而不是責難其他人。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-566784/，如需轉載，請註明出處，否則將追究法律責任。