现在软件领域三大俗，说的是敏捷、大数据、云，说的越多的往往也是处于成熟中，或者需求强调的，我所遇到的项目有幸几乎都触及到这些俗气的元素。
大家现在知道了，又遇到有中国特色的项目了，"需求范围不确定，资源限死、时间限死"，大家会说不是战略项目吗，资源怎么会限死呢？但是请大家想想，客户预算是一定，根据财务核算，老板要拿的利润也是刚性的，还能剩多少，大家可以发挥想象了。考虑该如何实施这个项目时，似乎传统的项目管理从计划来分配资源模式以及采用瀑布型的开发方式，根本行不通。就在我焦头烂额之际，我想起了解过的一种开发模式：
- Scrum 开发模式使得我们能够专注于如何在最短的时间内实现最有价值的部分；
- Scrum 开发模式使得我们能够快速的经常的监督实际产品发展的状况；
- Scrum 开发模式使得团队按照商业价值的高低先完成高优先级的产品功能，并自主管理，凝结了团队智慧创造出最好的方法因而提高效率 ；
- Scrum 开发模式使得每隔一两周或者一个月，我们就可以看到实实在在的可以上线的产品。此时，就可以进一步的决定是继续完善功能实现更多需求或者直接发布了 。
这正是我想要的管理方法，也是敏捷界被采用最广泛的管理方法，但一般的 Scrum 显然也无法有效的应对此种情况了，还得自己完善和扩展。
在敏捷开发中对于需求的假设是认为，需求是涌现出来的，但我们知道架构设计能够开始是基于关键需求已经确认的情况下，而且在国内的环境下如果在需求不确定的情况下就开发，客户更可能随意的修改需求，而工期又限死的情况下，项目必然是会失败的。因此在中国的客户成熟度情况下，最好还是书面确认大部分关键需求后再开始做，否则，很多情况下会成烂尾楼。
为了能加快前期需求阶段的进展，必须有业务架构师来分解业务模块，不同的 PO 来负责各自业务模块的需求分析。当关键需求确认后，开始技术架构的设计，同时在技术架构的基础上进行迭代的开发。
每个特性开发团队都是一个敏捷团队，均采用完整的 Scrum 的管理实践，同时采用持续集成、代码静态检查、代码交互评审的、验收测试驱动来进行质量的保证。单元测试的实践，由于时间紧研发人员都担心会影响项目进度，因为本身测试代码工作量也不少。因此我们没有按真正 TDD 方式去推行，而仅会要求针对问题最集中的模块和失败的用例涉及到的代码进行单元测试覆盖，目的是保证迭代过程中代码修改的完整性，而不是用于驱动设计，最终实际统计单元测试覆盖率仅 30%不到。先写测试用例再写代码的方式，在部分小组试过几次但大家都反馈很难适应。因此没有再继续要求。
项目遇到的麻烦-需求
由于需求与开发团队是异步进行，而不是从一开始就紧密运作的。开发团队与规划组之间，开始并没有团队意识，还是按瀑布的阶段交付的思维来对待。所以，项目组开会时，开发团队与需求团队就经常发现摩擦。
开发要求需求人员将需求描述的非常细，否则不予接受。而需求人员由于在局方现场，要将需求描述的很细的情况下就需要耗费很多文档时间，而用户时间有限，所以希望能将需求描述简单一点，关键是需求人员将需求写的很细的情况下，开发人员在开发过程中任然还是需要不断的去沟通需求，毕竟靠文档完整表述还是有困难的。而测试团队先等待开发做完，再开始测试。于是开发、需求之间经常就需求文档细致问题无法高效协同，测试介入很晚，到测试时对业务不熟悉，只能希望开发出相关的设计文档来进行测试，效果很差。由于团队之间对立情况，反而加剧了对文档传递的依赖，项目进度慢了下来。
对此，我们认为这个是因为项目实践出来偏差，没有真正领悟，敏捷开发中为什么需求必须是讨论出来，而不能是通过一个详细设计文档去传达，使得每个成员都对需求来负责，而不是仅仅被动的接受。
对此，项目要求各团队的 PO，不再写详细的需求文档，而是出需求列表。强制要求，需求的传递必须通过需求澄清方式完成。
也就是需求、开发、测试人员，同时参与需求的分析工作。步骤如下：
- 需求人员列出所有的 product backlog 的 story，并进行排序；
- 开发、测试人员，听 PO 对每个用户故事进行讲解，注意 PO 不再提供详细需求的文档了，然后开发、测试人员可以要求 PO 对每个需求讲解清楚，直到听懂理解并能开始进行设计工作为止；
- 开发人员将 PO 讲解的需求给记录描述出来，需要包括基本的业务流程图以及接口说明，同时要求测试人员将需求的验收条件给写出来，整合成针对每个 story 的需求澄清文档；
- 由 PO 确认需求澄清文档内容的准确性，如果无误可以开始进入开发过程了。
通过这样的方式，可以节省 PO 详细需求文档的时间，同时将需求的责任分担到每个角色的身上。因为，即使再详细的文档，研发和测试人员 还是需要阅读消化同时也需要多次找 PO 确认。直接通过讲解确认，我们也称为"需求的三次握手"过程，开发、测试、需求人员，实际完成了对需求的传递、需求验证规则的统一，这时测试就可以再前期介入到项目中，对业务理解与研发处于同一水准，可以在业务层面帮助研发来纠正需求理解的偏差，考虑对异常场景的处理。
通过这种方式，研发的详细设计文档基本可以省略，但对于复杂性比较高超过实现需要 8 人时以上的 story 还是需要给出简要的设计文档，需求详细文档可以裁减掉，而且测试用例通过验收准则可以很快就转换出来。通过需求的澄清过程，而不是需求文档的传递来沟通，大大提升了项目前期的进展。
缺陷的处理
通过厘清需求的过程，整个团队开发比较顺畅了，但是在迭代中我们发现对于缺陷的处理存在问题。有一次项目整体的回顾会，各特性团队，均顺利完成了各自的 sprint 的任务，但有个团队却没有完成而且是 0 完成率，但是我们发现他们遗留的问题并不多，那么是什么原因导致的呢？经过分析我们发现，他们在 sprint 中对缺陷的处理确实是缺乏处理策略。如图 3 所示，story 遗留缺陷对应图
我们在定义 story 的验收条件，是要求每个 story 不能遗留一般级别以上的缺陷。但该团队对缺陷的处理是：
- 先处理严重级别的缺陷；
- 缺陷集中到迭代后期再进行修复。
所以，当他们进行缺陷修复的排序时，将所有的严重缺陷都进行了修复，但是导致最后却是一个 story 都不能交付。因为，每个 story 都还剩一个一般级别的缺陷。而且，由于不是立即处理缺陷，导致缺陷处理周期变长，修复缺陷占用较大比例时间。等严重缺陷都修复完，已经到迭代结束期。导致所有的 story 都无法交付。
在此次，我们必须要认识到一点，我们每个迭代都要进行增量的价值交付，作为研发团队应该考虑如何在一个迭代中尽可能多的交付，而不是为了修复缺陷。所以，如果研发团队，在进行缺陷修复时，考虑先把一个 story 的缺陷全部修改完，再修订其他 story 的缺陷，应该可能交付 2 个 story 的，虽然对软件整体而言，缺陷没变，但是交付的商业价值却是更多的。
因此在后期，我们确定在迭代过程中：
- 必须树立尽量多交付价值的观点；
- 缺陷必须在发现时立即修复，不建议集中进行修复，因为缺陷的定位时间会随时间逐渐加长的，立即修复才是对进度、质量最有利的方式；
- 实在无法修复或确实需要时间修复的 bug，需要进行分析和规划，不能仅仅以故障的级别为修复的优先项，而是增量交付为核心关注点。
- 在团队中增加一个专职的 bug 修复人员，就是一旦 bug 出现，由专职的 bug 修复人员进行修复，其他人员继续 story 的开发，这个人员可以在不同迭代轮换。起初是在一个团队中采用，后来发现，这种方式也取得了很好的效率，所以，在所有特性开发团队中都采用起来。
Story 的切分
见下图 4，一般的业务系统都是按如下的方式进行横向的切分，也就是我们常说的流式结构，当某一层发生变动时，其他层可以保持不变。
当到敏捷开发中队 story 的切分是基于纵向的切分如图 5 所示，也就是每个 story 都可以方便的从系统中整合与拆并。
采用这种结构，可以方便的进行增量交付，而且当一个有问题时，可以拆开不影响其他部分，非常适合敏捷开发增量的要求。
但在实际中需求并不是由一个个孤立的"用户故事"组成的，业务概念、业务流程其实是贯穿多个用户故事的，软件设计应该多从业务概念、业务流程的角度来思考；表面上看上去一个用户故事对应一组界面，其实界面之间是很可能有重用和共享部分的；业务逻辑层中的一些类很难将其分拆开来与用户故事、界面组一一对应，存在交叉、共享和重用的可能；数据层中的某张表，通常会支撑多个用户故事而不是一个用户故事。
例如，以下列出来的可能都需要从软件架构上做一个整体的考虑：
- 权限控制；
- 性能要求；
- 日志记录；
- 工作流；
- 全文搜索；
- 多数据库支持；
- 搜索引擎优化；
因此，在每个 sprint 的 backlog 的安排上，不同的整合和考虑会对项目的进展速度产生很大的影响。PO 与架构师，必须经过深入的整合梳理与排序，而不是简单的对 story 进行罗列。如果说需求决定了软件的价值，那么设计包括对需求的安排决定了软件的成本。
目前敏捷开发中对于 story 的拆分也提到很多方式，一般来说如下几种：
跨团队的处理
由于有大量的底层技术结构，所以，我们在特性团队划分时，分成 3 个业务特性团队，这个团队主要是实现业务逻辑。而底层的，大数据存在和公共平台，是由另一个团队来独立完成的。这个时候，在任务的安排上和人员协同上就需要注意。
如：在界面上有一个查询功能，其中有部分数据，必须通过大数据平台来获取，又有部分可以直接通过 oarcle 数据库获取，还有部分通过 ES 集群就可以获取，这个时候就要注意。Story 可交付的定义，应该是系统能够集成交付，而不仅仅是上层业务可交付。
如：在界面上有一个查询功能，其中有部分数据，必须通过大数据平台来获取，又有部分可以直接通过 oarcle 数据库获取，还有部分通过 ES 集群就可以获取，这个时候就要注意。Story 可交付的定义，应该是系统能够集成交付，而不仅仅是上层业务可交付。
结束语
敏捷开发的实践，一直都聚焦在单一团队运作，但当往往很多系统规模，并非 10 个人团队可以在 要求时间内交付的。当团队规模大后，原来单团队的管理，并且团队间部分需求考分的交叉，原来的单一敏捷团队的管理方式会遇到一些麻烦。我给出了自己在大团队和技术复杂性团队的实践的经验，希望对大家有所帮助。
