我们比较熟悉的软件项目管理方式就是瀑布。它的基本流程是需求->设计->开发->测试。基本假设是只要每个环节都做对了，最后的结果也是正确的。瀑布式开发有非常成功的案例，比如微软。但是一般来说，瀑布项目的失败率是比较高的。国外的软件先驱们针对瀑布式开发暴露出的问题进行了一系列的探索、反思和总结，提出了AgileDev的概念，中文译为敏捷开发。一。什么是敏捷开发？敏捷开发关注用户需求的演变，采用迭代的、循序渐进的方法进行软件开发。在敏捷开发中，一个软件项目在建设初期被划分为多个子项目，每个子项目的成果都经过测试，使其可视化、可集成、可操作。换句话说，就是将一个大项目拆分成多个相互关联又可以独立运行的小项目，分别完成，软件在这个过程中始终处于可用状态。与瀑布式开发模式相比，敏捷开发更加灵活和可操作。二。敏捷开发方法及流程敏捷开发方法有很多，如scrum、XP、LSD、FDD等，其中scrum是非常流行的一种。Scrum将产品开发分解为若干个小的冲刺（迭代），其周期从1周到4周不等，但不会超过4周。参赛团队成员一般为5至9人。每次迭代要完成的用户故事是固定的。每次迭代都会产生特定的可交付成果。scrum的基本流程如图所示：1.po（productowner指的是产品负责人）负责梳理userstory，形成左边的productbacklog（产品需求排列清单）按优先顺序）。2.Releaseplanningmeeting：po负责解释用户故事，进行预估和整理，releaseplanningmeeting的输出是制定本次迭代需要完成的故事列表，称为sprintbacklog。3.迭代计划会议：项目组分解每个故事的任务。分解标准是完成故事的所有任务。最后，每项任务都有明确的负责人，完成工时的初步预估。4、每日例会：每天sm（scrummaster指的是项目负责人）召开立会，团队成员回答昨天做了什么，今天打算做什么，有什么问题。5、演示会：迭代结束后召开演示会，邀请相关人员参与，团队负责向大家展示本次迭代的成果。期间大家的反馈被PO记录整理，形成新的故事。6回顾会议：项目组对本次迭代进行总结，发现不足，制定改进计划，并在下一次迭代中继续改进，达到持续改进的效果。敏捷过程中的三个关键要素是：Productbacklog（产品需求）sprintbacklog（本期迭代任务）burn-downchart（燃尽图，进度的体现）呈现任务发布-拆分-推进的全过程。三。我们知道瀑布式开发是由文档驱动的，而文档是一切工作的核心。Po需要写很多复杂的文档，比如：需求文档，设计文档，API文档，验收文档等等。敏捷宣言说，“Workingsoftwareisbetterthanthoroughdocumentation”。敏捷反对这种“重文档”的方式，而是强调成员之间的紧密协作、面对面的沟通、频繁的新版本交付、紧凑和自组织的团队。由此可见，敏捷开发是一种更实用、更可操作的开发方式。但这并不意味着敏捷开发完全抛弃文档，敏捷开发遵循“轻文档，重沟通”的原则。“轻文档”体现在敏捷开发只关注文档中的重点，尽可能地简化文档，或者用软件工具呈现另一种形式的文档。就传统文档而言，一份PRD（ProductRequirementDocument）包含对多个成员的诉求，比如前端工程师、后端工程师、测试人员。众多的产品需求导致文档厚重繁琐，在实际工作中，很多开发人员不喜欢看文档。因为往往一个PRD里面可能有好几页和你无关，但是你要看一遍才知道是不是和你有关，无形中造成了时间的浪费。在敏捷管理中，用户故事用于呈现产品积压。“用户故事（简称用户故事）”是一种用用户熟悉的术语表达需求的方法。是用户讲给开发者的故事（实际上是通过po收集用户需求，整理成用户故事）。比如“作为禅道用户，我希望能实现自动登录功能，这样可以更方便的登录系统”。这是一个具体的需求描述。在这个需求描述中，涉及三个要素：“用户角色（禅道用户）”、“目的达成（自动登录功能）”、“开发价值（更便捷的登录系统）”。当然，除了这三个要素外，还需要涉及Acceptancecriteria、priority、reviewers等。借助软件工具实现产品待办事项信息沟通是敏捷开发最普遍的做法。po将功能点拆分，导入到项目管理软件中。相关人员只需按照需求目录一项一项执行即可，不再需要一页一页地阅读PRD。后端只需要提供接口相关，前端主要看功能相关的部分，不需要看与自己无关的内容。如果开发人员在具体的sprintbacklog开发中有问题和疑惑怎么办？交流！“重沟通”体现在以结果为导向，以人为本。通过面对面的交流快速反应和进步。您可以随时与po一对一沟通，解决您的疑惑。而且，整个敏捷团队还需要召开发布计划会、迭代计划会、演示会、每日站会等内部会议。在每日站会上，团队成员轮流回答昨天做了什么，今天打算做什么，有什么问题，发现问题及时提出解决。每个人都说完之后，就要去任务板更新自己的燃尽图了。这也是敏捷过程中必不可少的环节。任务看板一般包括未完成、进行中、已完成的工作状态。假设你今天完成了一个未完成的任务，那么你需要将未完成区域的小卡片粘贴到已完成区域。每个人的工作进度和完成情况都是公开的。如果一个人的工作任务在某个地点放置了好几天，大家就能发现他的工作进度可能出了什么问题。今天的任务看板和燃尽图已经从物理对象转变为项目管理软件。表现形式基本延续了实物看板的形式。禅道分为几种状态：未开始、进行中、暂停、完成、取消、关闭。在看板页面上，成员可以在完成一项任务后，从进行中拖拽到已完成栏目，这与实体看板如出一辙。与传统的开发模式相比，敏捷更强调去流程化，不再需要文档，可以简化和替换。因为在敏捷开发中，最简单的方案就是最好的方案，最高效的工作方式就是最好的工作方式。
