敏捷开发中的文档：要不要写？怎么写？

咱们比较熟知的软件项目管理方法是瀑布。其基本流程是需求-> 设计->开发->测试。基本假设只要把每个环节都作正确，那么最终获得的结果也是正确的。瀑布开发有很是成功的案例，好比微软。但从整体来说，瀑布项目失败率比较高。国外的软件先行者们针对瀑布开发中暴露出来的问题进行了一系列的探索、思考和总结，提出了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解除疑问。并且整个敏捷团队还须要召开发布计划会议、迭代计划会议、演示会议等内部会议及每日站立会议。每日站立会议上，团队成员依次回答昨天作了什么今天计划作什么，有什么问题，发现问题及时提出和解决。每一个人发言完后，要走到任务看板前更新本身的燃尽图。这也是敏捷流程中不可缺乏的环节。

任务看板通常包含未完成、正在作、已完成的工做状态，假设你今天把一个未完成的工做已经完成，那么你要把小卡片从未完成区域贴到已完成区域。每一个人的工做进度和完成状况都是公开的，若是有一我的的工做任务在某一个位置放了好几天，你们都能发现他的工做进度可能出现了什么问题。

现在的任务看板和燃尽图已经由实物形式转变为项目管理软件。表现形式基本延续实体看板的形式，禅道中分为未开始、进行中、已暂停、已完成、已取消、已关闭几种状态。在看板页面，成员完成某项任务后便可从进行中拖拽到已完成列，跟实体看板的做用一模一样。
比起传统开发模式，敏捷更增强调去流程化，文档再也不必须，变得能够简化和被取代。由于在敏捷开发中，最简单的解决方案就是最好的解决方案，最高效的工做方式就是最好的工做方式。