精益软件开发管理之道

当前位置:首页 > 计算机网络 > 软件工程/开发项目管理 > 精益软件开发管理之道

出版社:机械工业出版社华章公司
出版日期:2011-5-19
ISBN:9787111340829
作者:Mary Poppendieck,Tom Poppendieck
页数:245页

章节摘录

版权页:插图:取景框9:已验证的经验如果你必须准时交付,那么帝国大厦提供了一些重要的经验。当然,系统开发不同于建造大厦,所以这种类比有一些局限性。但是,将20世纪30年代最好的后勤实践与今天典型的建筑项目管理实践进行完全的对比,这为我们提供了思考的素材。第一件值得注意的事情就是,所有者没有从规格说明书或竞标开始,他们开始时甚至都没有设计。他们从雇佣两个具有丰富经验的公司开始,每个公司都已证明有能力满足他们激进的成本和最后期限约束条件。根据已有的经验推断,这些公司能够满足这些约束条件。实际上,在还没有结构图纸和建筑规程之前,建造者就签订了一份固定价格的合同。承诺准时交付和按预算交付并不是基于细节,而是基于塑造细节的能力,这一点非常重要。进度计划不是根据建筑设计的细节来制定的,建筑的设计是根据进度计划的约束条件来进行的。如果你必须准时交付,或不能超过一定的预算,或者两个约束条件都存在,那么只有具有足够领域知识和具有已经证明的经验的人才能做出可靠的承诺,并让人相信最后期限能够以某种方式得到实现。他们不知道怎样去做,但他们知道在现有的约束条件下,问题能够以某种方式得到解决,因为他们曾经成功地处理过类似的问题。如果不能够找到具有已经证明能力的人承诺在时间和预算的约束下肯定能可靠交付,你就不能指望可靠的交付。要么这些人没有理解问题及其解决方案所需的领域专业知识,要么问题不可理解、不可解决,或者会变化。不管在哪种情况下,你都应该使用演进式开发,不应该做出超过信心的承诺。

内容概要

Mary Poppendieck领导多个团队实现了不同的解决方案,领域包括从企业供应链管理到数字媒体。她是Poppendieck LLC的总裁,该公司擅长将精益技术应用于软件开发。
Tom Poppendieck是一名企业分析师、架构师和敏捷过程培训师,目前帮助一些组织机构在软件开发过程中应用精益原则和工具。
Poppendieck夫妇也是《Lean Software Development》(该书获得2004年Jolt软件开发生产力大奖)和《Implementing Lean Software Development》的作者。

书籍目录

译者序

前言
第1章 系统思考
 运营航空公司的一种不同方法
 取景框1:关注客户
 谁是客户
 目的是什么
 什么是客户要求的本质
 取景框2:系统能力
 什么是系统预计能达到的能力
 系统需要实现什么
 取景框3:端到端的流程
 消除失效要求
 为价值要求建立流程图
 寻找最大的机会
 取景框4:政策造成浪费
 政策怎么会造成浪费
 五项最大的政策浪费
 肖像:产品捍卫者—理解1
 面向客户的构思
 面向技术的构思
 练习
第2章 技术杰出
 事实、短暂的流行和谬误
 结构化编程
 面向对象语言
 高级语言
 生命周期概念
 演进式开发
 敏捷的未来
 取景框5:基本复杂性
 分而治之
 低依赖性架构
 conway法则
 取景框6:构建品质
 测试驱动开发
 持续集成
 代码清晰性
 取景框7:演进式开发
 取景框8:精湛的专业知识
 专业很重要
 培养专业知识
 肖像:竞争力领导者
 培养技术专业知识
 练习
第3章 可靠交付
 冲向天空
 他们是怎么做的
 取景框9:已验证的经验
 约束条件暴露风险
 系统设计
 实现复杂性
 取景框10:分层工作流
 小批次
 迭代
 看板
 迭代还是看板
 能力
 取景框11:拖式进度计划
 中等规模系统的进度计划
 小而频繁的请求的进度计划
 较大系统的进度计划
 组合管理
 取景框12:适应性控制
 每次迭代的客户反馈
 常发布
 可消费性
 漏掉的缺陷
 客户的成果
 肖像:产品捍卫者—理解2
 产品捍卫者的故事
 练习
第4章 无情改进
 有问题的医院
 检查清单
 消除应急措施
 消除模糊
 快速试验
 取景框13:让完美可视化
 理论极限
 快速的组织机构
 关注客户
 取景框14:建立基线
 工作设计
 测试驱动的工作传递
 过程标准
 取景框15:暴露问题
 到现场
 取景框16:学习改进
 目的是学习
 问题与对策板
 a3思考
 基于拖式的授权
 共享知识
 肖像:作为指导者的经理
 练习
