我们的敏捷之路——故事篇

*今天出于机缘巧合参加一个敏捷的研讨会，虽然在现在这个敏捷已经烂大街的年代，再一次听到各种熟悉的名词还是能让人再次心潮澎湃。正好趁此机会我把之前在为了奇怪目的根据真实经历写的论文拿出来作为本周的博客。

本文记录了我们的敏捷实践过程以及团队的成长历程，欢迎各位对号入座。*

小伙伴们准好了么？下周开始敏捷再落地。

什么是敏捷开发

定义

敏捷开发是以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。核心在于通过不断试错的形式向用户交付有意义的产品。关键词:用户，产品，迭代，改进，简单。

宣言

2001年2月11日至13日，在美国犹他州瓦萨奇山雪鸟滑雪胜地，17个人聚到一起，交谈、滑雪、休闲，当然还有聚餐。他们试图找到共识，最终的成果就是《敏捷软件开发宣言》（Manifesto for Agile Software Development）。参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们，还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。

由全体参会者签署的《敏捷软件开发宣言》（Manifesto for Agile Software Development）成为了重要标志，因为这么大一帮无政府主义者能聚到一起实在是太不容易。只有英国人Martin Fowler表达了对“敏捷”这个词的担心，他认为多数美国人都不知道“敏捷”这个词如何发音。

Alistair Cockburn和很多参会者一样，最初有很大的担忧。“我个人没有期望本次敏捷达人们的聚会能够达成任何实质性共识。”会后，他再次分享了自己的感受。“对我来说，很开心宣言能够最终定稿。而让我感到惊讶的是其他人也同样开心，因此我们的确达成了某种实质性共识。”

这群有时存在相互竞争的软件开发独立思考家们共同签署了展示在网站（http://www.agilemanifesto.org/）首页的《敏捷软件开发宣言》，他们称自己为“敏捷联盟”。

敏捷宣言的内容：

个体和交互 胜过 过程和工具

可以工作的软件 胜过 面面俱到的文档；

客户合作 胜过 合同谈判；

响应变化 胜过 遵循计划。

虽然右项也有价值，但是我们认为左项具有更大的价值。

对宣言的诠释：

1) 最重要的是通过尽早和不断交付有价值的软件满足客户需要。

2) 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。

3) 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。

4) 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。

5) 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。

6) 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。

7) 可以工作的软件是进度的主要度量标准。

8) 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。

9) 对卓越技术与良好设计的不断追求将有助于提高敏捷性。

10) 简单——尽可能减少工作量的艺术至关重要。

11) 最好的架构、需求和设计都源自自我组织的团队。

12) 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

1.3 原则

1) 通过早期和连续型的高价值工作交付满足“客户”。

2) 大工作分成可以迅速完成的较小组成部门。

3) 识别最好的工作是从自我组织的团队中出现的，

4) 为积极员工提供他们需要的环境和支持，并相信他们可以完成工作。

5) 创建可以改善可持续工作的流程。

6) 维持完整工作的不变的步调。

7) 欢迎改变的需求，即时是在项目后期。

8) 在项目期间每天与项目团队和业务所有者开会。

9) 在定期修正期，让团队反映如何能高效，然后进行相应地行为调整。

10) 通过完车的工作量计量工作进度。

11) 不断地追求完善。

12) 利用调整获得竞争优势。

价值观

1) 沟通

建模不但能够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的project stakeholder之间的沟通。

2) 简单

画一两张图表来代替几十甚至几百行的代码，通过这种方法，建模成为简化软件和软件（开发）过程的关键。这一点对开发人员而言非常重要－它简单，容易发现出新的想法，随着你（对软件）的理解的加深，也能够很容易的改进。

3) 反馈

Kent Beck在Extreme Programming Explained中有句话讲得非常好：“过度自信是编程的职业病，反馈则是其处方。”通过图表来交流你的想法，你可以快速获得反馈，并能够按照建议行事。

