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

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

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

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

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

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

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

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

 

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

posted @ 2018-05-18 10:49  CGYR  阅读(184)  评论(1编辑  收藏  举报