敏捷开发的实现和问题

今天学习了一波腾讯云里面的一篇文章：https://cloud.tencent.com/developer/article/1004881，你大概走了假敏捷：认真说说敏捷的实现和问题。

有次去西安百度创业园谈项目，甲方直接丢了一句，我们需要敏捷开发。我们：放心，肯定高质量、短周期的交期。敏捷需要面对面沟通，随时沟通，计划紧凑，总之就是快准狠。

1、敏捷

敏捷软件开发宣言：个体和互动高于流程和工具；工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划；

敏捷遵循的原则：

• 目标：持续不断地早交付有价值的软件使客户满意；
• 随时应对需求变化；
• 短周期交付可工作的软件；
• 业务与开发相互合作；
• 面对面交谈实现高效信息传递；
• 进度是首要度量标准；
• 减少不必要的工作量；

去文档，去流程，高效沟通和合作。去文档，敏捷管理者需要维护更为精细的需求池；去流程，口头沟通成为常态，对团队的耦合度要求更高。

agile：迅速，敏捷。这是敏捷的理念也是精髓：迅速响应需求，快速反馈结果。

sprint：字面意思是短跑冲刺，一个开发阶段被认为是一次冲刺，一个个 sprint 首位相连，构成一个项目。也可以理解为短期目标，短周期计划。

Scrum:指的是英式橄榄球中一股脑争球这一战术或行为。毕竟进展是最首要的度量标准；

scrum 即为这样一种方式，大家一拥而上，团队是球员，球是产品目标，人员环环相扣，围绕着产品目标进行工作。这里面多少有点“统筹法”的影子，人员深入协作以达到最优化效果。统筹协作。

Product Backlog:

backlog 即需求池。待办事项列表。其内容包含：1.待开发任务。2.任务优先级。

敏捷需要维护一份详尽的需求列表。这份列表常常要求 scrum 持有人（一般是产品经理）对所有待开发事项有深入了解，并且能够把待开发事项分解成更为细致的任务。众所周知，快速的开发需要责任到人，然后最有效的督促就是每天都有详细任务表，省得有偷懒的伙计。所以整个下来，会有一个详细的需求列表，每天都是deadline。

story board:在开发中，故事板展现所有需求的工作流。

burn down chart：燃尽图，一个 sprint 内，人/时是一个比较固定的值。在这个时间框架充分安排开发任务，每天进行时间结算，绘制时间燃尽图。项目成员通过燃尽图获知时间进展，若项目燃尽所用时间与预期时间契合，则需求时间预估和安排合理，若不契合则需要在下一个 sprint 进行调整。

这种燃尽图就类似下图，

 

2、 敏捷工具

随着敏捷在行业内的不断融入，各种工具产品层出不穷。国外jira、redmine，Axosoft ，国内的leangoo 、禅道，三大家则都有自研的工具，百度的icafe，阿里的aone，我鹅自研tapd。

项目协同软件还是很必须的，现在科普一下自己相关的工具

clearcase: IBM Rational, 商用，贵

perforce: P4,免费版支持5个license, 其他商用版

cvs: 开源，旧

subversion: 中小型公司常用，集中管控

git: 开源，分布式，最新，代码托管于github，使用于非集中办公的情况（故开源软件开发多选用它）

http://www.kuqin.com/shuoit/20141213/343854.html 【git开发流程好文】

-------------------------------------------

协同开发工具

Source Control: CVS/SVN 
Bug Tracking: Bugzilla, Trac, Roundup 
交流工具: maillist, IM, Forum, IRC, Wiki 
协同开发平台: sourceforge, BaseCamp

禅道， redmine: 

---------

Basecamp是37signals公司旗下的一款非常流行的基于云服务的项目管理软件。以简单易用和颠覆性的创新而出名。 Basecamp提供了消息板，待办事宜，简单调度，协同写作，文件共享。而不是甘特图，炫丽的曲线图，和繁重的电子表格。目前，成千上万的人同意这是一种更好的方式。来自的Farhad Manjoo说：“Basecamp代表了Web软件的未来。”

禅道是第一款国产的优秀开源项目管理软件。它集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款功能完备的项目管理软件，完美地覆盖了项目管理的核心流程。先进的管理思想，合理的软件架构，简洁实效的操作，优雅的代码实现，灵活的扩展机制，强大而易用的api调用机制，多语言支持，多风格支持，搜索功能，统计功能——这一切，您通过禅道，都可以拥有！禅道在手，项目无忧！
禅道百科地址：http://baike.baidu.com/view/7881832.htm

Redmine是用Ruby开发的基于web的项目管理软件，是用ROR框架开发的一套跨平台项目管理系统，据说是源于Basecamp的ror版而来，支持多种数据库，有不少自己独特的功能，例如提供wiki、新闻台等，还可以集成其他版本管理系统和BUG跟踪系统，例如SVN、CVS、TD等等。这种 Web 形式的项目管理系统通过“项目（Project）”的形式把成员、任务（问题）、文档、讨论以及各种形式的资源组织在一起，大家参与更新任务、文档等内容来推动项目的进度，同时系统利用时间线索和各种动态的报表形式来自动给成员汇报项目进度。

Redmine百科地址：http://baike.baidu.com/view/2228665.htm

上面来自：https://www.cnblogs.com/vigarbuaa/p/4317266.html

看了半天，没瞅见maven，

