本文是《火星人》系列的子系列,将分期向大家分享火星人敏捷开发管理工具的开发和管理实践。
一直以来,敏捷开发长期受困于各种名词、术语的堆叠、罗列、解释,而较少出现原创和实践分享过程。而敏捷实际上本来只把自己作为一个起点,需要大家的丰富和扩展。这可能与中国的软件业发展长期落后于国际所致,以及在PMP、CMMI推广中所养成的重标准、轻实践的的情况有关。
本子系列会与大家分享我们自己的开发和管理实践,它们可能不完美,也不是终极实践(因为我们未来会做地更好),但却是在时间、人员、市场、产品、团队……众多因素的限制下的真是实践。
每一期中,除了实践本身之外,我们都会尽量分享关于这个实践我们的考虑过程、未来设想,以便帮助大家思考和实践出自己的敏捷开发来。
本文已经收录于《敏捷开发案例集》,有志于提交和发表自己案例的读者,可致信wanglijie9057@gmail.com,或申请加入QQ群:173709637。注意这是一个内部讨论群,仅对潜在的案例提供者开放。
序言
这是一个真实的故事。
这是一个只会在世界上发生一次的故事。
所以,它揭示的是真理————————在现实世界中的一次闪现。
去年在业余时间开始了一个产品研发项目,开始的时候一个人隔三差五地抽空开发,后来投入了比较常规的时间进行开发,最后又有一个兄弟加盟两个人一起开发。
这个产品,就是“火星人”,一个敏捷开发管理工具。既然是敏捷开发管理工具,自然就应该按照敏捷开发的规矩办事:用户故事,迭代计划,每日立会,自动化测试……一个都不能少,对不对?然而在开始了不久以后,我们发现问题没有这么简单。
下面的故事,就是摘选了其中围绕用户故事相关的心得体会,以后还会有一些关于测试、重构、迭代规划、团队管理等方面的心得。
由于我们的前后人数变化、实际生产率、开发日程很特殊,下面的时间点做了一些加工,以利于可以像正常项目一样理解。
免责声明:本系列文章涉及的若干中间产品截图,本文作者也认为非常丑陋。但为了保持纪实性,仍然保留这些在实际产品中已经不复存在的历史资料。请在其他正式火星人产品文章的指导下进行阅读。