卓越Code团队SCRUM呕心沥血实践总结

卓越Code团队SCRUM呕心沥血实践总结

序言

所属课程	https://edu.cnblogs.com/campus/xnsy/2019autumnsystemanalysisanddesign
作业要求	https://www.cnblogs.com/harry240/p/11524252.html
团队名称	卓越Code
作业目标	（1）团队成员的学号列表； （2）团队成员课程总结； （3）提交资料清单；
码云地址	https://gitee.com/wangbingchao/zhuoyueCode

---

一、团队简介

团队名称：卓越Code

团队口号：宁为代码累弯腰，不为bug点提交

项目名称：基于SCRUM方法实践的西油计科党建设计与实现

姓名	学号	博客园
魏家田	201731062307	https://www.cnblogs.com/dwyy666/
曾文杰	201731062520	https://www.cnblogs.com/zwj-958654064/
魏川程	201731062312	https://www.cnblogs.com/chopinc/
罗伟诚	201731062309	https://www.cnblogs.com/lwcblogs/
杨苹	201731062404	https://www.cnblogs.com/step-enter/
冯俊霖	201731062311	https://www.cnblogs.com/linls/
王柄钞（队长）	201731062518	https://www.cnblogs.com/Slow-Walker/

---

二、课程总结：

2.1课程总结博客

姓名	学号	课程总结博客地址
魏家田	201731062307	https://www.cnblogs.com/dwyy666/p/12015298.html
曾文杰	201731062520	https://www.cnblogs.com/zwj-958654064/p/12019358.html
魏川程	201731062312	https://www.cnblogs.com/chopinc/p/12031781.html
罗伟诚	201731062309	https://www.cnblogs.com/lwcblogs/p/12036243.html
杨苹	201731062404	https://www.cnblogs.com/step-enter/p/12024352.html
冯俊霖	201731062311	https://www.cnblogs.com/linls/p/12017233.html
王柄钞（队长）	201731062518	https://www.cnblogs.com/Slow-Walker/p/12032835.html

2.2具体组员总结文章

2.2.1魏家田：

一、回望

找到课程开始写的第一篇博客，再看当时略显青涩的排版、文字，些许感慨，一个学期又结束了，时光飞逝，转眼大学生活进入了倒计时。

现对当时提出的一些问题，写一些个人看法。

二、有质量的问题

对于问题一：

我想说，对于这句话，在一些简单的项目中，单元测试可以由作者本人来写测试，但是对于一个大的团队来说，会有相关的测试团队吧（虽然没有深入了解过大规模软件开发团队模式嘿嘿嘿）

对于问题二：

编写代码时，我们总是会做出一些假设，断言可能就是用于在代码中捕捉这些假设
可以将断言看作是异常处理的一种高级形式 断言表示为一些布尔表达式，编码人员相信在程序中的某个特定点该表达式值为真
可以在任何时候启用和禁用断言验证，因此可以在测试时启用断言而在部署时禁用断言。同样，程序投入运行后，最终用户在遇到问题时可以重新起用断言。

对于问题三：

我想说，在整个团队开发过程中不是应该先分析整个流程中所需要的技术支持以及知识吗，所以这种情况应该是很少见的，如果像书上所说，那岂不是有可能在工作进行到一半的时候发现有一个任务没有人能完成，那整个工作岂不是白费，或者再招来能完成任务的技术人员，这样会严重拖慢开发进度。

对于问题四：

我觉得，不论是在软件工程项目中，还是在日常生活中，都会遇到某些事情需要作出权衡，在不能所有方面都取最优的情况下，要在各个关系之中取得一个平衡。所以，在软件开发过程中，可以通过质量成本控制，明确量化出开发过程中的成本，例如后面介绍的CMMI理论，即实现了一个定量的软件工程质量等级划分。

对于问题五：

创新，意味着改变，如果是一个团队或者公司已经做到了成功，那么上层领导可能就是认为我这种方式方法是正确的，甚至会形成一种圈子惰性，大家都习以为常，前辈这么做已经取得了成功，那么我就按照这个成功的方法继续完成工作就OK了，而且，如果一旦有人冒头提出改变，阻力可想而知。但是，对于一个初生的团队来说，做出改变的成本就会降低很多，而且想去改变的人也会有很多，因为他们还在摸索一个独特的操作以及运作流程，恰恰是更能创新的。

三、课程心得总结

新的问题：

在学习了这一门课程之后，会不会让我们在熟悉软件开发流程的基础上在以后开发软件的时候更加的具有自己的想法、创意和创新？

掌握技能：

团队协作，交流沟通（很重要）

软件工程项目团队开发流程，包括需求分析、功能设计、算法实现、结构设计、程序调试、软件测试、软件交付。针对不同模式，软件流程也可做相应调整。总的来说，软件流程决定了软件的成败。

课程总结：

通过本学期的软件工程理论学习，以及做的团队项目体验，再加上我是我们整个项目的Program Manager，改变了我长期以来对我这个专业发展方向的很多困惑和误解，我一直觉得我作为一个程序员只要学如何写代码，顶多把数据结构和算法掌握清楚、操作系统和计算机网络的知识学习扎实，会写前端会折腾数据库就可以了，其他的能不了解就不用了解。

通过这个阶段的学习之后我才明白自己其实离一个优秀的程序员还差得很远，光局限自己把代码写好是远远不够的，团队协作、小组敏捷开发、迭代会议、单元测试和代码复审这些部分都是我之前完全不了解的，而在我真正走完这个流程以后，我会更有针对性和方法来实现自己的目标，开始关注踏实的学习和提升自己，并更加注意和身边的同学合作写代码并和自己身边的同学一起互相学习，这也提示我这样的初级软件工程师要如何让自己成长起来。

2.2.2曾文杰

一、回答问题

第一次个人作业链接

问题一

我看到第四章的结对编程，百度了一下什么是结对编程。书上81页说到结对编程是一个相互督促的过程，每个人的一举一动都在别人的视线之内，所有的想法都要受到对方的评价。 当一个程序员处于流模式（Flow），另一个在一旁学习（Learning）——若另一个程序员时不时地打断他，并要求对一些基本的但与挑战性问题没有直接关系的事情做出解释，那么他很难专注于解决挑战性的问题。-引用自（什么时候该采用结对编程）因为两人的能力不一样，相互督促的话起到的作用并不大，同时每个人的想法不一样，有些人就不愿意接受别人评价，碍于所谓的面子。所以我觉得结对编程不仅双方性格要合得来，还要虚心接受别人的意见。那结对编程是利大于弊，还是弊大于利呢？ 我感觉还是利要多点，俗话说“三个臭皮匠，顶个诸葛亮”，团队合作比单打独斗更好一些。

回答:

利:程序员互相帮助，互相教对方，可能得到能力上的互补。
降低学习成本。一边编程，一边共享知识和经验，有效地在实践中进行学习。
可以让编程环境有效地贯彻Design。
增强代码和产品质量，并有效的减少BUG。
在编程中，相互讨论，可能更快更有效地解决问题。

