日志
过程改进日记之学习Scrum2010-8-18 backlog or Feature list？（二）
热度 1 ||
例会，除了PM和我，终于那个新员工MM记得站着，其他人坐着，就例会本身的描述，明天没有变化我就不写了。省得搞得和天气预报一样
。
。今天尝试写一个Wifi相机的Bcaklog，诸如以下形式（节选）
-
作为相机用户，我希望把相机上连上热点后，立即把缩略图发送到我指定网络图片库中，这样我的朋友可以随时看到我在哪里happy
-
作为相机用户，我希望把相机连上热点后，可以将我的GPS信息翻译成地址发送到我指定的手机号码上，这样我最重要的人可以随时知道我的方位
-
作为相机用户，我希望相机连上热点后，能够随时检查相机的固件信息，但我不需要随时更新，这样不会让我在拍摄的时候被干扰到。
-
作为相机用户，我希望除我之外，我不在边上时，相机上的所有信息不能被其他人阅读
觉得这样的内容只能算作传统流程中的用户需求，而按照传统模式，用户需求之后还要转化为业务需求，在此基础上做概要设计，最终才能够形成低保真模型。
我们以前的FDD模式其基本路线如下：
用户需求/业务分析－低保真原型－SPEC（Product Specification Document的缩写)/SPEC review－Feature List－schedule－Project start－RC
确定schedule后，Team一起按照schedule执行开发测试工作到版本发布。
另外一方面，我们这边会针对技术难点做些前期准备，一般项目中的技术困难都只是多消耗些时间来稳定和完善，不致于真的有不能突破的技术瓶颈（技术预研和成熟的公共库机制保证不会出现影响到产品核心功能实现的技术障碍）
如此，这样看起来象是原始需求的backlog最多应该是业务分析前的用户需求的抽象，而我们消费类软件产品的属性决定了低保真原型的重要性（有时候，我们还要高保真原型）。
我试图将这些看起来象原始需求的东西展开，但是发现和我们现有的Feature List别无二致。
苦思冥想，并且询问若干有些实践的同仁，从腾讯的实践介绍中找到了一丝答案，敢情在某种情况下FDD和Scrum的结合是路是一种必然。
在大的框架体系完成基础上，
用户需求/业务分析－低保真原型－SPEC（Product Specification Document的缩写)/SPEC review－Feature List
考虑结果如下，
1、在初期，应该仍旧保留业务分析和低保真原型，SPEC/review ,并形成最初的Feature List基础上，再次基础上分割Sprint，原则是明确前几个sprint
2、有需求/变更随时纳入管理，（考虑通过禅道来管理需求，将Feature List录入到需求栏），每次以Feature做为Sprint的讨论单元。原始需求加入前可以使用类似backlog讨论→低保真模型的方式（这样保证需求得以被集思广益、深入讨论），低保真模型始终是最新的，这样的好处是不用反复去改SPEC。
3、目前的测试是在开发之后的，比较被动，backlog中的how to test的思想很好，我们可以考虑在Feature List的详细信息中记录。这样以往开发没有完成，还不能递交测试的，可以在How to Test上写上通过运行特定Test Bed，这样，开发人员尽量配合编写简单的测试桩或通过在程序中添加消息来验证成果。（理想状态下，每天都要验证成果噢）
当然，这些还都是设想，希望能够成为实践:)
附：
腾讯在敏捷开发方面的实践大致包括3个部分：
1．产品：采用FDD，即产品特性开发驱动的一种模式，腾讯的产品会有一个明确的产品经理这样一个角色，他会负责整个产品，包括产品的验证、产品的方向、市场调研、用户调研等。FDD模式是一种非常适合产品经理来对产品做一些滚动的要求，腾讯在产品设计上引入了类似FDD这样的模式，但是也不完全是FDD，只是参考FDD，所有的开发团队都是由产品经理所归纳出来的产品特性去驱动整个产品的研发。
2．项目管理过程：腾讯采取了SCRUM，但也不完全是SCRUM，有腾讯根据自己的特点去总结的一些实践，大概的项目管理过程同SCRUM的过程是比较类似的，包括每天的晨会、迭代、timebox、每个迭代完成的时候会有showcase、回顾总结等。
3．开发实践：参考了很多XP的实践，就XP完整的实践来说会比较理想化，很多东西不一定在实际开发中能够采纳，所以腾讯也是采纳其中的某些实践，比如自动化测试和持续集成，通过这样的实践就能保证产品有一个快速发布的过程。
（不好意思，我找到转贴处，但那厮没给出处，无奈我只好给了同样在学习的人的链接，他好歹是部分原创的，参考）
