漫谈敏捷开发-精益和敏捷

聊聊软件开发
软件开发是一种非零和博弈，意思是某一方的获得不是建立在另一方的损失之上（赌 博就是一种零和博弈，获得和失去的总和等于零），所以软件开发必须实现双赢，帮助客户成功的同时帮助自己成功。如：通过软件帮助客户把手上的5块钱变成50块钱，然后从客户那里拿5块钱。通过软件帮助客户节约50块钱，然后从客户那里拿5块钱。

从精益说起
敏捷开发和丰田的精益思想颇有相似之处。传统的汽车制造是以计划驱动，如根据往年的经验判断今年应该生产多少汽车，但是这样带来的问题是有可能等汽车生产出来，市场已经不需要了，而这就是一种极大的浪费。精益思想是以价值为驱动的方法论，精益思想的核心是消除浪费，它认为不为客户创造价值的活动和尽管是创造价值的活动，但是所消耗的资源超多了“绝对最小”（投入产出比低）都视为浪费。浪费有七种：过量生产（生产多于所需），库存（不直接产生价值，并增加管理成本），搬运，返工，过程不当（对最终产品不能增加价值的活动），多余动作（任何不增加价值的设备和人员的动作），等待（两个关联的要素间，未能同步）。

再谈敏捷开发
敏捷开发的核心就是消除浪费。那么在软件开发当中应该如何消除浪费呢？

• 过量生产：在我们开发的产品当中，如果需求（用户故事）不是把握的很好，那么就会造成很大一部分功能用户从来都不会使用，这就是生产多于所需。所以我们需要用户和业务分析师（BA）或者需求分析师一起来规避过量生产。
• 库存：在我们的软件开发过程中，如果一直处于开发中，那么产品未给客户带来直接的价值，这就是一种库存。所以我们可以通过迭代开发和快速交付来减少库存。
• 返工：这个在软件开发当作比较常见，可能是对需求理解不透彻，开发出来的功能，不是客户所想的，导致返工。也有可能是当初的设计不合理，不能满足客户的新需求，导致返工。也有可能是开发人员不注意编码质量，导致代码的坏味道越来越重，最终导致代码无法修改，导致返工，我曾经遇到一个核心类有几千行，无人敢动。所以我们需要BA来规避需求风险，需要架构师来规避设计风险，需要好的基础和习惯来提高软件质量。
• 过程不当：我觉得这个主要体现在沟通方面。比如我和某同学讲述一个需求，如果别人不用心听，那么信息就不会有效的传递给他，或者是我表达的是A，而他听到的是B。所以在沟通的过程中一定要通过消除沟通壁垒来消除浪费，在表述者和聆听着之间存在两道沟通壁垒，减少第一个壁垒，表述者应该尽量站在聆听者的知识背景上去清楚的表达内容。减少第二个壁垒，聆听者应该怀着一个开放的心态，去用心的接收表述者传达的信息，不要在没完全听明白表述者传达的信息之前，就用惯性思维去抵触信息的传递。另外一点，我提倡定期沟通，而不是时时沟通，定期沟通是消除信息传递不畅导致的浪费，不提倡时时沟通，是为了减少开发人员的任务切换，从而提高效率。
• 等待：这个可能是不同模块之间的依赖和接口的联调需要等待，所以这个可以通过合理的计划来减少等待。也有可能是测试和研发的资源和计划不对称，导致开发的时候，测试闲置，开发完之后，测试资源不足。这个可以通过迭代开发持续交付的方式，来提高测试资源的利用。
• 多余动作，我觉得主要体现在重复开发。比如每个模块可能都会开发上传组件，分页组件和验证组件，可能都会调界面样式，可能花时间解决一个重复的问题。所以要减少多余动作造成的浪费，我觉得应该加强团队沟通，有专门的人负责公共组件的开发和复杂问题的解决。

我很喜欢这幅图片，我把它称为“举重若轻”，对于软件开发而言，它是一项非常复杂非常重的活动，那么如何能够举重若轻呢?我觉得应该采取敏捷的方式，将软件开发活动细化为一个一个非常轻的活动（迭代），那么我们就能做到举重若轻了。

SCRUM
SCRUM是一套敏捷开发的框架，说的是在进行一次敏捷开发的过程中，所需要参与的角色，进行的活动和输出的产物。
角色有三个：

• 团队负责人：作为客户代表，确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品ROI负责。没有BA的情况下，可以充当BA的角色，来规避因需求问题导致过量生产和返工所产生的浪费。
• SCRUM MASTER：主要负责消除团队障碍。我觉得他可以负责开发公共组件，解决复杂问题来规避多余动作。通过制定沟通机制，开发流程规避过程不当造成的浪费。通过协调开发计划，来规避等待所造成的浪费。
• 团队：一个完成的软件开发团队应该包括销售，售前，用户，研发，测试，售后等所有相关人员，因为任何几个角色都有可能导致软件开发的失败。对于团队而言最重要的是加强沟通，使信息能够准确的传递给团队的每一个人。