4) 谦逊

最优秀的开发人员都拥有谦逊的美德，他们总能认识到自己并不是无所不知的。事实上，无论是开发人员还是客户，甚至所有的 project stakeholder，都有他们自己的专业领域，都能够为项目做出贡献。一个有效的做法是假设参与项目的每一个人都有相同的价值，都应该被尊重。

为什么敏捷

满足用户不断变化的需求是软件开发的长期无法解决的难题之一,经典的瀑布模式在一个迭代周期内表现优异,但一旦需求变化,瀑布模式却显得无能为力。敏捷方法满足需求的办法主要通过迭代。在每一次迭代周期结束时,都能交付用户一个可用的、可部署的系统,用户使用并体验该系统并反馈意见,在随后的迭代周期这些意见和需求的其他变化一起在产品中实现和集成。每次迭代周期应尽可能短,以便能及时地处理需求变化和用户反馈。

敏捷开发方式能给企业和用户带来以下好处:

1) 精确。瀑布模式通常会在产品起点与最终结果之间规划出一条直线,然后沿着直线不断往前走。然而当项目到达终点时,用户通常会发现那已经不是他们想去的地方。而敏捷方法则采用小步快跑,每走完一步再调整并为下一步确定方向,直到真正的终点。

2) 质量。敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如极限编程等,甚至使用测试驱动开发(test-driven development),即在正式开发功能代码之前先开发该功能的测试代码。这些都为敏捷项目的整个开发周期提供了可靠的质量保证。

3) 速度。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外,较短的迭代周期使团队成员能迅速进入开发状态。

4) 丰厚的投资回报率。在敏捷开发过程中,最具价值的功能总是被优先开发,这样能给客户带来最大的投资回报率。

5) 高效的自我管理团队。敏捷开发要求团队成员必须积极主动,自我管理。在这样的团队中工作,每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。

我们的故事

背景

HY系统是一个对无人机任务，实时信息以及基础信息的监控与管理系统，在某单位的牵头下开始建设，但由于无人机作为一项新技术刚刚在HY行业中投入使用，对于无人机的应用没有现成的经验，用户更没有明确的需求，在这种情况下提前启动项目。本人作为项目负责人参与项目的开发。由于用户需求不明确，前期虽花费大量精力进行用户需求调研，也没有获得明确的系统功能要求或业务模型。只能按照自身的理解进行业务流程和系统功能的设计，开发的出功能虽满足用户所有系统功能的要求，并于2015年9月通过了用户的验收，但用户始终没有对系统满意，因此验收后仍不断对系统提出功能的变更。

在2015年9月，系统验收后，面对用户不断提出的功能要求，公司原有的科研生产机制已经无法进行灵活的应对和管理，而本人恰好在此时接触了敏捷开发理论并参加了敏捷落地之旅的培训，在培训中解开了多个敏捷开发的问题，并与老师进行了讨论，确认敏捷开发应该更适合这个系统的开发。于是，敏捷实战之旅开始了。

开始试验

在开始说正事之前，要介绍一下开发团队，在开始展开的时候团队由三个人组成:我，小H，小R和T姐，就是这样来了，小H是入职一年的员工，接手海域系统已经有几个月了，小R有前端开发经验而T姐没有开发经验，都是入职刚刚3个月，额，这就是现实，这也是寻求变革和突破的原因。大家都是在刚刚进入软件行业，没有经验，但同样没有束缚，都是年轻人，新东西接受起来还算比较快。

刚刚学成归来，我就迫不及待的计划着将团队的开发模式转为敏捷模式，对了首先采购了一批敏捷开发的书籍进行理论知识的恶补，由于都没有敏捷开发的任何经验，因此决定采用最流行的scrum并逐步将敏捷开发的措施引入到团队中，即：迭代开发，每日站会，产品backlog，验收演示和回顾会议。确定好第一步转型方案后，说干就干，反正我们也没什么可失去的。

