Build to Win
——手边无书，却欲成此读书笔记，仅凭记忆与经历谈谈自己的感想
时隔数月，我仍清晰地记得《最后期限》里面的一句话：人是经理所要解决的唯一重要的事情。（只可惜我很难想起《构建之法》中有很经典的语句，大概是干货太多就难以有所注重吧）
这是两本相辅相成的书——《最后期限》阐述如何解决人的问题，避而不谈构建方法，而《构建之法》则是一本厚厚的方法手册，对人事问题又谈及甚少。这两本书引领着我走入团队合作的世界，而想起过往在电子设计实践中的小打小闹，才发现要让一个大的团队紧密合作，任重而道远。
1、管理人的艺术
在最初的两个月里，我就像是疯了一般，每天加班加点地阅读有关团队项目的各种书籍，因为我一想到就要在三个多月后交付自己的作品，而自己对这个领域一无所知，就感到深深地恐慌。我以为队友们都是抱着这样的心态，时不时还能看见他们在群里讨论几句，就没有过问每一个人的投入与进度。实际上，这是很错误的，直到真正开始开发的时候，我才发现自己已经翻阅了接近十本书，而大部分组员阅读量还不到半本书。如果从开发的一开始就使用《构建之法》中提到的燃尽图，那么我想情况将会好很多，当然另外就是我没有用心去督促团队里面的成员，事实上这也是一门艺术，《最》也着重强调过。
2、燃尽图
敏捷开发流程中燃尽图是必不可少的，虽然《最》中的主人公看不起这些工具，认为解决好雇佣人的问题就足够了，然而至少对于我这类新手，这种工具用起来真是得心应手。每一天都要求组员汇报进度、耗时，每半周公告未完成任务、completed hours、 projected remaining hours， 这样团队的进度一目了然，再加上目前我对项目开发所需要的技术、所要走的流程都有了较深的认识（得益于之前的学习），这样就能很及时地发现没有完成任务的同学，虽然无法开除组员，但能及时将人物分配给其他组员，规避风险。我认为一个优秀的项目经理，掌握大致的底层知识也是必须的，在目前我也担任类似技术总监的工作，安排每个人的学习任务、编程任务并且指导他们查错，虽然这与初衷相背离，但我能感受到掌握所有知识的好处——组员无法再用你不懂的借口糊弄你。
3、管理项目的思考
在《构》敏捷开发一章接近最后的部分，提出了如何管理项目代码的问题，我也有过切身体会：
1）源代码控制系统——如何控制签入、签出？ 为了避免冲突，需要统计每个人每周有空的时间（因为课程有所不同），尽量按照分组安排修改的时间以避免冲突、每次安排相关性尽量小的任务，实在有冲突需要及时向有关联的小组联系。因为没有用团队项目管理工具，所以我们主要通过交流的形式进行管理。
2）如何看到修改与之前版本的差异？ 这是让我仍然很困惑的地方，github貌似只能回溯版本，而要一览差异却不像是个简单的工作。所以我让组员们将每一次的修改都汇报给我，而我进行管理、追踪。
3）如何合并不同的修改？ 这就需要参与者的面对面沟通，所以在敏捷开发中，频繁地沟通是很有必要的，《最》一书中谈到了交流所带来的效率损耗也是很明显的，因为每一个人就像是图上的每一个节点，随着人数的增长，交流几乎是平 方增长的，这也是为什么小团队容易创造奇迹的一个原因。