弊:对于有不同习惯的编程人员，可以在起工作会产生麻烦，甚至矛盾。
两个人在一起工作可能会出现工作精力不能集中的情况。程序员可能会交谈一些与工作无关的事情，反而分散注意力，导致效率比单人更为低下。
结对编程可能让程序员们相互学习得更快。有些时候，学习对方的长处，可能会和程序员们在起滋生不良气氛一样快。比如，合伙应付工作，敷衍项目。
新手在面对有经验的老手时会显得非常的紧张和不安，甚至出现害怕焦虑的的精神状态，从而总是出现低级错误，而老手站在他们后面不停地指责他们导致他们更加紧张，出现恶性循环。最终导致项目进展效率低下，并且团队貌合神离。
有经验的人更喜欢单兵作战，找个人来站在他背后看着他可能会让他感到非常的不爽，最终导致编程时受到情绪影响，反而出现反作用。]

问题二

书中第六章的敏捷流程，
知道了什么是敏捷流程以及敏捷流程的问题和解法。
我们怎样能做到敏捷开发？如何提早的交付软件达不到客户的需求？项目人员流动过大，新员工太多如何解决？书上提到时时总结如何提高团队效率，如果时不时的开会讨论的话，会严重影响工作效率，我们怎样制定一份完美的计划来把团队效率和日常工作做得更加完美呢？

回答:

首先我们定义一下是什么敏捷开发：敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。
敏捷的核心假设就是：需求是变化的。
我理解它仅仅是一种开发方法，更是为了应对激烈竞争和快速需求变化的一种价值观和商业模式。
敏捷提倡以人为核心，敏捷注重的是人与人之前的，面对面的交流。

我们在开发时项目经理就应和客户做好需求分析，不能到时候客户又要新增什么需求，又难为开发人员。如果达不到客户的需求，在正式交付之前，继续完善。新员工过多对开发并不是一件好事，我们要合理的安排项目人数。按照SCRUM流程，每日都可以组织一个站立会议，简单复述昨日自己做了什么，以及今天要做的事，进一步合理协调任务的安排。

问题三

第八章的需求分析，什么是需求分析?我们不能盲目的做需求分析，这是软件生存周期中一个重要的环节，我们要知道用户的需求是什么？当用户需求发生改变时我们要如何应对？如果软件都开始到了编码阶段，用户的需求又发生了改变，我们该怎么做？我们是不是要从头再来一遍需求分析？如果是采用瀑布模型来开发，开发到一半时客户需求改变，那你是不是心态爆炸，所以我们该采用哪个开发模式来开发软件？怎样应对多变的需求来做好需求分析与设计呢？

回答：

首先项目经理就要和用户做好沟通，要合理地把用户的需求和开发人员进行交接。如果用户的需求发生改变，我们要评估需求的工作量，对进度、成本带来的影响以及造成的其他风险，并提出针对性的解决方案。召集用户开需求变更评审会，让用户确认一套解决方案。双方在需求变更单上签字。如过在编码阶段发生需求变化，我们应和用户仔细确认是否要更改，同时要计算这个需求改变所引发的一连串问题，计算成本，会不会影响项目进度，反复计算后，再签订需求变更单。目前业界大多已经不采用瀑布模型的方式开发了，其主要问题在于：各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险。早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。我们在开发做一个项目时，就应比对这个项目适合的开发模式，如果需求变更大，采用哪种模式的问题等等。每个模式都有各自的优缺点，我们要合理的了解项目的需求，然后再使用合适的一种开发模式。我们怎样应对多变的需求来做好需求分析与设计呢？尽可能地让自己成为用户，倾听用户需要，理解用户需求，听听用户的解决方案，了解需求发生的频度，模拟用户操作，补全缺失流程。

问题四

第九章的项目经理，如何做到一个优秀的PM?是按照书上所说的做，就可以领导一个项目团队了吗，能让员工真正地服你吗？我觉得并不是这样，一个优秀的PM不仅要有专业的领导力，还要有出众的管理能力，一定的专业能力;还要懂得体贴员工，有责任心，自我约束能力强。

回答：

项目经理是项目的灵魂，项目经理可以说是一个全方位的角色，他什么都要扮演，可能是一个领导者，是一个决策者，也是一个协调者，也是一个代表者，他是这个项目的代表，是一个问题的解决者，也是一个信息的提供中心，更是一个界面的管理者，所以基本上项目经理什么角色都要扮演，有需要，任何角色都要扮演，也可能同时扮演多种角色。 
首先要真正理解项目经理的角色，领导并管理项目团队，依据项目进展的阶段，组织制订详细程度适宜的项目计划，监控计划的执行，并根据实际情况、客户要求或其他变更要求对计划的变更进行管理，注重客户和用户参与。

问题五

第十一章的软件设计与实现，书中223页提到了软件是怎么解决这些需求的？现实世界中的实体和属性在软件系统中是怎么表现和交换信息的？，以及224页的两个类似的问题，只是问法不同，解决方法相同。我们在软件的设计和实现的过程中，怎样才能构建一个与客户所要求的软件类似的模型呢？我们不仅要把需求分析透彻，还要建立多个模型相互比较，选择最优的那个。建立的模型就是把用户的需求所描绘了进去，在仿照模型去编写软件，这样就可以解决用户的需求。在开发过程中，模型出现问题，是否得重新建模，还是在原有基础上加以改进?

回答：在数据库设计阶段，就要做好概念模型的分析，然后再创建合理的ER图和关系模型，最后再建立合适的物理模型。其次是项目经理在和客户沟通时，就要把客户的想法了解透彻，然后做好需求分析。建立多个模型，判断多个开发模式的优缺点，择优选取项目需要的开发模式。如果开发的过程中，用户需求又改变，模型要改变，这样大大增大了开发的成本和进度，我个人觉得不一定需要重新建模，可以在原有的基础加以修改，就能适应客户的需求，如果需求变更过大，不得不重新建模，这要双方进行合理的商议后再签订需求变更条约，才能开展下一步的工作。

问题六

第十六章IT行业的创新，什么是创新？我们一定要盲从吗，别人创新我们就跟着一起创新？如何抓准合适的时机进行创新？都说有了新的就忘了旧的，我看确实是这样。有好的想法确实不错，但是如何把好的想法实施起来？这才是创新的难点。俗话说早起的鸟儿有虫吃，但书中提到往往领导者都不是先行者，这是为什么呢？假如有好的想法，如何去实施然后做到技术上的创新呢？

回答：

