如何通过技术手法避免进度风险

作者/分享人:乔梁
持续交付&DevOps专家,轻敏捷转型顾问,腾讯高级管理顾问、畅游、魅族、平安外聘顾问,映客卷皮墨迹企业教练。“持续交付”和“敏捷”公众号作者。 历年QCon技术大会的讲师和专题出品人,相关内容收集在持续交付中文站 http://www.continuousdelivery.com

上一场 Chat,我们聊过了产品前期的需求管理过程(收集、分析、估算、计划),然而并不是做了计划就完整大吉。本场 Chat 和大家讲一下三方面的内容:

  1. 故事墙的变迁:如果利用“故事墙(看板)”发现常见却不易察觉的“坏味道”。
  2. 单元测试与测试前置:虽然有生产成本,但收益更大。
  3. 主干开发的动机:放弃分支开发的恶习,消除不必要的浪费。

实录提要:

  • 主干开发带来的好处是什么?
  • 为什么不直接把发自测作为“开发”到“测试”的 DoD?
  • 本文是用精益看板的方法在暴露问题、预防风险,有没有其他的好方法?
  • 使用看板的团队如何在茫茫一望无垠的卡片墙中建立更有目标的发布节奏?
  • 对主干做少量修改的时候是不是要特别慎重,万一有人手滑了怎么办?
  • 如何评估重构中的风险和问题,如何让领导接受项目重构项目延期?
已有154人预订
预订达标
文章出炉
交流日期
     
06月16日
06月28日
07月06日 20:30
查看文章评论/提问
何留留
有几个问题请教老师: 1、主干开发带来的好处是什么? 2、测试前移中我们提到“每个需求在进入开发前,写好验收条件,甚至是测试用例。”看板方法让价值处于持续流动状态,在测试列几乎每时每刻都会有故事卡片存在,测试人员肯定首先聚焦在测试列的故事卡片的测试工作上,我们如何保证在需求设计时让测试同学去写还未进入开发需求的测试用例? 3、变化五中是否应该是“开发自测”到“测试”的DoD,而不是“开发”到“开发自测”;为什么我们不直接把发自测作为“开发”到“测试”的DoD? 4、变化四中code review是具体review什么,代码规范、实现方法还是什么,该层面的code review的价值是什么,想解决什么问题? 5、本文是用精益看板的方法在暴露问题,预防风险,乔帮主有没有其他的好方法? 6、请问使用看板的团队如何在茫茫一望无垠的卡片墙中建立更有目标的发布节奏? 7、- -!最近在看乔帮主译的《持续交付》,350多页的书几乎全是文字连个插图都很少,有没有特别推荐的章节,让我们技术小白更快更好的吸收到精华 最周感谢乔帮主解答,O(∩_∩)O哈哈~
糖-影
第四点小标题错了吧,先code review再测试吧?
糖-影: 明白了,代码评审任务优先级高于功能开发
糖-影
乔帮主分享下开发支援测试同事的技巧吧,我这儿不使用"暴力",开发就不帮测试,他们自己内心低视测试,自己也不愿做自测
哈比
Q1:「那些实现上相对简单的需求与相对复杂的需求相比,在设计时间上并没有太大的差异。」请问在发现这个问题后,您做了什么,才发现开发人员共同的习惯行为有问题的?这个方法有运气的成分吗?最关键是问/观察什么,怎么问/观察?
哈比
Q2:「限制在制品数量」策略,很大程度上依靠测试人员的自身能力和自评估的能力。是否会使她趋向于给出留有余地的答复?(因为承诺地超出了自己的能力,或者因为什么事情导致效率没有预想的高,这就意味着要加班,或者耽误了今天团队的工作。)有什么好法子避免这种情况吗?
哈比
Q3:「限制在制品数量」这个策略有没有考虑到测试人员的时间、精力利用度?不可能给到测试人员全天冲刺状态的工作量,那您的最低要求是利用到百分之多少?您认为这位测试人员自己给自己的要求,是利用到百分之多少?这两者的差距,甚至还有第三方视角(整个团队要求她做到的百分比)的差距,如何缩短?
哈比
Q4:「在制品数量」是如何衡量的,如果发现测试人员报出的上限其实可以更多,什么情况下会睁只眼闭只眼,什么情况会要求提高,要求提高的方式需要注意什么?
哈比
Q5:关于 Git,好在你们的设计与其它团队只有一个接口,如果碰见有好几个接口的,估计就不敢直接让所有人直接向主干提交代码了吧 QAQ,请问你们对主干做少量修改的时候是不是要特别慎重,万一有人手滑了怎么办?对那种好几个接口的团队,他们在这个问题上有什么好招咩?
你可能还喜欢
Service Mesh 在华为公有云的实践
田晓亮
利用 OpenCV 和 Caffe,根据大合影构造“平均脸”
李烨
从零开始,搭建 AI 音箱 Alexa 语音服务
Mike
Web 安全恩仇录:再谈逻辑漏洞
肖志华
TensorFlow 分布式原理与应用实践
刘光聪
编程和数学基础不佳如何入门人工智能?
赵宁|Neal
微信扫描登录