第5章 卓越的人
 文化假定
 管理实践的文化传统
 公司文化
 取景框17:知识工作者
 知识工作者的生产效率
 结果不是要点
 取景框18:互惠准则
 酬劳还是互惠
 取景框19:相互尊重
 跨文化团队
 自组织的团队
 取景框20:劳动者的自豪感
 目标-激情-坚持-自豪
 肖像:一线领导者
 练习
第6章 一致的领导
 敏捷@ibm
 转变
 利益相关人参与
 早期的实验
 学到的经验教训
 取景框21:从理论到实践
 关注客户结果
 改变系统
 制造一种紧迫感
 取景框22:治理
 超越预算
 十二条原则
 什么是生产效率
 取景框23:达成一致
 原因和结果
 取景框24:可持续性
 肖像:各级领导者
 领导者提供目标
 领导者定下基调和节奏
 领导者让人们进步
 领导者为他人成功创造空间
参考文献

编辑推荐

《精益软件开发管理之道》向软件领导者和团队成员展示了如何在一个软件组织中持续有效地推动项目向高价值转变。《精益软件开发管理之道》是一本展示如何在真正的项目、环境和公司中实现精益的实施指南。《精益软件开发管理之道》首次采用了取景框的概念,这个概念是形成看法和控制行为的幕后的思维结构。对软件领导者和团队成员来说,有些取景框导致了长期的失败,而另一些则为成功奠定了强大的基础。两位作者以几十年的经验为基础介绍了24个取景框,为领导精益软件开发提供了一致和完整的框架。《精益软件开发管理之道》介绍了一些强有力的新方法,可以帮助读者成为竞争力领导、产品捍卫者、改进指导者、一线领导者。《精益软件开发管理之道》主要内容:系统思考:关注客户。带来请求响应的可预测性和修改导致低效率的政策。技术杰出:实现低依赖性的架构、TDD、演进式开发过程,促进更精湛的开发。可靠交付:有效地管理企业的最大风险,同时优化工作流和进度计划。无情改进:发现问题,解决问题,共享知识。卓越的人:发现并培养具有目标、激情、坚持力和自豪感的人。一致的领导:让整个领导团队达成一致意见。《精益软件开发管理之道》出自世界一流的精益软件开发专家,对于每一个想兑现精益承诺的人来说都是必备的。特别是在企业IT部门和软件公司中。

作者简介

《精益软件开发管理之道》向软件领导者和团队成员展示了如何在一个软件组织中持续有效推动项目向高价值转变。本书不同于一般的精益实施指南,它展示了如何在真正的项目、环境和公司中实现精益。
作者采用取景框的概念来组织全书,这个概念是形成看法和控制行为背后的思维结构。对软件领导者和团队成员来说,有些取景框导致了长期的失败,而另一些则为成功奠定了强大的基础。两位作者以几十年的经验为基础介绍了24个取景框,为领导精益软件开发提供了一致和完整的框架。本书介绍了一些强有力的新方法,可以帮助读者成为竞争力领导、产品捍卫者、改进指导者、一线领导者。
《精益软件开发管理之道》包括以下内容:
系统思考:关注客户,带来请求响应的可预测性和修改导致低效率的政策。
技术杰出:实现低依赖性的架构、TDD、演进式开发过程,促进更精湛的开发。
可靠交付:有效地管理企业的最大风险,同时优化工作流和进度计划。
无情改进:发现问题,解决问题,共享知识。
卓越的人:发现并培养具有目标、激情、坚持力和自豪感的人。
一致的领导:让整个领导团队达成一致意见。
《精益软件开发管理之道》出自世界一流的精益软件开发专家,对于每一个想兑现精益承诺的人来说都是必不可少的,特别是在企业IT部门和软件公司中。

图书封面


 精益软件开发管理之道下载 更多精彩书评



发布书评

 
 


精彩书评 (总计1条)

  •     第一章 系统思考关注客户系统能力列出一个远景,让组织内的每个人都清楚地知道,组织机构要想现在和未来获得成功,都需要做些什么。这样每个人努力自底向上的建设比自顶向下的命令在最终效果上要好很多。不要设置目标相比较却不与利益挂钩,防止互相破坏端到端的流程画出流程图,它体现了产品或客户问题通过你的系统时的端到端的流程。(也可以画个失效流程图)它可以帮助我:1. 发现失效要求的愿意,可以消除失效要求2. 找到工作流中的浪费,并消除浪费除了正常生产流程(TDR->coding->text->fixes)也可能使其他的端到端,比如用户发现关键缺陷后到修复了这个关键缺陷让用户重新使用系统的过程。我们有很多泥巴路(scrum趟出来的)或者根本没有路,我们要用精益搞出端对端的高速路事务上的端到端(确定事务流程)+人员上的端到端(每个环节的人员固定,纵向team)政策造成浪费1. 软件极度复杂:停止将并非绝对必需的特征放到系统中。产品反馈每个特征都用的怎么样、有必要简化或舍弃。把90%的shi排出去2. 没有权限去拒绝不必需的特征3. 以为代码越多越好:其实应该不断完善,只留精髓,用少量的代码和巧妙设计保证后期维护4. 不要妄图一次开发很多:应该保持增量开发把已经开发的弄好,让基础清晰坚固5. 用户希望我们能自动化他们的复杂流程:应该让产品把业务过程先简单化,产品的shi自己扫走,不要让我们开发一坨屎。免得开发完了他们想清理shi还要动代码刀子如果有非要让我们赶时间做完的任务,不要砍掉测试时间,要砍掉功能精益思考利用流程经济性来为我们观察世界提供取景框,而不是规模经济性。避免工作的传递(效率低,还容易有理解偏差、多传递导致不接地气、不去实践也不去了解当事人)第二章 技术杰出基本复杂性构建品质测试驱动开发需要测试自动化决定什么要自动化编写好的测试让测试自动化在正确的时间执行测试维护这些测试遵循这些原则:1. 在跨只能团队中工作2. 确保团队深刻理解了客户的状况3. 通过团队协作得到解决方案4. 以某种方式对解决方案建模(文字、示意图、草图、原型,或者任何管用的东西),产生一个公认的方向5. 快速在尽可能真实的环境中尝试解决方案6. 将解决方案视为试验,并预期会进行修改7. 以小步骤的方式开展工作,最好是采用有规则的节拍8. 反复进行精湛的专业知识十年用心:1. 确定需要改进的具体技能2. 设计(或从老师那里学习)一项练习来改进这项技能3. 反复实践4. 每次努力后立即得到反馈,并根据反馈进行调整5. 专注于突破极限,预期会反复失败6. 实践通常很密集,也许每天3小时第三章 可靠交付第四章 无情改进检查清单指定一些规则并且形成规则文档,一项成功的规则计划需要仔细的规划,需要通过测试来确定过程是否成功,需要根据实际情况进行修改,也需要小心的实施改进团队应该1. 设定清晰的目标2. 建立一些测量指标,说明变化是否导致改进3. 确定有可能导致改进的变化计划>>>执行>>>研究>>>行动让完美可视化理论极限工作系统的理论极限:1. 没有缺陷---无bug2. 根据需要---只对真正的需要做出响应,不想些以后有的没的东西3. 一次一件---只在人们要用某样东西时才提供给他们,不麻烦他们保管东西以备将来使用4. 马上---向人们提供他们需要的东西,没有等待时间。5. 没有浪费---从不在没有其他人认为有价值的事情上浪费时间、精力、创造性或其他尝试6. 安全---没有人受到身体上或精神上的伤害,也没有人受到专业的威胁7. 机密---东西只送到应该送到的人手上,而不是其他人快速的组织机构快速公司不欢迎实际和计划的偏差这是计划定制的不够完美,并且在偏差中可以学习。关注客户从最终客户的角度考虑端到端的距离,这包括了跨部门的端到端同时确保所有团队成员和所有部门都意识到他们的双重角色:即是前一个操作的客户,也是下一个操作的供应者建立基线工作设计输出(保证价值),途径(工作流),连接(工作流内的跨部门跨职能的衔接),方法(规则执行)过程标准过程标准的目的:在业务上实现清晰的沟通和清楚的工作转手标准化的真正理由:过程标准化的目标是作为持续改进的基线。实现可审计性的开销带来了浪费,而不是标准本身带来了浪费。如果你认为标准就是你所能做到的最好水平,那就完了。标准只是基线,你找出按标准所行时候不喜欢的东西,然后看看问题所在,决定是否应该优化标准。暴露问题学习改进不要设置建议箱,占用别人的时间解决你的问题,最后问题就成为空谈。给提出问题的人、或者深受此困扰或者有好解决办法的人去执行,但为了避免以后没人愿意提问题了应该master全程撑场子防止问题没有下文:1. 在白饭上写上问题解决表2. 将问题A3表抄送给领导

精彩短评 (总计6条)

  •     不错,对问题的看法很有深度
  •     精益就是通过改变系统,减少浪费。
  •     不知所云
  •     老太太”肚子“里的东西还是很多的。分享了她很多的经验。同时很八卦的想知道,这本书Tom同学写了多少。不过分了那么多的”取景框“,稍微有点多,因为多了,那么就容易混乱。记不住那么多
  •     概念场景化,日本与西方的决策过程比较有提示。
  •     书名叫精益软件开发管理,但是里面的很多事例跟软件无关。更像介绍精益思想的一本书。所以,从软件管理角度看,写的就很一般了。不过,作者拓展了精益思想一书所描述,看看也行。属于一家之言吧。
 

外国儿童文学,篆刻,百科,生物科学,科普,初中通用,育儿亲子,美容护肤PDF图书下载,。 零度图书网 

零度图书网 @ 2024