首先我们要知道创新的概念，我们也不能盲从的创新，要了解合适的创新思维，抓准合适的创新时机。我们有了好的想法，去构思这个想法能带来什么价值，这才是把创新和好的想法互相结合，才是创新的难点之处。早起的鸟儿有虫吃，这是有双面行的，就是竞争意识.虫就好比是大家（鸟）所追求的目标,你要是早点行动,就比别的人有优势先得到虫.但是这句话也未必是绝对的.有些人可能因为自身能力不足或其他外界因素影响,即使他比别人抢先一步行动也未必成功.不过怎么说呢,你要想有所获得,必须付诸实际行动。有好的想法，也要有强硬的能力，才可以把想法转化成创新点，才可以真正实现创新。

2.经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。

在课堂之上学到了不少关于软件工程的知识，了解什么是软件工程。
了解了一些软件过程模型：瀑布模型、原型模型、增量模型、螺旋模型、喷泉模型、统一模型以及每个模型的优缺点。重点了解了敏捷开发，并应用敏捷开发作为小组的开发模式，为小组的项目开发，完整的实验了敏捷开发的流程，同时也熟悉了个人软件流程，个人在软件开发中要用到的技能有单元测试、效能分析、回归测试等等。在项目开发过程中，需要用到软件项目管理的知识，需要确立项目经理、产品经理，对项目进行风险管理，合理的安排计划并对项目进行评估，使软件的质量得到保证。
和小组一起完成了智慧党建云平台项目的开发，在组长的带领下，让我清楚的了解到了软件敏捷开发的流程、以及什么是敏捷开发、敏捷开发的好处，同时小组成员的任务分工明确，PM合理安排。通过此次的项目，让我了解到团队的作用，也让我认识到了团队协作的重要性。每个组员在团队里各司其职，团结协作，相互激励。

3.有什么深刻的体会，对自己一学期学习过程的总结

这一学期上完这门课，我感觉自己还是学到了许多东西，对软件工程有了更进一步的了解，知道了软件生存周期及其模型的一些基本概念，了解了目前比较常见的几种软件开发模式的基本理论、基本特点，和常见的几种模型：瀑布模型、原型模型、增量模型等等。了解了软件设计分为概念设计和详细设计两个阶段，概要设计阶段首先要介绍软件设计的任务和目标，然后介绍概要设计阶段一些重要的软件设计基本概念。还有就是软件测试的知识，软件测试是为了发现错误而执行程序的过程，目的在于发现错误。软件测试有黑、白盒两种测试方式。测试一般按照四个步骤进行，即单元测试、集成测试、确认测试和系统测试。

学习总是短暂的过程，课堂上学的知识总是很少的，还是需要自己在课后巩固自己课堂上所学的知识点，反复思考利用，才能转化成自己的。在每一次的个人博客作业中，还是收获颇多，既巩固了自己之前的学习的知识或者没学过的知识，也让自己对软件项目有了更好的了解。这门课让我意识到理论学习很重要，而实践更重要，实践是检验真理的唯一标准，只有实践和理论相结合，才能使效益最大化。软件工程的课虽然快要结束了，但是我对软件工程的学习才刚刚开始，有了这些基本知识做铺垫，在以后做项目的时候将会是解决问题的有效措施。同时也更加了解了基本团队模式开发软件的过程，自己开发和团队开发有什么不同之处，也认识到在团队中团结协作的重要性。

2.2.3魏川程

问题解答以及新产生的问题

第一次博客中提到很多问题（“构建之法”--第一次作业-阅读与准备工作）,课程结束也该有个了断了。也许现在的认知还是不能够很全面的回答问题，但是一学期新的磨炼，让我对这些问题有了能够回答的权利。

问题一“深度优先”还是“广度优先”？

其实，这个问题对于不同的人会有不同的答案。没有最好的，只有最适合的。从这门课程的意义来说，有的人精于管理，而有的人更喜欢技术。那么对于拥有一身管理的人来说，就是能够尽可能多的熟悉技术，并粗略了解其实现的难易程度，也就是虽然我不会做，但我能够找别人来做。而对于喜欢钻研的人来讲，他就更喜欢一条道走到黑。我喜欢Java，那么我不仅要用Java做项目看，我以后还要靠Java养活自己。这种人如果不钻研透彻一门技术，他自己也会觉得心里不舒服。也就是我一定要自己做出来。这个问题在我们团队实践过程中也体现的淋漓尽致。所以，川哥，好好考虑自己要走哪个方向吧！

问题二团队模式的选择

首先上一个概要表格吧

团队模式	解释	优点
窝蜂模式	像小朋友踢球一样，球在哪里，人就一窝蜂跟在哪里	欢乐而随意
主治医师模式	像在手术台一样，有一个主刀医师，其他人负责协助主刀医师	一个软件团队中，有首席程序员，负责主要模块的设计和编码，其他人尽可能从各个方面支持他的工作
明星模式	主治医师模式运用到极点	对“明星”个人的成长进步可能会有所帮助
社区模式	由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬	“众人拾柴火焰高”，成功案例：开发和维护Linux操作系统的社区，成功案例往往需要严格的代码复审和签入的质量控制
业余剧团模式	团队中各人扮演各人的角色	在业余玩票、培训的环境中，每个人都可以尝试不同角色，大家可以比较平等地讨论
秘密团队	有一些软件项目在秘密状态下进行，别人不知道他们具体在做什么	团队内部有极大的自由，较高的热情，没有外界的干扰。
特工团队	软件团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题	效率高
交响乐团模式	各司其职，想交响乐队一样	各司其职，重在执行
爵士乐模式	与交响乐模式存在相当多的对立	领导给出一个主题，然后成员们百花齐放，各显本领，快收尾时再总结
功能团队模式	具备不同能力的同事们平等协作公共完成一个功能	效率高

以上表格很明显的区分了各个团队模式应该怎么做，应该做什么。优缺点我也基本罗列出来了。很显然，还是那句话，每个团队模式对应在不同的场景下面，但是很多团队模式也有非常明显的问题，直接限制了大型项目开发和团队管理。如果选用了不合适的团队模式，可能会产生负效率。

问题三"测试危机"

通俗的来说，软件测试是不可能引起危机的，至少这个危机不可能是我这种凡人应该考虑的问题。通过这门课程，我也基本理解了软件测试的范围和原理。测试，就是要把软件全部地方，不管大大小小，看得到的，看不到的，都要进行测试，不管你是两个数相加的这种简单的功能还是机器学习智能算法，都得进行测试，相当于“王子庶民同罪”。软件开发人员就应该和测试人员不是同一个人，这样才能更好的完成对软件的测试，不然可能会自带无数隐形bug。

问题四软件工程的创新

软件工程本就是不断发展着的，就在我敲下这篇博客的时候，软件工程又在他的世界前进了好几年。人类社会对于如何评判一个事务的创新不是看的它的外观（它也确实没有外观），而是它是否符合人类的价值取向。说到底，软件工程就是一种思想，就像马克思主义一样。它依赖于人类的思想而拥有他自己的形态。我认为它已经创新了，对于上世纪的函数式和面向过程编程来说，现代软件工程已经是很先进的思想了，任何事物都是一直处于发展中的。能够降低人们做软件项目的效率就是它进步了，对人类有帮助的就是创新了，这就要看人类对它本身的看法和理解了。但是我认为它创新了，于是它就创新了。

