因为这次有了个人作业，读书方面相对较少。不过，软工这门课就应该这样以实践为主，理论都是架空的理想，实际的锻炼才是最重要的。

有这番感想主要还是因为，做了个人作业之后再看书上写的内容，简直就是不谋而合，虽说个人任务相对于团队任务或者一个项目的开发简直就是小巫见大巫，但是这些道理都是相同的，毕竟这些都是一个程序的开发过程。

1·Scrum

虽然，看书上说的增量式增量式，不实际干就是没有体会到它的意义。Scrum就是一种增量式和迭代的开发管理框架。因为，只是个人作业，所以并不能完全与之重合。Scrum有四个基本元素：时间盒（Sprint），Scrum团队，制品，规则。

时间盒感觉更像是一个周期，这样子就应和它是迭代框架的意思。在每个周期里面，我们关注与我们接下来要做的增量功能，对这个功能进行必要的分析，计划，开发，测试。一般来说，这种周期是一个月或者更短，但是我的作业给的时间也就一个星期，考虑到实际情况，我还有别的功课，其实也就只有四天时间，所以以一天为周期比较合适，每一天都会有计划增加的功能。

Scrum中最核心的制品是指潜在的可交付产品的增量，就像我们作业里面提到的程序要求，每过一个周期我们按照其要求和自己的计划实现各个功能，当然也还有自己独特的一些小功能会是很抢眼的。

规则是整个过程的监督者，有了强有力的规则，才能更好的管理，更高效的实现软件开发。例如：Scrum团队要求在每个Sprint的交付物都应该是达到实现规定的“完成”状态。这样有了清晰的目标和标准才能提高团队的动力。

总而言之我的理解就是，一个Scrum团队在一个Sprint内思考这一阶段的制品，并且按照既定的规则高效的工作。

2·极限编程

了解到它的重要的五个价值观：沟通，简单，反馈，勇气，尊重。

成功的软件开发和编程作业的关键要素既不是撰写文档，也不是一直码，而是能否掌握正确的信息。只有获得了正确的用户需求信息，才能知道我们的目标是啥，不然就像算是再厉害的编程高手也会像失去照明指示塔的强劲舰队，始终在一篇未知的或者自以为已知的海域飘荡~飘荡~，及时的沟通才能及时地调整我们开发的方向，力争做到不浪费每一分钟的努力，这样才能在极限短的时间内完成用户的需求任务，呈现一个满意的可交付的产品。

简单的原则要求团队在任何时刻仅做当前最必要的工作。简单直接也是最好的，像是拓扑排序那样，关注与那些最重要的环节，一切的任务的优先级都会次于它们。同时减少了不必要的开发浪费！让我们开发的时候不会陷入某些性价比极低而且不必要的工作，也让我们心里知道，我们走的每一步都是必须的绕不开的，每一步都是径直地通向我们的最终产品。没有了犹豫，也就可以全心全意的发挥每个成员的独特能力。

书中引用了一句名言来巧妙的说明了反馈的重要性，“盲目乐观是设计的敌人，而反馈是避免盲目乐观的药方”。极限编程中充满了大量的反馈回路，鼓励每个人利用一切机会来发现开发中的问题，这样子来缩短反馈的周期，减少反馈之后的调整工作量和工作时间，省去了很多可避免的时间浪费，人力物力的浪费。

软件开发的过程和编写程序的过程是一个未知的不确定的世界，在不确定的世界做出正确的决策是困难的，没有了全局观，没有了详尽的分析材料，无法做到每一步都依靠存粹的理性。勇气的存在使得团队倾向于做出正确的决策——即使是一个十分困难的决策，而不是选择看起来容易，实际上是错误的决策。在软件开发中，正确远远重于困难程度。勇气也不会是一味的冒险，而是需要和其他的价值观相互结合。

在一个团队中，每个人的努力都关乎最后产品问世的价值，团队应该尊重每个人的专业技能，构建整个团队的共同目标，让整个团队和睦团结互帮互助，团队的力量一定远超单纯的几个高手力量的总和，才能完成每个看似不可能的任务！