敏捷12原则之外的事
除了敏捷宣言，大家在讨论到敏捷实施落地的指导思想时，提到最多的就是12原则，哪除此之外，还有其他的原则可以作为参考么？答案是有的，就是下文中我们想要聊一聊的敏捷开发附加原则。
在聊敏捷软件开发的附加原则之前，先讲一个自己碰到过的一个真实案例，在某团队的一次迭代评审会上，团队ScrumMaster（简称SM）刚哥邀请了相关职能部门领导及业务干系人，在完成本轮迭代功能演示后，顺便提到了团队的一个困惑：现在产品线所有团队都被要求为2周一个迭代，这样的周期是否合理？是否所有团队要保持一致？因为刚哥所在的团队属于技术平台组，也就是所谓的组件团队，该团队的需求主要以配合上层应用的开发为主，涉及技术平台与其他应用的对接口联调、集成测试、可靠性等方面的验证，所以开发周期相对比较长，同时刚哥给大家呈现了团队看板中的数据度量，故事交付周期普遍都在5天左右，迭代完成率也一直低于60%，版本平均延迟5~7天，团队在进行分析后，为了能更好的支撑上层业务开发、配合其版本发布，希望尝试将迭代周期从2周调整到4周，以缓解团队目前面临的情况。基于刚哥和团队有理有据的说服和展示，相关领导和干系人最终也表示认同，接受了团队的要求，将迭代周期改为4周。
突然间我想到了《敏捷项目管理》（作者：Mark.C Layton）一书中提到的敏捷软件开发的附加原则，号称“白金原则”，不就是团队在这次活动中所体现出来的么？哪这几条原则到底是什么？值不值得“白金原则”的称号，我们就来一起聊一聊，为了便于对比，文中把3条附加原则和敏捷12原则都放在了一起，如下：
抵制形式化
首先第一条：抵制形式化，这里更多的是抵制各种形式主义，为了做某事而做某事，完全照搬流程来，不能灵活变化。主要体现在以下几个方面：
1. 追求统一。文中案例我们看到刚哥所在团队碰到的就是此类问题，在团队敏捷开发的过程中，组织为了方便管理，要求所有的产品线团队采取统一的迭代节奏，比如2周。实际上各个产品线以及产品线下属的不同产品团队所面对的业务场景、客户、市场要求、技术成熟度等等各方面都有差异，应结合实际的情况来定。刚哥的团队属于技术平台团队，对上层业务提供支撑，单个需求/故事开发周期相对较长、而且客户的需求变化频率也没有那么快，所以采取4周迭代的周期是完全可以的，没必要为了管理上的方便而采取一刀切。
2. 过度美化。这里既包括对于需求/功能的过渡修饰，比如在项目开发中通常指干些不解决实际问题，没有应用价值的项目活动（称之为镀金），客户并不会因此而额外买单；另外也包括工作中对于过程交付件或结果交付件的过渡修饰，比如投入太多精力于美化汇报PPT、装饰团队看板、进行数据和报表美化等，并不能给项目或产品带来实际的价值，很多往往是做管理层看的，所以应该尽量避免。
3. 灵活应对。过程中各项实践的教条执行，比如对于需求管理，正常情况下需求管理需要经过收集、过滤、分析、决策、转发、实现、验证这样几个阶段，但是在实际操作过程中，有些阶段根据实际情况是可以调整或者合并的。我就曾经遇到这样一个情况，开发工程师在做客户现场维护收到了一个新的需求，需求目的非常的明确、细节也很清楚，是解决客户痛点的价值需求，这种情况下开发人员在和产品经理经过简单沟通和就可以直接安排进迭代，迅速交付客户进行验证，而不需求经历过滤、分析、决策这样的环节，大大缩短了交付周期（按流程走最快也要安排进下下个迭代），提升了客户满意度。但是如果从内部管控的角度来看，有可能不符合项目交付的流程，存在一定的安全隐患，但是相比于需求价值和客户满意度，两者权衡下就需要我们进行灵活调整。
团队思考与行动
让团队进行集体思考与行动，专注于如何让整个团队的工作最富有成效。再回过头来看看刚哥所在的团队，正式因为团队在2周的迭代中受到了阻碍和挫折，才在上一轮的回顾会上提出了这样的问题，并希望能够跟管理层反馈并解决这个问题。最终在团队的集体推动下，顺利的将迭代周期从2周调整为4周，让团队成员感受到了集体行动的力量。当然除了案例中提到的情况外，团队思考与行动还可以以下几个方面有所体现：
1. 统一头衔。首先统一头衔，团队的所有成员都是开发人员，没有前端高级开发工程师、初级功能测试人员、高级数据专家这样的头衔区分，大家同属一个团队，为共同的目标服务，一荣俱荣、一损俱损，有利于团队凝聚力和整体战斗力的提升。
2. 项目或团队层级汇报。以项目或团队为单位向领导层进行汇报，或者和外部团队展开协作，对外展现一个集体的形象，责任共担、利益共享，避免强化个人角色展开团队活动。
3. 项目或团队指标代替个人指标。对外呈现的指标和数据都是基于项目，比如需求交付周期、迭代完成率、缺陷逃逸率等，避免晾晒个人的指标数据，比如个人bug数，开发代码行数等等不利于团队展开协作的指标。
可视化而非书写
着重强调可视化的沟通方式，而非书面语言进行信息传递，一方面会拉长沟通时间，导致效率低下，另一方面沟通的深度也不够。从刚哥团队向领导沟通的形式来看，很好的利用了团队的度量看板，将相关数据都呈现了出来，无形中增强了说服力，让管理者们更容易接受和做出决策。除此之外，常用的可视化表达策略有以下几种：
1. 可视化白板。建立可视化的白板沟通方式，比如在进行团队交流或者个人交流时，尽量通过沟通“三件套”（白板、马克笔、卡片）方式将所表达的内容可视化出来，一方面便于双方的理解，提升沟通效率，另一方面也便于信息的整理和分类，产生更多的碰撞和交流。
2. 简易模型表达。比如产品经理在和设计、开发人员沟通，通过原型设计、线框图等方式将产品设计思路、理念传递给团队成员，促进双方对于产品的理解、加速产品由原型到设计实现的过程，提升反馈的效率。当然也可以考采取保真、高保真等方式，前提是我们需要综合考虑设计成本和项目时间安排等因素。
3. 图表图形呈现。常言说，一图胜千表，一表胜千言，讲的就是这个道理。如果可以以图表图形的方式来呈现，就尽量避免采用文档、邮件等进行大量书写的方式进行信息传递和沟通。
以上，是《敏捷项目管理》一书作者Mark建议的3项“白金原则”，笔者认为，这几条原则还是非常值得我们借鉴的，也是经验之谈，确实在以前带团队过程中，我们也常常会参考以上3条原则作为指导团队。确实从很大程度上能够看到其积极一面。
后续：在2个月后的迭代回顾会上，我再次看到了刚哥团队在调整后的表现，仅仅从度量数据上就能看到变化：迭代完成率80%，版本延迟3.5天！团队的精神面貌也不一样了，能够更好的支撑上层业务，获得管理层对技术平台团队工作的认可！
