事后诸葛亮分析

会议合照

回顾与反思

Q：我们的软件要解决什么问题？
A：我们的软件是一个高校贴吧，集成水电，快递，外卖等功能

Q：我们达到目标了吗？
A：达成一半，集成功能仍然有bug需要修理

Q：我们是否有充足的时间做计划？
A：有的。

Q：如何解决不同成员的意见纠纷？
A：首先一个小组内的成员需要沟通与理解，我们主要根据可行性来进行判别，首先假设要落实各个成员的意见，看看需要多少资源，得如何布置任务，划分为一个个里程碑，然后插入到任务列表里，划出一个底线，底线是必须完成的，此外是锦上添花的。然后一个里程碑一个里程碑的完成

Q：有没有走弯路？做了一些事后看起来没必要的事？
A：目前看来没有

Q：项目是否出现了意外？有什么风险是当时没有估计到的？为什么没估计到？
A：有意外。当时有段时间是各科的实验和课设DDL集中期，大家疲于奔命，对编程的兴致很低，拖累了项目进度

Q：当初是如何估计各项任务所需资源的？精度如何？
A：主要根据代码量和成员当时是否空闲来判断所需资源。精度不是很高，因为影响一项任务的完成时间的因素还蛮多的，比如成员的熟练度，额外任务的产生，前置任务的完成情况等等。

Q：有没有留下缓冲区？
A：有预留一点缓冲区，但是没有很大的作用

Q：我们是否有充足的资源来完成各项任务？
A：说不上充足，也谈不上匮乏。

Q：人力资源是否充足？我们是否低估了哪些不需要编程的资源（文案/美工/设计）？
A：人力资源是足够的。有点低估文案了，博客看起来不起眼，一写一个不吱声，AI做得马马虎虎，最后还是得亲自上手。

Q：我们都尽力了吗？如果再来一次，能不能做得更好？如果让别人做，能不能做得更好？
A：不能说那种把命豁出去的那种尽力，虽然嘴上说什么摆烂躺平，但是所有成员都是认真对待了，他们都在偷偷地卷。再来一次肯定能做更好，但难保不会出现一个和尚挑水喝，两个和尚抬水喝，三个和尚没水喝的囧境，不说技术方面，就软件工程方面来说，我觉得很多细节是可以优化的，比如让前端和后端的接入时间提前，可能整个项目都会好很多。如果让别人做，别人未必做得比我们好，大家也是有点底气和骨气的，总而言之，我们都是一个脑子两只手，说不准是谁比谁强。

贡献分