创业阶段敏捷开发产品原型

公司成立不到几个月，团队一共3个人，决定做一个手机上的自动化测试软件，目标是一次编写在三个手机平台上运行，使用自然语言编写的自动化测试程序，产品介绍视频：iQA介绍。

这是我们两个月的研发成果，采用敏捷的方式研发：

1.首先团队经过几次讨论，对产品应该为客户解决的问题有一个大概的了解。讨论中，由于自己也不知道最后产品应该做成什么样子，只是知道要跨平台，要使用自然语言编程，而且当时也已经碰到客户明确有这样的需求。为了避免无休无止的讨论，大家一致决定就先做知道的功能。

2.明确第一阶段的目标之后，我们开了半天的会议，头脑风暴为了达到跨平台，自然语言编写的自动化测试程序，应该要做的事项，这时不预估任务的时间。

3.所有的任务列完后（即头脑风暴已经无法再想到新任务了，肯定有遗漏，没关系，毕竟还不懂要做的事情），我们制定第一阶段的交付日期（dead line）- 4月15号。

4.接下来对所有事项预估时间，很多任务的时间不好评估，因为团队成员对iphone、Windows Phone以及Android开发都不熟，甚至两个成员只用过Windows，主要都是.NET开发背景，Mac、Linux、Object C、Java开发都不熟，甚至是根本没有接触过。因此我们只对理解的任务预估时间，每个工作任务细分到1小时、3小时、5小时和8小时，说白了就是1小时、一个上午、一个下午和一天内完成。这是因为：“如果对任务理解透彻，必然可以细分；如果不能细分，则说明尚不完全理解任务。商业趋利避害，不懂的事情为何要干？”

5.每天早上10点开一个小会，过一下昨天完成的任务，今天要做的任务以及昨天碰到的问题，一般来说，只要一个任务在研发时碰到障碍，我们就将其砍掉，原则还是只做懂得事情。每天还会再大概预估一下任务的工作时间，因为随着研发的逐步推进，团队又理解了一些新的东西。

6.每天坚持开会的另一个原因就是督促团队成员每天都有进度，避免团队成员因为钻牛角尖发散对一个问题研究太深入。

7.有的时候，团队成员在研发过程中，对于三个平台通用的东西会有些争论，如果不能达成共识，搁置争议，当前先找一个临时的解决方案，争议放到下一个阶段再说。因为有争议，就说明团队尚未理解争议的内容。

8.阶段研发完成后，作一次总结会议（或者叫postmortem meeting），议程只有三个：

a)在上次项目里，我们哪些地方做得比较好？

b)哪些地方做得不好，做得不好如何改进？

c)接下来我们应该做什么？

团队成员轮流发言，主持人做会议记录。

总的来说，效果还可以，按时交付，实现了最初制定的目标。但在总结会议上，发现下面几个问题：

1.团队对整个产品的最终目标不明确，随着产品研发第一阶段的完成，现在视野更开阔了，可以列出更多的功能了。

2.在清明节的时候，原定是三个人去凤凰开发的，由于一个成员中途有点突发事件，不能去。而我又因为别的潜在业务机会提前去了武汉，原计划南下长沙－在张家界和女友会合－凤凰与团队成员会合的，团队初建，需要磨合，不能分布开发。但我女友又提前跟公司请了几天事假准备这次旅游，不好中途折回。在旅游间隙，我使用笔记本、iphone以及团队放在盛大云服务器的分布式源码服务器（mecurial）完成原定的研发任务，通过QQ语音进行三方会议通话。即使是这样，沟通效果还是差了很多，因此女友假期结束就急急赶回上海。

这次研发过程得到的经验嘛：

1.团队需要有一个放在公网的源码服务器，建议mecurial，svn无法做分布式开发，签入和合并太痛苦，GIT学习曲线有点陡。

2.团队成员每个人都需要有一个无线上网的手段，团队成员每个人都配备了一个无线上网卡，以应付突发的分布式开发合作需求。

3.使用TDD的方式开发，但不是每个类都是先写测试用例再实现类，对于一些设计起来比较复杂的类才会用TDD，在调试过程中，对于发现的BUG，就加上一个自动化的测试用例以便做回归测试。

不足：

1.Code review机制没有做好，一方面是因为团队有些时间不在一起，没有钱买webex、LiveMeeting这样的多人在线会议系统的服务。另一方面是没有一个好的工具，因为大家都是随心所欲的签入，推送，推送的时候没有邮件通知（没有时间设置这个功能，Mecurial的shelve changes这个功能还不大会用）。不过在研发过程中，有机会还是会用QQ的远程帮助来做两个人之间的code review。

2.当然还有很多不足，因为跟本文的经验分享没有关系，就不写了。