敏捷开发那些事

软件开发

这篇学习笔记来自《软件工程之美》的第05、06（上）、06（下）三篇文章，主要内容总结如下。

敏捷开发那些事.png

敏捷开发是一套价值观和原则：相比流程和工具，更重视个体和互动；相比详细的文档，跟重视可工作的软件；相比合同和谈判，更重视客户合作；相比遵循计划，更重视拥抱变化。

我们经常谈的敏捷开发，都是谈敏捷开发的“术”，也就是具体的流程和规范，例如：用户故事、Ticket、Sprint、Backlog、看板、站会、自动化测试、持续集成等等。其实，宝玉老师在最后也点出——具体用什么样的方法和流程都是形式上的东西，只要符合敏捷的价值观，就是使用敏捷开发，以站会这个事情为例，形式、时间都是可以按照实际情况进行调整，只要能达到高效沟通的目标就而可以。

重点摘抄

当你开发做决策的时候，遵循了敏捷开发的价值观和原则，不管你是不是使用Scrume或极限编程，都可以算是敏捷开发。
瀑布模型的典型问题就是周期长、发布烦、变更难，敏捷开发就是快速迭代、持续集成、拥抱变化。
软件开发，最核心的是人，而不是用什么方法，以前没有敏捷开发只有瀑布模型的时候，也一样诞生了很多伟大的软件，例如Windows、Office。现在有敏捷开发，只是给我们多提供了一种选择。
大厂做项目也没什么特别的，无非就是工程中常见的“分而治之”策略：大项目拆成小项目、大服务拆成小服务、大团队拆成小团队。
问题停车场——控制会议时间和主线的利器，将会议内无法立刻解决的问题，留在会议后进一步讨论，就可以将这些问题放在问题停车场。
扑克牌估算法——如何更好得估算工作量，面对一个Ticket，大家做出自己的评估，同时亮出自己的估计，最终达成一个共识，在这个过程中，经验比较浅的成员可以学习经验丰富的成员的评估经验。
敏捷开发中的项目经理（Scrum Master）的角色不是控制型，更多得是一种服务型角色。
敏捷开发虽然求快，但是不代表应该牺牲质量。

和作者的交流

第05篇

我的留言： 敏捷开发是一种价值观，可以给项目带来一些好处：及时（尽早）响应需求的变化；团队成员之间的关系和沟通比较紧密；团队成员的横向能力能得到发展；节奏比较快，客户可以不断看到改进。

在上一家公司中，我们有专门的敏捷教练跟着每个项目团队进行落地，同时相关的基础设施比较完善：我们用JIRA去管理项目的过程、为了增加趣味性，有时候还会用实物看板、站会是根据需求调整，测试同学也提供了完整的测试用例和压测工具，不足之处是持续集成和自动化测试做得一般。

如果现在加入一个新的团队，要实施敏捷开发，我准备从团队成员的培训和沟通上入手，一定要配专业的敏捷教练，让项目组的成员都理解敏捷的内在思路，我不会一上来就去推什么看板、站会。

作者的回复： 首先，可以看得出你已经开始又对敏捷开发和其中一些实践有了自己的思考，对不足的地方有反省，这都是非常好的现象，相信你慢慢可以有更多感悟。另外，我倒建议你不要着急先不做什么，不如先都照它的去做，实施一段时间后，由团队来决定哪些该继续做，哪些可以不需要继续做，而不是你一个人（Scrum Master）来决定这些事情。因为Scrum Master本身不是一个控制型的角色，而是一种服务型的角色。

我的感想： 宝玉老师提到这个服务型的角色，一语切中要害，不仅仅是针对软件工程的，更是针对为人处世的，例如，将来想做一个leader，那本质上leader是一个服务型的角色，或者说，服务型的leader更容易得民心，可能各种类型的leader都能取得结果，但是我个人来讲喜欢服务型的leader。

第06篇（上）

思考题： 你的项目中，有哪些跟敏捷开发相关的实践？你觉得哪些做的好的地方，哪些做得不够好的？再思考一个问题：一个每周一个sprint的敏捷项目，怎么保证每周都有交付，还能保证产品质量？

我的留言： 我们之前的项目依赖JIRA做任务管理，所有的开发工作、线上的BUG都被安排成对应的Ticket进行跟踪。我们有每日展会，有专门的值班同学负责处理线上问题和对外答疑。这些都是我们做得好的地方，也有一些做得不太好的地方，例如：任务的估算不准确，导致项目延期；自动化测试支持不够，导致效率不高。关于思考题：要保证每周交付的话，可以有三个办法：（1）要看ticket的粒度是否合理；（2）提前一周做计划；（3）每周结束做总结。要保证质量的话，我们当时是这么做的：（1）测试同学会提供完善的测试用例；（2）测试同学会提供对应的压测平台和用例；（3）大功能上线的话，全员参与测试；（4）开发上线之前，必须按照固定的流程来。

第06篇（下）

思考题： 在文章中，这个项目没有在一个Sprint里同时完成开发和测试，而是把测试放在下一个Sprint，这样做有什么优缺点？

我的留言： 优点是新开发的功能有足够的时间测试；缺点是合并分支有点麻烦，另外开发新功能和改BUG同时进行，如果前一个sprint开发的代码比较多，可能会影响这个sprint的开发。关于分支部署那里，我们采用的办法是拉个新分支做开发，在预发测试好了以后再合并到master进行部署。另外阅读本文的收获有两个：扑克牌估算工作量，这个确实之前是非常头疼的环节，准备后面的项目中尝试下新的方法。