于是经过一番准备，在十月的第一个周一，正式开始敏捷转型。第一步进行了一个启动会，会上先跟大家介绍了一下敏捷开发的基本理念，并划分了角色，限于经验和条件，我担任project onwer（PO）和scrum master（SM），小H，小R则为开发人员，T姐为测试人员，我们当时连单元测试都没有完全掌握，因此暂时安排专门的测试人员负责测试，并定义完成的状态必须是经过测试人员的亲自测试才能算完成，特殊情况（测试人员不在）需要project onwer来确认。对于像TDD，结对编程等高级实践只能先缓一缓了，心有余而力不足。同时宣布一下以下措施：

1） 采用两周为一个周期进行迭代开发；

2） 每天早晨九点进行每日站会；

3） 每个周期结束时进行验收演示；

4） 所有的开发需求都通过产品backlog来记录和展示；

5） 周期的第一天进行上一个周期的回顾和这个周期的工作内容的确定。

开完会感觉大家都还有点懵，但是都知道要开始新的开发模式了。团队的敏捷转型就这样开始了。

第一个周期进行的还算顺利，每天九点都招呼大家一起开会，回答三个为你：昨天做了什么，今天准备做什么，有什么困难，对了开始将backlog打印了一份贴在了开发团队场地，我们一般称为实验室。然后把这个周期要做的事用笔标出来，这就是我们任务板的起源，好吧有点low，但至少是有了。第一个周期很快就结束了，这两周确实不一样，大家基本了解其他人的工作，而且每天的工作进度都在任务板上有所体现，最后还进行了优化的系统演示。第一次演示时虽然有点乱，但还是将新功能演示出来了，好吧系统用起来确实有点不那么顺手。

第一个周期结束了，我们进行回顾会议，但大家没人主动说自己的想法，于是拿来便利贴，每个人将这个周期做的好的还有不好的都写出来，至少写一条，最终从中选两条进行改进。就这样，我们选择了改进任务板和兼职测试人员这两项改进措施。

完成了第三个周期后大家渐渐熟悉来这个模式，一切都变得好起来了，每次回顾会议大家都能提出一些真正的问题，每个周期都在改进优化，大家共同组成了一个真的团队，团队的凝聚力和战斗力快速提升。每个人都知道我们要达成怎样的一个效果，我们要做什么事。。

回顾与成长

经过10个周期的迭代，系统的质量明显好转，用户需求被快速满足，用户的满意度有了显著提升，而团队也得到来快速成长，从单元测试是什么到建立了基于junit的单元测试与集成测试框架，覆盖系统全部业务流程和核心功能，从各自只关心自己负责的模块的代码到每个人都了解整个系统的架构，从代码只要能运行就行了到力争在每天的code review中不让别人挑战成功。而我们的系统也在用户那开始试运行，每次都能快速的响应用户的需求，系统质量也大为提升，这一点上远远超出用户其他在建系统，得到了用户充分肯定。

我们在敏捷开发中也走的越走越远：每日站会，任务板，backlog，回顾会议，计划会议，故事评估，结对编程，代码公有制，测试驱动开发，code review，重构等等措施都被实践过，而不适合目前阶段的也都又被舍弃了。

同时我们也知道在敏捷中最为重要的几个实践我们都没有引入，如持续集成，自动化测试等措施，代码质量的评审作用也没有充分发挥。其实持续集成与自动化测试的关键技术如：maven与jenkins我们早就进行过调研和可行性研究，可惜由于海域系统是复用了某个大型项目的重量级框架（OSGI的定制版），使maven或ant很难应用，除非对项目整体框架进行迁移否则不太可能实现持续集成和自动化测试。由于项目已验收，这种架构级变动太大，不太可行。

而就在此时一个新的特殊项目很快就要上马了，我看到新项目的介绍我就知道新机会来了。

新机会