问题五系统重构的“修昔底德”

在国际政治上面，修昔底德陷阱指一个新崛起的大国必然要挑战现存大国，而现存大国也必然会回应这种威胁，这样战争变得不可避免。对于软件结构也是这样，如果新的软件工程思想出现，那么根据原有老的思想建立的工程项目就必然有一天会被进行重新建立。这个时候，重构就成了必然。要做好重构，那就必须拥有一套原有系统。所以原有系统存在的意义就是对重构打下基础，作为重构的目标以及重构后需要实现的最低需要。通过这学期的学习，我也同意作者的说法，重构是减少代码冗余量的最好办法！此时的重构，不仅属于原来项目的维护阶段，也属于新项目的开发阶段。

新学习的技能

学啥啥不行，吃饭第一名。通过这次小组合作开发项目，感觉只是学会了破解PHPStorm。但是仔细想来，这次项目总共用到的技术有ThinkPHP，Ajax，Bui，Bootstrap,Mysql,Apache,Windows
Server,微信开发者工具，Json，GitHub...等等，仔细想想确实没有多少新鲜的。但是在完成个人博客作业的时候，学会了VS中的对C#进行单元测试。最最重要的是，VSCode成为我停留最久的开发器了。但是发现MarkDown还是挺好用的。这应该是这门课学到的最大技能。
  此外，在个人能力方面，也基本了解了结对编程，并在开发项目的时候广泛使用这种方式。团队协作能力得到进一步提示，如何管理好一个团队也渐渐在我的头脑中有一点点的想法了。这应该算整门课程最有意义的地方了。

体会总结

这门课持续得是真的久，我感觉要是全部课程都采用这种模式，学生不还得累死。这种模式的初心我觉得是很好的，不仅能够锻炼自己的编程能力，更重要得是从管理上面学习到一些技能，不说完全掌握，应该能够萌发一下软件管理和团队管理的意识和基本操作了。根据我的观察，其实结对编程很多同学根本没有结对，都是自己编，编完叫队友过来摆拍，但是其实这也是“周瑜打黄盖，一个愿打一个愿挨”，也没有什么好说的。只是想证明，有些时候，这门课程可能太过注重于对博客内容的审核，而没有真正检查到过程。而要检查到过程，本身也是一件非常困难的事情。一边授课，一边写博客，这种形式我可能是还没有适应，给我的感觉就是条条框框很多。能不能达到老师和助教们心中的那种效果，我想，时间已经给出了答案。最后，感谢陈老师的细心指导和助教们的辛苦评审，以及一些看不见真身的幕后工作者。

2.2.4罗伟诚

一、问题回顾及解答

问题一

这个问题是我当初在看书的时候提出的，当时我认为结对编程会浪费人力资源，根本没必要用结对编程。在经过这一学期的学习之后，并且在项目中实际运用了结对编程之后，我想我能够理解为什么了，了解了结对编程虽然是需要两个人，但依旧是有很大的好处的，第一结对编程能够提供更好的设计质量和代码质量，两人合作解决问题的能力会变得更加强，不至于因为一个问题卡半天，两人合作，也有相互机理的作用，第二结对工作能带来更多的信心，高质量的产出能带来更高的满足感。

问题二

经过这一学期之后再回过头来，看这个问题，其实这个模式，我个人认为其实存在于其他的模式中，不可拆分，因为它这个模式就是从大机构的那种组织架构中提取出来的，所以，不论我们在开发的时候采用哪种模式进行开发，都多多少少的涉及到了这个模式，不过单独的将这个模式列出来，我还是认为没必要，我也同小组成员讨论过，他们大部分也认同我这个观点。

问题三

可能当时我去曲解了作者的意思，或者理解的不够彻底，对于秘密团队模式，如果一个人入选了这个团队中去做开发，那么相对于没有入选的人来说，我就在从事一项不为人知的任务，那么其实我们的心理就有一种很高傲的心态，也会很积极的去对待团队中的开发任务，所以团队中的人相对于其他人对于项目就有了更高的热情，也不需要随时随地的向别人报告进度，从而也拥有了极大的自由度，一个团队的成员如果有很大的自由度，又有独特的使命，这就是一个很大的驱动力。

问题四

这一章主要是讲的创新，作者是通过讲了是个迷思让我们来理解我们应该如何去创新，在看书之后，通过我自己的思考，我觉得应该善于大胆假设，要敢想、会想，不要被思维固化，跳出思维的局限待待事物，同时还要培养科学思维，面对同一问题，发散思维，以不同的角度去思考，而且培养创新意识是一个过程，不是可以速成的，也只能慢慢的来。

问题五

结对编程还是需要复审的，通过看书我知道了，复审的意义在于：1.找出代码的错误 2.发现逻辑错误 3.发现算法错误 4.发现潜在的错误和回归性错误 5.哪些地方还需要改进，所以代码的复审还会很有必要的

二、学到了哪些技能及学期总结

a、get到的技能

掌握了敏捷开发流程，这个老师在上课的时候，是给我们详细讲过的，然后我们在实际的项目中也是用的这样的一个开发流程，结合老师上课的讲的和具体的实践，使我有一个深刻的印象，清楚了敏捷开发的整个流程

明白了如何去做一个软件的需求分析，这部分老师上课也是讲过的，因为这学期老师让我们组队做一个项目，在开始这个项目的时候必然先做软件的需求分析，所以也同样是通过实践加老师讲的方式来理解记忆需求分析这一部分

掌握了scrum框架，SCRUM框架包括3个角色、3个工件、5个活动、5个价值。3个角色：产品负责人（Product
Owner、Scrum Master、Scrum团队
三个工件：产品Backlog（Product Backlog）、SprintBacklog、燃尽图（Burn-down Chart)，5个活动：rint计划会议（Sprint
Planning Meeting）、每日站会（Daily
Scrum Meeting）、Sprint评审会议（Sprint Review Meeting）、Sprint回顾会议（Sprint Retrospective Meeting）、产品Backlog梳理会议（ Product Backlog Refinement） 五个价值：承诺 – 愿意对目标做出承诺、专注– 把你的心思和能力都用到你承诺的工作上去、开放– Scrum 把项目中的一切开放给每个人看、尊重– 每个人都有他独特的背景和经验、勇气– 有勇气做出承诺，履行承诺，接受别人的尊重，这些我觉得我们小组做的很好，因为每个学习能力的问题导致每个人的技术能力不一样，可能分配给我的任务以我的技术和经验无法解决，但是其他队友觉得不会怪我，而是会耐心的帮助我一起解决我无法解决的技术难题，我们将整个学期的时间当做整个项目的所有时间，团队中完整包含了scrum框架的三个角色、三个工件、五个角色，在我们做功能开发的时候，也体现了五个价值。

