敏捷的潘多拉魔盒

今天我给大家带来了一些关于敏捷方面的分享，也希望大家能有所收获。由于疫情我被困在了家中，所以在此我插播一个广告，非常感谢敏捷家及网易杭研组织这次课程，同时也感谢Bob老师以及在场的各位小伙伴。

乌卡时代的魔盒

潘多拉打开了魔盒

敏捷魔盒中的这些冰与火

敏捷魔盒中的最后的希望

VUCA时代的魔盒

潘多拉打开了魔盒

首先是团队规模，从个人到团队再到大型的组织。

其次我们要改善的方向的维度，例如质量、效率和价值。通过大伞我们可以看到各种不同的方法实践和策略的运行场景，一个个人层面的质量问题，可以通过极限编程XP来解决，或者说团队效率方面，可以通过Scrum或精益看板去解决它。

同时值得关注的两个点，也可以看到是在价值方面，可能往往去忽略掉水晶Crystal或DSDM方法。这说到大型组织的一种质量策略，它这里写的是TNBI其实就是需要我们持续去寻找更好的一种解决方法来提升大型组织中的质量。也许大型组织中质量的提升是需要运用精益理念中，让团队和个人做到一种自工程完结，或者说是内建质量的一个过程。通过团队和个人的质量的提升，来最终达到大型组织的一个质量的提升。

敏捷魔盒中的冰与火

速度和价值是同一回事，真的是快了吗？我们就得到这种价值了吗？在我做团队培训的时候，往往会说Less is More，少即是多，不要去玩命的去制造那些用户不想要的功能，只有那些能真正打开用户钱包的功能才是要交付的。

敏捷方法要比瀑布方法好，但是敏捷不是什么灵丹妙药，不是只要敏捷了就变得无敌了。其实敏捷有时候并不如意，有时候瀑布的模式也可能是一个最好的选择。

敏捷表明稳定性降低，灵活性增加。虽然灵活性对于敏捷来说很重要，但不等于要交出次品，往往在实施敏捷的过程中，例如在DOD的定义当中，去忽略到一些技术卓越性的条目，导致了产品是一种次品上市，或者说带伤上市，或者说是带有技术债的功能就上市了。我会在后面的话题关于DOD的这块给大家用一个例子去讲解。

敏捷等于Scrum，大家如果是敏捷圈的人就明白，敏捷其实还包含了很多的实践，Scrum只是敏捷实践中的一个。

敏捷就像大爆炸一样，立刻就可以替代一切。但是其实像开始说工业范式一样，我们是一直在复制粘贴它，敏捷也一样，不可能去照搬，只能去寻找最佳的方式。同时敏捷的道路其实是一个变革的道路，它是一个非常漫长的，就像在面对疫情的过程，我们心理上其实都是经历过三个阶段的改变的——否认、接受、适应，这个过程是一个很艰苦的战斗过程，所以敏捷的变革道路也是这样的。想想我们在疫情刚开始的时候，每个人都被困在家中，我的孩子非常小，刚一岁半的时候，他每天都想着出去玩，然后我不可能老是带他下楼，因为担心他的身体健康，所以他被憋在家中很难受，但是人其实都可以慢慢去接受和适应的，我看到随着时间的推移，很多的人在朋友圈晒厨艺，晒生活，晒在家办公的状态，这时候大家就慢慢的接受了在家办公的状态和疫情带来的影响。最后其实是不是也有的小伙伴已经适应了或者习惯了在家办公的一个环境。我跟Bob聊天的时候，Bob老师就说他已经习惯了这个状态了，其实对他的影响并不大，他觉得还挺开心的。其实这就是敏捷变革的过程给我们的一些改变， 要从否认、接受到适应。

敏捷意味着没有计划，没有文档。说到文档这个事，我来说第二个故事，记得当时我们公司刚开始转型敏捷的时候，我和一个开发同学的一段聊天，我当时就问他你在最近在忙什么？因为我看他特别忙，他说“别提了,自从有了敏捷，我现在快成了产品加设计加开发的全栈了。现在我在做后天要评审的交互设计的程序设计”。这时候我就想交互设计都没出来，你怎么去做程序设计，我就继续问他：“你知道交互设计是什么样吗？”他的回答是什么？“领导说了敏捷就是要快，省去文档，所以你可以先做一些设计，等交互出来了，这些设计应该跟你的程序设计，因为你们俩一碰应该差不多”。当时我的脑海里就觉得各种的不知所谓，其实PPT中写的东西基本上都可以用敏捷的神话来表述。

我们使用了Scrum，但不在Sprint设置时间。