新上马的项目是个比较特殊的项目，暂时就叫SC项目吧，SC项目呢是一个典型的政府型项目，需求必然是说不清楚的，但有一个硬性要求，要在一个半月之后的某个大会上展示相关的成果，就是要在这个行业内做一个标杆性项目，总之一句话，具体的我也不管，但一定要高大上。根据我们对这个行业的调研，发现这个项目是集多种设备类型的实时数据监控，实时视频监测，任务跟踪和管理，基础信息管理于一身的监控与指挥系统，同时包括客户端，ios移动端以及android移动端还有Web版的系统。

非典型性高风险项目，一个辣手的活，还好我们已经有了HY项目的经验，如果复用原来的系统框架也许很短时间内就能做出来一版，先在是该做出选择的时候了。反正这个活是接定了，战略任务。

再次启航

由于时间紧任务重，开发团队由L，小H，小C，T姐还有我组成，同时跟在启动会中跟大家说明了情况，考虑到HY项目框架已经表现出过于重型，复用代价高且无法应用自动化测试与持续集成的问题，我们决定采用之前进行过调研的新一代技术框架，同时基于maven管理项目，虽然时间紧任务重，需求还不清，但HY项目给了大家足够的信心，这都不是事。同时由于周期很短只有7周时间，因此把sprint周期定为1周，我们需要更快的响应可能的变化和挑战。

就这样开始了sprint-0的开发，在sprint0，L首先进行系统springboot以及SSH框架的搭建，同时小H对HY项目的资源进行分析和抽取，毕竟模块级的复用还是必须的。T姐和小C则去跟踪分析需求，形成第一版的project backlog。我则开始来Jenkins，Sonar，Upsources以及Jacoco等平台的搭建。对backlog我们与项目负责人展开了激烈的讨论，并初步确定了里程碑节点。这一周很快就过去了。在周五我们向项目负责人展示了，新的平台，框架以及初步的开发计划。对了，系统前台和移动版及ios客户端由外包团队负责。所有接口通过RAP系统进行管理。由小C专职进行维护和管理。

我们每个周期都细化下一个周期的开发计划，同时根据实际情况调整之后的总体计划。每个周五下午4点都是我们的演示时间，项目负责人则根据演示情况直接向领导和用户进行汇报。并且这时项目负责人也会将最新的需求和要求传达给我们，我们也会同时更新到backlog上，并请他对需求进行优先级排序。

在sprint1中我们就开始了每天的code review，在jenkins上每隔十五分钟对系统进行一次集成和测试，每次测试还会进行SONAR的代码质量评分，同时进行阈值判定。我们对于代码质量的要求也很简单，就是提交后的代码质量不能低于提交前的质量，核心逻辑的代码测试覆盖率要高于60%，对于一般的CURD则不做测试覆盖率要求。

在持续集成系统的支撑下，SC项目的代码质量明显由于HY项目，团队的单元测试编写能力也都得到了大幅提升，在SONAR的质量评价中始终保持着A级评价。

很快经过6个周期的开发，预估系统的功能全部完成了，我们对于系统的质量拥有前所未有的信心，因为所有的接口功能都至少经过自动化测试和人工手动测试的确认。

但是我们得到了一个令人震惊的消息说外包团队也完成了开发，还反映我们做的有点慢。额，其实根据我们与外包团队实际开发人员的交流，好像他们进度没有这么快。好吧，我们表示了对于外包团队效率的十分钦佩，还好我们也按照计划完成了，那好我们开始联调吧。

但开始联调之后发现好像有一些不对劲，他们联调人员最多时竟然有5个，而且在测试时发现他们有相当大的部分根本没有做，而是现场开发，额，我又对他们的效率和勇气表示来十分钦佩。经过了3周的“联调”第一版系统终于出来了，这个项目也进入到新阶段。进入到后期维护和部署试运行阶段。

