本文是《火星人》系列的子系列，将分期向大家分享火星人敏捷开发管理工具的开发和管理实践。

一直以来，敏捷开发长期受困于各种名词、术语的堆叠、罗列、解释，而较少出现原创和实践分享过程。而敏捷实际上本来只把自己作为一个起点，需要大家的丰富和扩展。这可能与中国的软件业发展长期落后于国际所致，以及在PMP、CMMI推广中所养成的重标准、轻实践的的情况有关。

本子系列会与大家分享我们自己的开发和管理实践，它们可能不完美，也不是终极实践（因为我们未来会做地更好），但却是在时间、人员、市场、产品、团队……众多因素的限制下的真是实践。

每一期中，除了实践本身之外，我们都会尽量分享关于这个实践我们的考虑过程、未来设想，以便帮助大家思考和实践出自己的敏捷开发来。

本文已经收录于《敏捷开发案例集》，有志于提交和发表自己案例的读者，可致信wanglijie9057@gmail.com，或申请加入QQ群：173709637。注意这是一个内部讨论群，仅对潜在的案例提供者开放。

序言

这是一个真实的故事。

这是一个只会在世界上发生一次的故事。

所以，它揭示的是真理————————在现实世界中的一次闪现。

 

去年在业余时间开始了一个产品研发项目，开始的时候一个人隔三差五地抽空开发，后来投入了比较常规的时间进行开发，最后又有一个兄弟×××两个人一起开发。

这个产品，就是“火星人”，一个敏捷开发管理工具。既然是敏捷开发管理工具，自然就应该按照敏捷开发的规矩办事：用户故事，迭代计划，每日立会，自动化测试……一个都不能少，对不对？然而在开始了不久以后，我们发现问题没有这么简单。

 

下面的故事，就是摘选了其中围绕用户故事相关的心得体会，以后还会有一些关于测试、重构、迭代规划、团队管理等方面的心得。

由于我们的前后人数变化、实际生产率、开发日程很特殊，下面的时间点做了一些加工，以利于可以像正常项目一样理解。

 

免责声明：本系列文章涉及的若干中间产品截图，本文作者也认为非常丑陋。但为了保持纪实性，仍然保留这些在实际产品中已经不复存在的历史资料。请在其他正式火星人产品文章的指导下进行阅读。