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.

...全文
166 回复 打赏 收藏 举报
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复
源码直接下载地址: https://pan.quark.cn/s/854bd57df23a 在金融行业中,房产购置贷款是众多人在购置不动产时必须进行的一项财务规划。Matlab作为一种功能强大的数学及数据分析平台,经常被应用于各类复杂的运算,其中包括住房贷款的计算。本文将详细研究运用Matlab开发住房贷款计算程序的相关知识要点,以协助读者掌握如何借助编程技术处理实际的信贷问题。 1. **信贷种类** - **商业信贷**:此类贷款通常由金融机构提供,其利率会随市场行情变化,借款人可选用固定利率或浮动利率方案。 - **公积金信贷**:该类贷款获得政府机构的支持,利率一般低于商业信贷,但设有最高贷款金额的限制。 2. **偿付模式** - **等额本金偿付**:每月支付相同数量的本金,利息部分逐月减少,因此整体还款总额会逐步降低。 - **等额本息偿付**:每月支付固定金额的本金与利息组合,利息部分随本金的逐月减少而递减。 3. **住房贷款计算公式** - **等额本息偿付**:每月还款额=贷款本金×[月利率×(1+月利率)^(贷款期数)]÷[(1+月利率)^(贷款期数)-1]。 - **等额本金偿付**:每月应还本金=贷款总额/贷款期数,每月利息=(贷款余额-累计已还本金)×月利率。 4. **Matlab编程基础** - **变量设定**:在Matlab环境中,首要任务是设定贷款数额、年化利率、贷款时长等核心参数。 - **循环控制结构**:借助for循环来模拟每个还款周期的过程,进行本金与利息的计算。 - **函数构建**:将住房贷款的计算逻辑封装为函数,便于重复使用和测试不同条件下的结果。 5. **Matlab代码编写** - **等额本息函数实现**...

165

社区成员

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

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