|
正如你现在可能已经意识到的那样，由于它常常导致一些不能够被实现的需求定义或是过多的需求指定，这种解决方案比理想中稍差一些。 项目管理者联盟
这起初引起产生了不切实际的期望，然后关于每一个需求都不能够被实现的意识开始逐渐被相关的部分所理解，这导致了抵触的失望的气氛。项目管理者联盟
这还导致了需求团队独立隔绝的工作，剥夺了他们从开发团队得到的反馈，接下来导致产生在需求团队及开发团队之间的冲突。它还阻止了从首个需求集合的实现中得到的经验能够被团队整体学习并用此来提高需求质量以及整个团队效率的机会。项目管理者联盟文章
这种模式通常可以在这些组织中看到：项目管理者联盟
开发团队想要进行迭代但是已经证明了当前解决方案对业务组织的适用性。
开发被公司外包，这公司并不熟悉迭代式增量技术，而外包公司本身采用了它们。
开发团队与业务具有敌对的关系，并且不信任他们作出的任何决定或是与他们协同的工作。
业务不能区分需求的优先次序并且坚持将他们作为一个完整的，不可分割的集合而对待。
由于这种需求方法导致一种将团队成员置于他们所进行的工作种类的功能性“筒仓”中的企业结构，因此必须小心的进行处理。这在团队成员之间建立起了屏障，在解决方案发布过程中降低了通信及团队效率。这个问题通常与奖励成员完成了必须而不充分的工作以发布解决方案的测量系统混合在一起。对职能上有组织的团队来说将“成功”理解为对一个良好需求文档的发布或是一个被签署的软件结构文档是很普遍的情况。 项目管理者联盟
虽然这些事物对达到发布解决方案的目标来说是必须的，然而它们的价值并不在于它们自身。如果解决方案发布失败，已经被完成的需求文档没有产生任何价值。虽然也许需要组织于功能线的关系报告以促进技术发展及事业成长，但是对进展和结果的测量需要与解决方案的发布相符合。这通常导致一个“矩阵式的”报告结构，其中每人都需要向至少两个组织进行报告：一个从职能上与职业生涯相关联，另外一个则与项目及其目标相关联。pmp.mypm.net
前向－负载需求，后向－负载开发
如果在需求中存在着任何稳定性，那么正如图2－3所示，开发迭代可以在需求工作完成之前很好的展开。项目管理者联盟
 项目管理者联盟
图2－3：需求规范与开发迭代的重叠项目管理者联盟
它显示了一个更为迭代性增长的解决方案，但是它仍旧使需求及开发团队工作于不同的管理筒仓中，这必然要承受所有的通信开销以及冲突。项目管理者联盟
需求管道
存在着向管道模式发展的诱惑，正如图2－4所示的那样，需求团队为下一次迭代周期进行需求工作，同时开发团队实现本次迭代所定义的需求。项目管理培训
 项目管理者联盟
图2－4：需求管道项目管理者联盟
这种模式立即提出了一些问题，包括：团队工作于哪次迭代？迭代是否重叠？团队是否会在某些时候对多于一次的迭代进行工作？从个人及项目管理视角，人们怎样知道他们正工作于哪次迭代，或者他们的优先级是什么？（从管理视角对迭代进行探讨将是本系列文章中第三部分的主题。）项目管理者联盟
当需求团队与开发团队不可能像一个单一团队一样协同工作时（由于法律，地理，或是组织上的原因），需求管道模式是真正唯一适合的。项目管理论坛
实时需求
理想的，为了提供最敏捷的、灵活的、并且聚焦的开发团队，需求和开发工作被完全整合为一个单独的良好定义的迭代集合。这将扩展典型的迭代式开发模型以包括发行的需求规范及其系统测试。这将扩展上个月的文章 中的迭代模型如图2－5所示。service.mypm.net
这种工作方式是最有效的，但是它取决于要有一个集成的、合作的、包括业务及用户视角表现的同时技术导向的开发团队，项目经理博客
 service.mypm.net
图2-5：整合需求规范和系统测试的迭代bbs.mypm.net
这个方案通过对业务解决整体建立一个着重于有效的、迭代的增量式开发将迭代式增量开发引入他们自然的结论。这允许团队调整、自纠正它们的过程以确保尽快的分发业务价值。 项目管理培训
正如你可以看到的那样，当团队成员发现他们自身是一个项目团队整体的不可分割的部分，他们在整个项目周期内不仅仅工作在初始阶段时，对采用迭代式增量方案的业务分析团队来说作用是十分显著的。分析师也将发现迭代式的定义需求，通常采用实时的方式，常常在同一次迭代中实现这些需求是一样。项目管理者联盟
分析团队将为分发他们的解决方案而共享责任，分担与他们要求实现责任的项目的关联程度。需求文档，不仅仅作为对“最终”需求的必须被分发的不可变记录，而变成了一个活跃的在业务和关注何种需求能够被分发以达到一个满意的解决方案的开发团队之间的合同。当被作为一个合同来考虑时，需求文档指明了双方的责任，同时对谈判开放。它的规模及复杂度将意味者双方之间存在的信任。项目管理者联盟
系统用户
系统用户视角与客户视角非常相象，用户可以看到关于进展的周期性迹象以确保解决方案能够适应他们的实际需要。 club.mypm.net
对于项目整体，将用户包含入迭代所产生的发行版本的演示和评估一般来说这是非常有利的。但在每一个迭代中未必时必要的，因为允许对早期部分实现的广泛回顾可能会起到反作用。与系统用户的常规交互也可以帮助提醒开发团队的发布业务职责，而不仅仅是迷人的新技术。它还使得需求本身可以像它们的系统一样被验证。项目管理者联盟文章
对于早期用户反馈请求的益处，特别是在应用以及用户接口设计领域，已经由前面所提到的案例被证实。我们认为它提供了有价值的教训。项目管理者联盟
|
