技术: 浅谈我经历的敏捷

谈谈自己经历 敏捷开发 的体会。
2018年更新时，发现小公司基本很难做到敏捷，因为它需要很多基础设施Support。

老东家一直有个站会, 在看板(Kan Board)面前阐述一下自己的任务进度.
说实话, 我非常排斥这种东西(虽然我拥护TDD和XP).

后来听京东和支付宝的同学也在说敏捷会议, 敏捷开发, 我这才意识过来: 哦, 敏捷已经是趋势了.
于是开始认真接受Agile.

敏捷印象

我亲身实践的敏捷, 印象比较深刻的有两部分内容:

• 站会的反馈
• (配合SCM)持续集成
• 测试驱动

总结起来, 我所重视的是: 参与, 协作, 持续交付 (每个阶段都是可交付的).

本文先说敏捷, 之后再说我的个人体会.

敏捷到底是一种软件开发方法, 还是一种技术思想？
到现在我的觉得, 这些已经不再重要, 重要的是, 我们通过 Agile 能够获得什么, 而不是我最初跟风地尝试敏捷.

敏捷研究

敏捷宣言

主要的内容就这么几句话:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

如下图:

看得出, 宣言其实是很空洞的, 所以又出现了下面的 12项原则 .

12项原则

从中可以提取很多关键思想: 不断交付, 拥抱变化, 合作, 可工作的软件, 简洁为本, 定期反思 …

Scrum

不管一个产品, 还是一个项目, 整个团队的协作, 参与是最重要的. 所以比起其他一些(重视开发流程, 过程的)方法, Scrum更加注重协作&参与(当然也包括交付, 每一个过程都是可交付的).

是的, 我这里多次强调了 参与 .

关于这部分理论, 请找专业的资料参考吧, 不要去网上看一些不太专业的转载.

站会反馈

每天早上9:30, 会有一个站会, 内容是围绕看板任务, 大家各自汇报一下. 说实话, 效果很差. 因为除非是你的模块, 否则大家对你的进度, 遇到的困难, 没有太多的体会, 也很难给出意见. (何况有时候我都是单独一个项目, 单枪匹马).

但是在这里, 我却有一些很深刻的体会, 大体可以归纳为: 我们认为重要的, 用户不一定觉得重要.

这么说呢? 具体解释:

好比我的模块, 是否需要一个数据库View(视图), 一个Contoller调度模块, 是否要给出应用界面, 表格是竖着展开还是横向排列, 你的意见, 和最终用户的意见可能相差很远, 甚至你觉得重要的, 用户完全不care, 不关注的.

所以站会反馈, 最好能让用户, 客户参与到团队的开发中; 这里增加一点儿成本, 却省下了后期需求变更, 调整的代价. 好处不言自明.

也就是宣言中所说的 Customer collaboration over contract negotiation, 客户协作胜过合同谈判.

持续集成

在持续集成方面, 老东家 ZTE 可以说, 做的非常好; 因为面对的北美项目比较多, 所以在集成测试做不好, 不仅会加大人力投入, 还会降低开发效率. 但是就像自动测试一样, 是否应该持续集成关键在于投资回报率和缓解风险. 我想这一点, 不必多解释, 请看下面的要点.

持续集成的要点:

• 统一的代码库
• 自动构建
• 自动测试
• 每个人每天都要向代码库主干提交代码
• 每次代码递交后都会在持续集成服务器上触发一次构建
• 保证快速构建
• 模拟生产环境的自动测试
• 每个人都可以很容易的获取最新可执行的应用程序
• 每个人都清楚正在发生的状况
• 自动化的部署

个人经验

以前我的代码入库前, 至少经历这样的步骤:

• 代码编写完毕
• 本地验证通过(包括编译和功能验证)
• 然后在本地集成(可能是具体的开发板,比如手机)
• 之后上传代码, 在容器(生产环境)中测试, 而且分两次, 早上和下午(赶上一次就可以了)
• 之后通过了, 才合入dev分支, 经过几个版本的测试, 没有问题了, 才最终合入master分支

中间经过了N次自动化测试, 集成, 而且你的提交根本不干预集成.

这里面相关的技术也很多, Jekins, Gerrit, Repo, Docker等.

关心团队协作, 用心做产品. 希望敏捷的路越走越顺吧.