Beta之后的想法

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

不要认为一切将运作良好

缺乏合理的进度安排是造成项目滞后的最主要原因……它反映了一种不真实的假设：一切都将运作良好

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

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

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

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

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

人月

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

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

培训：大多数同学都没有实际的开发经验，所以需要熟练工或者学习能力比较强的同学带领大家在项目初期的时候开启有效的学习、实践。因为初期大家都是小白，尽快学习知识，使大多数团队成员从小白成为可以产出代码的项目组成员，这十分有意义。在我看来，这肯定是软工实践区别于其他实践课的一点。一、以后大家走上工作岗位，未来的软件开发团队，也肯定有leader，每个人技术有高低之分。如果自己是leader，如何带领大家前进？如果自己实力较弱如何提高自己的学习能力？都很有意义。二、学校里其他实践课可以存在抱大腿的行为，软工是一个可以让大家真正体验为一个目标共同努力的过程。大家水平有高有低，但经过我的努力，后端组所有成员都可以上手写代码并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的功能没有去做，由于没有像去年栋哥那样强制布置推广给真实用户，所以我们目前没有推广给真实的食堂店铺店主使用，其实也是自己没有去推动做这个事情，（现在要准备考试也不打算去做）可以说是一个遗憾。