构建之法阅读笔记02

软件大多不是一个人做出来的，软件属于一个团队。所谓团队，就要有一致的集体目标，并且要一起完成这目标；团队成员有各自的分工，互相依赖合作，共同完成任务。由此衍生出了各种团队的模式，我认为相对来说比较好的一种模式是功能团队模式，它组内地位平等，效率高，解决问题速度较快。而我更喜欢“秘密团队”，找几个志同道合的同门师兄师妹，针对感兴趣的项目付出极大的努力，具有自由的发展空间，可以根据自己的想法去发明创造，算是追寻最初的梦想。

以前也看到过瀑布模型，它系统地描述了软件开发的流程。但今天我了解到在瀑布下面(即水落下的最低点)会有一个“漩涡”，那就是：发布一个版本并交付给用户后，收集到用户的反馈，立即计划下一个版本，完成后再交给用户……这是一个不可避免的问题。当然，这个问题也有解救之法------MVP(Minimal Viable Product)，使用MVP就可以提前“看见”软件，提交给用户让他们尽早的“吹毛求疵”。

敏捷流程给我的启示是：注重理论与实践相结合，凡事讲究方法，蛮干只会拖延时间。敏捷流程能够帮助程序员看到项目预计完成的时间，团队成员一起工作，自主管理，每日总结，如果成员只是流于形式，不注重方法，就像狗熊掰棒子一样，再好的Scrum Master也会无能为力，摇摇头，说一句“臣妾做不到啊”。

我们的小组也一样，需要把问题放在明面上，拿出实实在在的解决方法，没有理论的方法，离想到解决之道就有很大的的距离(最重要的就是方法论，这也是我最薄弱的地方，同时也是我需要改进的地方)，如此便可尽量缩短解决问题的时间，提高工作效率，就算是掰棒子，也要标上号，写明今天掰了1号，2号棒子，3号没有掰动，明天……