BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

裁员下的敏捷

| 作者 Mark Levison 关注 0 他的粉丝 ,译者 麦天志 关注 0 他的粉丝 发布于 2009年1月11日. 估计阅读时间: 3 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT