《精益软件开发管理之道》书评

读书笔记

第一章 系统思考关注客户系统能力列出一个远景，让组织内的每个人都清楚地知道，组织机构要想现在和未来获得成功，都需要做些什么。这样每个人努力自底向上的建设比自顶向下的命令在最终效果上要好很多。不要设置目标相比较却不与利益挂钩，防止互相破坏端到端的流程画出流程图，它体现了产品或客户问题通过你的系统时的端到端的流程。（也可以画个失效流程图）它可以帮助我：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表抄送给领导