ITSM_V1.0_敏捷回顾

  最近终于完成ITSM第一版本的研发，耗时2个月，领导要求我们每人写一份总结。附件是我写的，欢迎大家排砖！

  各位是如何做敏捷回顾的呢？各位通过敏捷回顾提高了些什么呢？前段时间和TUTI交流了敏捷开发。聊了很多，受益匪浅！在此共享一下。
 
  我们引入敏捷开发是为了提高什么呢？为什么要引入敏捷开发？我之前总是说要通过持续改进来消除浪费，通过和TUTI的交流，发现这个说法不完全正确。引入敏捷开发应该首先分析价值流程图，从全局中识别出某个环节的瓶颈然后进行优化，才能达到最大产出。比如：我们每天能开发10个功能点，测试只能测试7个功能点，但我们找到一个提高开发效率的方法，每天能开发 100个功能点，那么从系统角度来说，我们提高多少交付能力呢，一个也没有，因为瓶颈不在开发上，而是在测试上。
为什么要优化瓶颈？为了提高产出，减少库存（非瓶颈环节效率高了，反而会加大库存，增加维护成本，这也是精益里所谓的浪费）。
如何找出瓶颈？工作堆积在哪个环节，哪个就是瓶颈。

  所以我觉得对于消除浪费的活动，应该分优先级，先优化瓶颈或先优化影响产出的环节。敏捷回顾也是一样，通过回顾，找出产品开发过程中的瓶颈，争取在下一个版本中提高产出。
 

你看看精益中对现场改善的内容，可能对你们的改善分析有些作用。

你们首先要考虑好需求设计如何快速准确的传递给开发人员，这个要基于问题清单来做分析和改善，其次是代码开发的标准化，这个可以对代码质量有很好的支撑，改善也是基于问题清单，这些跟过程关系不是特别大，是基础，在这些条件满足以后，再去考虑过程怎么改善，但是要基于项目所涉及的业务线来考虑，不同的业务领域的开发过程会有差异。
你的报告里面，业务和基础技术这两块的问题分析，还不够细致，我建议你通过问题清单和计划差异重新做一次分析。

回顾报告中的很多内容是一些沟通的手段的改善，比如QQ和日报、日例会怎么开等等，这些都是形式上的，大了说是为了状态显现化，做好目视管理，不过怎么说呢，这个可以做的很花哨，开始的时候有些新鲜感，时间长了也就那么回事，最后也会流于形式，所以我的意见是这块不用太花心思。

浪费的分析，你也要基于过程、QCD指标来做，这些指标你一个项目是得不到的。
还有一点，个别项目的瓶颈，并不代表着过程的瓶颈，准时化生产的关键是节拍，你们有节拍没有？

非常感谢您的建议。
关于你所说的问题单，这个是由团队的每个成员在生产过程中提出的是吗？收集者是scrum master?

你所说的节拍，是指在两个环节之间是否能够达到同步是吧？A环节的输出能够完全被B环节的输入所消化

你们现在这个情况，bug清单就足够了。

节拍的说明，你一会消除浪费，一会精益的，找本丰田生产方式和现场管理的书看吧。

呵呵，thank you!最近正在看。

做过程改善的时候，要考虑到业务是否能够复用，如果是一次性的开发项目，过程的改善很难落实到位，因为项目转换成本太高了，能够见到成效的是技术平台和开发标准，但是业务无法积累，导致最关键的环节的成本降不下来，这个也要注意，改善要有个基准。

转换成本包括什么呢?
是说业务无法敏捷么?
还是说改善过程代价太大?

我在给另一个帖子《漫谈敏捷开发-从精益到敏捷》的回复中，推荐了几本丰田生产方式的书，要想研究精益，就必须要看大野耐一的那本《丰田生产方式》，那里面把他最初的想法说的很清楚，非常的朴素易懂，书不厚，但却是真经。

敏捷应该有前提条件，让一个没有练过基本的技战术配合、没有良好的后勤保障、球员三天两头换的菜鸟球队去踢顶级球队的战术，外行人都知道是什么结果。但是有些人去可以忽略个人能力、公司能力和行业情况，告诉他们你们可以成功，看有这样的成功案例，每次我看到这样的东西，会非常的厌恶。