让交付效率与客户满意度齐飞|医疗IT敏捷案例
2019-12-09
来源：东软卓越效能社区 巩敏杰
题。
另外，使用用户故事，拆分过程也是沟通、理解过程。因为用户提出的问题，往往并不具有单一性，是需要多部门、多业务共同协作才可完成。按照业务线拆分完成之后，我们认为任务的粒度还是太大。所以拆分还在继续，一直到我们认为粒度已经足够清楚的评估出工作量后才算完成。
拆分之后给予开发团队最大的帮助是：可以承诺的更多了。可以承诺给PO需求的完成时间，也可以让PO给用户承诺一个具体的交付时间。不过万事开头难，我们第一次评估的工作与实际工作时间还是有很大差距的。但是正是这第一次的错误评估，为我们以后的工作量评估指明了方向，具有借鉴意义。而我们的开发团队、业务团队也在每一次故事的拆分中，加深了对业务的理解。
问题三、经常出现返工
定义验收标准与完成规则
需求返工是我们在实施敏捷后，发现的一个比较常见的问题。
我们常常认为我们交付的软件是符合客户预期的，但是事实往往并非如此。内部思考，总结后发现问题主要有两方面：需求理解的有误以及开发方向的错误。需求理解方面，我们的客户团队去到用户一线去理解、结合用户使用场景调研。开发方面，在保证客户团队正确的理解了需求的前提下，编写用户故事的同时，在卡片的背面写明了故事完成的验收条件。以结果为导向，保证了开发的正确性。
除了对结果的把控外，我们还增加了过程的规则。在看板的关键列，增加了DOR（Definition Of Ready）和DOD（Definition Of Done）。DOR是准备就绪的定义，比如用户故事进入开发阶段前，一定要满足就绪条件，比如需求澄清，包含验收标准，完成UI/UE设计等。在用户故事完成后，还要符合完成的定义(DOD)才算真的完成。
通过DOR和DOD，有效控制了需求把握不清，故事完成时总会留尾巴、留技术债的问题。此外，由于各个科室不同，如果有的科室有人员有时间，我们还邀请他们帮助测试。
综上，通过多种方式，终于让工作返工现象大幅减少。
问题四、大家互相不了解
团队互相知道做什么很重要。之前团队成员蜷缩在自己的工位内很少沟通，而且也没有沟通机制。结果导致遇到问题都不清楚该向谁求助。另外，由于工作内容不同，有的科室比较忙，有的比较闲，团队力量分布不均。
每日站会
每日站会，是每天早上大家在看板前，开15分钟以内的站会。
每日站会上，大家在说出自己任务的同时，也了解了别人的任务和进度。仪式感外，本身也加强了每个人对于项目的参与感。有了参与感，在别人遇到问题时，是真的可以主动去帮忙解决的。这也正是在项目中真实发生过的。通过早会，也建立了团队内部的斗沟通机制：有问题随时沟通。
回顾会议
回顾会议是敏捷实践的重要一环。通过看板墙的4次重要调整，就足以证明我们的前进的脚步。回顾会议上，将好的与不好的统统说出来。好的坚持，坏的改正。但总体都是帮助团队不断提升能力，提高产品的开发效率。
问题五、客户满意度低
客户满意度低，是多方面问题。提升满意度不是一朝一夕的事，我们首先要很好完成自己的工作。更重要的，是让用户看见我们的努力，参与到我们活动中。所以，我们采用了很多方式，比如不定期让用户参加早会，让用户跟着做优先级排序等。
事实上，客户对于现在这种方式非常满意。院长及信息室主任、科室领导等多次到看板墙前了解情况。团队使用的便利贴、白板等都是客户购买的。
评审会议
评审会议是团队交付之前，一
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
