智创未来队——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)是如何进行的,是否严格执行了代码规范?

团队成员在开始编码之前,会先熟悉并遵循代码规范,然后再着手编写代码。代码复审工作则通过团队成员之间的交叉审查来执行。

六、测试/发布

1.团队是否有一个测试计划?为什么没有?

有测试计划

2.是否进行了正式的验收测试?

是的,前端是功能逻辑的测试(界面点击等),后端主要是对于接口和模块的测试。

3.团队是否有测试工具来帮助测试?

我们采用了JMeter来进行我们的测试,这显著提升了测试工作的效率和精确度。然而,我们也意识到,针对不同项目的具体需求,需要对测试工具的选择和应用进行更深入的评估和优化,以确保它们能够最大程度地发挥作用。

4.在发布的过程中发现了哪些意外问题?

暂无

七、团队的角色,管理,合作

  1. 团队的每个角色是如何确定的,是不是人尽其才?

我们首先对每个成员的专业技能、经验以及个人意愿进行了全面的评估。基于这些信息,我们为每个成员分配了最适合他们的角色,这样可以确保每个人都能在自己最擅长的领域发挥最大的潜力,同时也能够保持工作的热情和动力。

  1. 团队成员之间有互相帮助么?

有的,因为有代码规范,所以成员间编写的时候也会互相讨论要怎么编写好,遇到不会的也会互相帮忙解决。

  1. 当出现项目管理、合作方面的问题时,团队成员如何解决问题?

由于我们团队在各个方向都设有小组长,如果出现同一方向的内部矛盾,将由该组内部成员通过讨论来解决;若问题涉及不同方向之间的协调,将由团队全体会议进行沟通,以确定最优的解决方案。

八、总结

1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

初始级档次。

2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

磨合期阶段

3.你觉得目前最需要改进的一个方面是什么?

前后端在设计阶段沟通时细节敲定不够准确,导致较多返工。

...全文
35 回复 打赏 收藏 转发到动态 举报
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复

116

社区成员

发帖
与我相关
我的任务
社区描述
FZU-SE
软件工程 高校
社区管理员
  • LinQF39
  • 助教-吴可仪
  • 一杯时间
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