导读：说起敏捷开发，并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了，这个东西并不是神器，实施了就可以解决所有软件公司的问题，而是要结合自己公司的特点和问题摸索出适合自己的一套模式。
大家都知道，创业公司刚开始需要研发出一款产品并且能够使公司赚钱的产品，不过大部分创业公司没有那么容易一下就能做出来，很多公司还没有成功的产品资金链就断掉了，公司也死掉了。我们公司是这样一个状况，有一条产品线可以维持公司开支并仅仅刚够盈余，要扩大高速发展还不够，一直维持就没有创业的意义。另一条线是做技术创新为未来能够开发一款人气爆棚的产品摸索着，但是又不能饿着肚子去开发。我们是如何结合自身的特点实施敏捷开发的呢?一个难题，很大的难题!
我们技术团队人员是这样的配置：1名技术总监、2名资深开发工程师、1名高级开发工程师、2名潜力开发工程师、1名前端开发、1名测试。技术总监需要处理很多团队管理、客户管理的工作，能够参与项目的时间最多每天二分之一。2名资深开发需要负责给其他工程师做导师，参与新项目开发时间大概有80%。高级工程师要预留项目学习时间，参与项目的时间大概有90%。潜力开发工程师需要有一些时间学习技术和项目，但是基本可以做到70%的时间投入项目。前端开发和测试哪里有需要就在哪里革命，属于机动部队。
现在总共有六个老项目在维护，两个新项目需要开发。六个项目的维护总共需要每周4人天时间(人天指需要花1个人4天的时间完成一个事情)。其中一个新项目“项目1”大概估计120人天的开发时间，需要1个月之内开发完成。“项目2”大概估计要40人天的开发时间，需要2周开发完成。而现在的人力按照能够投入的时间算一下，总共资源为 (1 * 1/2 + 2 * 8/10+1 * 9/10+2 * 7/10) 30天 = 132 人天，6个老项目每周需要4人天，一个月4周，需要 4 * 4 = 16人天。项目能够投入的资源有 132 – 16 = 116人天，而总共需要120 + 40 = 160天，足足少了44人天，这看起来是一个不可完成的任务。
不过到最后，我们还是使用敏捷开发完成了这两个项目，也没有影响老项目的维护。我们是怎么操作的?最开始我们两个开发，这个时候只要两个人就能够很好的合作把产品开发出来，不需要什么模式。随着人员的扩充，团队间如何协作按时按质按量完成任务就需要好好思考下了。
尝试一，传统软件开发模式。整个过程为 需求分析、系统设计、任务分解计划安排、开发设计、编码、测试、交付、验收、维护。这个模式也是大家最常使用的模式，不过套用在我们公司时我们是这么操作的。
传统开发过程
由于公司创业，老板有一个想法，但并不能很好的描述需求，所以需求分析的任务落在技术总监身上。系统设计和任务分解刚开始是技术总监完成，后面资深开发工程师可以承担一部分。开发设计可以让各个开发工程师完成，资深工程师进行把关，再到测试人员测试，最后再交付用户验收、技术维护。看起来很好的模式，开发了几个产品最终有的延时有的产品离用户的期望差距甚远，参与项目团队的人信心受挫。
为什么会失败呢?后来思考了这些问题：
1、技术总监不是产品经理，不能够承担产品设计的责任。老板是信任技术总监能做好产品，就交给他做。但这里搞混了一个概念，产品经理和项目经理，技术总监应该起到项目经理和架构师的作用。项目经理管控项目进度和计划、架构师把握整体技术问题。而技术总监接到这个任务又不能不做好，责任所在。说到底，就是机制没有把产品设计和项目经理区分开，不等于技术实现者就是产品设计者。更多的应该让老板或者其他业务人员承担产品设计的工作。
2、需求不稳定，变化后改动代价大。由于创业，需求为了适应市场会经常调整，但是一但调整，很多开发计划就会受到相应的调整。如果部分功能已经正在开发，调整需求后很多工作要重新开始，严重影响了技术同事积极性。业务不调整需求是不可能的，他们是为了满足用户的要求，用户满意了才能给企业带来价值。不过如果调整，代价太大，很多代码要重写，大家就会责怪技术总监或者项目负责人没有把握好需求。
3、团队经常加班，但战斗力不强。 核心团队疲于应对需求、技术开发、老系统维护，没时间指导新同事技术学习，而新同事技能暂时还没有发挥出来干活效率低，任务经常延期，没有成就感。核心团队事情很多，没有时间整理项目文档，新员工没有文档上手慢。大家每天很多事情，需要加班才能完成，比较疲惫。每个人除了工作还有很多事情需要做，比如回家看看电视、陪陪家人、看看书学习一下等。如果让一个员工一天二十四小时都是工作，他能同意，他家人也不一定同意。让大家愉悦的开发，比疲惫的上班效率要高很多。
4、交付软件质量差，离用户期望差距大。创业时大家的想法都是好的，大干一番，做一个所有人都爱使用的产品。现实是残酷的，大家辛辛苦苦做出来的东西，老板不满意、用户不埋单，付出的努力没有人认可。交付的软件没时间自测试，或者自测试不充分，交给测试又是一大堆问题。有些公司还没有测试，直接出去给用户，相当危险。这样交出去的公司不仅仅影响了用户的使用，还影响了整个公司的口碑。
不是说传统软件开发模式不好，只是不太适合我们这种创业公司。开始尝试其他模式，如果没有一个很好的体制就不能把大家的最大生产力发挥出来。
尝试二，敏捷开发模式。敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。敏捷方法强调以人为本，专注于交付对客户有价值的软件。在高度协作的开环境中，使用迭代式的方式进行增量开发，经常使用反馈进行思考、反省和总结，不停的进行自我调整和完善。
敏捷开发的主旨：
一：个体及交互比流程与工具更具价值
二：可用的软件比冗长的文档更有价值
三：与客户的协作比合同谈判更有价值
四：对变化的响应比遵循计划更有价值
而我们之前的问题，交付软件客户不满意、延期、需求更改代价大貌似都可以解决。这么好的模式赶紧要试试，先看一张敏捷开发的流程图。
创业公司敏捷开发敏捷流程化
敏捷开发简单流程：
1、产品负责人将整个产品设计成产品backlog。产品backlog就是一个个需求列表。(backlog可以理解为需求或者要做的事情)
2、召开产品backlog计划会议，预估每个backlog的时间，确定哪些backlog是需要在第一个sprint中完成的，即sprint的backlog。(sprint可以理解为一个团队一起开发的一个任务集合)
3、把sprint的backlog写在纸条上贴在任务墙，让大家认领分配。(任务墙就是把 未完成、正在做、已完成 的工作状态贴到一个墙上，这样大家都可以看得到任务的状态 )
4、举行每日站立会议，让大家在每日会议上总结昨天做的事情、遇到什么困难，今天开展什么任务。(每日站立会议，是在每天早上定时和大家在任务墙前站立讨论，时间控制在15分钟内)
5、绘制燃尽图，保证任务的概况能够清晰看到。(燃尽图把当前的任务总数和日期一起绘制，每天记录一下，可以看到每天还剩多少个任务，直到任务数为0 ，这个sprint就完成了)
想认识全国各地的创业者、创业专家，快来加入“中国创业圈”
|
