一晃就又是一个月过去了，到了管理端，心里想的就是如何把乱七八糟的事情有序排列，让团队持续地的产出。虽说基本不用敲代码，但同时参与3个项目，感觉略累，这是一场马拉松，要么走过终点吐口气，要么走火入魔。

    经过大概一个月的准备，8月份一个正式的创业项目终于确定下来，进入开发阶段。

    该项目虽然技术难度不高，属于是垂直领域的产品，但大大的挑战还是有的。

     我们的优势：

    线下运营团队已经实战两年，并且有过万的客户量，领头大哥也有强悍的市场地推能力。

    技术成员有2个，并且熟悉该业务；具备国际视野的设计师有1个。

    我们的挑战：

    我们是学生团队。技术不够强悍，对外招聘又不现实。

    解决方案：

    我出面找有比较有能力的学生参与进来，最终项目成员有7人；一人设计，一人APP界面实现，一人APP整合，一人APP交互，一人web前端，一人java后端，而我来做架构&项目管理。

    OK，简单的前期铺垫就到这里，接下来进入本文主题，按敏捷开发宣言的路线走。

     敏捷开发宣言：

个体和交互 胜过   过程和工具

可以工作的软件 胜过   面面俱到的文档

我们只有简陋版的文档，用word表格画的界面，标志其关联的数据库表。

我也只通过processon.com做了简单的概念架构图等，把每个模块说明清楚，具体设计&实现就交由相关负责人（当然不是丢过去就是了~）

事实证明，我们在开发过程中，需求还是在改动的，有时是减法，有时是改进，因为能力有限，没办法预先拿出最佳方案。

可以工作的软件，不一定是整合完的，不同人不同时间做出来的模块，都是“可以工作的软件”，软件出来了，思考点马上就清晰了。当然每周任务交付，也不是那么容易实现的，我设计的第一次迭代任务，就完成不了了，所以现在的话，提早进入了大乱斗阶段，整合工作放后，增强沟通，防止战场分散得太厉害。

客户合作 胜过   合同谈判

我们是为自己开发的，当然也有客户，因为项目不是我们技术团队主导的，而是市场运作人员。但即使是内部人员，也无法在一起工作，他们经常要跑动，我们不想出宿舍。开发人员一般也不喜欢开会，所以，每周我会跟客户碰面两次，讨论进展&各种情况，回来可能会调整下载工作计划。

响应变化 胜过   遵循计划

虽说这一点是敏捷开发的好处，但谁愿意听到“变化”这两个字？需要“变化”，是谁的错？

一次完整的开发，就是一场战争，一鼓作气，再而衰，三而竭！

所以响应变化，只能出现在我这个环节。开发前要把各主要系统独立开来，在第一次迭代的过程中，就得与客户确定第二次迭代的内容，当然客户是不懂的设计迭代的内容的，所以由我来安排优先序，最不确定的，最可能改变的，就先不做。（一般是建议最重要，最简单的先做，但我会加多考虑，是否是容易变化的）。

结论