让我们先看一些有关这款应用开发历程的基本数据：
团队规模：3~4人
从立项到上线时间：3~4个月
团队移动应用开发经验：从零开始，第一次做Windows Phone应用开发
具体做的事：4个月时间跑了4个Sprint，3个开发Sprint，1个纯粹的测试Sprint，集成了3家不同合作伙伴的数据，实现4个相对独立的功能，“衣食住行”项目实际上是做了4个应用。
代码量及Bug数：Beta版仅客户端代码就超过3万行，不包括XAML。后台端的代码轻量级一些，大概只占到客户端的一半。4个月内修复了300多个Bug。
黄昊文告诉CSDN记者，敏捷开发过程中很难避免Bug的产生，因为做的东西比较快，Bug量会比传统模式开发的高，但是经过最后几个周期下来以后，质量是可以得到控制的。
http://upload.chinaz.com/2012/0531/1338426761255.jpg
“衣食住行”应用的项目经理 黄昊文
在他看来，敏捷开发过程中至少有几个要素值得注意。首先就是团队成员规模，人不能太多，不宜超过10个。超过10个以上项目经理核查难度就会加大，因为每个人做什么根本就搞不清楚，每天有个短会，如果人太多每人讲三分钟半小时就过去了，已经失去敏捷开发的意义了。3~6个成员是比较合适的，可以最大程度上掌控进度并随时调整的。在团队规模比较小的情况下，成员分工也相对灵活。
此外，要真正保证产品交付，还需要确定每个Sprint。Sprint就是一个周期，每个Sprint周期一般是4到6个星期，实在要短也不能少于3个星期。Sprint在开始的时候，可能花半天左右做一个Sprint的计划，比如分4个星期，这4个星期里面能够完成什么。
具体到“衣食住行”项目，团队有3~4个人，做这个计划的时候要非常细，细化到每一个工作最长分工不能超过两天，最好是以半天为单位来划分。化的这么细，这个工作还是挺费时的，花3、4个小时做这个，但是以后的工作就会发现像搭积木一样，慢慢知道从哪一部分起能搭成一个房子。Sprint Planting的目的就是为了控制风险，同时大家都能很明白，自己下面的3~4个星期能够完成什么。
此外一个重要的要素就是每天的Sprint短会，目标很明确，每个人就回答三个问题：昨天做了什么？今天打算做什么？在做的过程中碰到过什么问题？如果能回答这三个问题团队成员就知道应该做的是不是完成了，能不能跟得上计划，还有没有突发的、之前没有预想的风险问题。通过这三个问题的回答，一个人就是2、3分钟，3到5个人的话就是15分钟左右，15分钟就能很好的了解项目的进度，项目的进展和一些突破的事件，然后很快可以调整一些计划。开短会的核心是一定要短，只谈关键问题，无关的事情就不用谈了。黄昊文的建议是在早晨开，因为早晨开一旦发生问题当天就可以解决。
敏捷开发过程中整个项目的把握和调整都在项目经理这边控制，因为是一个周期一个周期开发。一定要明确在几个周期做完以后，整个产品能做出来，而不是大家我喜欢做这个，我们做这个，我喜欢做那个就做那个，到最后发现不行还有好多东西缺了。
http://upload.chinaz.com/2012/0531/1338426761665.jpg
具体到“衣食住行”这个项目来说，因为团队是新的，设计师、开发、项目经理都是第一次合作，关键是对Windows Phone7又是第一次做。其实第一个Sprint是后来延长了的，因为之前估的时候确实是少估了，基本上延长了50%的时间。这个时候项目经理就要把后面的及时调整再做。这样做了一到两个Sprint下来第一是对团队比较了解了，第二是对技术上有信心了，所以后面的话就会越做顺。
敏捷开发大家很多人会抵制，认为很可能做Sprint很痛苦，每天好像都要报告一样，做的东西一开始都是拍脑袋瞎估，后来一会要赶这个一会要赶那个。但是如＊＊持做两到三个Sprint下来的话，无论是个团队还是项目就会越做越顺，到后面的话就会非常愉快了。
用“衣食住行”实际开发过程举例，第一个Sprint大致有4个星期，4个星期中第一个星期是设计，所有的东西设计稿全部确认出来，第二个星期到第三个星期的中间基本上开发完成，然后第三星期的后半周和第四星期是争取跑两轮的测试。测试一般测一到两天，然后改一到两天，基本上可能需要八天左右，还是非常紧张，两天测试两天改。Sprint还有一个好处就是可以就像pipeline一样，设计师在第一次Sprint设计完了以后，可以开始第二个Sprint的设计了。测试的人员在第一个Sprint后半期的测试可以继续往后面测下去，所以是结合了敏捷开发和一些pipeline开发的特点在里面。
页:
[1]