我们使用Scrum，我们在Sprint计划中去设置Sprint的时间，如果没有一个时间盒或者说时间是随时设置的，不是一个稳定的状态，团队很难找到这种节奏，同时这样的话会影响效率，往往会落入原来那种瀑布式的模式。记得我的公司开始实施Scrum的时候，我的团队当时由于需求非常多，想快速交付，所以运用了Scrum，但是Scrum来了以后，在最开始的时候，产品经理只能去把这些大的一个需求去拆成几个阶段性的一个步骤去交付，分阶段交付，其实就有点像在瀑布模式下的一种里程碑，他并没有形成这种Sprint的一个持续交付的状态。这时候团队状态其实还是在原有的工作模式下，大家都是在加班赶工去交付这些输出或者功能。但是Scrum其实不是一个范围或者功能驱动的一个框架，它是一个目标驱动的框架。我在后面关于Sprint Goal的时候，我会讲述一下Sprint目标应该是更关注于结果的，而不是一个关注于产出的一种状态。如果关注产出，员工就会不停的去忙碌着，大家也不知道目标是什么。当时我的团队因为前端开发的工作量很大，前端5个同学，基本上每天都是凌晨2点才下班，第二天早上10点到公司工作。到时候我们发现了在第一个阶段交付的时候，交付质量当然是相当差的，因为其实大家在那种强度下的工作已经成为了一个机器，但是软件工作其实是一个创造性的一个工作，不可能是通过简单的敲代码就能完成的。

我们在使用Scrum，但是我们不让产品待办事项逐渐的演进。

我们使用Scrum，但不在Sprint中去做回顾会议。如果产品不去做演进、团队不做回顾会议，也许是因为这些做起来真的可能比较费劲，但是我们失去了什么？失去了对产品和团队工作的持续改善和提升的机会。为什么说是可能说是产品演进比较费劲，或者是回顾会议比较费劲呢？因为在我实际指导的很多团队中，产品经理尤其是初期产品经理转过来的时候，他们还是习惯于完整的把需求收集过来，做一个完整的规划，成为一个产品的概要，这时候他们的需求清单其实已经在那了，他们没有时间或者说并不愿意去调整他们的Backlog的优先级或者说一些条目。这个时候其实他们的工作模式还是在旧的瀑布模式下，而且他们也不知道怎么去改变，因为可能每个Sprint目标就是一个为了产出多少个功能的一个Sprint，在Review和回顾的时候，并不能得到很多的客户的Feedback，所以也没法去调整去演进产品代办事项。

首先它是要把工作可视化。

第二就是WIP限制。

第三它是一个拉动，而不是一个推动的系统。

魔盒中最后的希望

我们的Sprint目标应该是访问整个网站的流量增加10%。

用户在停留在我们的网页至少15分钟。

我们的目标是增加10%的付费用户。

我们的用户在浏览我们网页5秒钟后的下降率降低到15%。

第一个问题就是 当前产品业务状况如何，上次Sprint评审会得到的客户反馈是什么？ 想一下，如果评审会的时候仅只是展示或演示功能，而没有一个Sprint的目标，或者先前的Sprint完成的时候，只是根据的Spring代办事项定的目标的话，很难去获得客户的反馈。

第二个问题我们需要问， 我们希望在 Sprint中影响的最重要的结果驱动指标是什么？ 有了这个结果指标，才能更好的运行Sprint计划会议。

第三个问题， 我们希望完成 Sprint ，通过产品改变的客户行为是什么 ？就我而言，我更喜欢在Sprint计划会议的一开始，首先去设定Sprint的目标，这时候产品负责人和开发团队就有了一个目标，然后他们就可以一起合作，从产品待办事项里头故事中选择符合目标的故事，放入到Sprint待办事项，这将使此Sprint成为一个结果驱动的Sprint，而不是一个输出或代办事项驱动的一个Sprint。同时在一个Sprint中，也不应该设置多个Sprint目标，应该只有一个。如果设置了多个Sprint目标的话，往往团队会陷入没有重点的混乱状态，会再次恢复到功能工厂的心态。

愿景是要在这种不可预测的状态下，需要更好的去使用愿景，使命去催生力量，去塑造环境。能预见未来才能创造未来，赶不上变化就不能塑造变化。

就像庄子说的一句话，井蛙不可语于海 夏虫不可语于冰。为了跟上这个时代，要突破原来思维框架的这些束缚，不断提升自己的知识模式和心智模式。

勇气就像框架中的价值观的勇气一样，我们需要勇气，变化意味着一种选择，选择的时候是需要很多的勇气的，不要让摸着石头过河的思路成为了我们不加思考，不做担当，不去选择的借口。所以勇气和选择在这个时代是非常重要的。

最后就是适应，物竞天择，适者生存。从个体的角度而言，需要我们从被动的适应到主动的塑造，乌卡时代我们要做一个士者，士者就是要整合所有的资源、知识、框架和体系，为组织去创造带来更多的价值，让我们与时俱进，让我们在这个时代中酣畅淋漓的发挥作用，让我们在敏捷的道路上更顺风顺水。

内容来源：敏捷+社区线上直播008期，《敏捷的潘多拉魔盒》分享实录

分享者：李聃

软件开发 游戏

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