2017-2018-1 Java演绎法 小组会议及交互汇总（不定期更新）

Posted 2020-10-15

第一周会议

　　今天我们小组开展了第一次团队例会活动。我们小组将《构建之法》分为了六个部分并由六位成员先分别学习并向组长上传学习收获，这次的活动内容便是 交流前两周小组成员学习阅读《构建之法》的收获。
　　在各位成员的交流中我们将自己所读的这部分内容的总结与其他人的进行交换，从而对自己还没有读到的内容有一个大致的了解。其中组员刘伟康提到的我们要形成 “交响乐队模式” 的团队是这次团队例会中大家共同赞成的观点，他提出要避免 “明星模式” 失控时一家独大的状态，让每个人都有明确的分工和职责，同时在某位成员工作暂时受到阻碍时，要有其他成员能够有能力及时补上他的工作。这样可以让团队中的每个人都最大化与格式化自己的力量，不会出现一个人干活一人偷懒的局面。同时我们也对尚未完成自己阅读项目的莫礼钟同学进行了鼓励，希望他能努力学习，在下一次交流中展现自己的学习成果。

【此次交流总结由 马军 记录】
【2017.10.11晚】

第二周会议

　　今天（10.18）我们小组开展了第二次团队例会活动。我们小组主要讨论了前两周我们组的优缺点以及第三周团队任务的分工等问题。
　　我们首先确定了第三周团队任务的大致分工，其中组员刘先润自荐修图。在选取游戏的讨论上，我们组意见出现分歧，组长袁逸灏及组员马军觉得闯关类游戏比较容易推销，莫礼钟想要新意多一点的RPG养成类游戏，并且以社交为主，但是我认为开发社交类游戏消耗的人月太多，所以我们还需要进一步讨论选取。
　　当我询问到组员们对于团队特色的描述以及关于团队前两周表现的优缺点时，一种自豪之感油然而生。虽然我们团队刚刚组建，还没有开发项目、合作的一些经验，但是我们前两周一直按照老师的要求执行任务，也参考了《构建之法》上的部分内容改进，我们小组每个人每周都为团队花费了一些时间，每周例会上畅所欲言的感觉真是不错，从软件工程的角度讲，我们团队要争取做一个?交响乐队模式的敏捷团队，相比起其他团队，我们的交流次数较多。刘诚昊还说，第二周我们小组成员选的游戏都比较新颖，这样一种默契和自信是正是我们团队的特色和优点。
　　大多数组员甚至认为我们组没有“缺点”，我觉得我们组还是缺少一些磨合，在交作业上也要加强督促力度，不然会耽误每周团队总结博客的发表时间。相信在组员们的持续配合下，我们团队能够表现得更出色。

【此次交流总结由 刘伟康 记录】
【2017.10.18晚】

第三周会议

　　第八周我们小组举行了会议讨论，会议围绕以下内容进行了讨论：

1.上周的采访后我们形成的结论有哪些？后面如何工作？
2.讨论一下马军制定的计划表合不合理？不合理及时修改。
3.（重要）参考QQ群中的用户需求文件，看看每种软件的介绍背景，目的，验收标准，明确并且讨论一下我们要做的软件的相关内容及具体需求。
4.前三周相比起其他组，我们有没有什么值得借鉴的地方

　　对于第一个问题：袁逸灏认为需要将人力主要集中在代码方面，工作效率要有保证，团队的开发要做到先苦后甜。除了袁逸灏发表见解，刘伟康同学进行了补充。他认为日后的工作中，要注意写工作文档来说明情况，尤其在代码方面，代码中要用注释来写明代码的运行逻辑，并注意产品代码要加入文档说明，说明内容：类对于用户的作用，时间记录，剩余时间预估。刘诚昊作为测试代码负责人员，他补充以后的工作他们测试代码这一板块需要提前将测试项目定好。他认为，测试项目其实就是用户的需求，这一方面很重要，因此这一项要提前做好。
　　对于第二个问题：大多同学都没有异议，马军同学认为自己做的计划表仍然太泛。他认为的问题集中在代码方面，他期望近期能将需求说明书，界面讨论出来。
　　对于第三个问题：由于该周任务重，而且用户需求文件篇幅较宽，因此大多同学都没看完。

