领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
速览：软件开发中的7大浪费
作者 Mike Bria 译者 金毅 发布于 2009年8月13日
精益软件开发的基本原则是追求浪费最小化。TPS总结了制造业的7种主要浪费，而Poppendiecks已经把它们引入到我们软件开发的领域中。Jack Mulinsky最近在agilesoftwaredevelopment.com上发表了系列文章对这些浪费进行一一介绍。
该系列文章的第一篇讨论了部分完成工作这一浪费。软件中的这种情况相当于精益制造业中的“进行中的清单”，Mulinksy认为这是所有浪费中最极品的部分。他对“进行中的工作”这种浪费归纳如下：
- 已完成但尚未签入的代码
- 没有相关说明文档的代码
- 未测试的代码
- 没人使用的代码
- 被注释掉的代码
第二篇文章中，参考那个众所周知的统计数据：在现有的软件应用程序中，多达三分之二的功能几乎或从未被使用过，Mulinsky提出额外的功能（制造业中的“生产过剩”）这一浪费。除此之外，他还指出什么是直接浪费（开发的花费而不是人员）以及什么是间接浪费（更多的功能意味着更多的代码以及更高的维护复杂度）。
Mulinsky的第三篇文章关注的是软件再学习/返工的浪费，这对应于精益制造业理论中的“额外处理”这一浪费。他用了这样一些浪费的例子来描述了他的想法，包括：
- 糟糕的计划
- 低劣的质量
- 在不同的任务间切换
- 不足的沟通和知识积累
- 没有相关说明文档的代码
这一系列中的第四篇（写此文时最新的部分）讨论的是交接带来的浪费，软件中的交接相当于制造业中的“运输”。他提到了以下一些可能产生浪费的技术方面的例子：
- 开发人员之间的代码交接
- 开发人员和测试人员间软件的交接
- 软件从开发到部署的交接
Mulinsky应该很快会继续其余3个软件浪费的话题：在不同的任务间切换，延期和缺陷。软件浪费这一概念，是由Mary Poppendieck和Tom Poppendieck在他们两本非常出色的精益软件方面的书《Lean Software Development: An Agile Toolkit for Software Development Managers》和《Implementing Lean Software Development: From Concept to Cash》中提出的。如果这是你和这一概念的第一次亲密接触，敬请期待Mulinsky的后续大作。
同样，对那些很熟悉这些观点的朋友们，不妨分享一下你们觉得浪费是怎么在软件开发中产生的，你们又是如何消除它们的？这会对大家都有很帮助。
查看英文原文：A Quick Look At The 7 Wastes of Software Development
译者 金毅 多年来服务于欧美软件外包行业从事管理工作，对软件工程、方法学等在外包业的运用和CMMI实施略有感悟。
最大的浪费
发表人
Wei Fisher
发表于
Re: 最大的浪费
发表人
Wei Fisher
发表于
Re: 最大的浪费
发表人
jiang yan
发表于
Re: 最大的浪费
发表人
唐 红军
发表于
Re:最大的浪费
发表人
Zhang Hector
发表于
RE：最大的浪费
发表人
Zhang Hector
发表于
细化这些浪费的项目还是有帮助
发表人
叶 旭辉
发表于
悲哀啊
发表人
Huang Joe
发表于
如何改善
发表人
King Tobato
发表于
挑战现有的开发团队组织结构
发表人
任 逍遥
发表于
-
已经被cancel的代码曾经的测试代码。
-
被cancel的代码，有一些还能复用。但是针对这些代码做的测试基本上没有复用的价值。
-
窃以为，浪费之一“不足的沟通和知识积累”为原罪之首。不能从过去吸取教训，不能反观内照。我见过很多软件工作人员，第1年和第n年的工作状态，工作环境，工作方式几乎一模一样。
以期盼着早日结束项目的心态做工作，结束的时候长出一口气，把所有东西丢到一边，这是最大的浪费。所以代码中的惯性问题，测试人员一次次的发现，却没办法让研发在初期就解决；那些惯性的测试用例缺失，一次次在走查中发现，却没能在测试人员在设计之初就弥补。
杜绝浪费最好的办法是现在多做些，就为了将来少做些。
We know we're doing it in harder way, that's the only way to make it easier in the future. -
我觉得浪费的原因是思考的时间太少
-
个人觉得这篇文章翻译得还可以， 但是为了弄清一些细节，或者能更清晰的了解原作者的想法， 最好还是访问 agilesoftwaredevelopment.com/blog/jackmilunsky/...
-
在补充一点个人观点哈， 我觉得最大的浪费就是没有做正确的事情。 可能可以归纳到：不足的沟通 这点。 Do the right thing by the right way. The most important thing is "Do the right thing!"
-
糟糕的计划让部分人忙得要死，而部分人无所事事-----浪费，
代码交接让一个开发人员重新学习项目，学习代码-----浪费，
个人觉得最大的浪费莫过于项目结束后没有总结，或是草草了事，不管是技术还是管理方面，于是下次类似的项目，又得从零开始 -
怎么我参加的每个项目都有这七宗罪，真是一个都不能少
-
总结得很精辟，确实是工作中最常见的问题。那么谁应该对这些问题负第一责任呢？改善应该从哪里开始呢？愚以为公司的中层（资源协调者，项目经理，团队领导）和高层应该负第一责任。说白了，就是一个软件企业的管理问题。
-
究竟需要谁来设计，谁来实现。
谁来为浪费的资源买单！
10 条回复
关注此讨论 回复