什么时候都不要延长迭代？
Jeff Xiong
> 无论何种情况，最终达成的一致意见有：发现问题就马上提醒产品负责人；演示已经完成的功能；产品负责人可以重新排定优先级；使用回顾会议发现根本原因；不要延长sprint。
假想一个情况：做了一个迭代，其间一个重要的依赖平台更换版本，导致配置库主线不可用，并且特性与平台的依赖也出了很多问题，绝大多数测试用例跑不起来。
这个时候应不应该延长迭代来集中解决这些问题，让第二个迭代从一个比较稳定的、至少可以前进的基础开始？
大家的感觉呢？
--
Jeff Xiong
Software Journeyman - http://gigix.agilechina.net
Open Source Contributor - http://fluorida.googlecode.com/
Technical Evangelist - http://www.infoq.com/cn/
Xiaoming Wang
我个人观点很简单，就是计算ROI，看哪一个方案的产出商业价值和投入的资源比大，就使用哪种方案。某些时候business critical的任务即使不能快速清晰的定义价值，也要放到高优先级去解决。
是不是还有其它的有效的实践来解决这个问题呢？
Best Regards
Xiaoming Wang (王晓明)
Home Page个人主页: http://AAladdin.com
Web log博客: http://ossme.com
LinkedIn Profile个人简历: http://www.linkedin.com/in/wangxiaoming
kang kang
笨羊羊
一旦有一次下不为例，就容易有很多次的下不为例了。
欧阳丹
砍掉无法交付为“可工作软件" 的故事,全力以赴保证剩下的故事，然后演示他们
你们的情况似乎是代码级别的问题，如果代码耦合度低，你至少可以演示你们可工作的部分
把依赖平台或者配置”假设为正常或者不正常“，用”桩“来模拟依赖环境，保证每个模块都是独立可测试的，这样你们仍然能够有可工作的代码演示
2009/10/16 笨羊羊 <szl...@gmail.com>:
> 开口子要慎重。
> 一旦有一次下不为例，就容易有很多次的下不为例了。
> >
>
欧阳丹
换成”我们“稍微要好一些，不好意思。
2009/10/16 欧阳丹 <dano...@gmail.com>:
克强
上个为期4周的迭代按时完成，在这个迭代的计划时，产品经理（可以理解为Scrum中的PO)要求实现A,B,C,D,E 等5块功能。
开发团队估算后认为，下个迭代就算加班也只能做A,B,C,D， 优先级最低的E放到下下个迭代。产品经理认为 E 在8周后才做完，太晚了，5周后必
须要，要求 下个迭代包括 5块。
因此，开发团队的方案有
方案1： 下个迭代为期4周，做5块功能，承担超负荷风险，一开始就加班，也许过程顺利，估算过于悲观
方案2： 下个迭代为期5周，做5块功能
方案3： 下个迭代为期3周，做3块功能， 再下个迭代为2周，做2块功能
自由天堂
以我们的情况看，之所以不能接受这个版本计划，其实是因为下个版本要等一个月，这个客户是很难同意的。所以我们现在虽然不强调敏捷，但是面对现场急迫的
要求，为了尽快反馈，实际上迭代周期还是在缩短。
顺便说一下我对迭代周期的理解，长迭代能够合并一些验证（测试）工作，降低成本，但是带来的后果是──迭代中的功能点不能区分优先级高低，都被强行统一
到一个交付时间点，这在与客户进行反馈时缺乏灵活性。因此越是客户敏感的项目，迭代应该越短，越是验证成本高的项目，迭代应该越长。
克强
On 10月17日, 上午7时32分, 克强 <zhangkeqi...@gmail.com> wrote:
克强
如果改成如下：
迭代一般是3周，在这个迭代的计划时，产品经理（可以理解为Scrum中的PO)要求实现A,B,C,D,E 等5块功能。
开发团队估算后认为，下个迭代就算加班也只能做A,B,C,D， 优先级最低的E放到下下个迭代。产品经理认为 E 在6周后才做完，太晚了，4周后
必
须要，要求 下个迭代包括 5块。
因此，开发团队的方案有
方案2： 下个迭代为期4周，做5块功能
方案3： 下个迭代为期2周，做3块功能， 再下个迭代为2周，做2块功能
On 10月17日, 上午9时03分, 自由天堂 <li.jia...@gmail.com> wrote:
> 这个例子恰好说明4周的迭代周期太长了。
笨羊羊
自由天堂
关键在于，过长的迭代周期势必难以调整，最后feature放入的越来越多，然后发布就变成一个big deal了
其实，如果你的功能粒度可以支持的话，我倒是倾向于在方案3的基础上更进一步，把迭代周期降到 2 周甚至 1 周
不管怎么算，你的E必然第五周搞定，那么何必让它拖累前面的功能点呢
克强
破坏时间箱原则是我比较担心的地方。
相信团队会自我学习，以后的迭代周期应当有明智的选择。
"开口子"并不可怕，相信敏捷的团队可以分辨。
也会把这里的意见转达，当然这里是人人可以访问的。
张磊
自由天堂
而"开口子"所开的是管理上的口子，制度要有稳定性，否则问题多多。
所以它们并不抵触，外圆和内方的关系而已
On 10月21日, 下午6时25分, 张磊 <ndzls...@gmail.com> wrote:
> 害怕"开口子"跟拥抱变化会抵触么？突然联想到的。。。
>
> 2009/10/20 克强 <zhangkeqi...@gmail.com>
姜志辉
Xu Yi
www.mountaingoatsoftware.com/.../25-a-regular-heartbeat-the-benefits-of-fixed-iteration-length - 网页快照 - 类似结果
-
Concept: Iteration
- [ 翻译此页 ]Iterations are timeboxed, meaning the schedule for an iteration should be ... Iterative development is very disciplined: the iteration length is fixed; ...
epf.eclipse.org/wikis/.../iteration_C20B1904.html - 网页快照 - 类似结果
--
- - - - - - - - - -
Xu Yi, Kaverjody
Agile Coach.CSP
Test Automation Coach
Blog : http://damianji.spaces.live.com
- - - - - - - - - -
笨羊羊
但是如果步调总是象打仗一样急，那反倒更吃不消，还不如战役间有休整的一张一弛。
笨羊羊
● Muri------超负荷的人员或设备，指对设备或人员施加超过其承受能力的压力。
