2019-10-29敏捷推行的最大阻力就是改变管理层的价值观和对问题的认知作者回复: 呵呵，我之前去台湾参加DevOpsDays活动，就给我老板带了一本书做礼物，书的名字是《原来你才是团队绊脚石》，你也可以试试看效果如何哈。
2 5
2019-11-01这篇文章纠正了我一个观念，就是看板不等于可视化板。看板的核心是加快价值流动，以拉动式生产为典型特征，约束制品数量为实践，灵活响应业务变化，快速交付价值。如果用这个标准来衡量敏捷程度，就不容易跑偏了作者回复: 是的，看板没有严格的时间盒的概念，虽然也会按照一定节奏的发布，但其实更理想的情况下就是随时发布，这对于内部平台来说并不是什么难事，你们可以在内部尝试一下😝
3
2019-10-29老师文章中提了站立会，想请问老师，正确的站立会应该如何做？作者回复: 你好，正确的站会我觉得应该有以下几个特征：自组织，暴露问题，反馈行动。自组织是说即便没有团队leader组织站会，大家也能按照既定的节奏来自发的组织站会，所以被动到主动的转变。暴露问题，就是团队敢于在大家面前暴露问题和风险，而不是一味的说明成绩，也就是心里紧张到心里安全的转变。反馈行动，就是站会上发现的问题能够直接影响接下来的行动，快速处理问题，也就是边说了白说到立竿见影的转变。
2
2019-10-29总有插入队列的“紧急需求”；前期没有明确，开发过程中持续掰扯。看到老师可视化流程这个，想起三年前有个领导针对开发团队提出过看板方法，不过富哦随着那个领导短暂的停留，也没继续保持下去。作者回复: 我在团队中也试行过很多实践，看板是自始至终坚持下来的，也的确经历了相当长的过程来养成习惯，但是一旦习惯了这种做法，整个状态的可视化会让你眼前一亮的。另外，我们经常会各种紧急需求打断，说实话一般也很难Say no，但是如果长此以往问题也不会自己好转，所以适当的积累一些数据也是很有必要的。
1
2020-01-09石老师，根据你的经验，一般公司做敏捷转型会普遍存在的通病是什么呢？
假如一个公司说他在做敏捷，我们可以通过问哪几个问题，就可以判断他是不是真的敏捷，做到什么程度，还是只是流于形式？
大家都说自己是在搞敏捷，但我对敏捷这个概念一直很模糊，我所看到的感觉都只是为了敏捷而敏捷，用户故事也只是需求的另一种叫法罢了。
可能看到的一直是假敏捷，所以看不出对技术人员真正的价值在哪里。另外，如果想入门和深入了解敏捷有哪些资料可以参考呢？作者回复: 你好，这个问题有点难倒我了，对于企业敏捷转型来说，很难通过几个数字来衡量敏捷转型的程度，为此我专门咨询了业界的一位我非常认可的敏捷专家（不方便透露姓名），简单总结她的观点如下：
真是有意思的话题，我一时却说不清楚 通常我不会特别注重企业是否真敏捷，重点还是放在帮助企业解决实际问题上面，类似黑猫白猫 不过打着敏捷旗号，行动却处处违背敏捷原则，我认为是最不可取的一种
2019-11-081.精益创业
2.去年从10x了解到精益创业和老板，就开始兴冲冲的想推行精益看板。结果从同事到领导一致否决了。最终也就只有站会推行下来了。事后我也有过思考，为什么推行不下去。首先，一开始看这么做是有维护成本的；其次，其价值并不直观，不具备一定知识背景也不容易看到价值；最后，人们在应对变化往往都会本能的敌对，特别是老领导对年轻下属，语重心长的拒绝有木有。
所以，最好的办法就是在自己可控的小团先推行，拿的价值去说法，这样才是科学高效的方式。想单纯通过自己的嘴皮子说服所有人，除非你是忽悠大师，不然真的挺有难度。作者回复: 哈哈，即便是忽悠大师也很难长久吧，你看，连看板这种渐进式的变革方式都这么困难，就可以理解为什么很多敏捷转型死在半路上了吧。其实，我到认为，在一个小团队里面让任何可视化，不仅是什么价值提升，单纯的只是对于管理团队的进度而言，也有很大的帮助呀，即便你们每天在开站会，那对着一个物理看板，电子看板，大家也不至于空想对吧，所以在我经历过的团队中，看板的起步阶段还是比较顺畅的，最难的就是向前扩展到业务方，要跟他们掰扯限制任务数量，调整优先级上面，研发团队其他还是比较好沟通的。
2019-11-07关于看板，其实我一开始想做到我们的研发平台上的，但是后来想了下，还是不做的好，还是物理结构真实的贴便利贴的更具备仪式感，更有作用，老师您说是不是？作者回复: 没错！仪式感很有必要！人与人的沟通才是最直接有效的，你没看公司里面解决问题最快的方式就跑到他座位旁边吗😝 不过电子看板也是很有必要的，否则数据没法沉淀下来。
2019-10-30关于老师提供的看板例子，“就绪”和“需求”不太理解，感觉只需要“就绪”就够了，为什么会考虑加“需求”这一列呢？
我公司一直在高呼搞敏捷，但是偶觉得最大的坑就是留于形式的敏捷，披着敏捷的皮干着瀑布式项目。例如：需求虽然做着细化，但是还是一个人负责一个模块；一个需求开发完成了，测试人员并不会去测试，而是等到积累到一定程度才会开始测试。敏捷所带来的好处似乎根本没有体会到～作者回复: 简单理解需求就是Backlog，就绪就是待开发，从Backlog进入待开发状态是有门槛的，首先需求拆分要合理，可行性评估通过，跟研发沟通工作量实现等都没问题，说白了万事俱备就等开干。而Backlog里面会有大量的未经分析的需求，甚至很多都是一句话需求，实际上这个需求还可以站在需求分析的角度进行展开，比如需求提出，分析，评估等环节哈。
2019-10-30实践中 站会往往开成三四十分钟的汇报会！作者回复: 每日汇报会很常见，一开始大家也不习惯自组织的形式，我的建议是组织者后退一步，而不是站在中心的位置，约定好每次从不同人开始，尽量控制时间，当然如果有物理看板建议还是围绕在看板旁边，说话的人向前一步，这时候他就是中心哈。
2019-10-29关于最后一张看板图片，有些疑惑：
1、通常需求“就绪”的定义是怎么样的？
我所在的团队对“就绪”的定义是大家对需求达成共识，产品经理的PRD、设计师的交互设计稿准备完成。接下来的工作是开发进行编码/构建，与此同时测试同事进行测试用例/测试脚本编写。
2、多维度的看板
在1的在这种情况下开发和测试时并行的，我们的看板时采用需求-子任务（开发任务、测试任务）的形式展现。一个需求下的多个子任务（比如前端开发、后端开发、测试用例编写）会在同一时间处于一个泳道上。我们可以看到在这个看板上看到每个需求的子任务状态，而需求的状态只能通过手工去做维护，这是比较痛苦的一点。这可能需要通过另一个看板去专门表现需求维度的状态（类似于最后一张图片），这就增加了维护成本了。
最后，希望老师介绍一下常见的看板流的最佳实践，谢谢。展开作者回复: 你好，关于需求就绪的定义，实际上就是DoR的概念，也就是Definition of Done，通俗理解就是类似你说的，万事俱备，只等开发投入就行的状态，但是我想提醒一下的是，需要有明确的验收条件。
第二个问题，需求拆分是比较常见的场景，我没太理解你说需求状态只能手工维护的痛点，实际上如果使用了泳道，每一个泳道就是一个需求，可以把需求卡片贴在最前面用户故事列，然后前端，后端，测试任务放在各自的列中，只有当这些子任务都完成之后，才会连着需求和子任务卡片一起向下流转，其实还是比较清晰的呀。
最后这个问题有点泛泛，不知从何说起，我的理解可以先遵守规则，再寻求发挥，可以先把看板的几项原则执行起来，所谓最佳实践会自然浮现出来的。
2019-10-29其实老师的话题中不觉得在抛出另外一个问题么：敏捷是否真的敏捷？敏捷只是且仅仅是安排的紧凑且快捷而已。软件的目的是产生效率或者说简化人工操作/沟通的量：本质上还是节约人力成本。
就像网银和手机支付其实节约的是许多超市大量的收银员雇佣的成本：为了敏捷而敏捷其实就脱离了本质，其实国内不少企业就用了丰田生产系统的做法融入其中。
其实学这门课的同时在学<全栈工程师修炼指南>：相互融入才能合理。其实敏捷不适合在开发环节，个人觉得适合在运维中，运维经常充分利用任何程序的等待时间去做其它事情。作者回复: 将敏捷注入运维工作正是DevOps之所有诞生的源动力啊，我在公司里面也经常有种感觉，我们在关心流程，关心工具，关心业务，唯独没人关心人的问题，除了要考查人的效率高低之外。敏捷说的再神，说到底还是需要重视人的价值，就像用户故事，如果不让整个团队带入场景之中共创好的解决方案，而只是单纯的宣讲需求分配任务，那么谁还对敏捷感兴趣呢。
2