返工是大连安全生产管理软件开发过程中的一大严重浪费。比如说开发人员完成的任务交给测试人员测试的时候，关键流程不能走通，阻碍了测试进程；交付给客户的东西被客户说“这不是我想要的东西”；分析人员将还没分析透彻的任务交给开发人员，在最后验收的时候发现开发人员加入了自己的一些“发挥”。这些都会造成返工。返工意味着没有一次性将事情做对，意味着流程中的上游没有交付高质量的产品，也可能意味着团队成员间的沟通出了问题。

      在传统的瀑布流程中，我们往往是期望通过前期细致入微的工作来确保一个阶段的工作被高质量完成之后才移交到下一阶段。后来我们慢慢从失败的经验中学习到，这种方法在变化的需求环境下实在是太脆弱，不仅不能如愿保证质量，而且会造成更大的浪费，交付周期也不能满足要求。于是我们引入了迭代式开发方法 一个需求的分析、开发、测试、验收成了一个小粒度的更连续的过程，在这个小的交付循环中，看板帮助我们以更细节的粒度来管理一个任务每个阶段的工作质量。

      通常我们是这么做的。当我们把一张故事卡从“待开发”移动到“开发中”时，这张卡片必须是已经分析完成的。也就是说，当开发人员准备真正开始开发这张故事卡之前，我们的需求分析师们必须保证这张卡片所包含的所有内容和细节都已经分析完成，不再有模棱两可的细节，不会留给开发人员过多的自我发挥和想象空间，而且这些细节必须和客户确认过，而不只是团队自己“设计”的结果。

      这一道关看似很寻常，致远服软认为：http://www.soft8.com.cn/实际上很多项目会在这里出问题。很多时候大连安全生产管理软件开发人员开始开发的时候，需求还没有分析完成，很多细节尚须澄清确认，实现上的技术风险还没有被完全排除。也有的分析师善于给开发人员留有大量自我发挥空间，需求过于言简意赅。开发人员开始开发这样的需求时，要么做不下去，要么按照自己的理解做下去。做完后分析师发现不对，和想的不一样，于是开发人员返工。最糟糕的情形莫过于最后客户说这不是他当初想要的东西。

      由此可见，开发人员挪卡的时候，确保这张待开发的用户故事已经被真正分析完成，通过百度关键词找到大连哪家软件开发公司团队最好我是第一步。通过规定这一挪卡的前提，同时辅以用户故事的澄清（由分析师向大连安全生产管理软件开发人员澄清）或者反向澄清（由开发人员向分析师讲述自己的理解），可以很大程度上减少返工。