再谈敏捷项目管理

前面谈敏捷开发和敏捷项目管理的文章已经很多了，由于最近在整理敏捷项目管理的培训材料，在整理材料的过程中又思考了一些离散点，特做记录。

在敏捷里面我们一直在强调团队的动态自适应和调整能力，要知道一个高成熟度的敏捷团队一定是一个能够高度高效率的进行自适应，自学习和自我调节的团队。那么传统的层级结构一定是不适合的，包括原来传统的按阶段划分的流水线式生命周期结构，取而代之的是多个小团队之间的网状结构，在这种结构下能够通过高效的消息传递快速的发送消息，接受反馈，并进行自我调整维持在一个动态平衡的状态。个人理解这个很类似在《失控》里面提到的看似无序而实则有序的一种高效的以消息为中心的组织架构模式。

在引入了软件工程后，我们始终期望能够通过工程学和借鉴工厂批量自动化生产的方法来解决软件开发质量和效率问题。而对于软件本身，从需求到测试完成都属于研发过程，而只有最终的光盘刻制才能够属于生产过程。在软件工厂的概念下，自然是将软件生产过程中的很多方法引入到了研发过程。对于一个产品研发或生产的复杂性问题的解决，我们有两个途径，第一个途径是将其进行产品生命周期阶段的划分，然后再按阶段进行分工和上下游协作，形成标准化的SOP方法和步骤，降低对单个阶段或人员过多的技能要求和依赖。第二个途径则是一开始就做好顶层设计和分解，然后在并行的进行各个部件的研发和生产，最后再进行集成和组装，在这种情况下往往是顶层设计和后续组装难，但是中间并行过程相当容易。

第一种途径有一个关键的假设，即标准的SOP已经制定完成并多次验证有效，那么每一个阶段的人员只需要关注上游的输出并经过加工和作业后提供给下游，他们并不需要对整体负责而只是对工序负责，即在这种模式下往往并不存在需要跨阶段或流程节点进行沟通的场景。但是要做到这种程度在软件领域是相当困难的，这种方式好像就在说我们的编码人员不需要关注需求，只需要看设计文档就足够了，而我们的需求人员也不用关心最终的开发测试产出，只需要把需求传递给测试就可以了。但是事实上再严谨的软件工程方法，包括瀑布模型都很难真正做到这点，其真正的原因还是在于我们将生产方法应用到了软件研发过程域中。

第二种途径相对来说也是我们常用的方法，即在进行完高端业务建模和技术架构设计后再进行分解，然后并行开发后再进行集成。这个好像和第一种途径并没有太大的区别，但是注意如果我们的需求仅仅高端业务建模，集成仅仅是后续额UAT测试的话，那么我们的中间过程就变成为了一个个并行的小流水线，我们关注的是这些并行的流水线团队本身足够小，足够相互不影响，同时我们不再关心流水线内部是否有严格的需求，设计，开发，测试各个岗位和阶段的划分。这也是前面谈到的对于稍微大一点的项目仍然可以在做好顶层设计后分解到多个敏捷小团队高效协作的原因。

在scrum里面我们看到有两个重要的角色，一个是product owner，一个是scrum master，要注意这两个角色本身是不能重叠的。对于产品负责人重点是需求本身的优先级，每一个user story本身对产品和用户的价值创作；而对于scrum master更加关心的是每个sprint能够按约定的范围，按进度按质量高效完成，保证团队尽可能的免于外部干扰，这个和我们传统划分产品经理和研发项目经理还是比较类似的。一个是站在用户和产品价值层面，要保证做正确的事情，而一个是站在进度和质量层面，要确保正确的做事。

敏捷项目管理我觉得最重要的不是方法论或最佳实践或工具层面，而最重要的还是敏捷团队。而对于一个敏捷团队最重要的包括了两点，一个是高效沟通和协同的意识和积极态度，一个是本身已经积累的协作默契和差不多的知识技能积累。两种缺一不可，只有都具备了才可能最大化的减少无效沟通，这也是对于一个刚逐渐的团队敏捷往往并不是最好方法的原因，刚逐渐的团队更加需要的仍然是通过传统的软件工程方法积累知识技能和团队词汇表，做为后续能够敏捷的基础要素。

我们不可能完全避免犯错误，但是我们可以通过短周期迭代和team review等多种方法尽早的发现错误和纠正错误。敏捷里面有个重要思想就是不是理想化的去要求需求不变化，而是尽可能的及早发现变化并适应变化。基于这个思想下的原型方法，持续集成和构建，短周期迭代发布，可视化看板等都是为了这个服务，即尽早的发现和纠正问题。以避免传统软件工程中缺陷遗漏到最后引来的巨大的坏质量成本。

在类似scrum的敏捷项目管理方法论里面，我们看到通过prodcut backlog->sprint backlog->task形成了一条完整的围绕user story的跟踪流水线，真正实现了最小粒度单元的用户故事（需求）的端到端跟踪和实现，这是一个完全理想化的条目化的过程。在这里面一致困扰我的地方还是在于对于一个复杂系统的顶层设计或保证概念完整性的架构设计究竟在哪里？我的理解是只有完成了高层架构设计和分解后才能够进行条目化的并行作业，以保证整个软件系统的概念完整性，否则我们后续在集成上会出比较大的问题。

在sprint的计划会议上，团队中每个人的估算，每个人的承诺准确性都直接影响到整个计划执行的有效性。如果制定出来的计划不断出现延期或无法履行的情况，对整个敏捷过程的破坏是相当大的。因此一个敏捷团队首先要求的是团队中的每一个人是敏捷个人，能够很好的知道自己的工作质量和工作效率，做事情能够有明确的个人计划和目标性。

敏捷项目管理不是没有方法或不重视文档，相反敏捷方法对纪律和文档输出的要求往往更加苛刻。同样，敏捷方法不是不关心过程，而是去除冗余没有价值创作的过程。还是一句话，越严格的纪律下往往对于高度自律的人才容易得到最大的自由。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密