上一章节我学习到了一整个敏捷开发的框架，需要运用到哪些方法，敏捷开发的基本理解是什么，接下来的章节会从敏捷开发的基本原则说起，然后介绍核心的实践，从基于统一迭代的全功能团队的概念入手，将一整个敏捷开发流程细分为几个步骤。
首先我们需要知道敏捷开发的宣言是什么：
个体互动>流程工具
工作软件>详尽文档
客户合作>合同谈判
响应变化>遵循计划
在本文中强调，大于不代表完全不参照右侧的流程。举例，在产品给开发讲需求的时候并不是直接想到什么说什么，而是要基于最基本的Story。
开发人员需要拥有客户思维，也就是说在拥有较强解决问题能力的同时，也要能够理解该需求在商业上的考量。其实所谓的客户思维，我认为更多的是在强调开发本身为服务方，不管是你的老板还是你的产品经历都是你的客户，你需要的不仅仅是拿到需求解决需求，更多的情况你需要去沟通，去弄清楚客户真正的需求是什么，同时也需要去学会分析做该决策的价值。其实我本人在实习的时候也遇到过差不多的问题，在那个时候我不敢多沟通，导致白白浪费了一天的时间在错误的需求上面，这就是很无效的沟通。回到最初的根本价值驱动这四个字上面，解决方案不一定是技术最先进的，而是多方面权衡以后的价值驱动最优解。在编程的时候一定要记住并且时刻提醒自己。
到了核心实践部分，对于基于统一迭代的节奏的全功能团队，作者运用了汽车贴膜专业团队这个例子，其中我觉得比较有价值的点是：1.所有的工作高度并行2.每个人的角色不唯一（全栈工程师）。骚窝口号“把项目成功交付看作能力建设的副产品”。他们认为软件开发中的一切问题基本都是个人能力不足的问题。这也体现出了敏捷开发宣言中的个体与交互>流程和工具。
接下来的一个章节在讲述用户需求和范围实时管理，其中提到了估算。估算取决于个人，取决于项目的重要程度，估算会议可以提高成员之间的交流。讲完估算后作者提到了需求风险的“坏味道”---客户过多的插入服务方的工作。其中解决的办法是接近客户决策者；努力将自己的价值输出，能够做决策；不要给选择，让客户相信我们提供的方案就是最优解；管理结果，对于该需求的讨论重点放在其会产生的结果上而不是具体的实现方式；建立游戏规则“我很高贵，服务收费”。其实我觉得这就是咨询类公司和其余科技大厂之间的不同吧，价值驱动所带来的影响注定是如何利益最大化，用最小的付出获得最大的收益，这也是敏捷开发能够体现到的东西。需求分析其实最为重要，是在开发以前一定要跟客户沟通好的，但是这也不仅仅是BA和客户之前的关系，也同时是BA和整个团队的沟通，其中涉及痛点分析，业务逻辑等。更是需要持续的了解用户，所谓的“迭代更新”，用户的需求也是不停的在改变的，我更愿意称之为“想到一出，是一出”“别人有的，我也要”。而后谈到的软件项目规模估计我认为跟前期的估算差不多。
第五章所讲的内容是持续集成和测试前置，先是讲述了什么是Gitflow，主分支master上的代码可以随时部署到生产环境，develop作为每日构建的集成分支，稳定时可，merge回master，feature分支用户开发新特性，结束后回develop分支。这样不同的分支之间的交互规划形成了一套集成部署开发的工作流。但是这样的方法并不是被推荐的方法！就是因为feature这个分支阻碍了频繁合并，总的来说就是feature这个分支不好，与敏捷开发相矛盾。于是提出了新的Trunk-Based Development，这个书中没有细说，等以后真正开始上班后自然会了解。单元测试的两个动机，一个是驱动和验证功能是否实现，第二个是保护已经有的功能不被破坏。接下来就是大名鼎鼎的代码回顾，该过程我听说在骚窝中每天下班前都会做，侧重于识别编程的喜欢而不是找bug。TDD是什么？ 是单元驱动测试开发，其中又分为UTDD和ATDD，ATDD面向业务：我们是在构建正确的系统吗？UTDD面向技术与代码：我们是在以正确的方式构建系统吗？我觉得这两个疑问句就能够很好的解释那两个名词。
结对编程，我最害怕也最好奇的编程方式，是隶属于极限编程里的方式，对于我这种小白来说真的还是蛮害怕的。特别是这一句话“如果代码审查很好，那么我们就一直代码审查”，听起来是一个压力巨大的场景。书中讲述了部分结对编程的方法，现在的我看着比较害怕，希望到时候到了真正的生产环境会有新的体验。