智创未来队——alpha阶段问题总结随笔

智创未来队团队 2024-05-19 18:01:06

这个作业属于哪个课程	2302软件工程
这个作业要求在哪里	团队作业——beta冲刺
团队名称	智创未来队
团队置顶集合随笔链接	智创未来队——置顶集合随笔
这个作业的目标	总结alpha阶段问题
其他参考文献	《构建之法》

一、设想和目标

1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

我们软件的目标，是减轻内容创作者，无论是个人还是团队，面临的繁重负担，帮助他们节省宝贵的创作时间，提升创作效率。这样，他们就可以将更多精力倾注于品牌IP的长期规划与发展，而不再纠结于细琐且重复的内容创作工作。这就是我们创造这款产品的初衷。

2.我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)

Alpha阶段目标功能基本完成；按照原计划交付时间交付了；原计划alpha阶段用户数量达到了，即组员和组员身边的同学，在beta阶段完成后会把用户数量扩大范围

3.和上一个阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？

和上一个阶段相比，团队软件工程的质量提高了。
（1）代码的可读性、可维护性和复用性提高了。这通过代码审查、静态代码分析工具和测试覆盖率来衡量。
（2）代码的交付速度加快了。团队成员之间的协作和沟通更加顺畅了，通过团队成员的反馈和协作工具的使用情况来评估。
（3）项目的功能性提高了，基本实现了基础功能
（4）团队的协作能力提高了，通过十日的每天会议共同商讨项目的进度

4.用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

在alpha测试阶段，我们还没有设定具体的用户数量目标，主要的用户群体是团队内部成员和成员身边同学。核心功能的实现与我们的预期基本一致，但是在前一个阶段中有一些小细节还没有来得及处理。相信通过阶段开发，我们离目标会更近一步。

5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

(1)为了提高工作效率和项目成功率，团队间的沟通至关重要。有效的沟通可以帮助团队成员理解各自的角色和责任，确保每个人都朝着共同的目标努力。
(2)此外，制定详细的计划也是团队成功的关键。一个好的计划应该包括明确的目标、时间表、资源分配和风险管理。团队领导应该确保每个成员都清楚计划的细节，并根据项目进展及时调整计划。
(3)通过加强沟通和制定周密的计划，团队可以更好地协作，克服挑战，最终实现项目的成功。这不仅能够提升团队士气，还能增强团队成员之间的信任和尊重，为团队的长期发展打下坚实的基础。
(4)更早地进行用户测试和反馈收集，以确保我们在开发过程中更好地满足用户的期望。

二、计划

1.是否有充足的时间来做计划?

经过上一轮的实践，我们认识到了事先规划的重要性，并且对使用项目管理工具也越来越得心应手。这次我们已经预留了充裕的时间来制定详细的计划。

2.团队在计划阶段是如何解决同事们对于计划的不同意见的？

由于我们团队在各个方向都设有小组长，如果出现同一方向的内部矛盾，将由该组内部成员通过讨论来解决；若问题涉及不同领域之间的协调，将由团队全体会议进行沟通，以确定最优的解决方案。我们倡导团队成员积极表达自己的见解和担忧，并相互倾听。通过汇聚众人智慧和平衡各种观点，我们致力于达成共识，并制定一个能够兼顾各方利益的方案。团队协作和顺畅的沟通非常关键，它们确保了计划能够得到广泛的赞同和接受。

3.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

alpha阶段的主要任务已经基本完成，尽管还有一些接口需要进一步调试，这些将在beta阶段继续进行。同时，我们还将对代码结构进行优化。

4.有没有发现你做了一些事后看来没必要或没多大价值的事?

暂时没有

5.是否每一项任务都有清楚定义和衡量的交付件?

是的，包含了任务和子任务，任务启动前需要详尽规划内容，并在任务结束时进行严格的验收。

6.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

整体而言，项目进展顺利，按照原定计划推进，尽管遇到了一些小问题（例如功能存在bug导致需要重做），但这些问题并未导致严重的时间延误。未被充分评估的风险主要在沟通方面，尤其是在前后端接口的交流上存在不畅，这导致了额外的时间成本。最初未能预见到这一点，主要是因为我们在协作开发方面的经验还不够丰富。

7.在计划中有没有留下缓冲区，缓冲区有作用么?