其他的不一一细说了，我认为SCRUM的核心是通过敏捷回顾来持续改进，从而消除浪费。因为在软件开发中遇到的小问题非常多，从而造成大量的浪费，所以必须通过敏捷回顾，不断的总结团队做得好的习惯和遇到的问题，在下一个迭代的开发中的解决这些问题。

XP
XP是实现敏捷开发的一些非常好的实践。

• 用户故事：是站在用户的角度和应用场景下来描述业务需求。格式为作为..我能..以便于..如作为网络管理员，我能查实时的查看每个设备的CPU利用率，以便于我能即时发现有问题的设备。
• TDD：狭义的测试驱动开发，是通过先写测试代码再写程序代码的方式，来理清编码思路和写有效的代码，之所以说有效的代码，是因为有时候写的方法，你会发现从来没有任何其他的方法会调用它，如多余的修改器（setter）和访问器（getter）。我强烈建议业务服务层代码使用TDD进行开发。进行TDD时很重要的一点是你要会使用IDE的部分快捷键，让代码自动生成。
• 持续集成：通过自动化构建工具（cc），持续集成版本，从而可以快速的反馈集成问题。
• 结对编程：两个程序员用一个电脑进行编程，一个人负责编码，另一个人负责思考，在编写之前需要和结对的同学表述自己的编程思路，从而将每一个程序员的优秀习惯传播给整个团队，但是遗憾的是结对编程对程序员的要求比较高，最好是两个程序员有一定的能力，并且能力差不多，如果一个能力很高的程序员和一个能力低的程序员结对可能效率很低。

最后推荐书籍：

• 《丰田汽车案例-精益制造的14项管理原则》
• 《硝烟中的Scrum和XP》

推荐博客：

• http://yizhituzei.blogbus.com 一只土贼的博客博客波波客

评论

34 楼 fantasy 2010-12-08  

kiol 写道

fantasy 写道

推荐书籍：
•《丰田汽车案例-精益制造的14项管理原则》
•《硝烟中的Scrum和XP》

推荐博客：
•http://yizhituzei.blogbus.com 一只土贼的博客博客波波客

关于敏捷，大家有什么推荐的书或者博文吗？

有人提到了:《敏捷软件开发工具－－精益开发方法》
我还常推荐的是<解析极限编程>

BTW:不太认同敏捷源于精益.精益虽然确实早于敏捷,但是最早提出敏捷方法的人,例如kent back没有说过是来自于精益.后来有人发现敏捷是符合精益的思想的,就写了《敏捷软件开发工具－－精益开发方法》.

你说很正确，我已经修改过来，敏捷不源于精益。

33 楼 fantasy 2010-12-08  

http4j 写道

fantasy 写道

http4j 写道

抛出异常的爱 写道

tuti 写道

抛出异常的爱 写道

tuti 写道

我们团队现在需要跨时区，就把站立会议，改为日报。
效果还可以。

呸.....
刚刚取消了日报...

这个例子说明，基于具体实践活动的取舍，往往是南橘北枳。
重要的是要基于全局和全流程的分析，找到问题点和瓶颈环节，再来谈需要提高什么，以及如何提高。

需要看的东西太多了.
buglist
tasklist
wiki
email列表
todolist
进度燃尽图

+N张日报...谁有这种闲的时间去check这些事

异常你们是不是没有一个好的敏捷工具啊？试试付费的VersionOne？
工欲善其事必先利其器啊。

我们目前使用的是mingle，对于VersionOne的功能，我们评估过，可以用mingle定制出来。
mingle是一个可定制的项目管理软件。

mingle是thoughtworks的产品吧？应该也是收费的。

是收费的（5个以下用户是免费的），但是打完折和VersionOne价格差不多。
目前我们在用变通的方式来先试用一下，按角色建用户，如管理员，测试，研发，BA。

32 楼 http4j 2010-12-08  

fantasy 写道

http4j 写道

抛出异常的爱 写道

tuti 写道

抛出异常的爱 写道

tuti 写道

我们团队现在需要跨时区，就把站立会议，改为日报。
效果还可以。

呸.....
刚刚取消了日报...

这个例子说明，基于具体实践活动的取舍，往往是南橘北枳。
重要的是要基于全局和全流程的分析，找到问题点和瓶颈环节，再来谈需要提高什么，以及如何提高。

需要看的东西太多了.
buglist
tasklist
wiki
email列表
todolist
进度燃尽图

+N张日报...谁有这种闲的时间去check这些事

异常你们是不是没有一个好的敏捷工具啊？试试付费的VersionOne？
工欲善其事必先利其器啊。

