本文是敏捷管理系列的第一篇,将介绍敏捷中重要的需求管理,涉及需求的获取和管理,以及后续规划问题。
▌主要内容:
- 瀑布流开发模式弊端
- 敏捷需求管理
- 如何获取需求
- 如何管理需求
- 史诗
- 用户故事
- 如何编写用户故事
- 如何规划需求——故事地图
- 总结
瀑布流开发模式弊端
在介绍敏捷之前先介绍一下瀑布流模式,这是产品开发中非常常见的一种管理模式,它以文档为驱动,在整个开发过程中,开发人员根据需求文档进行开发。所以在项目初期,确定需求和文档至关重要,通常在项目初期整个项目和产品便已经有了较为明确的雏形,项目成员需要严格按照需求文档和项目计划完成各自需要完成的工作。
由于在开发的中后期才会看到软件原型,早期只能通过文档来了解系统的模样,因此在一定的阶段,需求文档看起来会比产品实际的代码要重要。
这样的需求管理方式在传统软件系统管理中的优势在于可以在项目初期确定开发内容,更便于确定产品范围、人天预估、难度确认等,可以大大地减少项目失败的风险,同时项目成员也能通过详尽的文档来确认自己的职责和范围。但是这种管理方式在日新月异的产品开发中显得越来越笨重,在实践的过程中产生了以下难以解决的冲突和问题,比如:
-
需求变更:需求变更是软件研发中经常遇到的一种情况,而在瀑布流的方式中,软件开发的后一阶段都是在前一阶段交付后才开始实施,流程多、周期长,这样的特点导致瀑布流在应对需求变更时需要付出很大的代价。
-
质量管理:瀑布模式的测试阶段往往在大块功能开发完成后才会开始,在产品开发的时间线上都会比较晚,若测出来比较大的缺陷,可能导致产品无法准时上线。
-
成员积极性:由于需求驱动性开发,开发人员容易形成“事不关己”的态度,机械性的等待设计人员或者前阶段的产出与设计,不会站在客户或者实际使用者的角度去进行功能开发,导致开发出的功能常常“很难用”,一旦形成返工修改的恶性循环,甚至导致项目延期,会进一步打击项目成员的积极性。
-
过度开发:由于需求划定早,但是实际产出较晚,大概率出现实际上线的功能不符合预期或者花了大量时间在使用度并不高的功能上。导致过度开发的时间成本浪费。
-
适应性:市场需求、客户需求等对于产品的实际预期大概率会产生变化,现在产品需求的灵活度、创新性和变化度变得越来越频繁,瀑布式的开发模式由于开发流程时间长的特点很难适应这种场景下的需求管理。
针对以上传统瀑布流开发模式的弊端,敏捷管理的思维应运而生。在下面的文章中,将会以需求的产生、管理和规划三个部分去详细描述敏捷团队如何来处理软件开发中的需求。
敏捷需求管理
如何获取需求
需求实际上分为业务需求和软件需求,业务需求由不一定熟悉IT的业务人员完成,来源很广,会脱离实际的实现方式,着重于功能的描述。而软件需求由开发人员根据业