六月上旬心得体会

在五月末的时候，老师针对我们团队的状况提出了几点建议和解决方案，而这半个月里，我们尝试性地运用了其中的几件工具与方法。

1、燃尽图与每日总结

　　我们采用的是《构建之法》书中的燃尽图模型，通过 Projected Hours 与 Remaining Hours 观察团队的活跃度以及所能支配的时间。这一种模型不大适合我们的团队，因为它甚至敏捷开发都是基于一个有强大向心力的、能力都比较强的团队而设计的，这显然不适合像我们这样临时拼凑，不久便分道扬镳而且水平参差不齐的团队。不过我仍然学习到了很多东西，对于一个优秀的团队，燃尽图是一个不错的工具，它能时刻提醒组员尤其是 PM 一周剩下的支配时间，再结合团队项目的进度，便能对计划完成的程度进行预估，并作出相应的调整。而每日总结则是激励每一个组员强有效的方式，每晚每人相继汇报自己完成的工作，对于不做事情的成员是一种压力；这也是进行绩效评估的依据，在一周末的组会中公开考核成绩的时候，滑水的成员也难以找到求分的借口；这还是评估任务进展最有效的根据，当某一个成员的进展落后时，稍微敏感一点的 PM 都能察觉得到。一个很不错的成果就是以前一直滑水的两个队友，终于开始参与团队项目，大概在科大 GPA 是能让鬼推磨的神器吧。

2、任务板

　　我们曾尝试性地使用过这个工具。任务板的想法是不错，我也能感受到它的魅力，但是并不适合我们现在的团队。在实践的时候，它能很明晰地展现出任务的流程，能体现出对团队最重要的关键节点，还能体现出团队项目的进展，想象这样一个场景，每一个努力的员工在清晨、傍晚都看看团队的任务板，那么每个人都能知道团队的进展，并督促自己完成最重要的任务。但是它凑效的前提是：成员都在一个相对固定的地点。显然，因为我们的成员是分散的，而即使是聚在一起编程的时候地点也是一直在变化的，任务板的魅力也因此大打折扣了。

3、GitHub管理

　　以前我感觉用QQ文件管理的方式就挺不错，每个人有一点进展，标注上修改的时间就可以发到群里，这样交流也很方便，不过 GitHub 提供得更多。

　　分支管理——1）随时都有可以发布的版本 2）*地合作开发分支，避免了对主项目的冲突。

　　修改管理——提交时通过comment注释修改的内容，一方面便于回溯，另一方面也能体现项目的进展

　　在实践当中，GitHub就像一个施工地，随时都可以随心所欲地修修补补，而QQ群则不然，修改一个细小的地方都要将整个项目下载、打包、上传。

4、面对面地合作编程

　　面对面的交流总能更快地解决问题和传达思想。1）经常我在QQ群里强调了好几遍的东西，队员们也会忽略掉，大概是 QQ 已经成为了吵杂的代名词，大家都已经习惯了忽视这一台不停嗡嗡作响的机器。然而面对面的时候，我能根据每个队员的反应，推测出他们是否真的Get到我所要传达的最重要的东西。2）每个人掌握的知识是不一样的，在一起编程的时候，总能更快地解决问题，而不是一两个人在一边瞎忙活一下午还不敌另一个人几分钟的指导。

　　面对面是敏捷开发的前提，敏捷也不是所有的团队都试用，老师在考量推广敏捷的时候应该谨慎它的前提条件。

　　软工教给我了许多东西，尤其是团队方面的，让我深刻体会到建设一个团队的重要性，也学习到了其中的些许方法。虽然我以后很有可能不会进入程序猿的领域，但是管理团队所积累下来的经验以及管理项目所采用的工具能让我终身受益。剩下时间所能学到的东西可能就比较少，不过就算是给自己的项目画上一个完美的句号了吧。