裁员下的敏捷

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 指出，传统产品负责人或顾客角色的好处是在于，如果产品未能满足顾客期望时，业务部门对自己负责，而不是责难其他人。

查看英文原文： Doing Agile After Layoffs