"大泥球"
我了解到的就是这几点：
第一，有很多条件促使大泥球产生，包括"一次性代码"，时间紧缺，急于完成最小集，初期尝试，功利主义等等。
第二，有些时候可以允许代码沾一点泥：在初期尝试阶段，没有必要预先设计长期的架构，那样反而会束缚住探索。
第三，不能放任代码变成"大泥球",对应的方法有两个，一是重构，二是复审。
第四，随着软件需求、特性的更新发展，会面临重构，需要对过去的失败原因进行剖析充分吸取经验之后重构。
在实战中，我们组首先确定代码要可维护，并且时间宽裕，其次任务大多采用结对编程方式完成，不断复审，因此最终的结果也是避免了让代码变成大泥球。
敏捷开发
敏捷的核心在于以人为核心的迭代开发、增量交付、需求驱动，目前我们利用scrum的方法，完成了一个迭代的冲刺，达到了预期目标，并且接下来将以alpha阶段的成功为平台继续发挥，体验到了一种步步为营的感觉。我认为在现在的课程中尚未出现用户需求的重大改变，因此alpha 和 beta只是在按照最初的计划稳步进行而已。如果在alpha阶段结束后能把用户反馈统计的功能做好的话，可能会检测到用户需求的变化，真正体验到敏捷开发的重要性。
关于《人件》
人件给我的印象是：管理者要利用脑力劳动者所具有的属性实现团队的高效（单位时间产出）工作。
给我印象深刻的几个点：
1.大脑时间（Flow）：让团队里的人能够进入状态来工作而不被打断--让个体高效。
在alpha阶段中，尽量让工作在同一任务上的同学在同一环境下工作，避免因为不相干的工作干扰工作状态。
2.发掘成员的潜力：正确的人在其适合的方向上成长--团队成长与个人成长的统一。
我们的团队确实找到了合适的人，每个人都被安排到其乐意或者擅长的方向，而这些方向刚好是项目所需。这提高了工作质量和效率。
3.作为服务的领导力：领导者不凌驾于成员之上，而是作为一种服务存在，只求合理安排让每个人充分发挥自己的长处--领导者的心态。
我在做PM的过程中，首先了解清楚每个人都适合做什么样的事，跟每一位成员混的比较熟，接下来就只是把自己摆在一个催化剂的位置，做好安排，处理杂事，时刻了解并处理好突发问题，让每个成员在各自方向上安心发育，为其尽量扫平障碍。当然每个成员都相应地按时完成计划任务。
4.团队凝聚力：队员乐在其中，自信而充满热情--团队活力与耐久性。
这方面在alpha阶段做得还算比较到位：当前后端和模型第一次合体时，全员都挤在我寝室狭小的空间里，每次输入一张图片进去时大家都惊讶于生成对联的完美效果，每个人都意识到这是团队共同作用的结果。团队成员的感情也加深了一层。beta阶段虽然大家在学校和组里的事情更忙了，但是希望这种凝聚力继续保持。
5.让改变成为可能：要意识到需求是可能发生变化的，改变是必要的，过程是崎岖的，不可避免的。要转换思想，实践整合，让改变成为可能。
这一步我们尚且没有遇到：代码还比较规整，没有遇到需求的突变，重构不是迫在眉睫，但是我认为这一点是重要的，要有改变、适应的意识。这对以后有好处。