大型项目中的敏捷项目管理实践
2019-12-09
来源： 宋荆汉
础上进行迭代的开发。因此，整个团队的结构如下图 2：
图 2 .大型项目的组织结构
由规划经理来有序的协调和规划多个 PO 的前期工作，开发组由多个特性开发团队组成，由系统组完成整个软件架构设计，将系统按业务和技术进行切分，使得各开发团队间能够进行协同。
每个特性开发团队都是一个敏捷团队，均采用完整的 Scrum 的管理实践，同时采用持续集成、代码静态检查、代码交互评审的、验收测试驱动来进行质量的保证。单元测试的实践，由于时间紧研发人员都担心会影响项目进度，因为本身测试代码工作量也不少。因此我们没有按真正 TDD 方式去推行，而仅会要求针对问题最集中的模块和失败的用例涉及到的代码进行单元测试覆盖，目的是保证迭代过程中代码修改的完整性，而不是用于驱动设计，最终实际统计单元测试覆盖率仅 30%不到。先写测试用例再写代码的方式，在部分小组试过几次但大家都反馈很难适应。因此没有再继续要求。
具体的实践方法有很多文章来论述，这里就不再重复。
项目遇到的麻烦-需求
由于需求与开发团队是异步进行，而不是从一开始就紧密运作的。开发团队与规划组之间，开始并没有团队意识，还是按瀑布的阶段交付的思维来对待。所以，项目组开会时，开发团队与需求团队就经常发现摩擦。
开发要求需求人员将需求描述的非常细，否则不予接受。而需求人员由于在局方现场，要将需求描述的很细的情况下就需要耗费很多文档时间，而用户时间有限，所以希望能将需求描述简单一点，关键是需求人员将需求写的很细的情况下，开发人员在开发过程中任然还是需要不断的去沟通需求，毕竟靠文档完整表述还是有困难的。而测试团队先等待开发做完，再开始测试。于是开发、需求之间经常就需求文档细致问题无法高效协同，测试介入很晚，到测试时对业务不熟悉，只能希望开发出相关的设计文档来进行测试，效果很差。由于团队之间对立情况，反而加剧了对文档传递的依赖，项目进度慢了下来。
对此，我们认为这个是因为项目实践出来偏差，没有真正领悟，敏捷开发中为什么需求必须是讨论出来，而不能是通过一个详细设计文档去传达，使得每个成员都对需求来负责，而不是仅仅被动的接受。
对此，项目要求各团队的 PO，不再写详细的需求文档，而是出需求列表。强制要求，需求的传递必须通过需求澄清方式完成。
也就是需求、开发、测试人员，同时参与需求的分析工作。步骤如下：
需求人员列出所有的 product backlog 的 story，并进行排序；
开发、测试人员，听 PO 对每个用户故事进行讲解，注意 PO 不再提供详细需求的文档了，然后开发、测试人员可以要求 PO 对每个需求讲解清楚，直到听懂理解并能开始进行设计工作为止；
开发人员将 PO 讲解的需求给记录描述出来，需要包括基本的业务流程图以及接口说明，同时要求测试人员将需求的验收条件给写出来，整合成针对每个 story 的需求澄清文档；
由 PO 确认需求澄清文档内容的准确性，如果无误可以开始进入开发过程了。
通过这样的方式，可以节省 PO 详细需求文档的时间，同时将需求的责任分担到每个角色的身上。因为，即使再详细的文档，研发和测试人员 还是需要阅读消化同时也需要多次找 PO 确认。直接通过讲解确认，我们也称为"需求的三次握手"过程，开发、测试、需求人员，实际完成了对需求的传递、需求验证规则的统一，这时测试就可以再前期介入到项目
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
