大型项目中的敏捷项目管理实践
2019-12-09
来源： 宋荆汉
享部分的；业务逻辑层中的一些类很难将其分拆开来与用户故事、界面组一一对应，存在交叉、共享和重用的可能；数据层中的某张表，通常会支撑多个用户故事而不是一个用户故事。
例如，以下列出来的可能都需要从软件架构上做一个整体的考虑：
权限控制；
性能要求；
日志记录；
工作流；
全文搜索；
多数据库支持；
搜索引擎优化；
因此，在每个 sprint 的 backlog 的安排上，不同的整合和考虑会对项目的进展速度产生很大的影响。PO 与架构师，必须经过深入的整合梳理与排序，而不是简单的对 story 进行罗列。如果说需求决定了软件的价值，那么设计包括对需求的安排决定了软件的成本。
目前敏捷开发中对于 story 的拆分也提到很多方式，一般来说如下几种：
第一种，按工作流进行拆分
第二种，从简单到复杂
第三种，按原子操作，如分解成：Create, Read, Update, Delete；
第四种，针对公共功能的系统，
大家可以参考这几种方式来灵活的处理 story 的切分问题，但注意，还要有全局观。
跨团队的处理
我们在一个大型项目中的架构如下图 6：
图 6 .某项目的软件架构图
由于有大量的底层技术结构，所以，我们在特性团队划分时，分成 3 个业务特性团队，这个团队主要是实现业务逻辑。而底层的，大数据存在和公共平台，是由另一个团队来独立完成的。这个时候，在任务的安排上和人员协同上就需要注意。
如：在界面上有一个查询功能，其中有部分数据，必须通过大数据平台来获取，又有部分可以直接通过 oarcle 数据库获取，还有部分通过 ES 集群就可以获取，这个时候就要注意。Story 可交付的定义，应该是系统能够集成交付，而不仅仅是上层业务可交付。
图 7. 团队中 story 与人员的对应
如图 7 所示，其中业务团队要完成 story2 时，其系统要平台团队的 story2 也要完成时，就会出现协同问题。因为，2 个团队分别按自己的标准在确定故事的优先级，可能 story2 完成的时间与业务团队的 story2 的时机不对，还是无法完整交付。
对于这类，应该临时将小王划归到业务团队 2，将小宋与小王的 story 进行协同，以达到交付的目标。在多个特性敏捷团队同时运作时，这种情况，可以建立虚拟团队的方式，来临时应对这类需求。
图 8. 建立多个敏捷团队关联协同团队
这样可以很好进行某个具体交付特性的协同，保证交付的完整性。
结束语
敏捷开发的实践，一直都聚焦在单一团队运作，但当往往很多系统规模，并非 10 个人团队可以在 要求时间内交付的。当团队规模大后，原来单团队的管理，并且团队间部分需求考分的交叉，原来的单一敏捷团队的管理方式会遇到一些麻烦。我给出了自己在大团队和技术复杂性团队的实践的经验，希望对大家有所帮助。
来源：https://www.ibm.com/developerworks/cn/rational/1408_songjh_agilemanagement/
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
