敏捷指南阅后的几点体会

关于敏捷：

是一个框架，在此框架中，人们可以解决复杂的自适应难题，同时也能高效并创造性地交付最高价值的产品，它是轻量级的，易于理解的，难以精通的

敏捷的精髓在于小团队，个体团队具有高度灵活性和适应性，当单个、几个、多个和团队在开发、发布、运营和维护成千上万人的工作和工作产品时，这些优势得以持续运作并发挥价值。

从现在的趋势来看，不管是国外的谷歌、IBM、Facebook，还是国内的阿里、腾讯、华为，越来越多的是以小团队作战，这些公司慢慢成为了一个个平台，平台提供所有基础的服务和软硬件资源，优秀的人互补地、顺其自然的形成小型敏捷团队 5-9人，完成某一个或某几个特定目标的项目、产品、任务、活动 ，从而体现价值，创造财富，未来的世界是自由人的世界，这符合科学社会主义的发展趋势，而我们正走在这样的道路上。

敏捷采纳一种迭代、增量式的方法来优化对未来的预测和控制风险，我们可以检视下当前互联网企业，产品的发展基本也都遵循这样的发展轨迹，小到1天1次或几次，大到1周或1个月一次，不断进行版本的迭代升级，不管是APP、小程序或是PC端，亦或是一些非软硬件的营销活动，亦如此。

三大措施：

透明、检视、适应 是支撑每一个经验过程实施的支柱

透明：

就像从【重新定义公司】提到的谷歌的开会模式，过程中的关键环节对于那些产出负责的人必须是显而易见的，所有人都可以看到、听到、感受到这些内容，去引发思考和想象，所有的过程不是某一个人或领导们在参与或主导，而是每个人都在参与，都在未最终结果负责。

检视：

检视则是对过程或阶段性目标或结果的验收和把控，我们不再是安排一个任务，在最终交付的时候做检视，而是把一个大任务或活动切分成了很多细粒度的小因子，相应的目标进度，可以一目了然，这也就要求我们具备一项很重要的技能，对任务或工作的拆分，当前不管是敏捷，还是精益、亦或是PMP、P2，这些优秀的实践，均开始强调这些，既然我们都不是万能的，也都不是十项全能，那么在需要别人协助的时候，把问题拆分，便是解决问题的最好方式。

适应：

适应是我们强调要灵活变通，不要死板，调整工作必须尽快执行如此才能最小化进一步的偏离，甚至于在我们制定计划，执行策略或方案时，对方法论的裁剪，去适应我们具体的场景，也是很关键的，敏捷、精益、P2理论均如是。

四个事件：

包含Sprint 计划会议、每日Scrum 站会、Sprint 评审会议、Sprint 回顾会议

Sprint：

Sprint 是 Scrum的核心，其持续时间一般为一个月或更短的时间，每一个Sprint内构件一个“完成”、可用的潜在可发布的产品增量。Sprint由Sprint 计划会议、每日 Scrum 站会、开发工作、Sprint 评审会议 和 Sprint 回顾会议构成。

每个Sprint都可以被视为一个项目，为期不超过一个月。

Sprint 计划会议

Sprint 中要做的工作在Sprint 计划会议中做计划，这份工作计划是由整个Scrum团队共同协作完成的。Sprint 计划会议是限时的，以一个月的Sprint来说最多8小时为上限，Scrum Master 要确保会议顺利举行，并且每个参会者都理解会议目的，Scrum Master要教导Scrum团队遵守时间盒的规则。

每日Scrum 站会

每日 Scrum 站会是开发团队的一个以 15 分钟为限的事件。每日 Scrum 站会在 Sprint的每一天都举行。在每日 Scrum 站会上，开发团队为接下来的 24 小时的工作制定计划。通过检视上次每日 Scrum 站会以来的工作和预测即将到来的 Sprint 工作来优化团队协作和性能。每日 Scrum 站会在同一时间同一地点举行，以便降低复杂性。

我在做CTO和产品总监时，会要求每个产品研发团队，每天晚上在当天工作结束前的10分钟开始，团队成员在站会前把当日工作进度更新完毕，站会时检视进度，并主要聚焦于问题和经验分享，以及资源协作和次日的工作调整与安排。

Sprint 评审会议

Sprint 评审会议在Sprint快结束时举行，用以检视所交付的产品增量，并按需调整产品待办列表，在Spint 评审会议中，Scrum团队和利益攸关者协同讨论在这次Sprint中所完成的工作，根据完成情况和Sprint 期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化处理。

Sprint回顾会议是Scrum 团队检视自身并创建下一个Sprint改进计划的机会，该会议的目的在于：

（1）检视前一个Sprint 中关于人、关系、过程和工具的情况如何

