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

公司成立不到几个月，团队一共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. 当然还有很多不足，因为跟本文的经验分享没有关系，就不写了。

创业阶段敏捷开发产品原型相关推荐

敏捷开发产品管理系列之三：产品用户群规划
本文是敏捷开发产品管理系列的第三篇.(序言及设立迭代目标,产品版本规划,产品用户群规划,新产品研发,预估会议,Product Servant,Product Owner团队,产品线管理) 上周在培训做 ...
敏捷开发产品管理系列之四：新产品研发
本文是敏捷开发产品管理系列的第一篇.(序言及设立迭代目标,产品版本规划,产品用户群规划,新产品研发,预估会议,Product Servant,Product Owner团队,产品线管理) 这里所指的新 ...
敏捷开发产品管理系列之六：Product Servant
本文是敏捷开发产品管理系列的第六篇.(序言及设立迭代目标,产品版本规划,产品用户群规划,新产品研发,预估会议,Product Servant,Product Owner团队,产品线管理) 马与马车夫的 ...
敏捷开发产品管理系列之二：产品版本规划
本文是敏捷开发产品管理系列的第二篇.(序言及设立迭代目标,产品版本规划,产品用户群规划,新产品研发,预估会议,Product Servant,Product Owner团队,产品线管理) 本文是一篇旧 ...
“迭代期内无变更”与敏捷开发产品版本规划
作者:陈勇出处:blog.csdn.net/cheny_com 迭代期间无变更? 支持派说:对,如果经常变,我们怎么开发啊. 反对派说:不对,敏捷开发不能上来就确认了需求,要的就是在开发中逐步了解需 ...
设计方法（原型法、敏捷开发）
原型法和敏捷开发 [快速]原型法就是按照客户写的demo. 分类 1. 抛弃型原型 - demo的需求客户确认后就抛弃. a)探索性 - 为了确认需求: b)实验型 - 为了确认规格说明是否可靠. ...
ios敏捷开发的理解
一,根据以下几个问题来谈谈敏捷开发 1.什么是敏捷开发? 2.为什么使用敏捷开发? 3.如实使用敏捷开发? 4.采用敏捷开发的产品效果? 二.什么是敏捷开发? 敏捷开发是一种价值和原则,指导我们更加高 ...
《敏捷开发绩效管理》扩展阅读（敏捷开发绩效管理，敏捷团队绩效管理）
本文长期更新,请常来看看. • 序言 – 从代码行到故事点敏捷估算:故事点与直接估算天数的差异 – 下一步? • 敏捷团队绩效管理 – 谁来管理团队中的个体? 同行压力(兼谈敏捷团 ...
敏捷开发绩效管理之二：用中医理论管理团队及其绩效（绩效考核，团队管理，自组织团队）...
这是敏捷开发绩效管理的第二篇.(之一,之二,之三,之四,之五,之六,之七) 团队管理是个由来已久的话题,各式各样的管理理论和方法层出不穷.笔者因为工作原因在过去16年里与100多家企业的团队或团队领导 ...

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

创业阶段敏捷开发产品原型相关推荐

最新文章

热门文章