长达36个月的敏捷转型

　　敏捷转型涉及到流程建设、人员培训、平台建设、软件架构优化等，一家公司要想成功地完成敏捷转型并非易事。
　　一件事情，干了36个月，想想还真是蛮长的。作为一家传统公司（消费类电子）在进行智能硬件产品研发时进行敏捷转型，当前的结果还是比较令人满意。
　　公司没有专门的人做这个事情，都是业务部门的人兼职做，所以不要给自己设定边界，认为是一件对的事情，就持续坚持吧！
　　一、敏捷转型的目标与关键成果
　　目标
　　敏捷开发达到业界优秀水平，更快速的响应市场需求。
　　关键成果
　　可以任意指定用户群进行特性发布。
　　每周都可以对外进行特性发布。
　　各软件专业发布互不依赖，独立规划、独立发布。
　　版本规划、需求、资源、阻塞问题可以高度透明，及时同步。
　　二、敏捷转型的困难
　　敏捷转型是一项系统性工程，涉及到流程建设、人员培训、平台建设、软件架构优化，所以一家公司要成功的完成敏捷转型，往往比较困难，极其容易在转型初期形成敏捷无法有效提升研发效率的错觉，变得消极，难以突破。而且大家在谈论敏捷时，往往更多的谈及敏捷在流程上的改造，却容易忽略其他方面的重要性。
　　流程建设
　　流程建设在初期必然会和已有的流程产生一些冲突，如果一上来就全面替换现有的所有流程，必然引起强烈的不适。
　　更何况，在敏捷转型初期，我们对敏捷的理解往往还不到位，制定出来的流程往往存在不少缺陷，即使全面替换，也不能保障效率的提升，甚至还会导致效率的下降，打击大家转型的积极性。而且流程制定一定要结合企业的特点，不能完全照搬标准定义，这也考验着我们对敏捷和业务理解的深度。
　　当我们设定了一个合理的流程后，顺利的落地执行依旧是一项挑战。
　　忽略人员培训的重要性
　　由于在公司转型初期本身理解敏捷这套方法论的人就不多，往往缺乏培训人员，或者缺乏明确的培训责任划分，导致难以有效培训。
　　敏捷里面有一个scrummaster的角色，这个角色的工作业绩缺少太难以量化，我想很少有公司会设立专职的scrummaster，即使我们在这条路上走了三年，依旧没有这个角色。
　　另外，要打破我们固有的思维模式和工作习惯是一件比较难和需要持久进行的事情，在转型期如果没有明显的提升，质疑的声音就会迎面扑来，大家会表达出想用以前的工作方法愿望。
　　忽略平台建设
　　这个道理很简单，给你一辆拖拉机你永远都开不到法拉利的速度，不管你把其他方面做得多么极致。但是，当我们进行转型时，要顺利的完成相关的平台建设，可不是一件容易的事情。
　　从我们转型过程来看，我们在第三年才投入相关资源建设相关平台，虽然我们一直在吐槽平台难用，效率低。这里主要涉及到以下几个问题：
　　业务发展还不够明朗，不舍得投入资源进行平台建设。
　　业务发展过于迅猛，研发资源都投入到了业务开发上。
　　公司组织架构问题，多部门目标不一致。
　　缺乏对这件事情明确负责的人，三不管地带。
　　所以，如果平台建设不在业务线范围内明确其重要性，这件事情基本无法搞定。
　　软件架构优化
　　软件研发本身就是一件系统性工作，如果软件架构不合理，开发周期长、bug多、依赖重，同样很难快起来。
　　当前的智能硬件产品，往往都涉及非常多的软件专业，包括服务器、H5、Android、iOS等等，如果系统足够复杂，前面的几大专业还会细分出更多的专业。如果每个专业的发布需要依赖其他专业，那么很难快起来。
　　就像大家都在高速公路上跑，路上出了事故，大家都得慢下来，等出来完事故后，大家又得重新慢慢加速。
　　在春运期间我们很容易遇到，你发现把堵车的路段开完了也没有看到事故，可以为什么还是堵车呢，事故处处理完后堵车路段为什么不能迅速疏通呢？
　　另外一方面，你用H5开发一个功能和用原生应用开发一个功能，发布速度肯定有天壤之别。H5一天发几十个版本都有可能做到，你用Android原生开发可能做到吗？
　　三、流程建设
　　我们的产品涉及面广，我们针对产品特点，分出来了多个特性小组，每个特性小组由产品经理主导，作为特性交付的第一负责人，目前已成功运行的机制如下：
　　特性团队
　　产品提案评审
　　队列填充会议
　　晨会机制
　　交互评审
　　产品验收
　　版本火车发布
　　灰度与全量发布
　　大数据分析
　　3。1。确保需求有价值
　　问题越早发现，带来的收益就越高。
　　使用OKR梳理部门年度目标，基于部门年度目标，各专业梳理出自己的年度目标和季度目标，个人基于专业领域的年度和季度目标，梳理自己的季度目标。通过使用OKR这个工具，大家目标上下左右对齐，识别出正确的事情，避免不必要的资源和时间浪费。
　　产品团队针对新的特性需求建立提案评审机制，保障新需求的质量，虽然我们无法完成预见需求最终的市场表现，但是至少要做到逻辑上这个需求是靠谱的。特殊情况，一些需求大家很难达成一致，这个时候我们更趋向于允许这个需求进入研发，进行市场验证。
　　每周五最后一小时召开固定的队列填充会议，各领域负责人与产品经理共同确认拉入的需求。避免产品经理的单一视角，导致拉入一些不合理或者没想清楚的需求。
　　3。2确保需求优先级达成一致
　　资源永远是不够的，所有优先级在迭代过程中是必须要保障的事情，否则有可能导致一些重要的事情得不到足够的资源，或者各领域之间互相扯皮，增加沟通成本。
　　特性小组要有自主性和独立性，但是不能完全的独立和自主，这样他们很容易站在自己所负责的特性的狭隘视角安排迭代。另外我们要充分认识到不同产品经理的能力是有所不同的，不能完全放权到产品经理，否则很有可能因为产品经理能力的不足，导致一个特性团队处于混乱中。
　　建立需求准入审查机制，该机制可以在队列填充会议上运行，产品经理拉入研发的需求都需要让各领域知晓，如果发现不合理的需求，可以在该会议上有效控制。
　　进入研发的需求需要通过交互评审，如果存在文档，需要附上相关文档内容。该规定，也可以在队列填充会议上有效控制。
　　3。3确保进入研发的需求有相应的研发资源
　　停止启动，聚焦完成，我们迭代过程中一定要控制同时研发的需求量。否则你会发现每件事都在做，然而每件事情都需要很久才能做完。
　　控制研发看板上的需求数量，就需要控制流进和流出。所以大的原则是没有需求做完前，不允许拉入需求。当然，如果研发看板本上的需求本来就比较少，或者说增加了研发人员，这里可以灵活控制。
　　队列填充会议上给到多个特性小组互相协调资源的契机，也给到各专业负责人了解资源情况的一个契机。通过大家协调和调整资源，确保需求有对应的资源进行研发。
　　3。4确保研发过程足够透明
　　信息透明是自组织的基础，足够的信息透明，才能让讨论和问题处理有完全的参考，才能高效协作和解决问题。
　　对于大型团队一定是需要一个电子化工具支持研发信息的透明的，完全靠人是不合适的，这个市面上有相关产品，当然我们是自研的。为什么我们要自研呢？主要是为了保障产品敏感资料的安全性以及更好的适应我们企业的流程。
　　晨会作为敏捷的一个标志性会议，是一定需要开的。我们能通过这个会议让特性团队的凝聚感更强，同时及时同步研发信息和问题，提升研发效率。可以要开好晨会也不容易，例如：
　　1。存在团队成员跨团队的情况，导致你的晨会他不一定能参加。
　　2。晨会人员过多，导致场面混乱。
　　3。看板泳道设计不合理，导致信息可视性和可流动性差。
　　版本规划要明确，我们要有一个电子平台在里面公示版本信息，包括版本涉及领域、各个客户端版本号、包含哪些需求、集成时间、发布时间等等。
　　四、人员培训
　　以人为本，不断多好的流程、多好的工具，参与和使用它的人没有掌握，都无法有效达成目标。
　　需要对全员培训敏捷的相关理论，并为他们答疑解惑，长期辅导。
　　可以针对《敏捷软件开发实战估算与计划》《看板方法》这两本书里面的理论梳理培训大纲，同时也可以分享这两本书给到团队成员阅读。
　　当敏捷适配到企业流程后，建立出适合企业的敏捷流程，在这个适配过程中，也需要不断的给相关团队成员培训流程建设的目的和意义。
　　五、平台建设
　　持续集成平台
　　软件的构建当下越来越复杂，类似于Jenkins、GitLab、各种静态检测、依赖管理、自动化测试都得做起来，使用以前的原始手段处理当下的软件系统，效率是非常低的。
　　发布平台
　　智能硬件的软件发布可以分为多个层级，包括：OTA升级、应用发布与升级、应用内功能开放与关闭、H5发布。为此，我们需要针对这些发布方式，构建相关的后端发布平台，支持相关业务人员可以简单、高效、灵活的操作。
　　研发管理平台
　　研发管理包括：版本管理、需求管理、任务管理、bug管理、发布管理等等，缺少这些平台的支持，都会严重影响研发效率。
　　运营平台
　　一个好的功能，还需要让用户知道。我们需要通过推送、弹窗等各种手段将运营信息传达到用户眼里。因此，也需要提供简单、高效、灵活的运营平台。
　　六、软件架构优化
　　这是一个技术话题，大家可以关注当前比较火热的大前端，各家公司都在想办法如果通过软件架构优化提升迭代效率。这里可以大致列举一下业界的各种技术：
　　小程序（微信、支付宝）
　　快应用（各大手机厂商）
　　ReactNative（Facebook）
　　Flutter（Google）
　　组件化（微信）
　　插件化（携程）
　　Weex（淘宝）
　　另外补充一下，上面谈及的技术均是客户端技术，针对服务器的快速发布和部署，业界技术也是层出不穷，例如：微服务、各种运维技术等。
　　当然，软件架构优化也不一定要通过上新的框架这么大的动作来改善。这里重点想表达软件架构优化对敏捷转型也至关重要。例如仅仅做简单的代码重构，降低业务耦合度也是有意义的。

造句：长达个月的敏捷转型
造句：长达个月的敏捷转型