b、总结
可能这门课是我上大学以来唯一的一门不用期末考试的专业课，但是这种上课方式以及教学方式我觉得更能让上课的学生记住这门课需要教会我们的东西，就我个人而言，动手做一遍肯定比上课听纯理论强得多，俗话说：“实践出真知”、“实践是检验真理的唯一标准”，确实也不说老师交给我们的是真理，但是通过时间的方式结合上课理论的知识，可以让我们更快速的消化吸收以及更深刻的理解老师上课所讲的东西，毕竟我们学的如果仅仅是停留在纸面上是没用的，毕竟以后出社会之后，需要的是我们的实战经验，而不是你的理论经验有多丰富，可能有些同学会觉得理论挺简单，但是一旦你让着手去做那么便漏洞百出，所以“纸上得来终觉浅，绝知此事要躬行”，所以我还是非常喜欢陈老师的上课方式，虽然写博客这样的事情真的令人超级头大，但是这样经历过之后，你才会发现你学到了超级多的东西

2.2.5冯俊霖

课程总结

第一次博客地址：https://www.cnblogs.com/linls/p/11503248.html

初学之时，心中疑惑

《构建之法——现代软件工程》p250中提到了用户的体验，这里的体验指的是性能体验还是视觉体验呢？其次当性能与用户体验发生冲突了，这个时候我们是否应该和用户交流让用户选择（以交流的形式为主）还是说做出来两个版本让用户通过使用来选择他最后的使用版本（以实际体验为主）？如果设计出来的系统针对的用户很多的时候那么在性能之间与用户体验之间我们又该如何选择呢？

书中p151中提到了软件的需求，通过了解用户的需求来进行对软件的设计，那么使用用户调研的方式无疑是一种很好的方式。然而使用用户调研的方式，只是了解到用户该阶段的想法，随着开发时间的流逝，如果用户觉得之前的想法跟不上现有的节奏，需要改变需求，亦或者说就连用户本人都不能清晰的提出他对这个软件的需求（只是说了部分界面的要求，多数实际功能描述的很模糊）或者说要求时，那么我们这个时候又应该怎么做呢？换句话说，就是在还未完成上一次的软件需求，这时用户的需求又发生了改变，这种情况我们应该怎么应付？

在第十六章中看到了“效能过剩”这一概念，那么我们在设计过程中到底应该是努力做到我们能做到的最好，还是说做的刚好满足用户需求就行了？就目前市场上的笔记本电脑基本都是性能过剩，不过这样电脑的使用寿命会较之相对长一点。如果我们做软件的时候向制作电脑一样性能过剩，后面用户增多的时候也不需要做太多的改动。而如果当时做的时候就只是刚好满足当下的用户需求，那么后期还会有较大的改动。而如果效能过剩，那么我们软件制作的成本也会增加。因此，在软件设计过程中，我们到底应该选择“效能过剩”的模式还是应该选择“刚好满足需求的模式”？

书中p257中提到了“不让用户犯简单的错”，用一些限制条件将原本很容易出现的失误变为更加困难。从这么一句话中也就是体现出了，程序的功能的实现以及程序功能的使用都是由开发人员通过代码控制实现的。飞机中的工作人员肯定想让呼叫乘务员是真的呼叫乘务员而不是误碰导致的，而飞机中的乘客肯定是想更加方便快速的寻求乘务员的帮助，那么此时我们应该采取“限制的方式”来满足乘务员的需求还是满足乘客的需求呢？

在书中的第六章——敏捷流程，是一种快速开发软件的一种开发方法，这个开发方法的驱动核心是人，需要做到每日一会，报道各自的进程，根据相应的进度，来确定下一天的工作量。那么敏捷开发过程中，团队分工中是一个人做一个模块的好，还是每个模块由几人协商完成？如果每个模块只是由一个人去完成，然而这个人中途出了事故，那么他那个模块的进度不知道的时候，又应该怎么做？如果每个模块都是由几个人一起做，那么，发生思想以及技术中途的时候又应该怎么做？在团队中，不能进行有效的沟通时（万一有人失联），又该采取怎样的措施？

回顾课程，解答疑惑

我个人觉得，用户体验包括了性能体验、使用体验和视觉体验，当性能和使用发生冲突的时候，应该在满足用户对性能最低要求的基础下实现界面的友好性。由于我们开发出来的主要是用户使用，因此我们应该根据开发的系统进行选择，如果开发的系统需要更高的性能，那么我们在必要的时候可以放弃更优的体验效果；但是如果开发的系统对于性能没有较高的要求的话，在满足用户最低性能要求的情况下，可以选择放弃部分性能。

在这种情况下，我们可以使用敏捷开发（Scrum），还可以通过原型工具画出相应的原型，与用户进行沟通，实现对即将开发的系统的一个了解。（详情请见《构建之法——现代软件工程》P108-125）

敏捷开发（agile development）是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

一个产品在其生命周期有不同的阶段，每个阶段有不同的关注点，适时适当的功能点创新，就能改变竞争的局面；而不合时宜的创新，则往往隔靴止痒，事倍功半。在设计中不能一味的追求性能，每个事物都有属于它的生命周期，但是也不能吝啬，要考虑到用户的未来的使用，也就是说要有长远的目光，不能只是局限于很短的一段时间。也就是说不要“刚刚好的满足用户的需求”，也不需要刻意的追求“效能”。毕竟一个软件想要长远的发展下去，需要的是创新，更新换代。

“不让用户犯简单的错误”（Fool Proof）的原则，使用高明的设计，让操作者不需要花费额外的注意力，也不需要经验与专业知识即可凭直觉完成正确的操作。这里对于上面的问题来说，我觉得两者都需要考虑，只是所占比重的不同而已。因此适当和平衡挺重要的。掌握了适当与平衡，就可以恰到好处地把许多看起来非常棘手的事情处理好。适当与平衡，充溢在我们生活的方方面面，无法割断与舍弃。适当里面包含着平衡，平衡里面孕育着适当，两者相辅相成，相映成趣。

敏捷开发主要的就是交流，只要交流沟通到位了，项目一定是比较成功的。Scrum对项目的众多需求采取分而治之的方法，让相关人员集中精力，在一定时间内解决部分问题。它强调的是短时间的迭代，再多次迭代中不断总结，改进团队的流程和产品功能。对团队成员有较高的要求：自主管理、自我组织、多功能型。因此，当开发人员遇到问题的时候，就需要自主学习的能力了。如果发生技术冲突的话，那么通过交流，最终选择一个合理的方案（这里产品经理的作用就体现出来了）。在团队中失联，这就需要通过之前的每日例会了解失联人员的相关工作信息。

新问题

回顾课程，或通过开发过程，或通过看书，或通过课堂学习，将之前的疑问都得到了有效的解决。但是难免产生了新的疑问：哪种创新设计又才会得到人们的认可呢？是不是创新与设计必须应该根据人们的需求来设计呢？

回顾总结