我们目前使用的是mingle，对于VersionOne的功能，我们评估过，可以用mingle定制出来。
mingle是一个可定制的项目管理软件。

mingle是thoughtworks的产品吧？应该也是收费的。

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

那本案例的书也放到一边，先不用看。

30 楼 fantasy 2010-12-07  

http4j 写道

抛出异常的爱 写道

tuti 写道

抛出异常的爱 写道

tuti 写道

我们团队现在需要跨时区，就把站立会议，改为日报。
效果还可以。

呸.....
刚刚取消了日报...

这个例子说明，基于具体实践活动的取舍，往往是南橘北枳。
重要的是要基于全局和全流程的分析，找到问题点和瓶颈环节，再来谈需要提高什么，以及如何提高。

需要看的东西太多了.
buglist
tasklist
wiki
email列表
todolist
进度燃尽图

+N张日报...谁有这种闲的时间去check这些事

异常你们是不是没有一个好的敏捷工具啊？试试付费的VersionOne？
工欲善其事必先利其器啊。

我们目前使用的是mingle，对于VersionOne的功能，我们评估过，可以用mingle定制出来。
mingle是一个可定制的项目管理软件。

29 楼 fantasy 2010-12-07  

一蓑烟雨任平生 写道

如果你想好好研究精益，那么建议先把你现在说的这几本书扔掉，毫无价值。特别是那本《敏捷软件开发工具－－精益开发方法》，基本上是胡说八道。

我先给你推荐一本书，大野耐一的《丰田生产方式》，现场管理的书，大野耐一也有本，《大野耐一的现场管理》，有2个版本。大野耐一的书不看，就不要说精益。

还有2本书比较通俗，值得推荐，《图解丰田生产方式》、《图解丰田现场管理方式》。

好的，非常感谢你的推荐，我目前在看这本《丰田汽车案例-精益制造的14项管理原则》。

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

如果你想好好研究精益，那么建议先把你现在说的这几本书扔掉，毫无价值。特别是那本《敏捷软件开发工具－－精益开发方法》，基本上是胡说八道。

我先给你推荐一本书，大野耐一的《丰田生产方式》，现场管理的书，大野耐一也有本，《大野耐一的现场管理》，有2个版本。大野耐一的书不看，就不要说精益。

还有2本书比较通俗，值得推荐，《图解丰田生产方式》、《图解丰田现场管理方式》。

27 楼 抛出异常的爱 2010-12-07  

http4j 写道

抛出异常的爱 写道

tuti 写道

抛出异常的爱 写道

tuti 写道

我们团队现在需要跨时区，就把站立会议，改为日报。
效果还可以。

呸.....
刚刚取消了日报...

这个例子说明，基于具体实践活动的取舍，往往是南橘北枳。
重要的是要基于全局和全流程的分析，找到问题点和瓶颈环节，再来谈需要提高什么，以及如何提高。

需要看的东西太多了.
buglist
tasklist
wiki
email列表
todolist
进度燃尽图

+N张日报...谁有这种闲的时间去check这些事

异常你们是不是没有一个好的敏捷工具啊？试试付费的VersionOne？
工欲善其事必先利其器啊。

.....还要学习新工具太头痛了.

26 楼 http4j 2010-12-07  

抛出异常的爱 写道

tuti 写道

抛出异常的爱 写道

tuti 写道

我们团队现在需要跨时区，就把站立会议，改为日报。
效果还可以。

呸.....
刚刚取消了日报...

这个例子说明，基于具体实践活动的取舍，往往是南橘北枳。
重要的是要基于全局和全流程的分析，找到问题点和瓶颈环节，再来谈需要提高什么，以及如何提高。

需要看的东西太多了.
buglist
tasklist
wiki
email列表
todolist
进度燃尽图

+N张日报...谁有这种闲的时间去check这些事

异常你们是不是没有一个好的敏捷工具啊？试试付费的VersionOne？
工欲善其事必先利其器啊。

25 楼 fantasy 2010-12-07  

aws 写道

日报没啥意义，浪费时间，都是糊弄

周五下午花半天review一周进度和风险情况更有意义些

嗯，挺好。我们会在周例会的时候做这件事情。

24 楼 kiol 2010-12-06  

fantasy 写道

推荐书籍：
•《丰田汽车案例-精益制造的14项管理原则》
•《硝烟中的Scrum和XP》

推荐博客：
•http://yizhituzei.blogbus.com 一只土贼的博客博客波波客

关于敏捷，大家有什么推荐的书或者博文吗？

有人提到了:《敏捷软件开发工具－－精益开发方法》
我还常推荐的是<解析极限编程>

BTW:不太认同敏捷源于精益.精益虽然确实早于敏捷,但是最早提出敏捷方法的人,例如kent back没有说过是来自于精益.后来有人发现敏捷是符合精益的思想的,就写了《敏捷软件开发工具－－精益开发方法》.

