看过一篇文章，叫《像机器一样思考》。计算机的处理逻辑很简单，就是：输入--处理--输出。我们在做软件开发时，是跟计算机打交道，所以我们需要学习计算机的处理逻辑。可能会有人说，这个逻辑这么简单，而且计算机也是人造出来的，那我们还需要学习它吗？是的，我们需要学习它，因为造出计算机的人都是天才，计算机的处理逻辑是天才们总结归纳出来的处理逻辑，所以我们需要去学习它。
在软件开发过程中，可以分为两个阶段：第一个阶段是软件需求的提取阶段，把用户的想法提取为软件需求，作为软件开发的输入；第二个阶段是软件产品的实现阶段，把软件需求实现为可工作的软件程序。
怎么保障软件开发的质量？就需要保障这两个阶段的质量，这样就延伸出来两个概念：为DoR（Definition of Ready）和DoD（Definition of Done）。每个团队都需要建立起自己的DoR和DoD。
作为敏捷教练，怎么引导团队建立DoR？
1、发起会议，明确会议目标，明确会议时间盒（45分钟）
组织相关人参加会议，参会人员包含开发团队和产品负责人。明确会议目标，需要在敏捷开发活动中建立一个DoR，不要求今天达到完美，但是要有一些基本的条目要求。
2、展现当前由于没有DoR引起的一些问题
举例说明当前的一些需求反复沟通、迭代计划会时间不够、开发团队和产品负责人各执一词、沟通效率不高的现象，让大家就这些现象挖掘根本原因。根本原因在于我们对需求的理解不一致。怎么能够减少不一致，尽快就需求达成共识？
3、引导大家认知到，我们的需求需要有一个标准
从为什么出发？我们为什么需要有DoR标准，是为了解决我们上面提到的问题。人和人是不一样的，大家的技能水平、大家的背景经历、大家所了解的信息都是不同的，所以对同样的需求的理解也会不一致。怎么提高达成一致的效率？我们需要对需求有一个基本的标准，帮助大家尽快达成一致。
4、引导大家输出第一版DoR
举行头脑风暴，让大家提出对需求的要求，用报事贴贴在白板上，然后进行归纳分类；分类之后进行澄清，确保大家能够理解每个分类要求；对于不能理解，或者还不够明确的，可以暂时搁置；理解清楚之后，大家进行投票选择我们的第一版DoR。
5、这只是开始，重申敏捷价值观，我们一直在寻找更好的软件开发方法，所以第一版DoR不是固定不变的，在需要的时候，我们会更新DoR。
在我们日常生活中，一件事情，怎么样才是完成？比如小孩子吃饭，什么叫吃完了？是他把碗里的饭都吃掉了叫吃完，还是他觉得吃饱了才叫吃完？从父母的角度，一般会认为把碗里的饭菜都吃掉了，就叫吃完，因为人每天吃饭，可以要求每顿饭都定时定量，有变化也是缓慢的，不是突变的。如果是按小孩自己觉得吃饱了，遇到爱吃的可能就会吃的多些，遇到不爱吃的，吃两口就会说吃饱了。这样的话，小孩要么成为大胖子，要么营养不良。
那么，我们在软件开发活动中，什么叫做完成呢？当我们定义好输入（DoR）之后，我们的输出（DoD）哟啊不要定义呢？要的。DoD和DoR一样重要。如果我们给计算机一个输入（1+1），得不到确定的输出（2）的时候，我们不会为这个计算机买单。同样的，客户得不到他想要的输出，他也不会会产品买单。
在现实中，经常会有开发团队认为代码写完了就是完成了。所以在引导团队建立DoD时，产品负责人的认知需要先提升上来。
那怎么引导团队建立DoD？
1、明确会议目标，确定会议时间盒（45分钟）
参会人包含产品负责人和开发团队参加，邀请大家一起来建立团队的DoD。
2、拿数据说话，展示团队的产出、和当前用户故事的可视化状态
3、重申敏捷原则：可工作的软件是首要的进度度量
产品负责人和开发团队需要在这里达成共识，只有大家认同敏捷原则，我们才能建立DoD。如果不认同，则无法建立DoD。
4、引导建立用户故事完成标准，迭代完成标准
DoD的建立可以分层，分为用户故事和迭代，根据团队的当前情况，对于不同层级有不同的标准。最终可以引导团队把各个层级的完成标准合一。
5、DoD不是一层不变的，随着团队的进展，标准也会跟着更新。
网友评论