项目实践，获得技能

新掌握的技能：自学，专注，需求分析能力。

途径：通过项目实践过程中的项目开发过程、项目需求分析过程，最终获得了这些技能。

回首向来萧瑟处，也存风雨偶有晴

通过《系统分析与设计》这门课，我接触到了《构建之法-现代软件工程》这本书。这本书中所介绍的NACBD模型、分而治之方法、敏捷开发小组会议和燃尽图、结对编程这些方面的知识点和技巧我们都很好地应用到了自己的项目开发的整个过程之中去。我们通过分而治之的方法，利用WBS图拆分我们的需求，然后利用甘特图，结合每个组员的承诺工作时间把所要实现的所有功能具体化到每一天每一小时；我们在冲刺阶段采用了结对编程的方法，而且还实现了敏捷开发，并完成了至少2天一次的冲刺会议，每个人汇报自己的工作并展望接下来要做的事情，然后完善燃尽图；而且我们团队利用码云托管平台来管理代码，每个人做自己的模块，并保证一天至少merge一次所有人的分支，大大提升了团队协作的效率，每个人都完成了什么工作也是一目了然。可以说《构建之法》这本书对我们的团队的整个开发进展阶段都具有相当强的指导意义，也算是我们进行正式软件开发项目的一本入门引导手册了。

我对于职业规划还一直还停留在学好算法计算机基础就可以进大公司的非常低级的想法层面上，读了这本书之后我才明白自己其实离一个优秀的程序员还差得很远，虽然我一直在努力为实现进入大公司成为优秀的软件工程师这一目标而努力，但是其实努力得还远远不够，而且光局限自己把代码写好是远远不够的，团队协作、小组敏捷开发、迭代会议、单元测试和代码复审这些部分都是我之前完全不了解的，而在我读完以后更有针对性和方法来实现自己的目标，开始关注踏实的学习和提升自己，并更加注意和身边的同学合作写代码并和自己身边的同学一起互相学习，这也提示我这样的初级软件工程师要如何让自己成长起来。这是一本值得反复阅读的技术书、一本可以教会我们怎样去做好一名合格软件工程师的书、一本无论是对在校学生还是一线软件工程师都会受益的书、一本很适合阅读并且反复阅读的书。

2.5.6杨苹

构建之法——最后一次个人总结

时光飞逝，白驹过隙，一眨眼，这学期就快要结束了。这学期过得很快，快的让人不着边际。人们常说，只有当你投入了，把时间过的满满当当的时候才会觉得时间过得很快。我就是这样，觉得这学期过得比大一大二任何一个学期过得都快。今天安安静静的坐在没有人出现的教室里写下这个博客，思考这学期为什么过得这么快，这学期我做了什么，有没有遇到什么不懂的问题，遇到的问题是否都解决了，留下的问题都又是什么，自己能不能解决，在今后再次遇到这些问题，能不能直接解决。这学期结束后，给自己定一个小目标，每当结束一个阶段就完成一个小目标，这样到以后就会发现自己在一步一步提升，一步一步向前进。

这学期很忙，一个“忙”字充斥着整个大三。大一大二学习专业课没有任何动力，都是老师上课讲什么我就听什么，从来都不会花时间去查找相关的资料去“深度”学习。而这学期，遇到了一个很优秀的人，第一次有了想努力学习好好学习的愿望。每天都认真的在专业课上花时间，课后遇到什么问题就立马去解决，绝不拖延到“明天”（以前的“明天”可能是“明天”的“明天”，一直都不会去想办法解决，而现在是立即解决，不让它留到第二天^~^ ^~^），对我来说，这是一个进步，是一个阶段性的跨步，只有每天解决完自己应该解决的问题才能逐步的成长。

这学期的课程《构建之法》，虽然只上了短短的两个月，但对我来说，这两个月来我学到的不仅仅是两个月的知识，当然也不仅仅是一门课的知识，学到的是方法，是适用于很多项目、软件工程的具体的方法。比如在什么时候用什么开发模型，什么情况使用瀑布模型，什么情况又使用增量模型，每个模型之间的区别与联系，这些理论知识都是在这门课中学到的。有人说，我们是软件工程的学生，应该学一些技术上的知识，而不是坐在一个教室听着老师讲一些摸不着边际的理论知识。之前庸俗的我也是这么想的，觉得自己现在需要的不是理论知识，而是一些能上手的技术，比如Android开发、微信小程序开发等这些实用性强的技能。当时什么都不懂的我觉得这些理论知识就是为了凑学分而开设的，而我也是为了得到这些看似比较好得的学分而选修这门课程的。而想象的与实际恰恰相反，我们需要通过做一个实际的项目来更好的理解上课所讲的理论知识。这门课中，因为牵扯到微信小程序的开发，而我又从来没有做过微信小程序，只懂得一点H5，CSS，JS这些开发网站的皮毛的东西，当时的我还是个刚从羊妈妈肚子里出生的小羊羔，什么都不懂。当时组好队后组长告诉我，让我和另一个团队成员负责微信小程序的开发，当时我就蒙了，觉得自己接不下这项单。组长给我加油打气，让我尝试尝试，如果这条路走的好的话，还能学点不一样的新知识嘞，组长把微信小程序开发的学习视频学习资料都发给我，还一直鼓励我，从不催我，当我遇到不能解决的问题时，组长让我在群里说出来，看看团队成员们有谁会的就可以教教我，真的很感谢我的组长。这里还要感谢和我一起做微信小程序的队员，由于一些原因使我不能参加会议的时候，都是他告诉我会议内容和我需要做的事，我这人属于比较笨的人，接受新知识需要很长的时间才能懂，当我有不会做的，他就耐心的教我，帮我做测试，帮我写会议纪要。很感谢他和组长，还有其他团队成员，在这里，我体会了和上一个团队不一样的温暖和谐的感觉。因为团队组长没有给我分配很多工作，给我一个很大的空白时间段让我学习微信小程序的开发，虽然还是有很多问题，但在他们的帮助下页最终学习到很多有关微信小程序开发的知识。

在微信小程序开发中我遇到的问题特别多，如果举例的话，估计今天一天都说不完。这段时间里走过许多弯路，跳进到许多坑里，这些都没让我放弃学习小程序的开发。可能一个非常小的问题，我要花两三天才能解决。当时我开发了一个界面，我需要对两个标题换色，当点击一个标题时，另一个标题的颜色变暗淡，而这个标题字体颜色加深，同时在当前页面出现改标题所对应的列表选项。而当前页面的上面部分不变化，只变化下面部分。当时我就在想这个页面的变化怎么实现，又详情页面怎么响应它所对应的标题呢。于是我把标题对应的详情页面做了一个template，将该标题相对应的详情template引入到active中的详情detail中去，当时在detail.js中定义一个标题数组，使用res.target.id==choiceArray.id，将数组的id与当前鼠标点击事件的id相对应起来后就简单了，但最惨的还在后面，我引用了一个变量，我在template标签中引入了这个变量后，整个页面都不能跑出来。唉，后来我花了两天时间，把各种方法都使用了，开始我觉得template不能被这么引用（当时还是个小白，才开始尝试做的时候），于是又换另外的方式做，后来转来转去还是转到了引用变量这里。（当时我就觉得，跑的了和尚跑不了庙，该来的还是要来，该解决的还是要解决啊）于是我又反过头来解决这个变量的问题。最终，经过我的不懈努力，还是将它解决了。（唉，当时太蠢，在引用变量的时候加了个data，唉，蠢哭啊！！！）这只是其中的一个小插曲，在开发小程序的过程中出现了很多问题，像申请权限啊打开通讯录什么的，问题一大堆一大堆的，在度娘的帮助下最终还是解决了。

