FocusFlow Alpha Phase Retrospective: Learning from Our First Sprint

FOCUS_2025_SE 2025-12-28 14:57:30

目录

  • Project Overview
  • Introduction
  • 1. Problems Encountered During "Learning by Doing"
  • 2. Team Division of Labor & Collaboration Deficiencies
  • 3. Tool & Process Shortcomings
  • 4. Blog Planning & Time Management
  • Conclusion & Hindsight

Project Overview

Course2501_MU_SE_FZU
Assignment RequirementSixth Assignment - Beta Sprint
Team NameFocus_2025
Goal of this assignmentClarify Code Standards, Sprint Tasks, and Plans for the team Beta Sprint
Other referencesIEEE Std 830-1998, GB/T 8567-2006

Introduction

As our team concluded the Alpha sprint for FocusFlow, we delivered a minimum viable product with core features. However, true to the spirit of "learning by doing," we encountered significant hurdles that were as educational as the code we wrote. This blog serves as our mandated retrospective—a candid pause to dissect our problems with the benefit of hindsight. Our goal is not to dwell on shortcomings but to systematically identify root causes and transform these lessons into a concrete action plan for the upcoming Beta sprint (December 28, 2025 - January 6, 2026).

1. Problems Encountered During "Learning by Doing"

Our journey was marked by three main categories of challenges:

  • Technical Overwhelm: Adopting a new framework led to initial "spaghetti code." We focused on making features work rather than making them maintainable. This resulted in technical debt, such as poorly managed application state, which made later modifications risky and time-consuming.
  • Git Chaos: Our version control was a source of constant friction. We lacked a branching strategy, leading to broken main branches and "merge hell." Commit messages were uninformative (e.g., "update" or "fix bug"), making it impossible to trace the history of changes.
  • Incomplete Project Setup: The final steps of building, configuring environments for different machines, and preparing for deployment were underestimated. What worked on one developer's machine often failed on another's, consuming valuable sprint time.

2. Team Division of Labor & Collaboration Deficiencies

Our previous process was reactive and inefficient.

  • Vague Responsibilities: Tasks were often assigned based on who was available, not on defined roles. This led to knowledge silos and bottlenecks. For example, only one member fully understood the authentication flow, blocking all related fixes.
  • Ineffective Communication: Daily stand-ups became mere status reports ("I worked on X") without surfacing blockers or fostering collaborative problem-solving. Critical issues were raised too late.
  • Lack of Quality Gates: There was no code review process. Code was merged directly after being written, increasing the likelihood of bugs and style inconsistencies creeping into the codebase.

3. Tool & Process Shortcomings

We used tools but did not leverage processes around them.

  • Version Control (Git): Used merely as a file backup system, not as a collaborative development tool.
  • Testing: Almost non-existent. We relied entirely on manual, end-of-sprint "click testing," which was inefficient and failed to catch regression bugs.
  • Task Management: Issues in our project board were vague and not tracked against time, making progress measurement and forecasting difficult.

4. Blog Planning & Time Management

In the Alpha phase, blog writing was treated as an afterthought—a bulk task completed right before the deadline. This resulted in rushed content that did not accurately or usefully reflect our development journey. We failed to use the blogs as a living document of our progress.

Conclusion & Hindsight

Looking back, we now understand that "learning by doing" in software engineering is not just about coding. It is about iteratively applying and refining engineering practices alongside writing features. Our key insight is that a disciplined process is not a barrier to creativity; it is the foundation that enables sustainable progress and quality.

For the Beta sprint, we commit to turning this hindsight into foresight. We will implement defined roles, a strict Git workflow, and proactive blog scheduling. We will start by fixing our most glaring user-facing issues, beginning with the overly complex password reset flow, to build a more robust and user-friendly FocusFlow.

...全文
152 回复 打赏 收藏 转发到动态 举报
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复
内容概要:本文围绕含软开断装置(SOP)的配电网在发生多线路故障情况下的故障重构问题展开研究,提出了一种基于Matlab代码实现的优化重构方法。通过引入SOP这一先进的电力电子设备,充分发挥其对有功和无功功率的灵活独立调节能力,实现对配电网潮流的精确控制。在多点故障发生后,该方法能够快速隔离故障区域,并通过重构网络拓扑,最大限度地恢复健全区域的供电,有效减少停电损失,从而显著提升供电可靠性和系统应对突发事件的韧性。研究建立了以最小化负荷削减量和开关操作次数为目标的混合整数非线性规划模型,并综合考虑了潮流平衡、节点电压、线路容量及辐射状运行等关键约束条件,采用先进的智能优化算法进行求解,并通过标准算例系统进行了Matlab仿真验证,证明了所提方法在恢复能力和运行经济性方面的优越性。; 适合人群:电气工程、电力系统自动化等相关专业的高校师生、科研人员以及从事电网规划、运行与调度的工程技术人员。; 使用场景及目标:①用于研究高比例分布式电源接入背景下,配电网在极端故障事件后的快速恢复与韧性提升策略;②为SOP等新型柔性互联装置的规划配置、运行控制及效益评估提供理论依据和技术支持;③作为电力系统优化、故障恢复算法、智能优化算法教学与科研的综合性案例参考。; 阅读建议:读者应具备一定的电力系统分析、优化建模和Matlab编程基础,建议结合提供的Matlab代码进行实践操作,深入理解故障重构模型的构建逻辑、求解流程及SOP的作用机理,并可根据不同的电网参数或故障场景对模型进行修改和扩展,以适应多样化的研究与应用需求。

164

社区成员

发帖
与我相关
我的任务
社区描述
2501_MU_SE_FZU
软件工程 高校
社区管理员
  • FZU_SE_LQF
  • 助教_林日臻
  • 朱仕君
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

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