创业知识:如何在创业公司中实施敏捷开发【58创业榜】-58创业榜

【58创业榜】说到敏捷开发，不是因为敏捷才敏捷。近年来，敏捷开发已经成为许多敏捷咨询服务提供商的神话。这东西不是神器。如果实现了，可以解决所有软件公司的问题。而是要结合自己公司的特点和问题，找出一套适合自己的模式。

众所周知，初创企业只需要开发出一款能让公司盈利的产品。但是，大多数初创企业都做不到这么容易。很多公司还没成功就断了产品资金链，公司已经死了。我们公司就是这样的情况，有一条产品线可以维持公司的开支，刚好有盈余。仅仅扩大高速发展是不够的，如果一直维持下去，创业是没有意义的。另一条线是做技术创新，为一个热门产品的未来发展进行探索，但我们不能饿着肚子去开发。我们如何根据自己的特点实施敏捷开发？问题，大问题！

技术总监需要处理团队管理和客户管理的大量工作，每天最多有一半时间可以参与项目。两个高级开发人员需要负责给其他工程师当导师，80%左右的时间参与新项目的开发。高级工程师要为项目预留学习时间，90%左右的时间参与项目。潜在的工程师需要一些时间去学习技术和项目，但基本上可以把70%的时间投入到项目中。前端的开发和测试，哪里有需求哪里就是革命性的，属于机动部队。

六个项目的维护每周总共需要4个人工日(人工日是指一个人需要4天来完成一件事情)。其中一个新项目“项目1”预计需要大约120个人工日来开发，并且需要在一个月内开发完成。“项目2”的开发预计需要40个工作日，完成需要2周时间。目前的人力是按照可以投入的时间来计算的。总资源为(1 * 1/2+2 * 8/10+1 * 9/10+2 * 7/10) 30天= 132人-日。六个老项目需要每周4人天，每月4周，4 * 4 = 16人天。项目可投入的资源为132–16 = 116人天，而所需总时间为120+40 = 160天，还差44人天。这似乎是一个不可能完成的任务。

不过最后我们还是用敏捷开发完成了这两个项目，不影响老项目的维护。我们如何操作它？在我们两个人开发的初期，这个时候，只要两个人能很好的合作开发产品，就不需要什么模型。随着人员的膨胀，需要仔细思考团队之间如何合作才能按时、保质、保量的完成任务。

试试传统的软件开发模式。整个过程包括需求分析、系统设计、任务分解规划、开发设计、编码、测试、交付、验收和维护。这种模式也是最常用的模式，但这是我们应用到我们公司时的操作方式。

因为公司创业，老板有想法，但是无法很好的描述需求，于是需求分析的任务就落在了技术总监身上。刚开始的时候，系统设计和任务分解都是由技术总监完成，后期高级开发工程师可以承担一部分。设计可以由每个开发工程师完成，高级工程师检查，测试人员测试，最后交付用户验收和技术维护。好像是个不错的模式。开发了几个产品之后，有一些延迟。有些产品与用户的期望相差甚远，参与项目团队的人信心受挫。

58创业榜分享：为什么会失败？

1.技术总监不是产品经理，不能承担产品设计的责任。老板信任技术总监做出好的产品，所以他能做到。但是这里有一个混合的概念。产品经理和项目经理，以及技术总监应该扮演项目经理和架构师的角色。项目经理掌控项目进度和计划，架构师掌握整体技术问题。而技术总监在接到这个任务后也不能不做好，责任在。归根结底，机制没有区分产品设计和项目经理，并不意味着技术实施者就是产品设计者。更应该让老板或者其他业务人员承担产品设计的工作。

2.需求不稳定，改了又改，成本很高。因为创业，往往会调整需求以适应市场，但一旦调整，很多发展规划也会相应调整。如果有些功能已经在开发了，那么很多工作调整需求后就要重新开始，严重影响技术同事的积极性。企业不可能不调整需求。他们是为了满足用户的要求，只有用户满意了，才能给企业带来价值。但是如果调整代价太大，很多代码都要重写，大家都会责怪技术总监或者项目负责人没有把握住需求。

3.团队经常加班，但战斗力不强。核心团队疲于应对需求、技术开发和旧系统维护，无暇指导新同事技术学习。但是新同事的技能暂时没有发挥出来，所以工作效率低，任务经常延期，没有成就感。核心团队有很多事情要做，没有时间整理项目文档。新员工没有证件上手慢。每个人每天都需要加班完成很多事情，所以很累。每个人除了工作还有很多事情要做，比如回家看电视，陪家人，读书学习等等。如果让员工24小时工作，他可以同意，他的家人不一定同意。让所有人都开心的发展，比累人的工作效率高得多。