这段时间过得很充实，突然发现，忙起来的感觉还是挺不错的。我的马原老师李蒙李老师曾经说过，“每个人都有闪光点，只是自己现在还没发现罢了，人呀要善于找到自己的闪过点、找到自己的长处，当一个人把他的闪光点发挥到极致的时候，他就离成功不远了”。可能我不是一个天生的编程天才，我的闪光点也不是在开发项目上，但我希望我能变成一个不辜负大学美好时光努力的幸运儿。

2.2.7王柄钞

二、问题回答

2.1问题1：针对单元测试

怎么保持单元测试的孤立性呢，假如测试方法中的参数过多就会造成在被测试方法业务逻辑复杂，而且会频繁调用其它接口，他的优缺点具体有哪些呢？

课程学习回答：通过本次的课程的学习以及后面的单元测试项目实践、以及最后的团队项目实践都用到了单元测试，也较为深刻的掌握了单元测试的方法以及他的测试，也深刻的体会到了他的优点缺点；首先是采用自顶向下的单元测试策略，解决单元测试孤立性问题，实践的步骤如下：

（1）以单元组件的层次及调用关系为依据，从最顶层开始，把被顶层调用的单元做成桩模块。

（2）对第二层单元组件进行测试，如果第二层单元组件又被其上层调用，以上层已测试的单元代码为依据开发驱动模块来测试第二层单元组件。同时，如果有第二层单元组件调用的下一层单元组件，则还需要依据其下一层单元组件开发桩，桩的数量可以有多个。

（3）依此类推，直到全部单元组件测试结束。

项目中体会到它真正具备的优点个人总结如下：

因为单元测试是直接或间接地以单元组件的层次及调用关系为依据，所以可以在集成测试之前为系统提供早期的集成途径。由于详细设计一般都是自顶向下进行设计的，这样自顶向下的单元测试策略在顺序上同详细设计一致，因此测试可以与详细设计和编码工作重叠或交叉进行。

相应的自己也能感受到他的缺点：

测试过程会复杂，因为要开发驱动模块和桩模块。由于需求变更或其他原因而必须更改任何一个单元组件时，就必须重新测试该单元下层调用的所有单元。

2.2问题2：敏捷开发

针对于复杂的开发确实很有用，回想之前自己开发的几个程序，只是简单的执行，使用敏捷开发并不适用，简单的东西也许敏捷反而不敏捷了？

针对这个问题，确实如此，通过本次的对敏捷开发的学习与具体的实践，真正明白了他的实用的地方，也真正领略了他的魅力。确实对于小项目不用敏捷开发，比如就我自己一个人写的或者就我和我的小伙伴两个人的项目确实不适合，首先是针对敏捷开发起码最少也是三个人，敏捷的含义就是最注重沟通解决问题，两个人之间也很方便，反而增加这样一个流程会显得很麻烦，这样的小规模软件开发可以用原型开发或者边设计边改的模式就可以。

然而对于一个具有工程性需求不明确随时在变动的项目来说，敏捷开发就能真正的恰到好处，因为他天生就是给需求变动的项目设计的一种软件过程，他的三个角色以及里面的三个工件甚至每一个活动，现在真的能够体会到他设置的相应的意义，缺一不可。

2.3问题3：代码重构

然而现在对重构还有似乎疑惑，针对何时重构，在刚刚开始开发的时候应该在那些方面应该考虑后面的重构？

针对这个问题自己也确实感觉当初想的还是很好这个问题，对于一个软件的开发之前就考虑重构的思想，这样虽然在开发时期会比较费时、但是对于后期二次开发该是多么大的一件幸福的事啊。针对我们团队的项目我就在开发之前综合考虑了我自己设计的每一个小功能模块，尽最大能力遵从运用设计模式的思想，综合考虑了单一原则、开闭原则、里氏替换、依赖倒转、接口隔离、迪米特法则、合成复用原则。

比如我在设计党员管理和党员的里面接口时候就充分用了依赖倒转、接口隔离的原则也基本实现了低耦合高内聚的效果，里面在积分管理以及添加的时候运用到了观察者模式，以及在书记信箱的里面也用到了单例模式。确实在设计的时候要综合考虑各个接口之间的关联关系，看看这个业务逻辑能不能用设计模式的具体案例来优化，我想这也是我在这一门课程中实践到的最终要的一个思想。

2.4问题4：用户的角度参与测试

可以加一种测试方法，就是将用户和测试人员相结合的方式一起进行测试，这样的话通过用户的角度就能够更多的去发现问题，同事在他们测试过程过程中，也能让他们发现问题，并及时解决问题，不至于到最后交付项目时候出现偏？

确实是如此也真的感觉当时考虑的很全面，我们在团队项目的过程中，每一次的自己任务开发完成就会进行自己的单元测试，其次我将大家的代码整合到一起后我也会进行集成测试，乃至到每个冲刺版本结束之后我们也会对我们这个阶段的完成的功能模块进行全部测试。确实我感觉这个只是我们开发人员你的自己测试还有一些不完美的地方是通过我们的角度是发现很困难的。

因此我们将我们的学院领导微信添加了开发者模式，让他们站在用户的角度来试用我们的最近开发的模块的功能，他确实就能在这个体验过程中给我们提很多问题（其实第一次邀请他来的时候他在夸赞了我们的实现效果了之后，给我们提了超多一件，说这里要改哪里要改，瞬间觉得他前面的话是故意说的），没办法他是领导确实我们做的不够完美，虽然我们程序员确实都不愿意看到自己的代码出现错误，但是却是人家给我提的问题确实是问题在哪里。好在我们还是按照用户（领导）的意见更改了，也基本达到了要求，到最后beta版本交付的时候确实他就再也没有提出什么问题了，因此交付的也非常成功，也确实源于前几次冲刺版本他的意见帮助。

2.5问题五：什么是软件工程创新

针对软件工程开发领域创新到底什么样的才叫创新？要达到什么要求水平才能称得上创新？新的开发技术的出现算是软件工程的创新吗？