经过与外包单位开发单位的人员进行交流，发现他们采取的开发方式也类似于敏捷的思路，但缺乏自动化测试，缺乏回顾，缺乏演示，所以他们的计划和汇报的情况跟实际开发情况有所偏差，同时代码质量也令人堪忧，可见敏捷的核心并不在于形式而是在于通过不断地试错，不断的以最低的代价来完成最具有价值的产品的过程中吸取教训和经验，不断的强化自己。

虽然SC项目是一个大坑，但在新模式下我们至少把坑填上了，并且通过代码审查，持续集成，自动化测试将自身水平提升至新的层次。

一切无法杀死我的东西都只能让我更强大，而对于真正的敏捷团队也是一样。

再改进

经过了SC项目，团队更加的成熟了，而且基本形成了一套体系，主要包括：计划会议，任务板，每日站会，验收演示，回顾会议，重构，代码审查，持续集成，自动测试等。鉴于HY和SC的成功，逐步对另外一个NW项目逐步引入敏捷的模式，同时针对优化HY和SC项目的人员进一步提出引入BDD和seleium的方式构建验收测试，同时将持续集成状态以安灯和大屏幕的形式在开发场地进行直观展示，以TDD结合结对编程的形式进一步提高测试覆盖度和推进代码设计覆盖度，向着更高效率更高质量的软件开发团队继续前进。

敏捷成果

又值九月，经过了近一年的敏捷的尝试，开发团队无论是思维方式上还是技术上有了较大的飞跃。

我们通过持续集成，自动化测试以及人工确认测试有效的提高了项目的质量，有效降低来代码的Bug率。

通过code review和自动化代码质量评价，统一了代码标准和风格，大大降低了代码的坏味道，提高系统的可靠性和可维护性。

通过不断尝试建立来一套适应于自身水平和阶段的开发体系，能够不断的提高开发能力。

但在回顾这一年的成长历程中，还是发现有不少的问题的，仅仅是开发团队的敏捷是不足以实现真正的敏捷。真正的敏捷是从用户端获得要求以最快的速度返回给用户真正有价值的产品，不断的适应用户的需求。

因此，真正的敏捷不但应该包括开发团队，项目负责人，决策者甚至是用户都应该是敏捷的，才能让这一传送价值的链条运行的更紧密和快速。用户真正需要的不是产品而是解决方案，甚至有时就是解决问题本身。

我们可以做的更多

我感觉到敏捷的模式不应该仅仅停留在软件开发领域，而在读一本敏捷方面的书时作者表示他的这本书就是按照敏捷的模式完成的，将一本书的写作分为多个sprint，每个sprint完成后都拿着书和未来潜在的读者进行讨论，然后再根据建议进行调整，这使得他的作品在很短的时间内就出版来，获得读者的很高的评价，解决了他们很多实际问题。

同样敏捷的这种“小步快跑”的模式，也可以应用到我们其他项目的开发，产品的研发中，在许多大型国际化企业中都能看到敏捷模式的影子。因此，我们可以将敏捷的思维和模式更多的应用到我们自己的业务中，缩短反馈周期，反馈链条长度，提高自身业务的响应变化的能力。技术研发领域更多的要以快速原型的形式不断的验证和对标，快速的调整研发方向，而系统集成领域则要更加注重用户意见的征集，将用户也拉到项目中参与进来，周期性的要求合作单位拿出可展示的东西而不仅仅是周报或月报，各方单位强化合作，建立更加透明的信息共享机制，提高效率降低风险。产品生产领域则可以结合敏捷中的精益生产的理论，进一步提高质量和工作效率。

结语

早在多年前，敏捷开发早已风靡国外的软件开发行业，敏捷的形式是最容易学习的，而只有形的敏捷不是真的敏捷，只有将敏捷的思想与自身的情况相结合，得到适合于自身的敏捷模式才是真的敏捷，才能激发团队或企业的活力，达到不断优化不断改进的敏捷状态。