Beta以后的想法

软件工程若是没选实践，单纯在理论课上面对教条化的理论，这些理论都是颇有指导意义的，但没有实践课带来的切实的多人团队合做开发项目的实际体会，很难能领会到其中的深意。知行合一，才能发现软件工程里的知识都是有用的经验之谈。

不要认为一切将运做良好

缺少合理的进度安排是形成项目滞后的最主要缘由……它反映了一种不真实的假设：一切都将运做良好

软工的工做量确定是大学以来最大的一个实践课，须要选课的同窗端正本身的态度，若是想要实打实地完成一个质量尚可的项目，要投入的精力确定是不能少的。软工不是写写程序这么简单，这门实践课设计了一系列的环节，好比组队、立项报告和调查、资源规格说明书、UML绘制、现场团队编程、两次冲刺、展现答辩。能够发现写程序占比并很少（这和真实的软工过程也是类似的），一些在软工课以外绝对不会去作的事项，正是帮助你了解现实状况下的多人合做软件开发。

每个环节想要作好，都须要去真正地投入精力。最开始的博客做业会问你，每周打算投入多少时间。其实这个问题就是让你作好准备，由于这是一个硬指标，不投入较多的时间确定只能作出平庸的结果。拿团队组队选人举例子，寻找一个合适的团队是极其重要的，最后没组到队的人被迫造成一个小组，这个组的结果通常方方面面都不会使人满意。我一开始也不知道要怎么寻找队友，寻找怎样的队友比较合适。因而我询问了学长学姐这方面的经验，而且花时间写了一个招聘文件，最后组建了一个至关不错的团队。

在立项、资源规格说明书、UML的绘制中，整个团队对于脑海里想要作的软件的构想会逐渐清晰，但这里要注意的是团队的成员必定要加快学习的进度，尽早开始写代码、产出产品代码，尽早开始迭代、测试、发布产品。

计算机编程基于十分容易掌握的介质，编程人员经过纯粹的思惟活动——概念以及灵活的表现形式来开发程序。……咱们期待在实现过程当中不会遇到困难，所以形成了乐观主义的弥漫……而咱们的构思是由缺陷的，开发也总会遇到bug的。

团队在讨论的时候，经常会出现这种状况：“这个功能很简单的啦，建一张表，有XXX字段，到时候查表就好了”、“这里我就构造一个json发送给你你到时候接着就好了”。就是脑中构思程序逻辑并不困难，但实际开发中总会碰到这样那样的问题。我想了下，这实际上是一种客观现实，咱们应该理解并学会接受。能作到的只有提前开始学习相关知识，提前开始开发。由于是必定要遇到困难、遇到bug的，留足学习的时间，提前开始，才不会赶deadline，才能够从容不迫。

人月

跟书名同名的经典理论，在这里简单复述一下——人月做为衡量工做的规模是有欺骗性的神话，向进度落后的项目添加人手只会使进度更加拖延。这条理论十分有名，致使我在上软工课以前都提早去了解了一下。

通过团队现场编程的磨砺，让我明白了这条理论在多人团队合做中有一个背后的意义。书中所说，添加人手所增长的负担在于培训和相互交流成本，任务不能彻底分解给参与人员而不增长他们之间的交流成本。能够得知，培训、相互交流、合理地分配任务在软工中扮演极其重要的位置。

培训：大多数同窗都没有实际的开发经验，因此须要熟练工或者学习能力比较强的同窗带领你们在项目初期的时候开启有效的学习、实践。由于初期你们都是小白，尽快学习知识，使大多数团队成员从小白成为能够产出代码的项目组成员，这十分有意义。在我看来，这确定是软工实践区别于其余实践课的一点。1、之后你们走上工做岗位，将来的软件开发团队，也确定有leader，每一个人技术有高低之分。若是本身是leader，如何带领你们前进？若是本身实力较弱如何提升本身的学习能力？都颇有意义。2、学校里其余实践课能够存在抱大腿的行为，软工是一个可让你们真正体验为一个目标共同努力的过程。你们水平有高有低，但通过个人努力，后端组全部成员均可以上手写代码并commit，这是我很是自豪的一点。

交流：交流的成本是很大的，因此初期要谨慎地考虑分工。到了项目真正开展的时候要考虑一下团队的结构，好比，有没有技术leader？团队成员怎么分组？PM怎么和不一样的开发人员交流？使用什么手段来使团队成员有效地交流想法和问题？

