《知行合一： 实现价值驱动的敏捷和精益开发》读后感3
3.1 形似神不似的Scrum实施
搞清楚你的问题，搞清楚你需要什么后，也就是痛点，才能有效引导一个新流程框架的落地
>> 俗话说：好的开始是成功的一半。知道为什么引入敏捷，明确要解决的问题是一个好的开始。
>> 俗话说：好的开始是成功的一半。知道为什么引入敏捷，明确要解决的问题是一个好的开始。
3.2 使用Scrum的艺术
>> 软件开发团队的跨职能小组之间不应该是PK的关系，应该是荣辱与共、同在一条船上的关系：产品缺陷给使用的用户带来了不便是整个团队的耻辱，发布前发现的每一个缺陷都是值得整个团队庆祝的事。
>> 团队从被动到主动，不可能一步到位。管理者必须给团队创造一个安全的环境，让他们放手发挥自己的能动性，出了问题不要责难，而是要鼓励。中国的Scrum过程经理在这方面面临的挑战更大，他需要指导团队逐步学会使用自己的权力，去担当，去学习，逐步形成一个真正的团队。
>> 考虑两个今天需要做的决策选择：是用简单的方法实现功能、需要的话明天再修改，还是用复杂的、超前的方法来实现同样的功能，因为明天可能需要？敏捷的选择永远是前者，因为今天实现的额外复杂功能以后可能永远不会被使用。
不久前我为一家电信应
>> 敏捷实施中所需要的勇气，在这里我讲的是一个软件工程师在面对问题时应有的勇气。
不只是软件工程师，任何一个人员，都需要有说真话的勇气。
>> 在这里我讲的是一个软件工程师在面对问题时应有的勇气。
>> 敏捷中我们再加4个字——“错了再改”。Scrum中的频繁反馈会让你很快就有纠错的机会。
这个是一直困扰我的问题！！！看看书上如何解析？
>> 在国内我常听到这样一种说法：敏捷是好，但我们开发人员能力不足，所以我们无法敏捷
>> 在国内我常听到这样一种说法：敏捷是好，但我们开发人员能力不足，所以我们无法敏捷
>> 因为敏捷并不是为技术精英设计的，如果你的团队在传统模式下能够开发出软件，那么他们就有能力敏捷。但我同意这样一种观点：没有自律，没有把团队能力提升作为敏捷迭代一个目标，我们无法打造一个高效敏捷团队，这也是自我管理的重要基础。
>> 只有你的团队真正开始实施Scrum后，你才能逐步真正理解它以及它的价值，在实践中学习（learning by doing）是掌握Scrum的唯一方法
>> 一起攻克一个复杂问题，高效协作，学习调整时，你会慢慢体会到Scrum的妙处
>> 自律就是接受责任有担当，就是接受并遵循确定的开发架构，就是遵循团队定义的设计原则，就是遵循团队定义的编码规范，就是写出简洁的代码，就是不把质量作为一个牺牲品，就是遵循团队的行为规范，就是乐于让同伴检查自己的工作。这些不仅是贴在墙上的口号，而且是团队的日常实践。
>> 自律也是让开发过程完全透明，每天都使自己的工作和团队其他成员的工作同步
>> 的
所有的流程设计均需考虑将各条规则相辅相成，互相补充，但是灵活的流程必须满足一点，比如考核流程，需给执行流程的人员留有空间，上升的空间，而不是将人堵死，就像一个山谷，必须留有出口，这样大家才有努力的空间。
>> 敏捷（Scrum）实践有极好的互补性，每一条都有自己的缺陷，敏捷的妙处是这些缺陷会被其他实践所弥补。正是这些相辅相成的实践，让我们能够实现敏捷带来的价值。
>> 敏捷（Scrum）实践有极好的互补性，每一条都有自己的缺陷，敏捷的妙处是这些缺陷会被其他实践所弥补。正是这些相辅相成的实践，让我们能够实现敏捷带来的价值。
>> 很难在一个短的周期（1～4周）开发出对客户有价值、可发布（满足质量要求）的软件。
>> 跨职能团队
>> 能够在一周内完成。
>> 很难有一个真正做到自我管理的团队。
>> 很难让整个开发过程变得透明。
>> 很难获取产品的反馈并做及时、合理的调整。
>> 很难获取对所用敏捷过程的反馈并做出及时调整。
>> 的回顾会是获取反馈的好时机，对问题错误做根
>> 敏捷和CMMI结合的探索也许可以是解决软件开发问题之匙。
>> 让产品经理知道开发团队的能力——每次迭代能实现多少功能，这是让版本计划变
>> 敏捷对卓越技术的追求及明确的“完成”标准是控制带病迭代的关键。
—任何一个体系都是一项系统工程，其结构是整体架构，环环相扣，如果在某一环节缺失，必然会导致无法行成闭环，僵化-固化-优化是必不可少的。
>> 尽可能完整地引入Scrum是让其价值最大化的保证，令人遗憾的是敏捷实践者往往忽略这一点。
>> 尽可能完整地引入Scrum是让其价值最大化的保证，令人遗憾的是敏捷实践者往往忽略这一点。
