ITSM_V1.0_敏捷回顾

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

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

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

评论

13 楼 xindeman 2010-12-10  

是不是可以结合你的ITSM_V1.0一个典型实战来具体探讨一下，比如用户让你管理cvs，并能根据各种情况进行预警。在你设计的体系里怎么应对这种变化？

12 楼 fantasy 2010-12-09  

一蓑烟雨任平生说得很有道理。

业务应该敏捷吗？我觉得业务不应该敏捷，好的业务分析师应该能够站在比用户更高的层次来分析业务。那么你必须比用户更懂业务。

如果连业务都不是很熟悉，或者说业务知识没有达到用户的高度，那么必然会产生返工，这个时候拥抱变化也是一种浪费。

用户虽然很懂业务，但是要想将业务转化成产品，用户不擅长，或者说用户也不会考虑很多的附加因素（如引申需求），不懂业务就会跟着用户走，用户今天看到第一个迭代成果，觉得不合适，或者当初没想全面，让你修改，ok，继续迭代下一个版本，那么第一个版本就未产生任何价值造成浪费。

敏捷注重的是不返工，而不是快速返工！

11 楼 一蓑烟雨任平生 2010-12-08  

业务怎么敏捷，我真不知道。

如果在技术上能够让开发组面对变更的时候，对系统的结构性改动不大，可以得到控制，那么我觉得这块就非常厉害了，敏捷现在在这块能够提供一些有益的思路，重点是配置管理上，仅此而已。

对于项目组的业务功能团队来说，拥抱变化就是一场灾难，从这里出去的一点点变化将会被后续的环节逐级放大，所以需求的控制是最重要的。这块没有什么技术手段，完全是靠人的业务经验积累。

一些强势的公司，会将业务不成熟的试错成本转嫁给用户身上，通过合同来保护自己的利益，他们可以拥抱变化，也不怕业务需求怎么去变，但是这样的公司是少数，绝大部分公司是不可能做到这一点的，用户签合同怎样，需求确认签字怎样，要你改你敢不改？也就在喝酒的时候，跟用户诉苦，用户表示理解而已，谁要你不懂业务呢，所以还是老实点吧。

10 楼 一蓑烟雨任平生 2010-12-08  

转换是我们自己内部套用混流生产的说法，总装线上换装另一个产品时所要做的工作。

如果项目组不停的换业务领域，无法达到业务的成熟，会导致业务分析这个环节的成本高居不下，不停的进行试错和修正，后续的开发环节也会不停的变，导致成本仍然降不下来。精益里面的7种浪费，套用在软件开发上，我觉得很大一部分都是由于业务不成熟这个原因造成的。

我一直认为核心环节首先是业务分析，这块越成熟，后续环节就越容易控制成本。

9 楼 一蓑烟雨任平生 2010-12-08  

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

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

8 楼 抛出异常的爱 2010-12-08  

一蓑烟雨任平生 写道

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

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

7 楼 一蓑烟雨任平生 2010-12-07  

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

6 楼 fantasy 2010-12-07  

一蓑烟雨任平生 写道

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

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

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

5 楼 一蓑烟雨任平生 2010-12-07  

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

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

4 楼 fantasy 2010-12-07  

一蓑烟雨任平生 写道

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

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

3 楼 fantasy 2010-12-07  

一蓑烟雨任平生 写道

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

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

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

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

2 楼 一蓑烟雨任平生 2010-12-07  

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

1 楼 一蓑烟雨任平生 2010-12-07  

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

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

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