模板
教程
环境
性能
功能
管理
我是如何和产品线沟通敏捷软件开发方法的？
【做为敏捷教练需要和开发团队沟通为什么需要敏捷软件开发方法。这往往不容易讲清楚，因为每个团队的特点是不一样的，需要根据团队和产品的特点入手来讲，要条理清晰、循序渐进、由浅入深。以下是我和百度的一个产品线沟通的方式，写出来和大家分享。】
【首先要肯定人家已经取得的成绩，确实很棒!】
接触xxx团队一段时间了，我非常喜欢这个团队，也对你们取得的成绩感到骄傲。下面想和大家分享一下我的一些想法和建议。
1. 如何加快产品演进速度和效率?
【用问题带领陈述】
我们的产品目前还处在早期探索阶段，在这个阶段用户需求和产品形态都还不完全明确。在这个阶段最重要是如何尽快摸清用户的需求。但如何搞清楚呢?手段有多种，不过最有效的方式肯定是真实用户的行为反馈。这点没有异议。这个反馈环大概是这样的：
这是个不断循环的过程，循环反馈的速度越快，我们就能越快达成目标：即定位用户需求，确定解决方案。
这个阶段的效率主要体现在“整个反馈速度”上面，而其中“研发”是环节之一。 加快反馈速度有两点：
1. 单次循环的负载：每次任务越少，循环速度越快
2. 循环中每个环节的效率：效率越高，循环速度越快
a) 产品构思：PM及各老大
b) 代码实现：RD/QA等
c) 数据验证：PM为主，RD支撑
2. 如何实现这两点?(降低单次循环的负载，提高各环节效率)
这个是个PM-RD各环节联动的问题。简单说就是：
1)轻量级的输入
2)快速迭代，持续交付
3)需求和验证方法同时提出，同时交付
4)统一需求管理，明确优先级
2.1. 轻量级的输入
需求要细分成小片符合INVEST原则的条目，INVEST =
l Independent：相对独立
l Negotiable: 可协商的，就是大家都能看懂的(PM,RD,QA,FE,以及各位老大)
l Valuable：对用户有价值
l Estimable：交付工作量可估计
l Size properly：大小合适(根据项目特点，一般2-10人天)
l Testable：可测试的
这样就可以以轻量级的输入驱动每次的循环。而只有每次相对独立的输入才能取得最佳的验证效果。
2.2. 快速迭代，持续交付
只有具备持续快速交付的能力，才能支持小批量的需求实现。我们有时也能快速交付，但是通过：
1)不可持续的额外努力：加班
2)牺牲一定的质量(对early adopter可以接受的)
3)技术债务(需要后期弥补，否则影响后续交付速度)
这三种方式达成的。这不是可持续的。
我们的常态还是瀑布式的大批量生产模式。原因有很多，其中一点是为了降低每次测试发布的overhead成本，因为每次改动都需要相对大的成本进行测试以便达到发布需要的质量。其实这点是可以改变的。我们在小批量生产时也可以控制每次测试和发布的overhead成本，如何做呢?有以下几点：
l 持续集成(程序员六步提交法，代码同源，每日构建，等等)
l 自动化功能测试(包括单元测试、自动化功能测试、quick/slow测试，等)
l 代码评审，结对编程(内建质量)
l 每日站会，可视化管理(高效信息共享、消除浪费、流程持续优化)
l 等等
产品质量是在生产环节中内建的，而不是靠后期大规模检测取得的。只要我们在需求、设计、编码、自测的各个环节中都关注质量，不盲目以质量(长期利益)换时间(短期利益)，才能逐步地有计划地增强持续交付的能力。
2.3. 需求和验证方法同时提出，同时交付
为了保证需求能被快速验证，可能需要做以下几件事：
1) 每个需求都有验证方法
2) 验证方法是需求的一部分，要同时给RD
3) RD要确保验证方法和需求一起实现，一起交付
4) PM依据事先制定的验证方法进行验证，并快速知会各方：RD等
5) PM调整需求列表，进入下一次循环 这样我们就可以形成一个良性循环，不断加快试错速度。
2.4. 统一需求管理，明确优先级
在重要项目中，我们需求的来源是多方面的，那统一需求管理就变得额外重要了，否则很难系统地提高产品整体反馈速度。
特别是需要明确优先级：虽然RD等各部门的工作有各种依赖关系，但有了需求方的明确优先级，内部资源协调时，鸡翅项目负责人才有法可依，否则就可能导致功能团队的局部优化。
同时将需求细化到合适的粒度：合适的粒度是指所有利益相关人都可以理解的粒度。如果粒度太大，程序员无法对应到具体实现;如果粒度太小，PM或其他干系人无法了解进展。所以按INVEST原则进行需求拆分是关键。
【谦虚谨慎，不要托大】
以上是我的一些浅见，也很愿意有机会详细交流。