23 楼 aws 2010-12-03  

日报没啥意义，浪费时间，都是糊弄

周五下午花半天review一周进度和风险情况更有意义些

22 楼 fantasy 2010-12-02  

分享下TUTI说的“价值流图”参考资料

http://en.wikipedia.org/wiki/Value_stream_mapping

也可参考《敏捷软件开发工具－－精益开发方法》1.3章节 http://book.douban.com/subject/1151724/

其实画成其他形式的流程图也可以。目的都是为了能基于“全局”中识别出“瓶颈”步骤。
并可以针对“瓶颈”环节进行提高。

具体可参考《软件工程的敏捷管理》http://book.douban.com/subject/1178147/

21 楼 xuzhfa123 2010-12-02  

分析公司现状，采用敏捷开发思想引导开发。

20 楼 fantasy 2010-12-01  

tuti 写道

fantasy 写道

推荐书籍：
•《丰田汽车案例-精益制造的14项管理原则》
•《硝烟中的Scrum和XP》

推荐博客：
•http://yizhituzei.blogbus.com 一只土贼的博客博客波波客

关于敏捷，大家有什么推荐的书或者博文吗？

建议你还是先搞个自己项目的“价值流图”吧。
分析一下，到底要提高点什么。

好，非常感谢你的建议。正好领导让我们汇报可以提高的地方。
呵呵，从实践中反思比阅读什么书要更有价值。

19 楼 tuti 2010-12-01  

fantasy 写道

推荐书籍：
•《丰田汽车案例-精益制造的14项管理原则》
•《硝烟中的Scrum和XP》

推荐博客：
•http://yizhituzei.blogbus.com 一只土贼的博客博客波波客

关于敏捷，大家有什么推荐的书或者博文吗？

建议你还是先搞个自己项目的“价值流图”吧。
分析一下，到底要提高点什么。

18 楼 fantasy 2010-12-01  

推荐书籍：
•《丰田汽车案例-精益制造的14项管理原则》
•《硝烟中的Scrum和XP》

推荐博客：
•http://yizhituzei.blogbus.com 一只土贼的博客博客波波客

关于敏捷，大家有什么推荐的书或者博文吗？

17 楼 fantasy 2010-12-01  

抛出异常的爱 写道

fantasy 写道

抛出异常的爱 写道

tuti 写道

抛出异常的爱 写道

tuti 写道

我们团队现在需要跨时区，就把站立会议，改为日报。
效果还可以。

呸.....
刚刚取消了日报...

这个例子说明，基于具体实践活动的取舍，往往是南橘北枳。
重要的是要基于全局和全流程的分析，找到问题点和瓶颈环节，再来谈需要提高什么，以及如何提高。

需要看的东西太多了.
buglist
tasklist
wiki
email列表
todolist
进度燃尽图

+N张日报...谁有这种闲的时间去check这些事

的确要看的东西和处理的杂事比较多，所以每天定期抽出点时间来做，这样效率稍高点。减少任务切换。

日报没有什么反馈所以写的人看的人开始糊弄

的确是，日报很容易流于形式，我觉得可以让Scrum master负责查看日报，并负责解决或者协助解决日报里描述的问题。这样可能写日报的积极性会高很多。

16 楼 抛出异常的爱 2010-12-01  

fantasy 写道

抛出异常的爱 写道

tuti 写道

抛出异常的爱 写道

tuti 写道

我们团队现在需要跨时区，就把站立会议，改为日报。
效果还可以。

呸.....
刚刚取消了日报...

这个例子说明，基于具体实践活动的取舍，往往是南橘北枳。
重要的是要基于全局和全流程的分析，找到问题点和瓶颈环节，再来谈需要提高什么，以及如何提高。

需要看的东西太多了.
buglist
tasklist
wiki
email列表
todolist
进度燃尽图

+N张日报...谁有这种闲的时间去check这些事

的确要看的东西和处理的杂事比较多，所以每天定期抽出点时间来做，这样效率稍高点。减少任务切换。

日报没有什么反馈所以写的人看的人开始糊弄

15 楼 fantasy 2010-12-01  

抛出异常的爱 写道

tuti 写道

抛出异常的爱 写道

tuti 写道

我们团队现在需要跨时区，就把站立会议，改为日报。
效果还可以。

呸.....
刚刚取消了日报...

这个例子说明，基于具体实践活动的取舍，往往是南橘北枳。
重要的是要基于全局和全流程的分析，找到问题点和瓶颈环节，再来谈需要提高什么，以及如何提高。

需要看的东西太多了.
buglist
tasklist
wiki
email列表
todolist
进度燃尽图

+N张日报...谁有这种闲的时间去check这些事

的确要看的东西和处理的杂事比较多，所以每天定期抽出点时间来做，这样效率稍高点。减少任务切换。