关于敏捷开发的干货

敏捷开发，作为项目管理的新起之秀，已有二三十个年头。在这里，重温下这个经典，并顺路谈谈，自己在实际项目中的一些心得。

| 敏捷的本质

首先，什么是敏捷开发？它源于一个思考，那就是，你是要选择，务实的持续交付；还是要选择，去完成一个大而美的庞大计划？大而美的计划，总是让人兴奋的。但它在实践中存在着不少问题。比如，项目总是延期，开发完的功能很多已经不实用了。也有很多项目，因为过于庞大，最终甚至都没有完成。敏捷开发，倡导另一种更务实的做法。就是要持续产出可用的功能。这是敏捷开发一切理论的出发点。也是我推崇敏捷开发的原因。

| 迭代与心跳

敏捷开发，多以固定时间为一周期，专业名词叫做迭代。这种基于固定时间的心跳一般的模式，有比较明显的节奏感，是很让人舒服的。而传统的瀑布流，开发工作像是在焦油坑中进行漫长地挣扎，让人疲倦而又迷茫。（焦油坑源自于《人月神话》中的比喻）迭代的周期，一周、两周或者一个月。但对于互联网行业的我来说，更喜欢一周一个迭代。当然，你需要差异化开发和测试的节奏，并留下一定的容错时间。

| 用户故事

项目能敏捷起来的一个前提，就是要能准确地量化需求。用户故事，把需求拆解成一个个小的点，是需求卡片而不是大的计划书。当然，拆解需要有一定的技巧。首要原则是，每个卡片都是一个可独立完成、可独立发布的任务。举例来讲，你甚至应该把用户可下单，和下单支持地址选择，拆成两个卡片。这样，就可以更准确地估算开发时间，也可以在需要的时候，做一些取舍。

| 工时估算

需求卡片拆多大合适？就互联网行业的经验来说，一个卡片，可以根据进一步拆解后的任务量和开发难度，选择半小时、一小时、两小时、三小时或四小时。超过四个小时的卡片，其实已经不太准确了。比如估算两天或三天，其实没有什么本质区别。此时，我们就应该考虑分解卡片了。当然，还存在另一个问题，就是有些程序员会瞎报工时。此时，技术 Leader 还是得认真负责起来，一块研究实际的任务量和难度，得出一个可以接受的结果。不用太苛刻，但最起码也不太离谱。要不然，对别人不太公平。

| 进度监督

很多传统团队，平时皆大欢喜，等到了真要上线了，才发现这也有问题，那也有问题。甚至还有地方，说是完成了，可却压根不能用。这里很重要的原因，就是并没有有效的日常监督机制。敏捷开发，通过日站立会和敏捷看板等，很好的解决了这个问题。每天日常的沟通会，可以很快的了解实际开发进度，也可以及时处理出现的问题。当然，站立会更像是一种仪式感，不喜欢的话，大可以换更习惯的形式，保证每日及时沟通即可。

| 拥抱变化

及时在一次很短的迭代中，也可能会有很多想不到的变化。比如，突然要加进来一些紧急的需求，有些卡片出现了严重的延期，或者有人突然生病请假。这些都是无法预估的。敏捷开发，基于相对准确量化下的需求卡片，能很快地应对这些变化。我们只需要重新评估卡片工时，拆解不合适的卡片，延期一些优先级低的就好了。当然，这需要和需求方及时沟通。

| 团队和理念

以上都是我在实际工作中比较受用的一些点。当然，敏捷开发还有很多理论和追求。比如结对编程、测试驱动开发。还有关于团队的组织建设、人才驱动模式等方向的愿景。更多是技术角度的精神追求吧。在现实情况中，不一定真有你发挥的空间。但这并不影响你通过敏捷开发，获得一些管理上的收益。

| 敏捷中的教条

敏捷开发，有很多理论体系和经典玩法。比如极限编程、srcum 等。它们都有着自己一整套的方法论，有些地方，都俨然成为一种教条。编程，本身就是一件极其务实的东西，非要执着于一套理论，而不考虑实际情况，其实很是得不偿失。