老翟书摘：从《大野耐一的现场管理》看软件开发前年，接触到了《丰田生产方式》，就对大野耐一这个人十分感兴趣，就专门找他的书来看。 同时，我一直都有一种 “感觉”：我们软件工程的管理方式都是从传统工业借鉴的。比如被吹上天的 “精益” 概念及 “看板” 概念。然而，这些概念里，少有人说明这样地借鉴的理由及借鉴了哪些，放弃了哪些。想回答这个问题就必须分别弄清楚传统工业和软件工程的本质。 我尝试在这本书了解一些关于传统工业的管理概念。以下是书摘： “精益” 的概念的产生
领导说服力：坦诚即代表强劲的说服力
传统工业也会遇到我们软件工程一样的问题：面对同样一份工作，存在不同的意见。传统工业时里的体现可能是组装配件有两种方式，哪个效率更高；软件工程里的体现是实现某个功能，怎么实现更快（不要忘了，我们还要考虑可维护性，可读性）。当存在不同的意见时，双方容易在无用的争论上浪费时间，大野耐一是这么处理的：
其实，这样处理的最大好处是将“实践出真理”的文化慢慢带入企业。 要提高生产效率，“意识革命” 是首要问题
我们软件行业更是如此，特别是一毕业就只在一家公司待很久的人。很容易被 “常识化”，认为软件开发就只有一种方式：手工将 jar 包下载回来，导入到 IDE 中，然后写代码；部署软件也就是 ssh 上服务器，然后 stop,start。 大野耐一说：
再比如很多人认为写单元测试会导致进度被拖慢。其实，关于单元测试是否加快进度，需要更多的数据支撑。所以，需要软件项目管理工具为我们提供更全面的统计工具，来收集这些数据。这也说明了软件行业和传统工业的一个很大的不同。传统工业中很多工作是重复的（产品通常是批量生产），可以快速实验，快速看效果。而软件行业中，根本没有批量生产某一软件的说法。 无效率的动作不是工作
这里，对于这个 “无效率” 的定义会有争议。我是这样认为的，如果不能帮助我写出可读、可维护、用户可用的软件的动作都是无效率的。比如手动去管理软件依赖、手动部署、需求沟通需要等上一个星期、新加入团队的成员需要花两天的时间搭建开发环境、重复手工测试、单元测试写在 main 方法里、写代码过程分心看微博，动弹…… 作为 leader，发现这些无效率动作，然后找到改善办法是一项重中重的工作。 改善应该按顺序进行
软件行业中，顺序应该是软件开发流程改善，之后依次是实现技术改善、软件开发工具改善。原因是软件开发流程的成本收益率比实现技术改善、软件开发工具改善更高。这只是我的片面之词。希望有数据的同学能帮我证实。 产品质量问题
产品质量融于软件开发过程中，将风险高的软件模块提前开发。QA 在功能开发前就参与需求的讨论，并提出验收条件 AC。
减少浪费也可以降低成本。关键是我们如何看待浪费。在《丰田生产方式》中定义的浪费： 从这里就可以看出光靠架构师是不能彻底杜绝浪费，更不可能靠财务了。 这本书给我最大的启发是：高高在上不接地气的技术管理是无法管理好团队的。高高在上意味着他无法或很难及时、准确得知开发现场的情况的。如果你连 “施工现场” 的情况都不了解，谈何改善？ 同时，我也发现软件行业的代码审查、每日站会就很好的体现了大野耐一的现场管理思想。通过这两个实践，我们的 leader 才有更多机会靠近 “现场”。这才是代码审查、每日站会背后更深层的原因。 半年后再次重读这本小书，又知新。 ========== 老翟书摘说明 ========== 书摘内容完全来自原书，如果原书的作者或出版商觉得我侵权了。请通过开源中国 @翟志军 联系我。 老翟书摘旨在通过一种书摘的方式让大家花最少的时间了解一本书，从而决定要不要继续读下去。书摘的每一本书都是本人亲自读过并理解的。 http://my.oschina.net/zjzhai/blog/614509 sohu-dba 本文转载自：微信公众账号 - SOHU-DBA，版权归原作者所有！ |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