合理地分配任务：这学期因为栋哥跑路，本来三个班的选课人选挤到了两个班，致使每一个组人都会变多。人变多了，交流的成本就会变得更高。还有一个额外的问题就是，做为在学校里的软工项目，其实你们作的事情不会差异特别大，但人多了，要保证每一个人的贡献度，要如何分配每一个人都有合理的任务量能够作呢？这是一个须要考虑的问题。

外科手术队伍

能够说咱们在实践中基本采起了这种团队模式。

队伍成员	《人月神话》中的描述
外科医生（首席程序员）	首席程序员，亲自定义功能、设计程序、编制代码、书写文档、测试
副手	外科医生的后备，详细了解全部的代码，能完成任何一部分工做。
管理员	外科医生的老板

PM就是管理员，他除了PM常见的职责以外（负责组建团队、划分工做、督促进度、保持和团队成员的沟通）。他还常常参与先后端、数据库的开发，虽说他不负责核心开发工做，但能够说PM真的对整个项目有至关程度的了解和把控做用。能够说是十分合格的PM。

在外科手术团队中，外科医生和副手了解全部的设计和所有代码，并确保概念上的完整性。

在传统的队伍中你们是平等的，出现观点的差别时，不可避免须要相互讨论和妥协让步。但在外科手术团队中，不存在利益的差异，观点的不一致之处能够由外科医生单方面来统一。

概念的完整性要求设计必需要由一我的或者很是少数、互相有默契的人来实现。……对于大型项目，将设计方法、体系结构方面的工做和具体实现相分离时得到概念完整性的强有力方法。

外科医生是前端组和后端组分别有两个leader，两位leader能够保证代码的产出效率。我是后端的leader，后端组4名成员中有一个得力副手，剩余两位在项目初期的时候处于较缓慢的学习进度中，但通过努力均可以真正地产出代码或文档，或进行测试。PM在开会时常会讨论需求；全体成员能够一块儿讨论初步接口、数据库、代码逻辑等构思，但最后通常都是PM和Leader统一敲定，给出正式和清晰的定义；PM和leader对任务进行合理的划分，其余的成员执行PM和leader交付给他们的任务；每一个人都要承担本身的义务，PM和leader要确保你们不拖延和妥协。

从项目结构上和合做方式上说能够说这是一个很是良性的团队。这是在项目冲刺时天然而然地造成的，不得不说软工的理论确实仍是很是有道理的。

文档、编程手册

我以为本身作的最有意义的一件事情就是在项目过程当中造成的学习文档。后来重看《人月神话》在第七章才发现其实这个叫“工做手册”：

• 工做手册是外部规格说明、接口说明、技术标准、内部说明和管理备忘录。
• “将来产品”的高质量手册，将诞生于今日的备忘录。正确的项目工做手册，能保证为阿里的文档结构的规范而不是杂乱无章。
• 工做手册是每个编程人员应当了解的全部材料。
• 工做手册的实时更新是很是关键的。

贴几张图展现一下：

在过后读《人月神话》看到对应的内容，这代表了我在事先不知情的状况下作了一件实际上是符合软工理念的事情。但最让我高兴的是“alpha过后诸葛亮”时，个人队友对我表达的感谢。这让我感觉到了本身作的事情是很是有意义的，我体会到了什么是真正的合做，什么是真正的软工。

（王源）我感谢赵畅对个人帮助， 由于某个具体的事情: 共同爆肝编程解决了从部署到接口逻辑到代码的诸多问题。他提出并一直在努力维护的技术文档也为我和其余成员省下了许多debug的功夫。

（展瑞）我感谢赵畅对个人帮助， 由于某个具体的事情: 带领我进去后端框架的学习，而且帮助我梳理了整个后端框架，以及postman的工具使用；在我自闭的时候积极鼓励我。

Beta吐槽

Beta冲刺过程当中团队成员出现了必定的懈怠状况。

1. alpha冲刺过了快一个月，你们紧绷的神经放松了下来。还有就是隔了一个月发现本身忽然不会打代码了
2. beta期间存在着考试，复习的安排，以及毕竟已经有了alpha版本，对于将来的新功能不是特别的着急了。这也符合历年课程中你们认为alpha环节对本身提高最大的状况。
3. 其实本身的动力也是降低了吧，其实明明本身构想好了很cool的功能没有去作，因为没有像去年栋哥那样强制布置推广给真实用户，因此咱们目前没有推广给真实的食堂店铺店主使用，其实也是本身没有去推进作这个事情，（如今要准备考试也不打算去作）能够说是一个遗憾。