剖析短迭代
敏捷教练Dave Nicolette提出：我们应该如何设定迭代长度？是要根据发布周期的时间么？使用短迭代又有哪些好处？
新闻
应对敏捷项目中的干扰
作者 Vikas Hazrati译者 郑柯 发布于 2008年6月6日 上午4时8分
干扰，正如它名字所显示的，是影响敏捷项目团队速度、减缓其前进的刹车闸。有些干扰是必需的，其他则不是。关键在于：要识别出影响工作进程的干扰，并尽量减少它对项目的负面影响。
Extreme Programming讨论组上有一个有趣的讨论，Alistair Cockburn在其中分享了他认为影响“团队涌流”的一些主要干扰：
（1） 过多会议（程序员必须放下工作去参加一个接一个的会议，以及）
（2） 过多同时进行的项目（程序员必须放下项目A的工作，切换到项目B）。
这些干扰会消耗很多的时间和精力。不过一般总可以找到调整项目、会议和每天工作安排的方式，减少干扰，程序员也可以多花时间，进行不间断的编程。
Alistair接着说道：团队中，有时必须有一个人完全负责接电话、参加会议、找人、做与客户的接口等工作。而此人的工作也因此而无法达到团队对他的期望。但是Alistair说，对这个人工作产出的期望，应该受限于他能够花在项目上的时间。
在他的众多项目管理模式中，Alistair将此命名为“牺牲一个人”。Alistair在这个模式里提出，一个项目可能无法像当初规划的运转那么快，这是因为有很重要的干扰占用了整个团队的时间。虽然干扰可能是很重要的次要任务，而且无法放弃；但是，它确实分散了团队在最主要的任务上的注意力。
Alistair认为解决问题的方式是，分配一个人来专门应对干扰。虽然这个人可能觉得自己是牺牲品，但是团队剩余的成员可以通过处理最主要的任务来取得工作进展。
Gojko Adzic也提供了类似的意见，他讲述了自己的故事：当时他在一个项目中承担架构师的工作，但却花费了很多时间来充当软件方面的润滑剂。相关的任务包括：解答新人的问题、协调不同的讨论、与客户沟通、参加各种会议。Gojko补充道，如果他试着花更多时间在编程方面的任务上，很多其他团队成员就必须充当润滑剂，这拖慢了整个团队的速度。因此他决定接过来所有的次要工作，让其他人集中精力处理主要任务。Gojko提到：
虽然我仍力图编写代码、了解项目的整体进度，但是团队在做计划时，已经不怎么再指望我的参与了——我的时间不会被计算在内。四个月之后回头再看看，考虑到项目的进度以及团队的工作效率，我认为这样解决问题很有效。
对于Alistair提出的第二个主要干扰，邮件组的成员们都同意：让人同时参与多个项目没法取得好的效果。对于这样带来的心态问题，Gojko这样总结。
问题在于，如果你的成员是四、五个只能部分参与项目的人，项目干系人会认为你拥有一个完整的团队；而实际上，他们最多相当于一个全职投入的人，如果不是更少的话。
为了进一步表明支持人们专心投入单个项目，Gojko说到：团队成员同时在多个项目中工作，沟通和协调工作会占用相当多的时间和精力。他举了下面这个很有趣的例子，来证明他的观点：
10个投入程度为20%的人，他们的产出理论上相当于两个全职人员；但是协调这10个人却要比协调两个人花费更多的精力。而且与协调10个全职人员的精力花费相当，甚至有可能更多。我想这是因为下面的原因：由于其他工作的要求，这10个部分投入的人会经常无法参加站立会议和进度会议，而且不能像10个全职人员那样始终坐在一起。两个全职的人，基本上不需要什么协调，也没有多少沟通上的无谓消耗。
讨论组的人都认为：要去除与这些主要的干扰相关的风险，应该从两方面下手：牺牲一个人，让他来处理所有的次要任务；还要注意不要让一个人同时参加多个任务。
查看英文原文： Handling Interruptions on an Agile Project
本该是项目经理干的事
发表人
Jeff Xiong
发表于
2008年6月7日 下午1时24分
Re: 本该是项目经理干的事
发表人
ozzzzzz liu
发表于
2008年6月8日 上午2时17分
Re: 本该是项目经理干的事
发表人
zhimeng wangzm
发表于
2008年6月8日 上午9时17分
Re: 本该是项目经理干的事
发表人
zhx wei
发表于
2008年6月9日 上午4时42分
是这样
发表人
liu qiang
发表于
2008年6月10日 上午2时17分
Re: 是这样
发表人
jin qinghai
发表于
2008年6月10日 上午9时35分
.gif)
6 条回复
回复