初次接触Scrum和XP（更加准确的说是“看到”），心里不免有些疑问，软件开发为什么会有如此多的方式，难道软件开发、软件工程不就是写写代码的事儿吗？直到后来，才明白，一个庞大的软件工程，不会只是一个人的事儿，倘若我们现在（学生时代）还是只有着一种写代码是自己的事儿的态度来看待软件工程这样的“工程”，是低端的，是不全面的。
作为一名软件工程的学生，编写代码的能力是一方面，理解计算机对于代码编辑、编译、链接、运行过程是一方面，理解算法、数据结构有事另一方面。这些当然是我们软件工程学生应该有的素质，但同时，我们还应该明白，一个只有几个人能胜任的软件工程的小组毕竟只是少数，少数中的少数，更多的则是庞大的集合体，我们（对于一般的程序员、工程师）只这个庞大的集合体中的一两个小小的元素。所以，我们应当有团队意识。
说了一大堆空白话，让我们回到《硝烟中的Scrum和XP》来。
何为Scrum？这里我不想复制某度百科一堆，我只想说说我的理解（拙见），在我看来，Scrum更加给人一种具有技术的高效开发团队组织的感觉，这个组织拥有对于时间掌控的能力，能够充分利用时间的分割来进行项目的开发、管理，从这一点来看，Scrum更加注重管理，注重一种形式，一种规则。XP则是在另一番景象，XP所做到的是注重了编程的实践，注重强有力的工程实践，是实际的，具有技术的。为什么二者能够和谐的处在一起，因为它们都是在处理软件工程领域不同的部分，而不同的部分，则是软件工程如今所面临的重要之处，同时，它们都强调了个人与组织的关系，强调了个人应当与组织形成一种高效的交流。本书序章中看到了一句话“实际上，Scrum和XP都关注如何把事情做好”。的确如此，所以才造就了如今的敏捷开发与极限编程所拥有的魅力。
Scrum与XP的共同点：实践与交流。正如书中所说“但在纷乱芜杂的信息中，我感到最有价值的就是那些真枪实弹的故事。它们把‘原则与实践’变成了‘如何真正动手去做’”。理论知识就是动动嘴皮子，在此我并非贬低理论的形成过程，是的，理论也是需要动用你的大脑去真正的考虑设置一种想法的“实现”，这种“实现”并不是简单想想就能搞定的。但是，现实是残酷的，时间是不等人的，在如今的软将工程这个领域里，你永远不知道“下一个巧克力是什么味道的”。甜的，恭喜你“侥幸”度过了软件工程实践里的难处；哭的，很遗憾，你的项目，你的工程将很有可能面临淘汰。（胡乱扯了一通，拙见）
在书中我还看到了一个很有意思或者说确实也出现在我身上的事例。就是在backlog这一部分，书中所讲的就是“需求，或故事，或特性等组成的列表”，理解一下就是贴了一些便条的梗概，这些都是业务层次上的（产品负责人来负责），不需要你添加一些技术性的问题在其中（技术人员的事儿）。然而（比如我）在写这个backlog的时候，常常就会添加一些技术性的比如这里用某某算法、这里用某某结构体等来描述，这实际上已经突破了业务的层次，这在实际过程中应当避免。
本书中还提到了Scrum Master：负责监督整个Scrum进程。是的，Scrum确实需要这样的Master存在，Scrum Master并非团队的领导，而是一个负责屏蔽外界对开发团队干扰的角色。Scrum Master是规则的执行者，他是Scrum团队中的服务型领导。不难看出，SM的需要非常熟悉敏捷开发模式，同时还需要很强的能力。
我在看这本书的时候，其实并没有太关注Scrum与XP的过程，而是在思考Scrum与XP的思想，这样的思想是如何体现的。其实作为一名程序员，我们不能仅仅关注于技术，而是应当在做技术的同时，思考一些理念，一些想法，一些蕴藏在软件开发之中的文化（当然实在已经有较好的技术的前提下，否则就是理想主义者了）。