【此次交流总结由 袁逸灏 记录】
【2017.10.26晚】

第四五周交互

• 当团队作业进行到第三周时，娄老师给我们安排了一项任务： 采访老师或有开发经验的学长，访谈他们关于项目开发经验、团队组织方式、团队成员协作、时间周期安排等包括但不限于上述内容的采访。采访前，准备好相应的提纲，做好功课。

• 由于同学们都没有经历过合作开发项目的经验，所以大家问的问题都差不多是几个点：

  1.如何分工
  2.时间上的安排
  3.小组凝聚力

• 我也去询问过各个小组的成员，关于他们小组的时间分配和遇到的难题。我得到的反馈是有些同学担心小组内代码水平参差不齐，可能会有较大的代码任务分配到自己的身上。但他们暂时也没有想到好的办法。

• 而关于这个问题，有些被采访的老师和学长学姐们意识到了，他们给出的回答有以下几个方面：

  1.全组成员一起敲代码。
  2.选取组员的时候要选取踏实能干事的组员。
  3.发挥各个组员的专长，给他们分配最理想的工作。

• 对于以上方面，我觉得第三点实现起来比较容易，第一第二点实现的困难程度依次递减。为什么呢？

• 关于第一点的全体组员一起敲代码，依照我们小组的打酱油成员（没错就是我）来说，大家一起敲代码确实是能快速提高我自身的代码水平，但很有可能出现的问题就是：我基础太弱导致代码敲不出来，严重影响了团队项目的进度。那么对于我这种情况的解决方案是什么呢，我要求小组给我分配更多的关于代码外的任务：问题讨论、博客思路、对于推广的想法。但敲代码也不能落下，所以我跟刘伟康讨论的结果是：尽可能的分配代码任务让我编写，或者是组员们一起讨论编写，如果我的代码水平能够在一段时间内赶上他们，那么就让他们把更多的代码任务分配给我。总的来说就是水平差的人多搞搞后勤，代码任务可以少分配一点，跟在其他组员的身后多学习提高水平，等水平提上去了就可以获得一样的工作量。

• 关于第二点的选取组员，只能说小组如果凝聚力足够，组员各司其职，其实不用在团队组建之前就商量好要和谁抱团，大家都想把项目弄好，有这份心再加上行动，谁都是一个好苗子。

【此次交互任务由 莫礼钟 完成】
【2017.11.02晚】

第六七周交互

• 团队任务已经进行到第六第七周，从开始的规格说明书如何编写，到现在根据《构建之法》第四章内容讨论编码规范，各个小组已经进入到了开始代码构架的阶段。
  为此，我继续进行着我的交互任务，对各个小组做了一些简单的问答。

  bug终结者小组说：他们的需求规格说明书还没有做到他们满意的效果，所以他们关于团队任务的安排是：让小组成员们对需求规格说明书的任意一章（自选）进行修改，并且在此任务的基础上让小组成员们寻找关于APP的素材，并开始对APP的构架。
  JaWorld小组说：他们遇到的困难是，会遇到有不懂的代码，而且担心赶不上开发进度。
  剩下的两个小组我得到的信息大概与上面两个小组相同，对于遇到的问题都是一些开发上面的问题。

• 交互反思：

  觉得这次和上次的交互比起来太草率而且太不严谨了，许多小组都对于我（莫礼钟）的来意表示疑惑，并且我对他们的提问总是一成不变的：遇到什么问题？打算怎么解决？怎么分工？这些能在团队博客里呈现的内容。

• 交互改进（下一次团队作业时）：

  我会准备一个问题模版并针对当前我们小组遇到的开发问题与其他小组进行探讨，让交互不再是简单的你问我答环节，而是对于各个小组遇到的问题能互相沟通提出建议或改进，学习其他小组的先进内容。

【此次交互任务由 莫礼钟 完成】
【2017.11.19晚】

第八周会议

• 期待 刘先润 的总结！