Maven是一个项目管理和综合工具。Maven提供了开发人员构建一个完整的生命周期框架。开发团队可以自动完成项目的基础工具建设，Maven使用标准的目录结构和默认构建生命周期。

在多个开发团队环境时，Maven可以设置按标准在非常短的时间里完成配置工作。由于大部分项目的设置都很简单，并且可重复使用，Maven让开发人员的工作更轻松，同时创建报表，检查，构建和测试自动化设置。

第一次使用的工具就是这个，当时就知道可以版本管理，汗颜。

敏捷工具的伟大作用，就是显而易见的需求、实时更新的计划、优先级明确的安排、详细的待开发列表。协同，最方便的是协同。

在人保驻场工作那会，最大的感触就是到处都是的计划、任务、预估时间、燃尽图，看的人亚历山大呀。像我看见领导都脑波是燃尽图，根本不需要这种吧！但是变成老油条的时候，还是很需要的。

3、设计师进入敏捷

我也算是做设计出身的，人保的移动报价器就是我的第一个整体做设计的作品。那是龙哥辛勤教导才出来的正常设计。设计进入敏捷，就是每天都有计划、每天都有进度、每天都有沟通、每天都是deadline。要知道，你需要不停的改，不停，不停，不停。

4、敏捷需要需求文档

从短期收益上看，文档对于敏捷开发是非必须品，并且很有可能会拖慢进度。在一个 sprint 中，口头沟通显然效率更高，每个人都有精确到工时的任务，没人有等待文档更新的时间。强调文档就等于放弃灵活性。

从长期和宏观上看，文档对于敏捷团队和敏捷的实施利大于弊——节省在一些常规问题上的沟通成本，同时降低错误的发生概率。对于一个将要长期实施敏捷的 团队来讲，文档让后续的工作效率更高。

几个重要的文档：产品文档、概要设计、接口文档

产品文档：1.需求；2.加入日期；3.开发版本；4.呈现和详细方案

在非敏捷开发流程中，文档在评审会后完善并更新，形成一个给研发参考的实现目标。在敏捷中，需求本身在 sprint 周期内不断完善，你可以在一个 sprint 之后将文档补全。

概要设计：敏捷的常规迭代中，概要设计不是一个必须的文档。但全新项目、重构以及重大新功能则必须输出概要设计文档。研发 leader 责无旁贷，这个落你身上了。

接口文档：必要且重要。包括接口说明、字段定义、字段类型、值定义、数据上报、错误码等。一般来说约定之后由接口开发者更新文档，如果你们没有云端存储的能力，至少咱们人手一份，定期更新。

在和客户对接过程中发现，文档真是个好东西，就像区块链一样，有着你不可篡改的规矩。有时候客户不断的改动需求，还就说你没按计划，所以，白纸黑字最好的证据。如果说可以灵活变动需求，那看钱也是能实现的。

文档最大的好处就是有据可寻。

5、大项目的敏捷

既然是大项目，需求确定至关重要。所以先要多次沟通需求（此处重点）。团队必须不厌其烦地理解需求或修正产品经理“天真的幻想”，产品经理使用不断完善的原型同团队进（tao）行( jia )沟( huan )通( jia )。在最后的产品评审之前，至少敲定产品框架和大部分细节。这次评审邀请项目成员和所有协同团队，除了敲定的产品功能，技术上需要得到一些初步结论（比如“能不能做”。事实上，产品经理应该在产品规划阶段就知会协同团队将要做什么）。接下来进行概要设计（新产品、重构、重大新功能必须进行概要设计）。技术评审邀请除设计以外的项目成员和协同团队参会。

首次接项目，遇到过一个奇葩，需求确定多次，这个不懂技术的客户，最后不要了。丢了一句，不符合需求。当时想一嘴巴子扇死他。后来也就咬咬牙，收手了。所以，多次确认需求，多次确认需求，无论项目大小，这是填坑最好的方式。

大项目敏捷中：

1.将 deadline 之前的时间分解为多个 sprint 。（deadline 之前必须留出一定“出血时间”用以解决时间预估不足的任务、返工任务以及 bug )

2.将所有需求分解成任务，开一次全局 scrum 会。预估时间之后，分散任务到各个 sprint 中。在时间较紧的情况下，sprint 的容量就要相应增加。

3.进入敏捷流程，常规 scrum 会、站会，燃尽图，故事版。未完成任务在 scrum 会上重新预估时间，滚入新 sprint 内，以此类推（按时完成 sprint 内的任务是目标。实在不行我们还有“出血时间”呢）

4.别忘了文档。虽然被推崇备至，但敏捷并不是完美的开发方法。敏捷的最大的优势是灵活，而造成敏捷问题的根源也正是灵活。

文末再总结本文重点：

1.敏捷是一种流程、方法、理念，甚至信仰。

2 用了敏捷管理软件不一定就是敏捷。敏捷的初衷是团队成员能够更加紧密地配合完成工作，线上的的流转如果削弱了这种配合性，反倒背离了敏捷的本意。实际上只要有白板纸张和笔，你的团队就能开始敏捷。

4.我们敏捷了，不是不要文档了。在外部交流多、世代跨度长的情况下，文档的必要性显而易见。长期的面对面沟通最终会导致低效，这也是敏捷缺陷的根源。

5.设计师可以完全介入到敏捷流程中，只需要做一些细心的安排。

6.大项目开发中可以走敏捷，具体问题具体分析，需要根据项目特点制定敏捷计划。

敏捷开发总结出来果然就是快、准、狠。