Build realistic delivery schedules, communicate blockers early, and visualise dependencies so multi-file codebases, npm libraries, and testing pipelines stay on track. 制定切实可行的交付时间表，提前沟通阻碍，并可视化依赖关系，确保多文件代码库、npm 依赖与测试流始终在线。
Display iterations, milestones, and buffer so no deliverable sneaks up on the team. 清晰呈现迭代、里程碑与缓冲区，避免交付节点“偷袭”。
Map out which stories unblock others and plan branch coordination. 标明哪个故事解锁其他任务，提前规划分支协作。
Compare planned versus actual velocity and trigger scope trims when needed. 对比计划与实际速度，在需要时及时缩减范围。
Use tones to differentiate design, implementation, testing, and review windows. 用颜色区分设计、实现、测试与评审时段。
adminAuthRegister before adminUserDetails).识别前置条件：将规格拆为原子端点或模块，例如 adminAuthRegister 先于 adminUserDetails。Start with the course-supplied iteration checklist, then apply the lecture’s “plan for dependencies” mantra. Group endpoints that share infrastructure (e.g. authentication, quiz lifecycle) and colour the GANTT chart by responsibility so ownership is obvious. 先使用课程提供的迭代清单，再落实“规划依赖”的理念。把共享基础设施的端点归类（如认证、测验流程），在甘特图中按负责人上色，让所有权一目了然。
Lecture 2.2 (Multi-file & Importing) reminds us that modern features rarely live in a single file. When planning, capture which modules export shared utilities and which tests need mocks. Link these notes directly into your meeting minutes and task board. 《多文件与导入》讲座指出现代功能很少存在于单一文件里。规划时要记录哪些模块导出通用函数、哪些测试需要 mock，并把这些说明连接到会议记录与任务板中。
npm init, dependency installation, and script authoring early in Iteration 0.在第 0 次迭代早期安排 npm 相关工作（如 npm init、安装依赖、编写脚本）。Explicitly noting library versions, module boundaries, and test coverage in your plan prevents “hidden” dependencies from derailing delivery when teammates merge work late in the cycle. 在计划中明确记录库版本、模块边界与测试覆盖度，避免同伴在周期末合并代码时，被“隐形”依赖拖慢进度。
Document multi-file design decisions so teammates know how modules interact before implementation. Note which files export utilities, which rely on named imports, and where aliases are required to avoid collisions. 在实现前写下多文件设计决定，帮助团队了解模块如何协同。记录每个文件导出的工具、哪些地方需要命名导入，以及为了避免冲突必须使用别名的场景。
Lecture 2.2 shows how default exports differ from named exports. Capture the contract in planning docs so consumers know whether to write import util from './file.js' or import { util }.
讲座 2.2 展示了默认导出与命名导出的差异。把约定写进规划文档，让调用方明确是写 import util from './file.js' 还是 import { util }。
// lib.js
function addBrackets(string) {
return `(${string})`;
}
function manyString(repeat, str) {
let out = '';
for (let i = 0; i < repeat; i++) {
out += str;
}
return out;
}
export { addBrackets, manyString };
If two modules expose similar names, plan the aliasing strategy (e.g. import { sum as simpleSum }) and assign an owner to maintain the shared import registry.
若多个模块导出的名称相似，提前规划别名策略（如 import { sum as simpleSum }），并指定负责人维护共享导入登记。
A plan only works when coupled with regular communication. Combine weekly status meetings with twice-weekly stand-ups to keep the GANTT chart honest. Use the “always set deadlines” mindset to attach dates to every dependency hand-off. 只有配合规律沟通，计划才能落地。把每周状态会与每周两次站会结合，确保甘特图真实可信；用“总是设定截止时间”的思路，为每一次依赖交接附上日期。