Flex与JSON及XML的互操作
平台需要互操作性。在这篇文章中，作者仔细研究了Flex和JSON及XML的互操作性。文章也包含了使用E4X库来将XML映射到图表和表格组件的内容，还演示了如何使用as3core库来解码JSON消息。
文章
剖析短迭代
作者 Dave Nicolette译者 郑柯 发布于 2008年11月19日 下午3时56分
很多人都觉得：迭代的长度应该由发布周期的长短确定。我不同意，我认为这两个周期之间不应有关系。相对于长迭代来说，短迭代可以提供更为频繁的客户反馈， 同时也给予团队机会，让他们可以反思并改进自己的工作实践。短周期可以形成“心跳节奏”，这样的快节奏也足以展现更多意义。由于短周期的本性使然，团队不 大有机会创建过于冗长的工作项目，而这样的项目会使得人们很难产生成就感，除非等到大量的工作完成之后。即使发布的周期很长，下面这些好处仍然存在。
相关厂商内容
QClub：敏捷在互联网时代产品研发中的实践（12.27 深圳）
相关赞助商
InfoQ中文站敏捷社区，关注敏捷软件开发和项目管理，通过新闻、深度文章、视频访谈和演讲以及迷你书等为中国技术社区提供一流资讯。
好处
- 快速响应。在不影响正在进行的工作的情况下优先快速响应变化。产品负责人、客户或是代理人在迭代中期改变优先级或是添加新功能，这样的情况很多见。如果迭代时间足够 短，这种状况就可以得到更好的处理，因为变更在下个迭代中就可以容纳进来了，这样也可以避免打乱当前迭代本不应受影响的正常节奏。
- 问题检测。成熟的敏捷团队能够发现流程上的问题并马上处理。然而，目前看来，很多敏捷团队仍然在学习曲线上前行，他们还没有成熟到可以自己 发现并解决问题的地步。他们需要根据项目度量数据的变化来识别问题。由于趋势要靠三个点的连线才能体现出来，而项目数据每个迭代才能收集一次，因此更短的 迭代可以更快地暴露问题。
- 范围管理。如果待办事项列表中的条目都很小，那就可以灵活移动。较长的迭代会产生较大的用户故事。如果产品负责人需要变更待办事项列表条目的优先级，如果用户故事较大，那么变更这些用户故事造成的影响也更大。较短的迭代则趋向产生较小的用户故事。遵循INVEST原则，产品负责人也更容易变更用户故事的优先级。
- 迭代规划和跟踪。长迭代产生的较大的用户故事，经常要被分解为“任务”，也就是要将大块儿的开发工作拆分为可操作性更强的明细任务。接下 来，为了让团队知道所有用户故事的状态，这些任务要在迭代中跟踪，要么使用类似于“看板”的系统，要么使用迭代的燃尽图。很多团队每天都会停下来重新估算 尚未完成的个人任务。使用短迭代，可以去除所有这些内部流程的管理成本；用户故事变成了更小的工作单位，而人们也能够以更简单的方式跟踪迭代状态。
- 成为转向“无迭代流程”的基础。迭代式开发保留了一些瀑布开发过程固有的管理成本，即使我们付出代价想去掉它们也是如此。如果将每个迭代从 头到尾画一个价值流累积图（cumulative flow diagram），这些管理成本就会以“在途时间（lead time）”的形式体现出来。我参与过的一些团队，他们在自己承受范围之内尽量压缩迭代的时间。我注意到他们可以消除大量类似的管理成本。迭代时间越短， 让一切工作顺利进行所需花费的流程管理成本就越少。
从另一方面来看，在有严格时间限制的迭代中工作，也可以带来一些敏捷方法的附加价值，包括频繁和有规律的演示和回顾、用来交付增量开发结果的一致性时间 表、频繁得到客户反馈的机会、以及对于“心跳”或是“脉搏”类似节奏的感觉，这样的感觉可以让团队在长期的开发过程中保证认真投入。使用时间盒的方式工作 是有一些额外的好处的，而有些团队在采纳无迭代的流程时会把这些好处丢掉，这就等于是“连孩子带洗澡水一起泼出去了”。而使用短迭代，可以减少转向超轻量 级、无迭代的流程所带来的痛苦；这也是可以预期的。
人们在转向无迭代流程时经常会犯一个错误，他们会将所有与“迭代”有关系的实践都抛弃掉。我们要将“迭代”的概念与有附加价值的敏捷开发特定实践区分开，并寻找能够减少流程管理成本、同时还可以保留有价值实践的解决之道。
潜在问题
有人在使用短迭代时遇到了困难。短迭代的拥护者Mishkin Berteig也提到一些潜在的问题 ：
- “密集的工作回让人筋疲力尽。”我想这是团队选择何种工作方式的问题。周期短，不一定意味着工作就一定密集。短迭代可能仅仅意味着小时间盒；也就是说，每 个时间盒承诺交付的工作更少了。在工作密度上不一定有什么变化。其他的敏捷原则（特别是“可持续的步调”）就是为了防止发生筋疲力尽的情况。
- “战略层面的思考很难跟日程相结合。”战略层面的思考跟每个迭代要做的具体工作没有太大干系。迭代是战术层面的。战略层面的思考是……呃，非战术层面的。这听起来更像是管理上的问题，而不是短迭代的特性之类的东西。
- “ 每个迭代必须完成的、耗费管理成本的相关任务占用了短迭代的大部分时间。”这似乎又是一个团队如何选择工作方式的问题。我曾观察到挤压迭代时间长度而引 发的一个有趣结果：人们首先“发现”一些并不是非常必要的管理任务，然后就不再做它们了。最后，团队只做必要的事情，换句话说，他们去除了流程中的浪费。 实际上，这些观察让我对Jim Shore在Java Ranch上的发言持 保留意见。他认为更长的迭代给团队的压力更小，因此有经验的敏捷团队更适合用长期的迭代。我觉得我们不必在迭代规划上花费更多时间， 我认为迭代规划还可以更少些。我支持更短的迭代，如果客户可以采取拉式的方法以单件流 （single piece flow）的方式提出需求，这些迭代甚至可能逐渐消弭。
- “对团队之外的资源或是人员的等待，这会使得工作的完成要跨越多个迭代。”组织上的约束造成了此类状况。如果试图采取的迭代长 度过短，以至于组织不能应 对，这样做并不合适。如果真这么做了，也就不能称之为“迭代”了，因为不可能在那样短的时间内交付工作结果，而组织也无法吸收这样的结果。要想有所进步， 我们必须识别出组织的约束。我并不认为临时的组织约束（它们是临时的，只要你真心愿意改变）就会使得短迭代不可行。简单么？没人会这么想。但如果组织的变 革很容易的话，那就没什么乐趣了，不是么？
InfoQ相关内容： Extremely Short Iterations as a Catalyst for Effective Prioritization of Work。
作者简介
Dave Nicolette自 1977年起就从事IT行业了，他在2002年找到了敏捷，并视其为传统IT行业很多内在问题的缓解和去除之道。从那时起，在敏捷和精益的思考和实践上， 他就成为了一名尽心竭力的实践者和大力鼓吹的提倡者。他喜欢与IT从业人士分享经验和有益的实践，并积极参与到敏捷社区的活动中。Dave目前是美国 Valtech科技公司的敏捷团队教练。
志愿参与InfoQ中文站内容建设，请邮件至editors@cn.infoq.com。也欢迎大家到InfoQ中文站用户讨论组参与我们的线上讨论。
Re:剖析短迭代
发表人
Love Jade
发表于
2008年11月25日 下午7时34分
什么是 extremely short 迭代？
发表人
Charlie Zhang（张恂）
发表于
2008年11月27日 下午8时11分
FAQ：如何确定迭代的长度？
发表人
Charlie Zhang（张恂）
发表于
2008年12月3日 下午8时16分
-
总体上说，短迭代有很多好处。不过我认为以下因素或许也需要参考：
(1)迭代周期不能短到很多stories都需要hang over（在本周期内不能通过分析师的Sandbox验证）。有人建议在每个迭代中每个开发人员（或pair）平均能完成2个stories为宜，因此迭代周期可能要考虑iteration story的平均大小。
(2)尽管敏捷项目的迭代计划和迭代关闭工作成本不高，但过于短小的迭代要么增加了这类成本的比例。如果省略了这类管理活动，又会让成员有点儿感觉像没有迭代一样。
(3)对于项目组成员来说，一个迭代在关闭的时候能够像客户展示足够多的新features并得到客户的首肯，是一种无法言表的精神激励。尽管每天客户代表都在关注项目进展、都能够看到最新成果，不过正式的showcase会有客户方的高层（如项目经理、业务负责人等）参与，这种更加“正式”的会议会让项目组觉得受到重视。如果迭代太短、产品增量不足，团队对于项目在稳步前进的感觉就会有所损失。
(4)还要考虑项目团队的大小、是否分布式协作开发等因素。项目过大而必须分为若干敏捷teams,或者分布式开发、沟通成本比例很高，可能迭代周期需要适当拉长（当然每个小team可以进行每周一次的内部retro)。
(５)我所参加过的敏捷项目有1周一个迭代的，也有2周一个迭代的，总体感觉还比较适中。其中有1个5个teams、一个location的项目中我们采用了１周的迭代周期，个人感觉有些短、有时候似乎感受不到迭代的存在。 -
迭代长度推荐在 1-6 周之间是个经验数值，过去很多敏捷专家和文献都有报道，比方 XP 的常规值为 1-2 周，Scrum 的常规值为 4 周。
原文的标题用的是“extremely short iterations”，不知 Dave 所说的“extremely short”具体是什么含义，是不是指长度小于 1 周的迭代？如果他的 extremely short 也是指 1-2 周（short）这个经验值，那么在这点上我们其实没有什么分歧，符合我们过去的认知。
对于周期小于 1 周（比方 3 天以内）的超短迭代，是否真的利大于弊，我有点怀疑。我觉得 Dave 在解释为什么 extremely short 要比 short 好方面，给出的理由仍然不够充分，很多优点其实普通的 short 迭代也具备。超短迭代也许理论上分析有很多好处，到底好不好，我想还需要更多国内外的实践案例、数据来证明。
迭代的长度是否真的存在下限？有人说，这个下限就是 0，也就是取消迭代。
而据我估计，至今国内还有大部分软件开发组织尚不清楚地知道自己为什么要迭代、如何做好迭代式开发，因此超短迭代、无迭代过程（看板）对于国内来说可能太超前了。 -
我的观点可能与 Dave 等人略有不同，供大家参考。
来自 敏捷 FAQ：
很多经典文献、教材上都有关于这个问题的解答。迭代长度通常建议为 2-6 周（或 1-6 周），这是一个经验数值。到底选择几周为一次迭代，这个问题其实不太难，因为通常你只有 1、2、3、4、5、6 这 6 个数字需要选择。
我们太极敏捷派的建议是这样的：
如何确定迭代长度，有这样几个关键点需要权衡（包括但不限于）：
第一，我们希望每次迭代开发，可以获得实质性的进展，完成足够多的开发任务，所以对于普通项目，1 周甚至小于 1 周的迭代长度就显得有点短，做不了几天的开发就要暂时 close，不太合算。
第二，迭代任务（包括模块集成、系统测试、评审等等）的完成，应该比较顺畅（streamlined）、从容或者适度紧张，没有非常紧迫、仓促的感觉。如果在某次迭代开发中，需要砍掉很多完成不了的任务，感到进度很紧张，那么很可能说明迭代的长度设置太短了，在下一轮的开发中应该增加迭代的长度。
第三，对于每个项目团队而言，合适的迭代长度有一个有效区间。总体上我们希望迭代越短越好，它有个下限，短于这个下限就可能得不偿失。那么，迭代时间为什么不能过长？它的上限是多少呢？迭代的主要目的是为了及时获得各方面反馈，确认已开发的内容是正确和可靠的，从而减少风险，保证开发能够始终稳步地、沿着正确的轨道前进。显然迭代过长，很长时间不对已开发的系统部分进行验证、反馈，随之而累积的各种风险就可能增加，形成返工和浪费。如果超过一个半月（6 周）以上，还都拿不出一些可以执行、验证和 demo 的软件程序，那么这样的项目开发显然不能说是高效的。
从 2 到 6 周，建议选择偶数 2、4、6 周作为迭代长度，排除奇数 3、5 周。执行周计划周总结和月计划月总结是国内很多企业比较普遍的做法，显然设置迭代长度为半个月、一个月或一个半月，就能与之相合拍，更自然和便于管理。设想，当您做月度总结的时候，只完成了 1 又 1/3 的迭代，会是什么感觉？
迭代长度通常还与整个项目的工期（或复杂度、规模）有关。如果项目的工期在 1 年以上，那么 1 个月或 1.5 个月的迭代长度就是比较合适的。对于进度压力不同的项目，人们的心理紧张程度是不同的。假设 2 周就要完成一次迭代，持续干上一年，大家会不会感到太累、太频繁？如果整个项目工期小于 3 个月，那么 2 周迭代甚至 1 周迭代，就是非常合适的。对于进度这么紧的项目，可能每周、每天都是非常宝贵的。
通常，张恂会向客户推荐采取 2 周或 4 周作为迭代长度的首选，3 周、5 周和 6 周作为备选，往往大项目、比较复杂的项目才会采用 6 周，6 周以上基本不考虑。2 周通常适合各方面很成熟的开发团队。如果一个传统瀑布团队，要尝试着转向迭代开发方式，从 4 周的迭代开始学习、积累经验，然后逐步缩短迭代长度，是比较稳妥的改进方式。
建议一个团队在熟练使用 2 周迭代一段时间（比方半年）之后，再尝试 1 周迭代。通常一个团队在开发和管理方面经验越丰富、越成熟，各方面的细节控制得越好，就可以尝试越短的迭代。
此外，不同的项目开发阶段，可以采用不同的迭代长度。根据 UP 的建议，我们通常可以把一个项目分为起始、细化、构造和移交四个阶段。项目前期的起始、细化阶段，很多内容不明确，需要做很多探索性的工作，一般迭代的长度可以适度拉长，比方 2-4 周；而在构造、移交阶段，架构已经明确和稳固，主要追求开发实现的速度，所以迭代长度可以适当缩短，比方 1-2 周。
最后，最重要的一点是，在敏捷开发中，迭代的长度完全是可调的。如果开始的迭代长度设置太短，或太长，都没关系，我们可以在随后的迭代中根据项目实际情况的反馈进行调整，这就叫自适应（adaptive）。
www.zhangxun.com
3 条回复
回复