附加白金原则

根据我们在全球帮助大、中、小型组织的团队向敏捷产品开发转型的实战经验和现场测试，我们发展了被称之为“白金原则”的敏捷产品开发的3个附加原则。它们是：

>>抵制形式化；

>>将团队视为整体的思考与行动；

>>可视化而非书写。

你能在接下来的几小节中探索每项原则的具体细节。

抵制形式化

即便是最敏捷的产品开发团队也可能会走向过度形式化。例如，团队成员要等到进度计划中的会议召开，才去讨论本来几秒钟就可以解决的简单问题，这对我们来说并不少见。这些会议通常有议程和会议纪要，并需要为参会做一定程度的动员和遣散。在敏捷方法中，这种过度形式化是不需要的。

不开玩笑！危险！

你应当经常质疑形式化和没必要的华丽的展示。例如，是否有更容易的方法获取你所需要的内容？当前的活动如何尽可能快地支持高质量的产品开发？对这些问题的回答有助于你专注于高效的工作并避免无谓的任务。

在敏捷系统中，物理工作环境和讨论都是开放而畅通无阻的。文档只需保持最低的数量和复杂度，以便为产品贡献价值而非造成阻碍。花哨的展示（比如过度装饰的报告）要加以避免。专业且友好的沟通有利于团队协作，整个组织环境必须是开放的和舒适的。

小贴士大用途

以下是抵制形式化的一些成功的策略：

>>减少组织的层级，尽可能去掉团队中的头衔；

>>避免在美工方面过度投入，诸如精心制作幻灯片展示或者挑选额外的会议纪要格式，尤其是在冲刺结束阶段需要演示可交付功能的时候；

>>引导那些要求进行复杂工作展示的干系人，让他们认识到此类展示成本高但回报低。

将团队视为整体的思考与行动

团队成员应当专注于如何让团队整体最富有成效。这种专注意味着抛开个体的立场和绩效指标。在敏捷环境中，整个团队需要将对目标的承诺、对工作的主人翁意识，以及对实现该承诺所需时间的理解保持一致。

以下是将团队视为整体的思考与行动策略。

>>结对开发并经常交换伙伴。无论是结对编程（伙伴双方都具备某领域的知识）还是影子编程（只有一方具备该领域的知识），都能提高产品质量和团队成员的能力，并减少单点故障。你可以在第17章学习更多关于结对编程的知识。

>>用统一的“产品开发者”的头衔替代各种不同的头衔。开发活动包含所有使需求转化为功能所需的任务，这些任务包括设计、执行（如编码）、测试和归档，而不仅仅是写代码或转动一下螺丝刀。

>>只在团队层级汇报工作，反对创建细分团队的特别的管理报告。

>>用团队绩效度量指标替代个人绩效度量指标。

可视化而非书写

产品开发团队应当尽可能多地使用可视化技术，无论是通过简单的图表还是计算机建模工具。图形比文字更有用，只有当你使用图表或模型而非文档时，你的客户才能更好地把概念和内容联系起来。

图形化的演示几乎永远胜于文字的表述，我们若能亲自体验功能，则效果最佳。当我们采用这样的方案来丰富我们的交互时，我们定义系统特性的能力将成倍增长。

小贴士大用途

关于沟通工具，一张纸面草图甚至比一份正式的文档更加有效，即所谓的一图胜千言。如果你要试图达成共识，那么文字描述是最差的沟通形式，尤其是当你通过邮件发送很多文字描述的内容，并且有“如果有任何问题，请让我知道”这样的要求时。

可视化策略的例子包括：

>>在工作环境中配备大量的白板、贴纸、笔以及纸张，使绘图工具随手可得；

>>使用模型而非文字来沟通概念；

>>通过图表、图形和仪表板来汇报状态，类似于图2-2所示。

图2-2实现信息透明的图表和图形