陈勇的博客 - Scrum 敏捷开发培训咨询，绩效管理，团队管理，《火星人敏捷开发手册》

（序言，之一，之二，之三，之四，之五） 先开发整个框架，还是先开发故事群？         当用户故事的增删改查都还没做的时候，这个问题就被提了提出。         最初曾经想：只做故事的显示功能，增删改都在数据库内直接操作，然后迅速进入“迭代计划”部分，把迭代计划大致弄出个样子来后，赶紧做燃烧图、故事板……但是这个想法很快就被否定了，因为在此前做敏捷咨询的时候就曾经在用户项目里发现：如果把一个

（序言，之一，之二，之三，之四，之五） 第一个月：一个产品的诞生 没有国王，没有宰相，没有能讲故事的王后，也没有需求文档，开发就这样开始了：为何不先写需求文档？因为敏捷开发不写文档！不是的。策划这个产品的时候，有一个大愿：就是用这个产品管理这个产品自己的研发。虽然这不等于没有“长得像”Word的文档的需求，但是我们仍然想尽量只用产品本身的功能来写需求。所在在项目开始的那天，我们手里（确切说是脑海里

（序言，之一，之二，之三，之四，之五） 本文是《火星人》系列的子系列，将分期向大家分享火星人敏捷开发管理工具的开发和管理实践。一直以来，敏捷开发长期受困于各种名词、术语的堆叠、罗列、解释，而较少出现原创和实践分享过程。而敏捷实际上本来只把自己作为一个起点，需要大家的丰富和扩展。这可能与中国的软件业发展长期落后于国际所致，以及在PMP、CMMI推广中所养成的重标准、轻实践的的情况有关。本子系列会与大