• David Mao
    2019-01-01
    职场新人估计都会遇到文中所描述的场景,上下级没有做好DoD的沟通,其实这是上下级都需要的职场素养。
    1.上级交代任务时把完成的指标和工作的边界讲清楚,下级根据要求去做。
    2.反过来,下级应不断提高技能,能自己定义DoD, 请上级check, 毕竟上级不希望每次沟通都占用较多时间。
    
     26
  • 雍
    2018-12-31
    公司有各种checklist,类似于DoD,举例开发过程自检就有41项,开发人员真要check完,至少要花半天时间,大多时候开发都是复制以前的,然后“偷得浮生半日闲”了,项目组成员一多,全部复核一遍基本不可能,如何确定真正落实checklist就成个问题了,老师有没有什么好的建议?

    作者回复: 我很好奇,四十多项都检查什么,是否可以分享一下?

     2
     13
  • Alexdown
    2018-12-31
    写的太好了,谢谢老师帮我捋清头脑中模糊不清的东西

    前面那两个故事简直就是我和领导之间的情景再现,我的“完成”——实现功能,通过单元测试,他的“完成”——响应时间,系统吞吐,部署上线。

    当你问他他的“完成”定义标准时,在得到解答后还会得到一个“这还用说的那么细吗,这不都应该知道的吗”排斥感,很反感这种感觉,每次问点啥后都有被鄙视被diss的感觉,不知该如何处理
     1
     8
  • Monday
    2018-12-31
    正在立2019的flag。刚好可以使用DoD
    
     4
  • Demi
    2018-12-31
    我们在工作中,都不会去写单元测试,认为那是测试人员的事。也没有时间去写,写功能代码就已经要加班加点了。可能也是因为懒,公司没有强制写,只要代码能跑通,没有很大的BUG,就可以上线。我不知道其他公司是不是这样。我做Android开发3年了,待过两家公司。第一家创业干了四个月,公司倒闭了。然后目前这家公司呆了两年多了。老师您这么一分析,我得提高下职业素养了。
     2
     4
  • 北天魔狼
    2018-12-31
    偶像,醒醐灌顶啊。一开始就要确定完成的定义。

    编辑回复: 😊加油!

    
     3
  • 喜悦
    2019-01-02
    今日概念:
    1. DoD(Definition of Done):DoD是一种思维模式,是一种尽可能消除不确定性,达成共识的方式;
        - DoD 是一个清单,清单是由一个个检查项组成的,用来检查我们的工作完成情况;
        - DoD 的检查项应该是实际可检查的;
        - DoD 是团队成员间彼此汇报的一种机制;
    2. 任务开发只有两种状态:完成/未完成;

    今日总结:
    1. 使用DoD可以事先将需要做的事量化;
    2. 一件事用了DoD之后,就确定了需要完成的具体事项,不会觉得自己有很多时间,提高效率;
    3. 使用不同“粒度”定义DoD有助于换位思考,也可以加深对系统的理解;

    使用DoD的例子
    1. 做计划,比如制定年度计划;
    展开
    
     2
  • pyhhou
    2018-12-31
    老师想请教一下,现在我在一家小公司里工作,人很少,没有项目经理,直接听老板讲需求,老板不怎么懂技术,没有什么技术基础,对一个项目需要的时间以及技术流程不太清晰,加上我也是刚从学校里出来可以说没啥经验,他问我多久能完成我也是迷迷糊糊的给不出一个大概的时间,老板需求也会时常变化即便是经常开会说想法讨论方案,没有严格的DoD,可能就像您说的完成功能代码就算完成,因此我们的产品老是出问题,想请问下在这种环境下如何更好的使用DoD呢,或者说是更好的提升工作效率,和上级沟通呢?是不是只要是时间足够就尽量把自己的DoD定严一些,或者是根据时间来定DoD?谢谢老师

    作者回复: 遇到一个不懂技术的老板是一件让人头疼的事。你可能需要拉着老板一起坐下来,先分析问题在哪里,再来谈如何改进。后面会讲到复盘与回顾,到时候,你可以尝试一下。

    
     2
  • 春之绿野
    2019-05-02
    之前做过一个任务是测试artifactory 的性能,并发上载下载100个时的表现,然后我测了,等到周末review 的时候我们组架构师说你怎么只测了100个,0到100间其他的数字呢?我说plan 的时候也没有要求啊,架构师说你自己不会举一反三吗?其实那次不光没有dod ,需求澄清也有没弄清楚“终”是什么。现在回过头来看发现我们的工作做的都好不专业啊。不过后来我们有了ac,就是accept criterion ,也是检查项,不然真是扯不清楚。

    作者回复: 这不是DoD,是验收条件。

    
     1
  • 谷径
    2019-03-27
    在做任何事之前,先定义完成的标准。很好的总结。
    
     1
  • 小伟
    2019-03-22
    在做任何事情之前,制定“可量化”的标准。
    
     1
  • helloworld
    2019-02-15
    定义好完成的程度,就是明确了目标!
    
     1
  • 彩色的沙漠
    2019-01-02
    Dod,做任何事情之前,先定义完成的标准。目前工作中有一项使用了Dod,提测标准:开发人员提测之前,要自测通过测试人员针对本次开发梳理出来的自测的case,测试人员也以这个自测case作为检查项,达不到提测标准的退回,开发人员重新测试。
    作为已经工作了四年的开发人员来说,对于完成还是停留在功能代码写完,令人汗颜,说实在的自己也不会写单元测试和集成也没有去了解过,造成改完代码覆盖测试的成本极大,今年需要弥补单元测试和集成测试自己自动化测试的短板。
    
     1
  • xiaoqcn
    2020-01-14
    完全是教程序员怎么处理各种异常
    不合格的项目经理
    不合格的产品经理
    。。。
    当然,我们也有可能是不合格的程序员

    何况,即使都合格还有意外
    展开
    
    
  • 张亚运
    2019-12-25
    可落地,可量化,可追溯
    
    
  • A^Lee
    2019-12-19
    我理解的DoD是一种思考工具,它可以帮助我们从结果上也就是从输出上消除人与人之间的理解偏差。做事之前先明确终点,这样才能让事情完美对接起来,让需求方满意,避免让工作白做。在现实工作中我确实遇到过几次文中提到过的情况,今天学习了DoD,我认为我以后可以很好的避免这种糟心事的发生了
    
    
  • 小马
    2019-12-11
    DOD,实践起来总是困难重重的!
    
    
  • 业哥
    2019-11-18
    老师,您好,最近买了这个专栏,看到这篇文章时有个问题想请教下:最近在公司实践的OKR中的KR(关键路径),和DoD好像说的都是完成的定义,这两者有什么不同呢?

    作者回复: 首先,KR是关键结果(Key Result)。关键结果不一定要做到,但DoD则是必须要做到。二者不是一个领域的内容,放到一起类比,多少还是有些牵强。

    
    
  • 丁丁历险记
    2019-10-30
    笔记:

    dod 明确终点。提前确定好,容易歧义的地方,同步理解。
    1 dod 确定, 消除理解的鸿沟。
    2 团队dod
       迭代dod 发布dod
    3 放开思维。协作中确定dod

    个人思考
    1 根据香龙第一定律,消除不确定性,需要用更多的有效信息消除。
    再者 越后发现问题,成本越大。
    2 dod 的弊端,过度dod 就是官僚化,仔细想想,哪个政府机构不是dod 高手,会让你服气。
    3 多用约定来消除不确定性,基数排序为啥快 ,go 语言为啥 function 都简化到func 了。 i:=1 自动设为int 了。restful 接口等
    展开
    
    
  • 辰九
    2019-10-25
    沟通达成一致,非常重要,否则都是做无用功。
    
    
我们在线,来聊聊吧