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.

...全文
134 回复 打赏 收藏 转发到动态 举报
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复
内容概要:本文系统研究了构网型变流器的正负序阻抗解耦特性及其在弱电网环境下的稳定性表现,重点依托Matlab/Simulink仿真平台,构建了详细的阻抗数学模型,设计了解耦控制策略,并采用小信号扫频法进行频域辨识与稳定性验证。研究深入探讨了构网型变流器与传统跟网型逆变器在正负序阻抗特性上的本质差异,结合虚拟同步发电机(VSG)等先进控制技术,分析其在抑制宽频带振荡、削弱锁相环动态耦合等方面的优越性。文中不仅提供了完整的仿真模型与MATLAB代码实现,还整合了光伏、风电、储能、微电网等多类新能源系统的阻抗建模与稳定性分析资源,形成了一套面向新型电力系统稳定性的综合性技术资料体系,具有较强的科研复现与工程参考价值。; 适合人群:面向具备电力电子、电力系统自动化、新能源并网等专业背景的研究生、高校教师及工程技术人员,特别适用于从事阻抗建模、小干扰稳定性分析、宽频振荡机理研究以及撰写高水平学术论文的科研工作者。; 使用场景及目标:①掌握构网型变流器正负序阻抗建模与扫频辨识的仿真方法;②深入理解VSG等构网型控制在弱电网中提升稳定性的内在机理;③复现顶刊论文中的阻抗分析流程与稳定性判据应用;④利用提供的成熟模型与代码加速科研进程,支撑课题研究与学术成果产出。; 阅读建议:建议结合文中提供的Simulink模型与MATLAB代码,按照“理论建模—仿真搭建—扫频激励—频响提取—Nyquist判据分析”的完整流程进行实践操作,重点关注扫频信号的注入方式、频率范围设置及阻抗曲线的物理意义解读,并参考博士论文复现案例深化对复杂动态耦合问题的理解。

164

社区成员

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

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