跳到正文FIT5120 Seminar Week 1 · Jimmy Huang's BlogFIT5120 Seminar Week 1
本页目录· 28 条
这一页有部分内容暂时无法显示，其余内容完整。
一、Seminar 的核心主题
本次 Seminar 的重点，是帮助我们理解 FIT5120 项目的基本规则、考核方式，以及如何使用 Agile 和 Design Thinking 方法，将一个真实社会问题逐步转化为可开发、可测试的软件产品。
整场 Seminar 所介绍的方法可以连成一条完整流程：
理解真实问题 → 产生多个想法 → 团队形成共识 → 编写 User Story 和 Acceptance Criteria → 设计功能 → 使用 Kanban 管理开发工作 → 持续迭代和改进
课件第 8—15 页主要围绕 Agile、团队协作、Crazy Eights、Fist of Five、Given–When–Then 和 Kanban 展开。
二、课程项目的基本要求
1. 项目主题
FIT5120 的总体方向是：
IT for Social Good
也就是使用信息技术解决真实的社会问题，而不只是开发一个普通的软件产品。
课件使用 WheelMelb——墨尔本无障碍地图作为示例，说明项目应该关注社会价值、用户需求和实际影响。
2. 项目必须包含的三个部分
项目需要具备以下三个核心要素：
因此，项目不能只停留在研究报告、Figma 页面或概念展示阶段，最后必须形成一个可以操作和演示的系统。
3. Performance Review
正式的表现评估会在：
Week 8
这些反馈主要是帮助团队改进。学生需要认真听取反馈、及时调整工作方式，而不是把反馈理解为单纯的批评。
三、课程考核与 Professionalism
1. 成绩组成
团队项目成绩还会受到 Professionalism Factor 的调整。也就是说，即使团队最后完成了一个不错的产品，每个成员的个人成绩仍然可能因为贡献、参与度和专业表现不同而不同。
2. 个人贡献如何被判断
Seminar 特别强调，导师不会只看最终产品，还会观察整个工作过程，包括：
是否积极参加 Studio 和团队活动；
是否参加 Stand-up Meeting；
是否公平承担任务；
是否持续为团队 Deliverables 作出贡献；
是否在 PGP 或 e-portfolio 中留下工作证据；
是否认真回应 Mentor 的反馈；
是否帮助团队成员或其他团队；
是否完成指定的准备工作和课堂任务；
Peer Evaluation 中其他成员如何评价你的贡献。
因此，不能只在最后阶段集中完成一部分代码，然后认为自己的贡献已经足够。持续、透明和可验证的参与过程非常重要。
3. 重要活动
Onboarding Expo；
Final Expo；
与用户或相关人员进行的访谈；
Studio 内的团队展示与活动。
4. AI 使用规则
Seminar 展示的 Assessment Schedule 明确说明：
除非具体作业说明允许，否则 FIT5120 的 Assessment 不允许使用生成式 AI。
因此，每项作业都需要单独查看说明。不能因为某一次任务允许使用 Copilot 或其他 AI，就默认其他任务也允许使用。
四、Agile Manifesto 的核心思想
Agile 并不是完全不要计划、文档或工具，而是在两组都有价值的内容之间，优先关注更能直接创造产品价值的部分。
Individuals and interactions
团队成员之间的沟通与协作，比单纯依赖流程、模板或软件工具更加重要。
即使使用了最好的项目管理工具，如果成员之间不交流，项目仍然可能失败。
Working software
文档有价值，但真正可以运行、测试和展示的软件更加重要。
团队不应该花大量时间制作看起来很完整的文档，却没有完成实际功能。
Customer collaboration
项目需要持续了解用户和利益相关者的需求，而不是只按照最初写下的要求机械开发。
Responding to change
真实项目中的需求、技术条件和用户反馈都会变化。团队需要根据新信息进行调整，而不是为了坚持原计划而忽略问题。
五、如何在 Agile Team 中工作
Agile Team 是一个能够共同完成产品增量的 跨职能团队（cross-functional team）。
一个有效的 Agile Team 通常具有以下特点：
Adapting：能够根据变化调整；
Collaborative：成员之间主动合作；
Conversational：通过持续沟通解决问题；
Self-organising：团队可以自行组织和分配工作；
Cross-skilled：成员拥有不同技能，也愿意学习和帮助其他领域。
即使成员可能有主要负责方向，整个团队仍然共同负责：
例如，不能认为“我是开发人员，所以不需要理解用户需求”，或者“我是 Business Analyst，所以不需要参与测试”。每个人都需要理解产品整体，而不仅是自己的一小部分任务。
六、从想法到产品的 Design Thinking 流程
Seminar 将产品发现和开发过程归纳为四个连续阶段：
1. Divergent Ideation：Crazy Eights
首先通过 Crazy Eights 快速产生大量不同方案。
通常是在较短时间内画出八个不同的解决思路。重点不是把图画得漂亮，而是：
避免团队过早锁定第一个想法；
鼓励不同角度的思考；
增加解决方案的数量；
让比较和选择成为可能。
这个想法是否真的解决了用户问题？
问题是方案本身造成的，还是可以修正的小问题？
是否应该继续迭代？
是否需要 Pivot，改变原来的方向？
Pivot cleanly without ego。
当证据显示原来的想法不适合时，团队应该调整方向，而不是因为某个想法是自己提出的，就坚持保留。
2. Convergent Consensus：Fist of Five
有多个方案后，团队可以使用 Fist of Five 进行快速投票和共识判断：
如果有人给出 0、1 或 2，就需要讨论其担忧，修改方案并重新投票。一般需要达到：
3. Requirement Definition：Given–When–Then
选定方案后，需要把模糊的需求转化为明确、可测试的 Acceptance Criteria。
GIVEN：初始背景、系统状态或前提；
WHEN：用户执行了什么操作，或发生了什么事件；
THEN：系统应产生什么可观察、可验证的结果。
GIVEN 用户账户余额充足，且近期没有受到提款限制
4. Execution Dynamics：Kanban Board
需求明确后，再使用 Kanban 管理工作流程，例如：
In Queue → Analyse and Define → Code/Unit Test → Test → Perform Acceptance → Done
每项任务目前处于哪个阶段；
谁正在负责；
哪些工作被阻塞；
哪个阶段出现了瓶颈；
哪些任务已经完成。
七、视频中的 Sensory-aware Route Planning 演示
视频后半部分通过白板演示，说明如何把 User Story 转化为系统功能和 Acceptance Criteria。
As a sensory-sensitive commuter,
I want to avoid highly congested pedestrian corridors,
so that I can reduce exposure to crowd-related stress.
作为一名对感官刺激敏感的通勤者，我希望避开非常拥挤的步行通道，从而减少因人群拥挤产生的压力。
As a…：用户是谁；
I want…：用户想完成什么；
So that…：用户为什么需要这个功能。
视频演示进一步讨论了实现该需求需要考虑的内容，例如：
不能从一条 User Story 直接跳到写代码。
用户需要；
所需数据；
后端处理逻辑；
用户界面；
系统行为；
Acceptance Criteria；
测试条件。
例如，可以形成类似的 Acceptance Criteria：
这使“感官友好路线”从一个抽象概念，变成一个可以设计、开发和验证的功能。
八、Kanban 与 WIP Limits
Seminar 使用管道堵塞的比喻说明 WIP Limits（Work in Progress Limits）。
同时处理的任务越多；
成员切换上下文的次数越多；
任务等待和阻塞的时间越长；
真正完成的任务反而越少。
因此，Kanban 会为不同阶段设置 WIP Limit，例如：
当某列达到限制时，团队不能继续把新任务拉进来，而应该先帮助完成或解决已有任务。
WIP Limits 的目的不是限制团队效率，而是：
识别瓶颈；
减少任务堆积；
加快任务完成速度；
维持稳定、可预测的工作流。
九、Week 2 前需要完成的事情
Task 1：Week 2 Pre-reading Quiz
Task 2：Product Discovery Presentation
这体现了 Agile Team 的 Shared Responsibility。
Task 3：Team Outing and Reflection
完成团队 Social Activity 或 Outing；
根据 Reflective Diary Guidelines 撰写反思；
反思不应该只是描述“做了什么”，还应该说明从团队互动中学到了什么，以及这些经验如何影响后续合作。
本次 Seminar 最重要的五个结论
FIT5120 评价的不只是最终产品，也评价整个团队协作和个人贡献过程。
Agile 并不等于没有计划，而是优先关注用户、协作、可运行软件和对变化的响应。
团队成员可以有不同专长，但产品设计、开发、测试和交付属于所有人的共同责任。
需求应从 User Story 逐步转化为数据、界面、功能和 Given–When–Then Acceptance Criteria。
不要同时开始太多任务；通过 Kanban 和 WIP Limits 优先完成当前工作并及时暴露瓶颈。