2017-2018-1Java演绎法第四五周作业

团队任务：撰写《需求规格说明书》

• 团队组长：袁逸灏
  本次编辑：刘伟康

流程、分工、比例

（比例按照任务的费时、难度和完成情况估算）

• 流程

  确定任务 -→ 分配任务 -→ 各组员完成各自任务 -→ 检查补充修改 -→ 汇总整理（时间、markdown 及 pdf）

• 分工及比例

需求规格说明书

【markdown 链接】

【pdf 链接】

【注】pdf 版本可以通过点击“下载”预览文件：

Git团队协作初步尝试

• 本次Git我们并没有撰写详细的 commit 信息，但是都尝试了一下：

交互总结

考虑到各个小组之间的交流问题，我们团队的 莫礼钟 主动提出对接其他小组的任务请求，他主要询问了一些小组的一些 明星成员，有的同学非常配合小编在此表示感谢，莫礼钟也针对他的采访做出了以下总结：

关于第三周团队采访的一点小小感想：

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

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

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

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

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

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

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

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

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

小编感想

　　两周的任务量其实和之前一周的任务量差不多，虽然也感觉有点多，但是对于凝聚力强的团队来说不足挂齿。我们本次撰写的说明书，由于具体页面和一些功能需求还没有设计出来，所以在需求规格说明书中我们只能尽可能详细地描述这些部分，之后的版本还会有修改补充。我们这次的流程分工仍然需要加强，一个组员，如果对于流程不够了解或者分工不够明确，必然会对团队整体造成一定影响，这就导致了团队效率的下降。我们小组仍然在不断积累经验，不知道以后还会有什么挑战呢？
　　作为一个团队博客撰写人员，可能这是个“苦差事”，我认为主要苦在等其他组员完成各自任务之后才能进行完整的总结，才能提交博客。为此就需要在 DeadLine 之前不断督促一些组员，但是也有一些组员做得很好，每次作业都可以在整体完成阶段的中期提交，这样下来如果检查时缺少了哪部分内容还可以及时补全，达到预想的效果，这也是一个团队凝聚力和 敏捷流程 的体现，我希望能够有更多组员积极配合团队一起进步。
　　可能每次任务都会有一两个组员承担略多的任务，你们多承担一点，责任就会重一点，但是团队的瓶颈就会少一点，同时也能锻炼的自己的能力，你们毫无怨言地接收任务就应该得到表扬。（编辑：刘伟康）

最后吐槽一下吧：一些网站或者编辑器上都会有 markdown 格式，但是码云上的 markdown 兼容格式真心不太满意，然而再转 pdf 时又需要使用另外一种格式，我为此消耗了大量时间。

参考资料汇总

• 软工团队 - 需求规格说明书

• 报课系统软件需求规格说明书

• “一起买APP“需求规格说明书

• ”报课系统“需求规格说明书