（2）找出并加以排序做得好的和潜在需要改进的主要方面

（3）制定改进Scrum团队工作方式的计划

我们可以理解为复盘，阶段性的复盘，可以帮我们查漏补缺，同时进行团队协作和工作方式的优化、改进，以此方式不断以阶梯式或螺旋式上升的方式推动产品迭代和团队提升

五大价值观：

承诺、勇气、专注、开放、尊重

团队的构成：

一名产品负责人、开发团队、一名Scrum Master组成。正如现在敏捷、精益大行其道，所有模式的发展正遵循着以项目为中心——以产品为中心——以用户为中心的发展路线，向前推进，有一个产品负责人和Scrum Master来领导的开发团队，会更专注于用户增长和商业价值，开发团队未来的头脑中也应该会多一些用户、商业的理念或认知，不再仅仅只有技术，或编程、代码。

设置我们可以进一步想象，除开发团队外，我们还会有运营团队、售后团队，那么是不是跟增长黑客的理念吻合了呢，所以说大道至简、世界大同，很多新的理念都不是那么高深莫测的，从以前的部门职能团队，到现在的自组织跨职能团队，我们所要达成的是怎么更好的服务客户，怎么更有效的创造商业价值。

产品负责人

未来的工作中，我们会看到更多的职能岗位发展成为负责人，就像产品负责人一样，我们应该担负起一定的职责，而不仅仅是执行完成工作，这么简单

产品负责人是负责管理产品待办列表的唯一负责人，产品待办列表的管理包括：

（1）清晰地表述产品待办列表项

（2）对产品待办列表项进行排序，使其最好地实现目标和使命，即我们所说的迭代次序、优先级

（3）优化开发团队所执行工作的价值

（4）确保产品待办列表对所有人是可见、透明和清晰的，同时显示Scrum团队下一步要做的工作

（5）确保开发团队对产品待办列表项目有足够深的了解

但从现在国内的中小型企业来看，一些公司中高级领导者对产品主导型跨职能团队的理解和认知，还未到一定程度，仍停留在项目管理层级，仍然以项目经理、技术总监来主导产品研发，产品经理只是负责原型设计、需求规格制定的整个产品生命周期的某一个环节工作，但我们可以看到的是华为、阿里、腾讯这些科技巨头，已经开始实践，不管是Scrum，还是DevOps，相信在这些公司的引领下，我们很快能看到一个快速进步的局面。

Scrum Master

在此实践中，我们还看到了一个职位Scrum Master，这个人对于团队来说，是一个服务型领导，主要来促进和支持Scrum，通过他来帮助每个人理解Scrum理论、实践、规则、价值。

从其职责定位上来看，Scrum Master以各种方式服务于产品负责人，包括：

（1）尽可能确保Scrum团队中的每个人都能理解目标、范围和产品域

（2）找到有效管理产品待办列表的技巧

（3）帮助Scrum团队理解为何需要清晰且简明的产品待办列表项

（4）理解在经验主义的环境中的产品规划

（5）确保产品负责人懂得如何安排产品待办列表使其达到最大化价值

（6）按要求或需要引导Scrum事件

当然Scrum Master也要服务于团队、组织，具体的职责可以查看附件中的描述，怎么类比理解两者的关系呢，就好像团长、政委、参谋长三者之间的关系，产品负责人就相当于团长，负责产品的整个生命周期，对目标和具体工作决策和领导，负全部责任，Scrum Master就相当于政委、参谋长，进行理论的宣导和策略的讲解，同时制定具体的作战方针，辅助产品在整个生命周期中各个环境高效、顺利运行。 这样的搭档模式，才能让团队发挥最大效能，产品生命周期更顺畅、高效，独裁或是多人决策，都不是一个好的选择。

推荐工具：

在带团队的时候，对比多TeamBition、WorkTile、腾讯TAPD，觉得都没有跟自身已有BUG Tracker系统、TIM讨论组这种方式结合起来方便好用，也或许是习惯问题，当把内部流程打通之后，最适合自己的反倒是对已有资源的整合，这种成本也最小

最近在接触DevOps，觉得对于开发或产品团队来讲，这是一个很好的工具或理念，非常完美的把整体流程串联了起来，把一些复杂的流程自动化pull了起来，而不是push，不管是Gitee、阿里云效、腾讯TAPD还是华为的DevCloud，我都试用了下，如果从我的角度来看的话，我更喜欢华为的DevCloud，比较灵活，而且是一体成型的，使用操作流程、功能齐全、页面功能清晰可得，项目构建、发布、代码管理、检测等都一应俱全，而且5人内免费使用，对于团队或个人，都适用。

软件开发平台 DevCloud 敏捷开发 DevOps

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。