《构建之法》CH5~6读书笔记 PB16110698 第九周（~5.15）

　　这段时间我阅读了《构建之法》的大部分章节，包括个人技能、软件测试、用户体验和需求分析等相关内容。之前的个人作业和结对作业结束后，我们的工作重心终于转向了团队项目，作为团队中前端组的组长，我和组员们每周碰面、共同商讨团队项目细节并一起实现。因此，书中与团队项目开发有关的第五章、第六章的“团队和流程”“敏捷开发”两部分内容最令我印象深刻、受益匪浅，本次读书笔记主要记录阅读这两章的心得体会。

　　1、团队模式和开发流程：

　　团队项目的开发与团队工作模式（分工模式）和整体开发流程息息相关。我们的团队在决定开发模式时，考虑了各同学的能力和知识储备，结合我们团队项目“做BBS”的特点，将7人小组分为前端组（4人）、后端组（3人），并分别设定前后端组长进行小组工作的统筹安排、任务布置。书中谈到了很多种团队分工模式，如欢乐随意的目标追逐模式（一窝蜂模式）、主力担重任模式（主治医师模式、明星模式）、社区志愿模式和业余剧团模式等。在我看来，我们小组的团队模式比较像低配版的交响乐团模式，整体设计思路都是分而治之、各司其职，完成任务、相互配合，但我们作为开发实践经验基本为0的学生，知识量、技能储备等等各方面都还十分捉急，时常边学边做、边做边学，离“演奏靠谱、练习多次”的专业交响乐团模式还是有不小的差距。总而言之，我们的团队采用了一个在我看来还算比较科学合理的分工模式，能让每个人发挥才智、各自分工、互相依赖合作、共同完成任务。

　　开发流程方面，书中介绍了业余的Code-and-Fix模式、较专业的瀑布模型及变种、统一流程、老板驱动和渐进开发流程。回想我们的团队项目，虽然刚刚起步，但也进行了一定程度的开发，在这些开发过程中，我们采用的模式比简单的“写了再改”要好一些，但远不如瀑布模型、迭代模型专业。我们进行了需求分析、架构设计、知识储备和框架熟悉，但详细设计没有整理成详尽的文稿，整个项目的时间轴要求也不太明确，这是因为我们经验不足、对项目的整体把控不太有信心。但我们的组员责任心和热情比较强，在得知需要完成的主要工作任务后，能积极投入、奋力实现，目前项目开发工作初步进行得还算顺利。本周组会上，我们会进一步细化项目细节需求，把每一个页面的布局设计、动画效果和功能等等细节都敲定，且定下切实可行的工作计划，尽量向专业、成体系的开发流程看齐。同时，在将来交付团队项目时，还要注意迭代开发、积极反馈和改进，任重而道远。

　　2、敏捷思想和敏捷团队：

　　关于敏捷开发的内容，老师在课上、班群里都已反复强调无数遍，读过的软工相关书籍里基本必备这一内容，“小步快跑、沿途下蛋、快速迭代”等字眼也司空见惯了。敏捷思想其实在我们之前的课程中已经充分体现了，单人作业中要求我们快速掌握文件夹检索、不同操作系统间兼容编程，结对作业中要求我们迅速学习UI开发、dll发布等，让我们通过实践体会到了做中学、做后改、敏捷开发。在我看来，敏捷开发其实非常考验个人的主观能动性，若程序员有热情、有兴趣、有责任心，那么敏捷开发能让他快速成长、高效编程；若程序员比较怠惰、佛系，那么敏捷开发的要求只能让他压力巨大、步履维艰。说到底，态度决定一切，敏捷开发不但是一种方法论，更是一种价值观，只有主观态度上积极主动、追求敏捷、乐于提升，才能真正实现敏捷。

　　敏捷团队，只有三条要求：自主管理、自主组织、多功能型。作为学生，我们的团队在敏捷开发方面其实有一些得天独厚的优势，比如我们的空闲时间比较一致，能保持频繁、及时的面对面交流讨论，开发过程中可以预约研讨室坐在一起共同工作，学习新技术时能交流互补等等。在我看来，“自主管理”方面各团队都做得比较好，毕竟老师一开始就表明态度、当甩手掌柜，每个团队项目的选题、调研等都是我们自己完成的，也都通过较频繁的组会进行工作安排、反思，实现自我管理；“自我组织”方面主要看组员的自觉和责任感，我所在的小组里，大家的热情和责任心还是非常OK的，安排任务时都会主动接锅，出现问题也愿意主动排查，十分具有“自我组织”所需的贡献精神、主人意识；“多功能型”方面，我们虽然进行了前后端分工，但整个项目的框架设计、博客编写甚至美工等均由所有组员共同实现，每位同学都是多面手，这也是出于“人手不多、不得不做”的现实考量。当前我们团队的敏捷开发只需要三步：发现问题，找到办法，做。将来发布alpha版以后，还需增添一步“改进和迭代”。总而言之，我们会尽量构建一个高效的敏捷团队，小步快跑，快跑。

 

　　以上阅读内容和反思，让我对团队项目的分工模式、开发流程、工作思想等有了更充分的认识和考量，在日后的团队项目开发中，我会尽量以书中提及的规范、高效流程和思想来要求自己、督促团队，力求成功。