4.交付的软件质量很差，与用户的期望相差甚远。创业的时候，大家的想法都是好的。做得很棒，做出一个人人都爱用的产品。现实是残酷的。大家辛辛苦苦做出来的东西，老板不满意，用户不买单，没人认可他们的努力。交付的软件没有时间自检，或者自检不足，交给测试就是一大堆问题。有些公司还没有测试过，所以直接出去给用户是相当危险的。这样交出来的公司，不仅影响用户的使用，还会影响整个公司的声誉。

不是说传统的软件开发模式不好，只是不适合我们这样的创业公司。试试其他模式。如果你没有一个好的制度，你就不能发挥每个人的最大生产力。

尝试敏捷开发模式。敏捷开发是一种以人为中心的、迭代的、循序渐进的开发方法。敏捷方法强调以人为本，专注于向客户交付有价值的软件。在高度协作的开放环境中，以迭代的方式进行增量开发，经常利用反馈进行思考、反思和总结，不断进行自我调整和改进。

敏捷开发的主要思想:

1.个人和交互比过程和工具更有价值。

二:可用的软件比冗长的文档更有价值。

第三，与客户合作比合同谈判更有价值。

四:应对变化比遵循计划更有价值。

但是我们之前的问题，比如软件交付客户不满意，延迟，需求变更成本高，好像都解决了。这么好的模式，要赶紧尝试。首先，看一个敏捷开发的流程图。

开发敏捷的简单流程:

1.产品负责人将整个产品设计为产品backlog。产品backlog是一个需求列表。(backlog可以理解为需求或者要做的事情)

2.召开产品积压计划会议，预估每个积压的时间，确定哪些积压需要在第一个sprint完成，也就是sprint的积压。(sprint可以理解为一个团队开发的一组任务)

3.把sprint的待办事项写在一张纸条上，贴在任务墙上，这样大家就可以认领分配了。(任务墙就是把未完成、进行中、已完成的工作状态贴在一面墙上，让每个人都能看到任务状态)

4.每天开一个常务会，大家可以总结一下昨天做了什么，遇到了什么困难，今天执行了什么任务。(每日站会，每天早上定时站在任务墙前和大家讨论，时间控制在15分钟以内)

5.画出倦怠图，保证能看清任务的大致情况。(燃尽图将当前任务总数和日期一起绘制出来，并每天记录。你可以看看每天还剩多少任务，直到任务数为0，这个冲刺就完成了。)

6.sprint评审会议在sprint完成时召开，向客户展示完成的软件产品。

7.最后通过轮流发言的方式召开冲刺总结会。大家都要发言，总结上一次冲刺遇到的问题，改进，分享给大家讨论。

如何结合敏捷开发解决现有项目的问题？记住，任何措施都是为了保证软件按时、保质、保量地交付给用户。不要为了敏捷而教条地实施敏捷。公司无法产生商业价值，任何先进的理念或技术都没有意义。我们采取了以下措施:

1.推广敏捷开发的概念。不管是大公司还是小公司强制执行一个制度，效果一般都不太好。任何可以推广的东西，都要被大家接受，才能得到认可。

先培养测试女生学习敏捷开发，然后让她承担一些产品负责人和敏捷导师的角色，原因如下:

A.要测试和接受功能，您必须了解业务需求。

测试也是QA质量体系的一部分。学习之后，你会对软件质量有更深刻的理解。

c，团队大部分是男生，女生更有晋升的亲和力。

召集所有技术团队开会，为推广做准备。开始和测试女生好好讨论如何告诉大家更有效，更容易接受。要解释，她必须对敏捷开发非常清楚，准备足够的知识点。会上先指出我们目前存在的问题，让大家看看有没有解决问题的思路？现在，我们做的产品不被客户认可，不被老板满意，很累，没有成就感。我们能做些什么来解决它们呢？经过大家的讨论，抛出敏捷开发的优势。一般大家都会认可。你可能会问怎么实现，怎么落地。可以尝试找一个试点项目。如果实施成功，可以全面推广。失败只会影响一些项目。

2.构建敏捷开发环境。实施敏捷开发，需要更好的基础条件来保证敏捷开发的顺利进行。几个关键软件:nexus构建仓库依赖中心，maven管理工程的依赖，jenkins持续集成和自动编译发布，svn集中代码管理，jira记录需求和状态。详见敏捷开发环境构建。

3.敏捷项目实施。整个公司建立以业务为导向的氛围。就“项目1”而言，为了完成该项目，需要执行以下步骤:

先聚集一群勇士，根据各自的能力和意图来完成这个目标，无论技术或非技术。如果聚集的人不够，技术总监可以根据整体项目的投入，灵活调整资源进行支持，但如果条件允许，会根据大家的意愿进行聚集。最后“项目1”召集了一个技术总监，一个高级开发者，两个潜在开发者，一个前端，一个测试，总共可以算4个人，除了大家做其他事情的时间。

