再谈敏捷

本文仅代表个人观点，大部分观点可能不正确，请带着批判的眼光看

一个问题
在知乎上回答了一个问题：IT 行业技能越强经验越丰富的人员比较轻视软件工程，对个人技能极度崇拜。这种现象存在的原因是什么？

个人的理解是这样的：
1. 极少数优秀的人组成的小团队，确实能够无视软件工程的经验来创造好的产品。因为这种团队会形成最适合自己的开发模式。这些开发模式往往借鉴了现有的优秀的软件工程的经验。
2. 软件工程是一些经验的总结，并非一定要遵守的律法。通常是前人在开发中，遇到了问题，然后尝试总结出最佳解决方案活着失败的教训。软件工程通常能够帮助平均水平的团队，或者大型团队（其实平均水平被拉低了）来取得一个较优的开发过程。
3. 真正足够优秀的人的数量可能不够，而且通常不便宜。

这个问题引发了我对软件工程的一些反思：

工作现状
平时工作中已经采用了敏捷开发模式，准确点说应该是Scrum的变种。我们有规律的Sync up，有product backlog，有的组会采用看板。人员分散到较为小的团队（4开发、3测试、1个PM、1个Lead）,在一定时间内专注于一个（组）功能进行开发。

不同之处在于：项目的拆分粒度相对较大，通常为1-2天的工作量，有时可能是一周。同时每个人会更加专注于更小的一个方面，互相之间的交叉相对较小。这样做的好处是人和人之间的依赖相对较少，而且个人发挥空间相对较大。坏处在于对于彼此技术细节的掌握程度可能没有那么深刻。

TDD Workshop
最近参加了Thought Works的一些讲TDD的Workshop，主要就是十来个人在一起用一下午的时间实践一下TDD。和主办人仝键童鞋聊过几次，他认为敏捷开发的相关技术应该已经是普及到人尽皆知的地步，但是事实却大相径庭。所以他希望能通过这种活动来传播相关技术。

软件工程到底重要么？
个人理解还是十分重要的，它从一定程度上保证了平均水平的产出。

敏捷开发有用么？
其实这个问题和前一个问题一样，都问的不好。它们一定有用。存在即合理。它们的提出一定解决了当时的一些问题，才能够流行起来。

我应该拥抱敏捷么？
个人认为，我们应该拥抱敏捷。真正的拥抱敏捷开发的思想和其中对我们有所帮助的东西，而不是教条式的按照所有的范式去执行“敏捷开发”。例如，我们最开始每天Sync Up。团队成员被迫拆分任务或者加班，从而使得每天看起来都有进展。而且固定的会议时间使得人们的工作、生活节奏受到了限制。所以最后变成了两天Sync Up一次。

Definition Of Done (DOD)
这是我的整个敏捷实践里面最有待提高的地方。我们做了A/B testing，但是我们不知道如何判定成功和失败。我们在项目遇到风险的时候，没有能够很好的决定什么是最重要的东西以至于没能够更为及时的舍弃掉一些功能。（虽然这个被团队的强力弥补了，我们很快发布了Plan B）

Action

• 更好的结合使用Trello
• 在做事情之前先想好DOD
• 继续参加一些社区活动，能够从不同的角度来体会敏捷