看了一天多《移山之道》，来写篇文章，为什么三本书挑了这么一本呢，就是因为它薄，似乎看起来容易一些。看完之后觉得这本书很好玩，像一本小说而不是艰涩的学术专著，我非常喜欢这样的书，至少它不会让我在5分钟之内睡着，而是让我饶有兴致地通读到底。
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
这是盛行的敏捷开发原则之一，却是我们现在这个团队面临的巨大问题，如何提高效率是PM该做的事情，我想过好多次，从组建团队以来，然而我却发现这个效率不是嘴上说说就能够实现的。原因有以下几条。首先，我们这样的开发团队并不是一个可靠而又有能力的团队，作为学生，每个人的能力各有不同，而不能够像公司招聘员工一样尽量保证员工的水平在某一个指标之上，所以我们的开发能力不能够得不到保证。第二，因为是强制课程的强制作业，所以我们的动力源泉并不是喷薄而出的，一个团队可能只有一两个人有热情去开发，甚至有的团队大家都是为了应付这个项目，而不能够真正投入，结合第一点，这有热情的20%的人中假设有一半有足够的能力完成自己的任务和设想，这样的团队又如何能够高效的完成任务呢？第三，我们现在的阶段，时间并不是能够随心所欲的控制的，各种课程和各种作业，确实，要想赶时间可以赶得出来，可是精力被分散实在是难以避免，每个人各有各的安排，而不像公司里所有人通知执行一个指令。如何能够提高我们这样的团队的工作效率，确实是一个不简单的问题。
The best architectures, requirements, and designs emerge from self-organizing teams.
这是另一条，我正在努力做并且能够达到我自己的要求。作为学生团队最大的好处就是我们一起学习生活已有2年，互相非常熟识，而且队伍是自己拉起来的，组员之间没有勉强为之，不存在勾心斗角，有什么事情可以大声说，遇到成功可以大声笑，自由自在，无拘无束，作为PM不是一个命令者，而是一个规划师，努力的构建一条适合自己团队的路，并和同伴并肩走下去，这样的团队管理不是上下级的，不是单方面的，这样更能够发挥每个人的主观能动性，也许能够迸发出公司里层级制度森严，一家独大所不能够发现的创意火花。
作为团队的PM，和其他组相比我的编程能力不是最强的，所以在项目开发中压力非常大，不敢自信满满地说带领整个团队编出程序来，所以只能发挥整个团队的力量一起来完成这项艰巨的任务。所以在这个项目里我最重要的作用并不是一个人贡献出多少代码量，而是带动整个团队一起写代码，做出更好的框架，拿出更好地规划，只有这样，我们才能够更成功的写出更成功的软件。
