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.

...全文
109 回复 打赏 收藏 转发到动态 举报
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复
内容概要:本文聚焦于“基于配电网韧性提升的应急移动电源预配置和动态调度”研究中的MPS预配置部分,属于SCI一区高水平论文的复现工作。通过Matlab编程实现,构建了面向极端事件下配电网快速恢复能力提升的优化模型,重点解决应急移动电源(MPS)在灾前的科学预配置问题。研究系统阐述了问题背景、建模逻辑与求解方法,强调科研过程中逻辑严谨性、借力高水平成果的重要性,并倡导在扎实基础上追求创新突破。资源包包含完整代码、数据及论文资料,支持读者复现结果并进一步开展动态调度等后续研究,对提升电力系统抗灾韧性具有重要的理论与实践价值。; 适合人群:具备电力系统分析、优化建模及Matlab编程基础的科研人员,特别适用于从事电网韧性、应急调度、微电网规划、综合能源系统等方向的硕士、博士研究生及高校研究人员。; 使用场景及目标:① 复现并深入理解SCI一区论文中关于MPS预配置的数学模型与算法实现;② 掌握利用Matlab进行电力系统应急优化仿真与韧性评估的技术方法;③ 探究应急电源空间配置与电网恢复性能间的量化关系,为实际电力系统防灾规划与调度决策提供理论依据和技术支撑。; 阅读建议:建议读者结合提供的网盘资源,按照文档结构循序渐进地学习,重点关注模型构建的物理意义、约束条件设定及Matlab代码的实现细节,务必动手运行与调试代码以加深理解。同时可参考团队发布的其他相关研究,拓展在智能优化算法、鲁棒调度等领域的综合应用能力。
内容概要:本文系统阐述了Private访问控制在芯片设计全生命周期中的实战应用,覆盖设计态、验证态、DFT态到制造态四大阶段,提出基于EDA工具链的四维防护体系。通过Synopsys Design Compiler约束脚本、UVM验证环境私有化配置以及Mentor Tessent DFT私有指令集实现,展示了如何在RTL设计、仿真验证、测试向量生成等关键环节实施精细化访问控制,有效防止IP泄露与非法调试。重点案例包括JTAG私有指令定义、扫描链信号隔离、测试向量AES-256加密及eFuse密钥保护机制,构建从硬件到流程的安全闭环。; 适合人群:从事芯片前端/后端设计、DFT开发、验证工程的技术人员,以及关注集成电路安全的架构师与项目管理人员,具备数字电路设计与EDA工具使用基础者更佳。; 使用场景及目标:①在芯片设计中实现IP核与敏感寄存器的访问隔离;②提升DFT测试安全性,防范通过JTAG接口进行的数据窃取;③构建企业级权限管理体系,支持多团队协作下的安全交付;④满足高安全等级芯片(如加密芯片、AI芯片)的合规性要求。; 阅读建议:此资源强调实战性,建议结合EDA工具实际操作相关脚本(TCL/UVM/SystemVerilog),重点关注私有指令设计、权限绑定与加密策略的集成应用,并在项目中评估安全与可测性的平衡,以实现高效可靠的安全闭环设计。

164

社区成员

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

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