|
前言项目管理者联盟
现在软件领域三大俗，说的是敏捷、大数据、云，说的越多的往往也是处于成熟中，或者需求强调的，我所遇到的项目有幸几乎都触及到这些俗气的元素。项目管理者联盟
不得不说，市场竞争和各厂商客户意识的提升，现在的用户已经被宠坏了，以前我们叫挖掘需求，也就是客户是有自己需求的只是表达传递的完整性问题，通过一定的需求工程的方法把这些需求给定义出来，变成软件需求就好了。现在客户往往是不知道自己想要什么的，他们往往会提出"高大上"的需求，比如："我要一款软件，使我的业务管理水平达到行业的标杆，至少这个软件具体应该有什么功能我也不知道，我们预算是要多少有多少，关键是要做好，要在最短时间内最好是明天交付出来，否则后续取消与你们的合作。"，相信很多开发人员听到这些"需求"都会感到无所适从。pmp.mypm.net
不幸我就遇到类似的一个项目，客户需求就是一句话："在国家批下来的预算范围内，给我们做一个本行业标杆性的软件，需求嘛你们自己研究研究，我们就看效果，但必须在 1 个月内上面领导下来参观前完成"，经过初步分析，参考这个行业的同类软件，至少涉及到集群数据存储与分布式检索、广度爬虫、自然语言识别，当然还有面向客户的业务应用系统。而且作为公司的战略项目，关系公司后续的市场开拓，老板发话："必须成功，还要注意成本"。项目管理者联盟
大家现在知道了，又遇到有中国特色的项目了，"需求范围不确定，资源限死、时间限死"，大家会说不是战略项目吗，资源怎么会限死呢?但是请大家想想，客户预算是一定，根据财务核算，老板要拿的利润也是刚性的，还能剩多少，大家可以发挥想象了。考虑该如何实施这个项目时，似乎传统的项目管理从计划来分配资源模式以及采用瀑布型的开发方式，根本行不通。就在我焦头烂额之际，我想起了解过的一种开发模式：项目管理者联盟
Scrum 开发模式使得我们能够专注于如何在最短的时间内实现最有价值的部分;Scrum 开发模式使得我们能够快速的经常的监督实际产品发展的状况;Scrum 开发模式使得团队按照商业价值的高低先完成高优先级的产品功能，并自主管理，凝结了团队智慧创造出最好的方法因而提高效率 ;Scrum 开发模式使得每隔一两周或者一个月，我们就可以看到实实在在的可以上线的产品。此时，就可以进一步的决定是继续完善功能实现更多需求或者直接发布了 。这正是我想要的管理方法，也是敏捷界被采用最广泛的管理方法，但一般的 Scrum 显然也无法有效的应对此种情况了，还得自己完善和扩展。PgMp.mypm.net
项目开发过程的设计项目管理者联盟
 项目管理者联盟
针对这类客户应该是提供业务的解决方案然后再提供软件系统，因此整体的开发过程不能直接从用户需求开始，而应该从业务研究开始，如上图 1 的开发过程来实施。talent.mypm.net
在敏捷开发中对于需求的假设是认为，需求是涌现出来的，但我们知道架构设计能够开始是基于关键需求已经确认的情况下，而且在国内的环境下如果在需求不确定的情况下就开发，客户更可能随意的修改需求，而工期又限死的情况下，项目必然是会失败的。因此在中国的客户成熟度情况下，最好还是书面确认大部分关键需求后再开始做，否则，很多情况下会成烂尾楼。talent.mypm.net
为了能加快前期需求阶段的进展，必须有业务架构师来分解业务模块，不同的 PO 来负责各自业务模块的需求分析。当关键需求确认后，开始技术架构的设计，同时在技术架构的基础上进行迭代的开发。因此，整个团队的结构如下图2：training.mypm.net
 项目管理者联盟
由规划经理来有序的协调和规划多个PO的前期工作，开发组由多个特性开发团队组成，由系统组完成整个软件架构设计，将系统按业务和技术进行切分，使得各开发团队间能够进行协同。talent.mypm.net
每个特性开发团队都是一个敏捷团队，均采用完整的 Scrum 的管理实践，同时采用持续集成、代码静态检查、代码交互评审的、验收测试驱动来进行质量的保证。单元测试的实践，由于时间紧研发人员都担心会影响项目进度，因为本身测试代码工作量也不少。因此我们没有按真正 TDD 方式去推行，而仅会要求针对问题最集中的模块和失败的用例涉及到的代码进行单元测试覆盖，目的是保证迭代过程中代码修改的完整性，而不是用于驱动设计，最终实际统计单元测试覆盖率仅 30%不到。先写测试用例再写代码的方式，在部分小组试过几次但大家都反馈很难适应。因此没有再继续要求。项目管理者联盟
具体的实践方法有很多文章来论述，这里就不再重复。项目管理论坛
项目遇到的麻烦-需求club.mypm.net
由于需求与开发团队是异步进行，而不是从一开始就紧密运作的。开发团队与规划组之间，开始并没有团队意识，还是按瀑布的阶段交付的思维来对待。所以，项目组开会时，开发团队与需求团队就经常发现摩擦。项目经理博客
开发要求需求人员将需求描述的非常细，否则不予接受。而需求人员由于在局方现场，要将需求描述的很细的情况下就需要耗费很多文档时间，而用户时间有限，所以希望能将需求描述简单一点，关键是需求人员将需求写的很细的情况下，开发人员在开发过程中任然还是需要不断的去沟通需求，毕竟靠文档完整表述还是有困难的。而测试团队先等待开发做完，再开始测试。于是开发、需求之间经常就需求文档细致问题无法高效协同，测试介入很晚，到测试时对业务不熟悉，只能希望开发出相关的设计文档来进行测试，效果很差。由于团队之间对立情况，反而加剧了对文档传递的依赖，项目进度慢了下来。club.mypm.net
对此，我们认为这个是因为项目实践出来偏差，没有真正领悟，敏捷开发中为什么需求必须是讨论出来，而不能是通过一个详细设计文档去传达，使得每个成员都对需求来负责，而不是仅仅被动的接受。项目管理论坛
对此，项目要求各团队的 PO，不再写详细的需求文档，而是出需求列表。强制要求，需求的传递必须通过需求澄清方式完成。training.mypm.net
也就是需求、开发、测试人员，同时参与需求的分析工作。步骤如下：项目管理者联盟
需求人员列出所有的 product backlog 的 story，并进行排序;talent.mypm.net
开发、测试人员，听 PO 对每个用户故事进行讲解，注意 PO 不再提供详细需求的文档了，然后开发、测试人员可以要求 PO 对每个需求讲解清楚，直到听懂理解并能开始进行设计工作为止;项目管理者联盟
开发人员将 PO 讲解的需求给记录描述出来，需要包括基本的业务流程图以及接口说明，同时要求测试人员将需求的验收条件给写出来，整合成针对每个 story 的需求澄清文档;pmp.mypm.net
由PO确认需求澄清文档内容的准确性，如果无误可以开始进入开发过程了。项目管理者联盟
|
