裁员下的敏捷

  • Mark Levison
  • 麦天志

2009 年 1 月 10 日

话题:敏捷Scrum文化 & 方法

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

敏捷Scrum文化 & 方法