摘要：但这并不意味着敏捷开发完全抛弃文档，敏捷开发遵循轻文档，重沟通的原则。把功能点拆分，导入到项目管理软件中，相关人员只需要按照需求目录一条条执行即可，不再需要一页一页的看了。如今的任务看板和燃尽图已经由实物形式转变为项目管理软件。
我们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-> 设计->开发->测试。基本假设只要把每一个环节都做正确，那么最终得到的结果也是正确的。瀑布开发有非常成功的案例，比如微软。但从总体来讲，瀑布项目失败率比较高。国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结，提出了Agile Dev的概念，中文翻译为敏捷开发。
一．什么是敏捷开发
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。
换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。相对于瀑布开发模式，敏捷开发更加灵活可操作。
二．敏捷开发方式及流程
敏捷开发有很多种方式，如scrum,XP,LSD，FDD等，其中scrum是非常流行的一种。
scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。
scrum的基本流程如图所示：
1.po（product owner指产品负责人）负责整理user story，形成左侧的product backlog（按优先顺序排列的一个产品需求列表)。
2.发布计划会议：po负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，叫做sprint backlog。
3.迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，最终每个任务都有明确的负责人，并完成工时的初估计。
4.每日例会：每天sm（scrum master指项目负责人）召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
5.演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
6回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。
敏捷流程中的三个关键要素是：
product backlog（产品需求）
sprint backlog（本期迭代任务）
burn-down chart（燃尽图，进度的体现）
呈现了任务下达-拆分-推进的整个过程。
三．“轻文档，重沟通”的敏捷
我们知道，瀑布开发是以文档为驱动，文档是一切工作的核心，po需要写非常多而复杂的文档，例如：需求文档、设计文档、API文档、验收文档等等。
敏捷宣言说，“可工作的软件胜于详尽的文档”。敏捷反对这种 “重文档”的方法，而是强调成员之间的紧密协作、面对面的沟通、频繁交付的新版本、紧凑而自我组织型的团队。可见，敏捷开发是更实际，更注重操作性的开发方式。
但这并不意味着敏捷开发完全抛弃文档，敏捷开发遵循“轻文档，重沟通”的原则。
“轻文档”体现在，敏捷开发只关注文档中的重要点，尽可能的简化文档，或者用软件工具呈现另一种形式的文档。
以传统文档来说，一个PRD（产品需求文档）中包含对多个成员的诉求，比如前端工程师、后端工程师、测试人员。众多的产品需求导致文档厚重繁琐，而且在实际工作中，很多开发人员并不喜欢看文档。因为常常一个PRD中可能有好几页内容都是与自己无关的，但是要看过才知道是否与自己有关，这在无形中就造成了时间的浪费。
敏捷管理中采用了用户故事的方式进行product backlog的呈现，“用户故事（称作user story）”是采用用户熟悉的术语来表达需求的一种方法，是用户讲给开发人员的故事（实际由po搜集用户需求并整理成用户故事）。
例如“作为禅道 用户，我希望能实现自动登陆功能，这样能更方便的登陆系统。“这就是一个具体的需求描述。
在这个需求描述中，涉及到三个要素“用户角色（禅道用户）”、“达成的目的（自动登陆功能）”、“开发价值（更方便的登陆系统）”
当然除了这三个要素，还需要涉及到验收标准、优先级、评审人等。
借助软件工具实现product backlog的信息传达是敏捷开发最普遍的做法。po把功能点拆分，导入到项目管理软件中，相关人员只需要按照需求目录一条条执行即可，不再需要一页一页的看PRD了。后端只需要与提供接口相关的，前端主要看与功能相关的部分，而不需要查看与自己无关的内容。如果开发人员在具体的sprint backlog开发中存在问题和疑问怎么办呢？沟通！
“重沟通”体现在以结果为导向，以人为核心。通过面对面沟通的方式快速反应，推动进度。
你可以随时一对一沟通po解除疑问。而且整个敏捷团队还需要召开发布计划会议、迭代计划会议、演示会议等内部会议及每日站立会议。每日站立会议上，团队成员依次回答昨天做了什么今天计划做什么，有什么问题，发现问题及时提出和解决。每个人发言完后，要走到任务看板前更新自己的燃尽图。这也是敏捷流程中不可缺少的环节。
任务看板一般包含未完成、正在做、已完成的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。每个人的工作进度和完成情况都是公开的，如果有一个人的工作任务在某一个位置放了好几天，大家都能发现他的工作进度可能出现了什么问题。
如今的任务看板和燃尽图已经由实物形式转变为项目管理软件。表现形式基本延续实体看板的形式，禅道中分为未开始、进行中、已暂停、已完成、已取消、已关闭几种状态。在看板页面，成员完成某项任务后即可从进行中拖拽到已完成列，跟实体看板的作用如出一辙。
比起传统开发模式，敏捷更加强调去流程化，文档不再必须，变得可以简化和被取代。因为在敏捷开发中，最简单的解决方案就是最好的解决方案，最高效的工作方式就是最好的工作方式。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/52481.html
摘要：毕竟，架构师不参与写代码的工作。例如，通常架构师需要针对可能发生的每种情况进行规划。这种架构师需要信任开发团队来编写代码。 showImg(https://segmentfault.com/img/bVblaqV?w=900&h=383); Talk is cheap, show me the code！但是在互联网企业中，身处技术要职的架构师到底需不需要写代码？ showImg(ht...
摘要：简单来说就是给定条件执行流程预期结果的一个文档，供后续测试人员进行测试。测试用例的设计需要尽可能覆盖软件的所有状态，尽量考虑周期。针对测试人员少，上线时间紧的项目，可只做思维导图列出测试点。我平时是用去设计测试用例。 ...
摘要：看起来没有集合框架，线程，等那么耀眼，但它可是很多框架的基础啊回复反射查看相关文章，先把基础学会，后面的得用到它。 回头看看， 我进入Java 领域已经快15个年头了， 虽然学的也一般， 但是分享下我的心得，估计也能帮大家少走点弯路。[入门]我在2001年之前是C/C++阵营， 有C和面向对象的基础， 后来转到Java ，发现没有指针的Java真是好简单， 另外Java 的类库好用的让...
摘要：自动填补分号的规则在说要不要写分号之前，先了解一下自动填补分号的规则。后来看到知乎上的作者尤雨溪和前端大神贺师俊的回答后，我对写分号的想法完全颠覆了。总是写分号并不能完全解决缺陷如后换行会自动插入分号。 在打算写这篇文章之前，我是一个分号党，在写这篇文章之后，可能会转为无分号党了。之前是写分号是编辑器语法较检所养成的强迫症，现在观念的转变，是因为看了不少大神的讨论后，觉得javascr...
摘要：原文链接有大量平均水平左右的工人可被选择参与进来这意味着好招人有成熟的大量的程序库可供选择这意味着大多数项目都是既有程序库的拼装，标准化程度高而定制化场景少开发工具测试工具问题排查工具完善，成熟基本上没有团队愿意在时间紧任务重的项目情况 原文链接：http://pfmiles.github.io/blog/java-groovy-mixed/ 有大量平均水平左右的工人可被选择、参与...
阅读 2181·2021-11-18 10:02
阅读 536·2021-10-08 10:04
阅读 2001·2021-09-03 10:51
阅读 3393·2019-08-30 15:44
阅读 2675·2019-08-29 14:09
阅读 2349·2019-08-29 12:21
阅读 1916·2019-08-26 13:45
阅读 1661·2019-08-26 13:25
