今日系列：DevOps平台的从0到1实践分享。
主要从四个维度介绍：产品管理、团队组织、过程管理、工程实践。
背景介绍：无敏捷经验、新组建的全职能12人团队，负责某产品迭代开发。
产品管理
1. 产品价值
“产品重心不应只关注输出什么样的功能，更多的应考虑能不能帮用户解决问题。以此为出发点，用最小的产出达成最大的结果和影响，也就是用最小的代价实现最大的价值。”
2.产品目标
“那如何定义产品目标呢？OKR，即目标管理工作法。产品需要有一个远景目标，但真正开始第一步的时候需要找到一个可以切入的目标。例如：‘提高测试环境运行效率’——是产品的一个切入目标，它是定性的，关键结果是达成目标的需要达成的内容，它是定量的。关键结果要关注资源效率和时间效率，这是我们产品最重要的目标。在产品最开始立项的时候，我们就确定需要解决的问题和要达到的结果。”
3.产品Roadmap
“有一个目标之后，就要考虑另外一个问题，产品需要做哪些内容，来实现既定目标呢？
Why-为什么我们做这个产品？
Who-谁可以促成目标的达成或者妨碍目标的达成？
How-什么样的行为会对这个结果有影响？
What-最后我们产品需要交付什么样的内容，去触发相关人行为的变化，从而帮助我们实现我们的目标。”
4.产品Backlog
“我们希望用最小的代价达成目标。这个过程中，我们需要在roadmap上找到一个最短的路径。用敏捷的方式形成一个产品的backlog，梳理确定优先级，及时根据用户的反馈做出变化和调整。以前的需求强调的是系统需要做一个什么样的东西，使用用户故事的方式描述需求，更关注的是客户到底需要什么东西，虽然只是小小的改变，但是思维的转变很关键。”
团队组织
“做好产品的规划和管理后，如何落地执行呢？要怎样组织这样的团队，用最小的代价更快的达成呢？”
【组件团队和特性团队】
“组件团队，是指每个团队只是完成系统功能的某一个部件，而不是一个端到端用户可见的功能。特性团队，是一个长期跨职能跨组件可以端到端交付客户需求的团队。跨功能就是我们会有开发、测试等不同的技能在同一个团队里。
组件团队和特性团队做一个对比：
【多团队开发】
“如果项目涉及到多个团队的开发，我们要问一下团队的进度大概怎么样。A团队说我们好了，B团队说我还没有弄好。这样就会导致等到B完成之后才能做集成，集成的时候又发现一堆问题，方案和需求也许会发生一些变化。
特别是平台研发，没有对应到某个业务线，业务线就更关注自己的绩效是怎么样的，需要的时候就会抢平台的资源，而对于整个公司来说，这件事的优先级是不是最高呢？”
【一直变大的团队】
“在某一个时间之内某个项目很紧急，要发展肯定要加人，导致团队的组织越来越大。客观来看，虽然人增加了，但是交付的价值好像没有那么大。在一些互联网企业，可能三或六个月要重构一下，把领域合并拆分一下。”
过程管理
“有了产品和需求我们也知道如何组织团队，这些人到底该怎样合作把产品交付呢？这涉及到过程管理，比如Scrum框架。”
“最开始只给团队一个约束，如每两周交付一些可工作的产品。可以在第一周的周一做迭代计划，PO明确做哪些东西，评估哪些可以做完。然后在第二周的周五做验收和回顾。这里不是每一个迭代只交付一次，而是在这个迭代过程是持续的提交这些东西，只要做完了就上线。”
工程实践
“有产品，有需求，有组织，我们也知道如何配合，最后就是采用什么样的工程实践来实现产品。”
【单体to微服务】
“最开始我们是一个单体的结构，随着团队的不断成长，业务的不断丰富，会发现很多冲突和依赖会降低我们的效率。接着做了第二件事，我们先把它模块化，再后面就把它拆成了微服务的架构。”
【测试阶段to测试活动】
“前期会把测试阶段变成测试活动，每个开发都去做测试，而不是说只有测试的同学去做，不仅在提测之后才进入测试，这是一个变化。采用接收测试驱动开发的模式，让测试更早的介入，更早的发挥测试的技能，进行需求的测试。”
总结
1. 产品价值
“定期把产品的结果给大家review一下，及时的跟团队、产品及相关方沟通我们的情况。每做一个功能都确定一个类似的指标，定期分析这个指标有没有达到，如果没有达到的话，定位下原因，然后决定是否继续下去。”
2. 变化
“原来的延期交付变成持续快速交付产品，那么用户的信任度会加深，过程也更透明，因为可以持续得到反馈。”
3. 关键点
“持续尽早的交付可工作产品，最重要的是要有持续的改进，所有的东西不是一个人设计出来推给团队的，在这个过程中需要持续不断的做一些改进和尝试。”
“概括来说即守—破—离。初期大家如果没有把握的时候，最好是守，去follow去实践，熟悉了之后，有规则受到阻碍的时候可以适当破一下。当你真正的掌握了这个东西以后，也许可以抛开所谓的招式等等，也就是所谓的无招胜有招。”
