阅读指南
753
采用「框架先行,细节涌现」的敏捷模式。整体架构在前期确定,具体功能通过迭代完善。
需求涌现
Emergence
敏捷 vs 传统需求分析
Data Collation / Comparison
项目启动前完整定义
需求随迭代持续涌现
编写 200 页 SRS 文档
用户故事 + 持续交付
需求冻结,变更审批
拥抱变更,快速响应
数月后才能看到产品
每日可部署,即时反馈
按文档验收
按可工作软件验收
流水线中的位置
Pipeline Position
反馈周期
分钟级
用户参与
全程
变更响应
即时
文档载体
代码
Project Vision
打造一个兼具个人品牌展示
与工程实践标杆的全栈作品集
不仅展示"做了什么",更展示"怎么做"和"为什么这样做"。
01
What
全栈工程化个人网站
02
How
DevOps 实践 · 代码审查
03
Why
可验证的工程能力
核心价值主张
Value Proposition Logic Flow
潜在雇主
技术同行
验证能力
考察深度
凝神全栈
作品集
可运行
可追溯
核心目标分解
品牌展示
Goal 1建立专业的个人技术品牌形象,传递技术价值观。
访客能快速了解技术背景。
能力证明
Goal 2通过项目本身证明全栈开发能力与架构设计能力。
代码可审查、架构可分析。
工程实践
Goal 3展示企业级 DevOps 最佳实践,而非玩具级Demo。
CI/CD、监控告警完备。
知识沉淀
Goal 4记录技术学习路径和项目经验,形成知识库。
技术文档完整、可复用。
产品展示
Goal 5集中展示个人开发的 iOS/Web 产品,提供入口。
产品介绍完整、有链接。
目标用户与
利益相关者
明确"为谁服务"以及"谁影响项目",是需求决策的基础。
3.1 用户画像
User Personas Archive
潜在雇主/HR
招聘技术人才,需要评估候选人能力
简历千篇一律,难以判断真实能力
快速了解技术背景、项目经验、代码质量
浏览简历后,点击链接深入了解
技术同行/开发者
同行评估、技术交流、学习参考
网上教程零散,缺乏完整的工程实践案例
看到完整的技术栈、架构设计、最佳实践
搜索技术方案时发现,深入学习
产品潜在用户
对个人开发的 iOS/Web 应用感兴趣
不了解产品功能、隐私政策、使用方式
清晰的产品介绍、下载入口、支持渠道
App Store 搜索后,访问官网了解详情
自己(项目 Owner)
全栈开发者、产品设计者、运维管理者
需要一个长期维护的技术沉淀平台
易于更新、可持续扩展、低运维成本
日常内容更新、功能迭代、问题排查
3.2 利益相关者分析
Project Owner
功能实现、品牌形象、技术实践
全程参与,开发+运维
Visitor
内容质量、浏览体验、响应速度
访问行为提供隐式反馈
Product User
产品功能、隐私安全、支持服务
下载使用、反馈问题
功能性需求
用户故事
基于项目 753 次提交历史,梳理核心功能模块与用户故事。
4.1 核心功能模块
System Architecture Map
首页模块
作品集
产品展示
学习笔记
模块统计
4.2 用户故事清单
User Stories Backlog
首页与导航
作为访客,我希望看到一个有视觉冲击力的首页,以便快速了解网站风格
作为访客,我希望有清晰的导航菜单,以便快速找到感兴趣的内容
作为访客,我希望导航在不同页面能正确高亮当前位置
产品展示
作为产品用户,我希望看到完整的产品介绍,以便了解功能特性
作为产品用户,我希望能直达 App Store 下载页面
作为产品用户,我希望能查看隐私政策和使用条款
技术文档
作为技术同行,我希望看到完整的系统设计文档,以便学习架构思路
作为技术同行,我希望看到 DevOps 最佳实践,以便参考实现
作为技术同行,我希望文档有清晰的结构和导航
4.3 用户故事映射
User Journey Flow
非功能性需求
系统的质量属性约束:性能、可用性、安全性与可维护性。
5.1 性能需求
Performance Specifications
首页加载(首次)
峰值处理能力
服务器内存限制
5.2 可用性需求
Service Level Agreement
< 8.76 h/yr
< 5 min
99.9%
蓝绿切换
自动回滚
定期备份
5.3 安全需求
Security Architecture Layers
传输安全
基础设施
合规要求
5.4 可维护性需求
Engineering Toolchain
代码质量
统一风格,杜绝低级错误
自动化部署
提交即发布,减少人工干预
可观测性
运行状态透明可视
文档完备
知识沉淀,易于接手
技术约束与选型
基于需求与资源限制,推导出的技术决策路径。
6.1 技术栈选型
Requirement → Solution → Reason
Nuxt.js
Tailwind CSS
TypeScript
FastAPI
PostgreSQL
Redis
Docker
Blue-Green
GitHub Actions
6.2 架构约束
Hard Limits & Boundaries
服务器资源
需精细化资源分配,限制并发上限。
存储空间
需定期清理日志与过期镜像。
部署架构
无法使用 K8s,采用 Docker Compose 编排。
镜像拉取
通过 GitHub Actions 中转推送至阿里云 ACR。
需求演进历程
需求不是预设的,而是在 753 次提交中逐步清晰的。
7.1 演进阶段
Accumulation Layers
基础架构
2024-Q1DevOps 体系
2024-Q2前端功能
2024-Q3内容体系
2024-Q47.2 需求变更决策链
Problem → Solution Chains
CI 环境中 pnpm 在 GitHub Actions 无法正常工作
调整构建脚本,改用兼容性更好的包管理方案
蓝绿部署时数据库连接切换导致短暂不可用
将数据库改为共享数据层,不参与蓝绿切换
用户反馈导航在高亮逻辑上存在混淆
重构导航组件,增加路径匹配的准确性
页面代码耦合度高,难以独立迭代
组件化重构,提取通用模块
项目知识分散,缺乏系统沉淀
建立文档体系,将经验转化为可检索的知识库
总结
敏捷需求分析实践
8.1 本项目需求分析特点
需求涌现而非预定义
项目从基础骨架开始,需求随着开发过程逐步涌现。
- • 先跑通 CI/CD
- • 再丰富前端页面
- • 再补充技术文档
可工作软件即文档
没有传统的 200 页 SRS,需求体现在可验证的实体中。
- • Git 提交历史 (753次)
- • 可运行的代码
- • 本文档 (迭代梳理)
持续反馈驱动
每次部署都是一次需求验证,将被动修正变为主动优化。
- • CI 检查发现规范需求
- • 实际访问发现体验需求
- • 内容创作发现组织需求
8.2 经验教训
Lessons Learned → Actions
先跑通再丰富
基础设施优先于功能,CI/CD 是迭代的地基。
变更是常态
753 次提交证明,拥抱变更比抗拒变更更重要。
文档与代码同步
事后补文档不如边做边记,Commit message 就是最好的日志。
用户反馈是金
即使是个人项目,也要定期以访客视角审视网站。
8.3 需求清单总览
Requirements Status Dashboard