目录

Project Overview

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.