|
精确度与准确度www.mypm.net
在一个成功的软件项目中，每一个开发阶段都加深了对发展计划、规格说明和完整解决方案的理解，因为每一个阶段都延伸了可执行序列和团队对竞争目标的认识。在生命周期中的任意一点，次要工件的精确性应与这种理解相平衡，在详细程度上保持一致，相互之间保持一定程度的可追踪性。项目管理者联盟
精确度与准确度之间的区别(在软件管理的上下文中)并不是它们看起来那样小。软件管理充满灰色的区域、情景依赖性以及不明确的折衷。对优秀的软件管理者来说，理解精确性与准确性之间的区别是一种基本技能，因为他们必须准确地对投资、风险以及变化带来的影响进行预测。未被证实的精确度——在需求或是计划内的——实际上是造成阻碍成功的潜在而微妙的因素。大多数时候，早期的精确性是不诚实的，造成了有比实际上更多的进展和更高的质量的假象。不幸的是，很多项目发起者和涉众要求这种早期精确性和详细性，因为这给了他们对已经取得的进展的(虚假的)安慰。项目管理者联盟
我在软件工业中所见的最常见的失败模式之一是开发有五位数精度的规格说明，而涉众其实对问题、方案或者计划只有一位数精度的理解。延长建立一个精确的需求理解或详细的计划的时间实际上耽误了对架构上更重要的问题的理解。你曾经做过、修改过、痛苦地回顾过多少厚度吓人的需求文档或是详细的管理计划呢?而几个月后当项目取得了有实际意义的可演示的进展，加快了涉众对实际的权衡的理解时，你又要全部重新检查这些文档和计划了。这种普遍现象在我们的行业里被称为刨光废物。bbs.mypm.net
一些成功的指导模式项目管理者联盟
迭代过程大多是由解决不确定性和管理软件风险的需要而发展的。这里的指导需要动态控制以及中间的检查点，这样涉众就可以评估到目前为止完成了哪些工作，应该对目标作出什么修改，以及如何重新分配他们的工作以使目标按照最为经济的方式组合。我曾观察到成功的软件集中型项目典型的四种模式。这些模式表现了一些“抽象规格”，对指导评估、范围管理、过程控制、进展和质量控制有所帮助。我有预感，多数在项目管理中“被鉴定过的”项目管理者对此都会作出消极的反应，因为这些理念在一定程度上是与传统相悖的。项目管理者联盟
范围管理：方案从用户具体的要求发展而来，而用户的具体要求从候选方案发展而来。与从开始就确定所有需求不同。项目管理者联盟
过程控制：过程和工具的使用从轻到重渐变。与把整个项目的生存周期过程定义为轻或重不同。training.mypm.net
进展：健康的项目展示出一个进展和背离的序列。与按照预期计划100%实现价值，没有明显的背离不同。项目管理者联盟
质量控制：测试可演示的发布版本是一个头等重要的、贯穿全生命周期的活动。与认为它是次要的，生命周期晚期的活动的观点不同。项目管理者联盟
我承认在实际软件项目中，上述四点都是说起来容易做起来难，而且对不同领域它们应该被不同地应用。网络应用程序开发团队与嵌入式应用程序开发团队实现这些模式的方法应该是不同的，但是对他们来说模式都是可用的。方法、模式和技术的书籍和论文的写作，(工业界称为思想领导)，是相对简单的。尽管如此，我们中的多数人并不是在寻找最好的思想，而是在寻找最好的实践方法。管理实际项目需要实践的领导力，而在实际项目条件下应用和执行这些理念是相对困难的。我们应当珍惜懂得实践的领导力的项目管理者：他们可能是每个公司中最稀有的资源。优秀的项目管理者，就像优秀的电影制作人一样，不只是常常创造出优秀的产品，他们还是年轻团队成员的良师益友，这些年轻人能够学习有效的技术并发展他们自己在多维权衡、持续性沟通、风险管理、模式识别以及指导式领导等方面的技能。项目管理训练课程是学习的良好催化剂，但是学徒期是不可或缺的。项目管理者联盟
范围管理项目管理者联盟
传统软件过程的比较微妙的挑战之一是如何把生存周期表现为一系列顺序的活动：从需求分析到设计，编码，测试，最后发行。成功的项目确实用一种抽象的方式实现了这种进展路线，但是活动之间的界限是模糊不清的，只能被合作的涉众所接受。另一方面，不成功的项目则陷入了挣扎着寻找活动间清晰的界限的误区。比如，在过渡到设计前追求100%固定的需求基线，或是在过渡到编码前追求非常详细的设计文档，都是严格的中间目标，造成了注意力被琐碎细节所分散，而重要工程决定的进展却被放缓甚至停止。项目管理者联盟
当我们建立一个全新的软件方案时，从需求到设计的连续的详细规格说明流也许是有一定意义的。但是现在，我们通常是升级一个已有系统或者根据已有部件(操作系统、网络服务、网络、图形用户界面、数据管理、封装的应用程序、中间件、计算平台、遗留系统等)建立新的系统。改造或复用已有财产的经济效益迫使我们考虑在这些已有财产的环境和限制下的用户具体需要。pmp.mypm.net
我前面曾经说过，需求可能是我们的工业中被最严重误用的词。需求意味着不可协商，但我们却在几乎所有成功项目中看到需求的变化，妥协和让步。改变一个需求需要进行大量严格的审查，因为这通常对涉众间的合同有很大影响。我建议我们使用规格说明来代替需求。规格说明是可以更改的，而且可以理解为我们现阶段对项目的认识状态。项目管理者联盟
就我所见过的而言，用户规格说明有两种重要形式。第一种是观点陈述(或用户需要)，它抓住了开发团队和买方或说用户之间的合同。这些信息应以用户可理解的形式(一种包括了文本、原型、用例，电子表格等等的特殊格式)表现。一个支持观点陈述的用例模型起到了用户或买方可以理解的语言表达可操作的概念以及期望的行为的作用。项目管理者联盟
规格说明的第二种形式与需求非常不同。我倾向于使用评估标准这种说法，它被自然理解为目标的瞬间快照，而目标是一个生存周期的中间检查点，比如一个可演示的版本发布。评估标准是从观点陈述或者其他资源(制作/购买/复用分析、风险管理相关、架构方面的考虑、隐藏问题、实现限制、质量极限等等)中派生出来的中间的指导目标。它们与用例模型一起，为早期测试，而不是为传统的需求表达提供了更好的框架。一个计划的发布内容序列和计划的评估标准的初始提议就是一个风险管理计划的很好的形式。talent.mypm.net
过程严格性项目管理者联盟
多年来，我一直尝试着调解敏捷阵营(软件过程观点的自由主义左翼)和过程成熟阵营(软件过程观点的保守派右翼)之间狂热的争论。他们都有有益的观点和适当的技术。但是经过最老于世故的努力，在需要解决方案的范围内没有清晰的正确或者错误的处方。上下文环境是极为重要的，而且几乎所有不是太过普通的项目和组织都需要结合技术、常识、领域内的经验来取得成功。多数项目管理者会同意下述观点：项目管理者联盟
项目管理者联盟
在我看来，最后一个观点描述了决定敏捷方法的速度和自由度，严格方法的质量和说明性指导的决定性因素。过程严格性应该与重力作用很相似：你越接近产品的发布，过程、工具、员工每天的活动使用仪器的影响就越大。你离发布日期越远，这种影响就越小。这个公理在过程里似乎完全被忽略了，或者至少是不受重视的，但是它在成功的软件项目中通常是非常引人注目的。bbs.mypm.net
大多数成功的软件开发过程的一个标志性特征是详细定义的从创造阶段(初始和细化)到生产阶段(构建和产品化)的过渡过程。当软件项目无法成功时，一个主要的原因是对过程严格性不合适的强调(过多或者过少)。这种现象在传统过程和迭代过程中都是存在的。多数不成功的项目带有下列特征之一：项目管理者联盟
生存周期早期阶段(创造性方面)的过度设计。你需要有机动性的过程，该过程容易适应新发现、适应对几个主要风险和原型方案造成攻击的一定程度上的不确定性，并且建立早期的粗糙工件。你能想到哪些创造性原则，根据这些原则过程严格性对帮助人类思考被认为是有益的?项目管理者联盟
生存周期晚期阶段(生产方面)的设计不足。详细工件的广泛的变化管理基线需要带有富有洞察力的实现方法，对连贯性的密切关注，以及自始至终对产品质量聚焦的工程过程。项目管理者联盟
成功的现代项目——以及使用传统过程开发的成功项目——通常都有详细定义的项目阶段性标志，即从创造性研究状态到生产状态的显著过渡。早期阶段着重于实现可演示的功能。后期阶段着重于实现可供用户使用的产品，这种产品关注的是健壮性、性能、适用性以及完整性。blog.mypm.net
|