个人觉得当时提的这问题还是有点点大哦。但是学完这门课程确实有了不一样的理解和体会。我感觉针对本次项目的实践的scrum流程，他当初由人家创造的手这也是创新，他产生的原因就是解决其他软件开发模型解决不了的问题-需求变动较大、需求不明确的问题。个人觉得如果要算创新，起码是其他没有这种思想而重新生成的产物才叫创新，我感觉如果能够结合各个软件过程模型的优点避开他们相应的缺点，从而定义出了一种新的软件过程模型能够对软件开发过程中解决实际的开发问题，这样才能算创新，比如设计一个瀑布+敏捷折中的软件设计模型，这也是一种创新。

我个人认为新的技术上的产生真的不是软件工程的创新。个人认为应该是致力于提升软件工程管理质量、明确计算机软件工程管理内容等方面的创新才是软件工程上的创新。原因是新技术是日新月异的，随时更替的，并不能对软件工程这样一个工程性的思想性概念产生太大的影响。

三、新提问

实践的具体过程中体验了敏捷开发具体体验到了那些他的优点，具体应用在哪？

针对本次的实践真正发自内心的感受到了敏捷开发的优点：

体会优点	具体感知
更大的灵活性和稳定性	我们后期需求针对不明确，在一直变化，这样一个开发过程满足了我们后期开发的变动
更高的质量，更快的交付	我们细化了每一个冲刺版本、具体到我们每一个冲刺订单到每一个人头上、使得大家更加的明晰了自己的任务、达到了最大的效率和质量
提高团队绩效	在每次立会的时候大家都会总结过去几天的不足，这样真得能够提高大家在下一个阶段的开发效绩
简历持续改善的文化	在这里我们团队也有相应的惩罚和奖励文化，形成了自己的一套团队文化，激励大家不断向前
更高的客户满意度	因为分了版本我们每期结束都跟学院领导进行了交互，这样用户就能时刻看到我们的进度提高了对我们的满意度
更高的队员满意度	大家每天虽然遇到很多困难和绝望但是在每次自己工作完成之后都能看到大家对这样一个开发流程还是很满意，因为大家都做出了自己的成绩
失败成本更低	相应的我们严格按照这样一个流程即便中间有些延误我们也进行了相应的调整、最终成功交付了项目

四、课程实践总结

终于这一次也是我这门课程最后一次写博客了，不禁感慨当初助教开始布置的那么多作业。回顾这门课程经过了个人实践团队实践，真的也明白了为什么陈老师要申请这门课程不考试的原因了，确实真的好有道理。感悟很深自己也对自己分三个方面总结一下自己：

（1）专业技能的提升：说实话微信开发第一次做这么大的作品，之前做过很多开发，包括c#桌面开发，java高并发开发、一致到这次tp5开发，后端从零到各个功能的填充完成实现，不禁感慨我的队友们当初的仅仅是为了钱来开发这个项目（学院资助），当初想想都不可能实现的任务，曾在这门课程开课选题时候都想着给大家选一个简单的，然而最终还是选择了这个。真好，这次自己也是做小程序后段的，我的开发过程也是在本地搭的微擎服务器，一步步用thinkphp5的框架进行，其实之前还不是很熟这个，但是慢慢的这门课程之后对PHP也就更加熟练了，一致与从微信开发到最终发布的这样一个流程自己心里都有一个较为明晰的过程，确实自己的动手能力也增加太多了。

（2）工程实践认知技能提升：说实话我之前听过瀑布敏捷原型螺旋这些软件模型、也去了解过他的公司的实际运用情况，但是真的没有这次亲身体验震撼scrum这样一个过程的深刻感受。其实陈老师在课堂上也转们花了一次课讲敏捷，那个时候我也就大概字面上知道他的优点或者内容，但是真正的花了三个月去搞它真的感受不一样。

估计自己这一辈子都记得到他的三个角色三个工件五个活动，原因就是真的亲身组织和经历了这样的一个过程、经历了无数次日日夜夜的实践，折服于这样一个软件开发思想，把各方面都想的很到位。在本次scrum的角色中自己主要是担任master的角色，自己也深刻的体会到了master的肩负的责任，首先是自己要严格要求自己，才能严格要求他人，我们队友们大家都要兼顾学习，然而我们还是严格三天开一次会议乃至到最后形成会议记录真的太不容易了。我也有幸自己能在这样一个团队里面担任领导者来亲自组织大家做这样一个事情，收获得太多太多。。。

（3）个人领导力团队管理提升：从大一以来到大二以至于到现在，自己也真的愿意和想去做这样一群支持自己的小伙伴的领头羊，带领团队总结经验永争第一，即便没有达到也不后悔。

前两天有两件事特别深深感触了我，第一个就是我身边的小伙伴他们自己报的一个科研项目，然而大家都是轮流来当组长，起初我还是以为他们想互相锻炼，结果他们是以抽签的形式相互推诿的形式，其次是另外一个小伙伴他们要做一个课程设计的汇报，小组内竟然没有一个人愿意去当这样一个组长去牵头做这样一件事，大家都等着。唉，回过头来不禁感慨，这样的话这个大团队还怎么发展怎么能够冲在最前面呢？

自己也思考自己一直做领队的经验有成功也有失败，成功是最大是源于队友的信任与支持，更包括自己全新全意的为整个团队付出不留所有。本次scrum课程实践也是一样的，虽然自己团队里面各方面技术的人都有比自己厉害的，但是自己依然愿意敢这样的一个勇气去担起这份责任，跟随大家一起进步我想有担当能接受失败、善于总结经验、将心比心团结队友这也许才是最重要的。

---

三、卓越Code-文档整理

3.1资料清单

3.1.1 西油计科党建-汇报PPT

西油计科党建-需求分析.pptx

西油计科党建-系统设计.pptx

西油计科党建-结题汇报.pptx

3.1.2西油计科党建-设计文档

西油计科党建-选题报告.doc

西油计科党建-需求规格说明书.docx

西油计科党建-数据库设计说明书.docx

西油计科党建-概要设计说明书.docx

西油计科党建-详细设计说明书.docx

3.1.3西油计科党建-scrum实践记录

21次立会记录情况

会议记录照片

五次sprint燃尽图记录情况.xlsx

3.1.4西油计科党建-源码及其发布教程

网站源码

小程序前端源码

小程序后端源码

网站发布教程.docx

本地微擎搭建教程.docx

小程序后端微擎部署教程.docx

微信后台审核发布教程.docx

3.1.5西油计科党建-软件使用说明书

西油计科党建-软件使用说明书.doc

3.2 Gitup下载地址：

因为里面涉及到了党建的一些材料比较私密，所以本次提交用的国内代码服务器提供码云地址如下：

https://gitee.com/wangbingchao/zhuoyueCode.git

---

四、发布疑惑咨询

欢迎后期有学弟学妹能够测试学习我们的代码，但是尽量保护我们源码哈，如果有网站发布、微信发布、后端微擎开发的问题欢迎咨询qq:1432678283,电话17381592101王Mr.