虽然没有设置专门的缓冲期，但我们有意识地每天都会进行一定时间的回顾和检查，并确保结束时进行反思和检查，这在一定程度上起到了缓冲的作用。

8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）

将来的计划中，我们将做出一些修改，包括重新定义缓冲区、更合理的安排工作时间和加班策略，加强组内沟通等。

三、资源

1.我们有足够的资源来完成各项任务么?

在项目的规划阶段，我们对可用资源进行了细致的评估，并实施了合理的资源配置，确保每项任务都能获得充足的资源。我们致力于防止资源不足或过剩分配的问题，以保障项目能够按照预定时间顺利进行。

2.各项任务所需的时间和其他资源是如何估计的，精度如何?

我们基于以往的项目经验、相关任务的历史数据以及团队成员的专业技能，进行了全面的评估。尽管我们努力提升预估的精确度，项目的复杂性和不可预测性还是导致了一定程度的误差。我们重视持续的监控和调整过程，以确保资源得到高效利用，并保证任务按时完成。

3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

在项目计划阶段，我们对测试工作进行了充分的考虑，并为测试活动预留了足够的时间、人力和软件/硬件资源。我们根据测试的复杂性和覆盖范围进行了合理的估计，并确保测试团队具备所需的技能和工具。我们致力于高质量的测试，以确保软件在交付之前经过全面且彻底的验证和确认。但是美工活动低估了难度，目前美工还未完善。

四、变更管理

1.每个相关的员工都及时知道了变更的消息?

我们保证及时向所有团队成员通报变更情况，利用定期的会议和qq群来确保信息的顺畅流通。这种做法有助于保持团队成员的共识和协同工作，从而确保变更的顺利执行。

2.我们采用了什么办法决定“推迟”和“必须实现”的功能?

组长会整体地分配每个部分的任务，而每个方向有自己的小组长，小组长根据需求的优先级来制定计划和分配资源。

3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

（1）项目的主要目标和关键结果已经实现。
（2）项目成果符合预定的质量标准和验收标准。
（3）用户验收项目成果，并满意。
（4）所有相关的项目文档，包括设计文档、测试报告、用户手册等都已经完成并经过审核。

4.对于可能的变更是否能制定应急计划?

为应对潜在的变更和紧急情况，我们制定一套应急方案。该方案涵盖了预先设定的反应策略、备选计划和资源调配流程，旨在使团队能够迅速适应变化，同时确保项目顺利推进。

5.员工是否能够有效地处理意料之外的工作请求？

是的，面对突发的请求，都能较好地完成，会通过灵活变通，协调时间来达成目的。

6.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

(1)沟通与协作：我们认识到了沟通和团队协作的挑战，将致力于加强团队间的交流与合作，确保信息传递的准确性和效率，从而提高任务的清晰度和解决问题的能力。
(2)风险管理：我们意识到了项目中风险管理的不足，将提前识别和评估潜在风险，并制定有效的应对策略，以减少风险对项目的影响。
(3)资源规划与管理：我们学到了合理规划和管理资源的重要性，将更精确地估计任务所需资源，并合理分配和管理，以确保项目的顺利进行。
(4) 学习和知识积累：我们认识到了积累经验和知识的重要性，将建立知识库或文档，以便更好地记录、应用和分享项目中的经验和教训。

五、设计/实现

1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计工作通常在项目的早期进行，由专门的设计人员或开发团队负责完成。我们会确保在适当的时间安排设计工作，并选择具备相关经验和技能的人员来执行设计任务。

2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？

有时会遇到一些模棱两可的情况，通常都是在团队的例会上共同商量解决的，集思广益。

3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

我们采用了单元测试、UML和Axure等工具，它们在项目中发挥了重要作用。
在类图和接口设计方面，我们进行了一些调整和优化。

4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

运营功能出现的bug数量最多，这主要是因为在后端与前端对接的过程中，发现了许多预期之外的问题。这些问题的出现并不是设计阶段的问题，而是由于接口文档的不准确或不完整导致的。接口文档是前后端开发人员沟通的桥梁，它详细描述了接口的输入、输出、行为和限制条件。如果接口文档存在缺陷，那么前端和后端开发人员可能会基于不同的理解进行开发，最终导致实现的功能与预期不符。

5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？