充分调动客户(老板和业务同事)参与项目，他们的参与直接决定了项目的成功。结合之前的经验，如果他们参与的不够，最终的产品就不会是他们想要的，或者说离他们想要的相差很远。刚加入的时候很迷茫，有时会表现出抗拒。这时候他们一定要有耐心，坚持让每个人都发展第一次冲刺成功，让每个人都尝到甜头。让他们参与整个项目也表明我们欢迎变革。如果需求有变化，将任务添加到任务墙上。可以全面了解所有任务的时间。如果超过了sprint结束时间，就需要做出业务决策，决定在这个sprint周期中不添加哪些功能。

技术总监安排与客户的沟通，客户在这里指的是老板和业务。测试姐姐负责与客户沟通记录，技术总监协助。经过多次沟通，尽量让测试用最简单的工具画出需求的原型。技术总监审核通过后，与客户沟通确认，反复迭代，直到大家对整个需求没有异议。很多公司都有专门的产品经理来完成这个需求，但是按照我们目前的人力，做不到。在这里，不允许技术总监为了避免前面的问题而牵头进行过度技术性的产品设计。

产品设计完成后，召集项目成员分解任务，确定每项任务的时间，可以用敏捷扑克牌估算。尽量把任务分解的粒度控制在1-2天，让大家在1-2天内做出一个可以测试的原型，整合测试，尽早发现问题。尽量把一次冲刺的任务集控制在1-2周，不要太长也不要太短。太长会导致疲劳，太短的冲刺会让大家觉得工作量太大，一个接一个的完。“项目1”预计结果为120人-天，总共投入4人需要30天4周。我们将其分为4个sprint，用了将近1个月的时间完成，满足了业务的时间要求。

Sprint将分阶段实施，并绘制任务墙，划分未开始、计划中、进行中、完成和烧坏的地图。把要做的冲刺任务贴在墙上，贴在没开始的地方。

每个人都在每日的常务会议上提出任务。包括业务任务、开发设计、开发编码、前端设计开发、测试等。，所有任务都以统一的方式进行管理。重点是一个群体。如果一个同事请假，其他同事可以完成任务。常务会总结昨天的任务有没有问题，对当前的任务有什么建议，尽量控制在15分钟以内，会议才有效果。不像以前的业务或者项目经理追着每个人的屁股要结果，而是团队驱动。每天每个人做的事情都反映在墙上，每个人都会帮他想办法保证整个项目的成功。当每个任务完成时，项目执行者将任务从进度粘贴到完成区域。从未分配的区域申请新任务，并将其粘贴到正在进行的区域。

软件开发过程。认领任务后，如何保证每个人都开发出优质代码？拥有高级团队的工程师可以直接参与项目的开发，不需要太多的指导。学习工程师需要指导和帮助，一步一步做用例、系统分析。技术总监不建议宣称太多开发任务。他负责开发团队的概要设计审查。没有通过评审的设计不能开发，指导大家分析设计系统。众所周知，有了系统思维，剩下的就是技术实现的过程了。只要技能掌握熟练，基本不难实现。你可能会问，敏捷开发不是强调软件开发的产品是软件，而不是文档吗？在这里，我们不像传统的软件开发那样为了文档而文档。我们只是让每个人写下自己的设计想法。只有经过精心设计，他们才能清楚地写下自己的想法。写的时候不需要长篇大论。这种文件不受欢迎。流行的文档只需要写用例分析、表格设计，复杂的逻辑需要画流程序列图。

结对编程。这种编程模式之前被无数人调侃过，但实际上不可能每个项目都是两个人两人一组编程。这种不现实也是资源浪费。我们的结对就是当我们开发一个难度较大的模块时，会给结对的人增加一个任务，让他和其他开发人员一起完成这个任务。其实我们在开发的时候，经常会结对，比如指导新同事，讨论设计模块，这些都是之前没有算在我们开发工作量里的。

项目陈述和总结会议。项目结束后，让参与项目的所有成员都参与进来，一起给客户演示，解答客户的疑问，让大家充分感受到收获的果实。总结会主要是分享大家在这次冲刺中遇到的问题和经验，为下一次冲刺做准备。

敏捷实施后，我们的生产力提高了很多，员工的积极性提高了，业务的参与使得整体需求得到了很好的控制，沟通也多了，30天的任务提前5天完成了。我们每周有一天或半天的额外时间给每个人研究他们感兴趣的领域，但这些研究必须最终显示出结果。比如后台开发想研究一项新技术，最后需要写一个ppt给大家分享。既能让大家做自己想做的事，又能营造大家互相学习的氛围。