[建议]我对软工有话说（下）

2.3 团队项目scrum周

更合理的scrum meetting报告

现在罗老师所要求的scrum meeting中含有下列元素：

• 遇到的困难和难点
• 今日完成的任务
• 明天计划要完成的任务
• scrum meetting照片
• 签入记录
• 燃尽图

而我认为，光有上述的这些，其实是不够的。从我个人的角度来说，scrum meeting的撰写与进度的催促成为了项目经理单方面的职责。如果某个同学当天meeting时谈到自己什么都没做，项目经理并不能责备什么。如果你期望项目经理会从最后的贡献分里将队员延期的分数扣除的话，那也是不大可能的。从我掌握的情况来看，我以为没有任何一个团队是严格按照贡献分计算公式来计算团队成员贡献分的。原因是多方面的，比较困难的就是无法准确衡量一个人的工作量。而且大家对分数比较敏感，在这方面不同的项目经理会有不同的考虑。

所以我认为，scrum meeting报告最好拆分成个人的分数。我的预想如下：

每日scrum后：

完成任务的队员写一个scrum博客，附上如下内容：

• 今日个人签入记录
• 截图展示今日个人签入部分内容
• 签入记录对应的Issue内容与链接
• 简短的学习体会（可有可无）

未完成任务的队员也需要写一个scrum博客，附上如下内容：

• 今日个人预定任务
• 预定任务完成度与对应内容（如果不想签入，可以展示在git/TFS中的本地与暂存区文件差异对比）
• 遇到的困难与难点

每日团队的scrum meeting报告：

• scrum meetting照片
• 工作安排
• 燃尽图

由项目经理公布每个人的今日完成计划与明日要完成的计划，在今日完成计划中应标注是否完成并给出该成员对应的个人scrum博客链接。

在计算分数时，个人scrum博客合格即给5分，个人scrum直接参与个人分数计算，团队scrum是另算的。团队scrum报告合格给5分，符合条件即有5分，算入团队最后的总分中，参与贡献度分配。

更好的质量监督与风控

在这一节中我主要想说的是在软件工程课引入高一届学长助教与工业界助教结合的制度。

首先，就我的体验来看，引入工业界助教真的是非常棒的做法！我在软件工程课中不仅从助教薛师兄的建议中学到了一些关于项目管理等方面的知识、获得了一些实际开发中的经验，更通过与福州大学的助教范老师（@沉默的代码 ）的互动中学到了丰富的经验！与在经验的丰富程度、见识的广度以及看问题的犀利程度上，高一届的学长助教是远远无法与工业界的助教相比的。所以我认为评论博客与展示点评等，由工业界的助教老师进行依然是目前的最佳选择~

我之所以希望引入高一届学长助教与工业界助教结合的制度，是希望克服以下部分工业界助教老师本身的限制：

• 工业界的助教老师大部分时候只能通过博客看到一个团队的运作情况，其他了解手段比较受限。
• 目前一门课程中只有一个工业界的助教，他们还有实际的工作，时间和精力都比较有限，无法细致追踪每一个团队项目的实际进度并进行核实。

其中比较重要的一点是，工业界助教老师大部分时候是无法面对面地跟实际的团队项目负责人进行沟通的。从博客里得到的讯息未必是真实的消息，当面沟通更容易把握整个项目的走向。

如果说引入工业界的助教最大的好处是普遍增长了同学们的见识，授予了同学们实际开发的经验，在多方面引导同学们入门，那么引入高一届的学长最大的好处在于团队项目的质量监督与风险控制。他体验过，他知道问题最容易出现在哪里，所以一方面可以根据经验来提前做好预防——包括预防团队项目停滞，预防项目经理的不作为（不作为是指不给那些“得分宝宝”安排任务）等。

所以个人觉得，每3~5个项目应当有一个实际体验过完整软件工程开发流程的（最好是上一届的部分项目经理）对整体进行风险控制，及时发现问题与跟老师探讨并反馈。这样一方面节省了课上老师为了解课下项目的实际进度，而专门腾出的一节课时间，另一方面可以收集到更好的意见与建议，从而将整个课程的制度改得更好。

这样算下来，一门软件工程课中需要的助教大约按如下配置：

1名工业界的助教负责博客点评/提出建议，2名高年级学长助教负责团队项目追踪，1名助教负责个人项目/结对项目等成绩评测

这样个人认为对于整体的把握比较好，人员也不算冗余：）

现在的想法还不甚成熟，有待进一步的完善与加强。但我觉得这是一个可持续的过程，并且过程中质量监督和风险控制会做得比现在更好，高一届的学长可以给项目经理传授一些基本经验，对高一届的同学来说也是另外一次绝佳的体验。

2.4 团队项目产品上线与维护周

每一个软件都应当有用户，并且应当重视用户。就今年的情况来看，团队项目上线与维护这一周要么是在填之前未竟的scrum meeting，要么就放羊了，实实在在进行认真推广与宣传的团队很少。大多数项目不太重视是否有真实的用户与真正的需求。我认为针对这一点，如果想让一个团队有意识地去重视获取用户反馈与进行迭代更新的话，老师必须得重视这一点。而想让他们重视的最好的方法就是，将这一项单独作为一个评分项——关于评分会在后面提到自己的一些看法。

2.5 团队评分与贡献分配

更合理的评分方式

第一轮迭代展示的时候我曾经吐槽过评分与得分宝宝的关系。而想杜绝这种问题，我觉得必须将多个得分项独立开。个人认为分以下几个独立项比较好：

• 项目展示效果（50分）
• 团队协作与流程管理（50分）
• 用户需求把握与场景分析（30分）
• 用户反馈与迭代更新（20分）
• 团队项目实际进展（30分）
• 团队贡献分配（20分）
• 团队宣传与推广（20分）
• 项目代码质量保证与测试（30分）

这八方面我认为可以足以评价一个团队项目在软件开发流程中的优劣，并且可以将项目本身的效果和软件工程流程的体会分离开来，这门课初衷依旧是对软件工程开发流程与团队协作有更好的认知与体会，不是完全的软件间的优劣对比。

这里面团队贡献分配的20分是为那些得分宝宝团队准备的，个人觉得如果一个团队拿不出合理的解释来说明为什么贡献分数极差很大的话，这一部分的团队分是拿不到的。

更合理的贡献分配

个人认为现行的团队内的贡献分分配制度本身存在很多漏洞——关键的一点在于大家对于分数这一点看得太重（感慨一下，有些同学真是不问学问之深浅，唯争分数之多寡啊）而且没有什么很好的方法来对大家的分数进行限制。愚以为，更好的一种方式是，在团队项目M1/M2阶段结束时，让每位队员根据自己的个人scrum报告，把自己在github/TFS签入的代码（每一个签入的代码都要有TFS的路径或github的文件链接）和学习心得等综合为一篇文章，进行自我评价。同样地，项目经理写一篇汇总稿，对每个队员做出的贡献进行确认，给出每个成员的工作占比。然后由上一届的学长助教给出最终每个人的团队贡献分数。