保持项目节奏

保持项目节奏

• 在项目中使用持续集成
  * 持续集成可以让开发人员马上得到所作工作的反馈，尽早识别出集成风险
  * 完成了某个功能才签入是按阶段集成。长时间才签入会打断项目节奏：构建出现问题会中断设计和编写新功能的人员的思路。回忆细节是一种同时处理多任务的方式因为思考问题的上下文发生了改变，但不容易发现。
  * 频繁构建是为开发人员和项目经理准备的，如果可以运行测试就更好了
  * 持续集成的变种：做一个主代码库的分支版本，在此分支版本上开发且每次签入都与主代码库进行同步，保证分支代码是最新的版本，最后将所有代码合并回主线

• 为构建创建自动化冒烟测试

  • 冒烟测试仅仅是为了验证要构建的版本没有问题
  • 跨平台，数据库或固件的，要确保团队每天都为所有的平台编译并构建产品。兼容性问题早发现就更容易修复

• 按功能实现而不是按架构

  • 按架构实现，很难进行持续集成，无法构建和持续测试
  • 没有有价值的东西产生因为无法衡量，如果按功能实现，完成某个功能就可以开始计算价值了
  • 按架构实现会打乱项目的节奏，得到的都是部分完成的功能
  • 要了解实现功能要具备的足够的架构的完整性
  • 考虑功能之前仍需知道整体架构没有问题，这种情况，架构草图会有所帮助
  • 首先实现具有具有高价值的功能
    • 产品代办事项列表，产品经理，或客户参与。如果都没有项目经理和团队一起制定和发布
    • 功能的价值和完成度越高，团队就拥有更多的灵活性
  • 按功能调试， 构建跨架构团队
  • 按功能测试

• 多几只眼睛盯着产品

  • 结对编程：减少缺陷，加快开发速度，有backup, 且深入了解团队开发的系统的各个部分
  • 伙伴复查：无法达到结对编程的学习效果
  • 同行复查：复查代码风格多于内容
  • 走查
  • 正式检查：很难坚持
  • 维持检查很难坚持，检查别人的代码会打乱每个人的节奏，还有项目的节奏

• 准备重构

  • 重构是对代码的简化，无论是产品代码还是测试代码。重构不等于重新设计，只是简化而已。不会改变它的契约，只是更简单
  • 可以让重构与开发同时进行–重构成本小，也可以最后再进行重构—重构成本高，因为反馈延迟过久，不知道应该重构哪些代码以及如何重构。

• 通过用例，用户故事，角色和场景来定义需求

  • 只要大家了解需求的上下文，开发，测试和文案人员就能知道如何开发测试编写文案

• 分离需求与GUI设计

  • GUI设计要体现出GUI如何引导用户使用系统以解决他们的问题
  • 很多项目都以需求获取为幌子，陷入GUI设计的瘫痪之中
    • 项目总是陷于无尽的需求工作之中，看看问题是不是在GUI设计上
    • GUI是设计，不是需求， GUI设计不应该放到需求文档中

• 尽可能使用低保真度的原型

  • 使用低保真度的原型，可更全面的评估要解决的问题
  • 高保真度的原型会限制反馈。项目初期，项目经理希望得到更广泛的反馈，而不是限制反馈
  • 低保真度的原型不只可以用在GUI设计中（案例用了纸上的模型来完成GUI设计）

注意事项： 项目经理可以邀请团队成员考虑这些实践，但不能强迫他们采纳； 如果项目经理职能选择一个实践，那推荐持续集成； 项目经理采纳和调整实践要有助于保持项目节奏，允许项目提高起动和结束速度