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

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

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

我们的优势：

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

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

我们的挑战：

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

解决方案：

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

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

敏捷开发宣言：

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

团队合作的最大难度不是技术，而是人。对于我们这个立马从外部拉起，立马开工的团队，敏捷开发适合我们吗？要知道，敏捷开发最重要的就是团队默契，其次是个人综合能力，最后就是专长。

在这个点上，有一个比较成熟的套路，那就是每天几分钟的站立会议，大家来交心，昨天做了什么，今天要做什么，遇到什么问题&解决思路。但这个套路我们用不了，因为我们工作时间太过自由（不是公司制度）。

一开始是这样的，我跟大家说，我们每天下午一起到机房工作如何？其它时间就自由安排。但只有3人说可以做到这样。缘由就不说了，没问题的，有时需要集结，再一起过来就行了。

敏捷开发的话，团队协作工具是为沟通&交互的。

我们技术部组建了QQ群，可以及时发布，大家测试&交流；我加了其他所有人飞信，需要集合的适合，会群发短信给大家；然后使用了worktile，进行工作分配。

目前的主要个体交互点是这样的：设计&APP界面实现；APP整合&APP交互；web前端&java后端；我&所有人；但没有极限编程的元素。

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

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

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

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

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

客户合作 胜过   合同谈判

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

响应变化 胜过   遵循计划

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

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

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

结论

敏捷开发第一建议，团队都要坐到一起，旁边要有白板贴纸……

而这第一小步，我们就没做到了，但开发进度还是可以推动的，虽然不快，我也不知道算不算敏捷，但目前还算顺利，没什么大bug出现。

计划9月15号完成项目初期工作，9月25号发布……