您当前的位置: Section 4 User Story & Task
Task Estimates 实际工作比US更细致
US是给客户看的, 描述软件需求. 每个US收集了一些特定任务, 每个任务是能组合成US的小功能代码
>Task Title +Rough Description+ Estimation(Planning Poker)
在估计过程开始时, 把US分解为Task有助于计划和估计增加信心. 可信的任务估计是可靠的 (hours)
>发现比较大的任务遗漏, 调整开发循环, 推迟和调整其他的开发循环(避免这种情况, 在开始计划时就把US划分成Task来做准确Estimation)
>Burndown rate 使用Task Stick Notes便利签, 栏目 -US/Tasks -正在进行中 -已完成 -趋势图 -递延的US/Task Daily Sync up
开始任务 在Task Notes上写上SWD/TD的名字 从dependency最高的US开始
>完成一个US比两个US完成一半要好, 所以分配任务最好是按一个US接一个US >确保白板的准确性
如果有几项任务是相关或者有依赖的, 最好是按优先级或者同时进行, 相关任务可以分配给同一个SWD, 增加效率. -某项任务的完成可能会为另外一项任务的开展提供决策依据, 相互影响
Daily Sync up >跟踪任务 每个人简报 >更新工作量完成情况 更新趋势图 >更新任务 把状态改变的任务移动到相应区域 >昨天的情况和今天的任务 >提出Issue 准备解决方案 >5-15 minutes
1 哪些完成了 2 有Issue么 3 今天的计划, 对于具体Issue的讨论可以在Daily Sync之后
要点 -每天Daily Sync -会议15mins内, 了解进展, 更新白板 -提出Issue -早会
计划外任务 (客户需求) 使用红色卡片, 放入In Progress区, 和客户沟通, 由客户决定优先级, 调整计划US和Task, 预留意外时间, 并且让客户知道项目所受到的影响, 让客户选择可接受的影响, 更新白板
用不同颜色标签来表示任务的不同紧急度, 时间效率值是可以更新的
及时了解状况 客户/团队 知道工作到哪了 -客户融入工作流程 -白板显示工作过程, 在需要时交付软件
---Section4 End---
Section 5 Good Design
Refactoring 重构
>单一责任原则 Single Responsibility Principle(SRP) 每个对象应该有一个单一的责任, 所有对象的服务集中在实现单一责任上. 避免涟漪效应 Ripple Effect, 一个类负责一类事情, 不影响其他类
>DRY Don't Repeat Yourself 把系统中每个片段的信息和行为放在单一合理的的地方, 避免重复
-较少的类, 易于管理维护 Cohesion 内聚性
>良好的设计有助减轻生产压力, 使软件系统更灵活
>不管任务是如何产生的, 一旦任务出现在白板上, 就需要 assignment和estimation, implememnt
>Estimation需要包括各种情况, Demo 也属于任务部分, 不仅仅预计coding的时间
Enough Design vs Perfect Design 完美固然好, 但是符合客户所需, 按时交付软件也不错
完成所有任务包括计划外的Task和Demo以后, Iteration也完成了.
Ship, Change, Deliver, Refactoring, Honest, Single Responsibility Principle,
---Section5 End---
Section 6 Version Control
防御性开发 安全第一 保证一直能运行的代码
代码存储库 Code repository 取消错误 Undo Mistakes 修错 Bug Fixes
(Serialization, Deserialization)
配置管理 Configuration Managerment
Subversion, Visual SourceSafe
提交代码时的重点 merge, resolve
服务器主干Trunk, 分支Branch, 标记Tag
要点 -对客户而言, 已发布的软件的漏洞比实施新功能优先级高 -漏洞的修复对发布软件有影响, 要在进行中的软件版本中进行修复
-有效的漏洞修复取决于版本的定位, 不影响现有开发的情况下, 对特定版本修改
>版本信息以及ChangList的注释需要清晰: title descirption...
Reversion system
要点 -主干是正进行开发工作的地方, 代表软件的最新版本 -标记是存储目录中附在特定修改项上的名称, 以便检索
-分支是代码的副本, 对分支做修改不影响主干, 通常从标记的版本开始 -Bug Fix有时候需要同时提交到主干和分支 -标记是静态的
>比较旧的软件代码放入分支, 保持主干为最新
Perforce比书中介绍的要强大的多, 所以大多都省略吧
>该做分支的情况 -已经发布了需要在主开发循环外维护的版本 -试图对代码做颠覆性的修改, 不想影响其他人的进度
>不该做分支的情况 -代码分解到不同的文件 -为了每个开发编译自己的代码
良好分支 只有绝对必要时才做分支, 每个分支都需要维护, 测试以及发布.
版本控制做的事情 -创建存储目录, 代码保存在单一位置 -多个开发调出代码副本开发并Merge, 实现团队工作 -记录修改的时间, ID, 内容
-为代码做分支或者标记, 便于回头参照(History) -Revert 恢复代码, 消除不该有的修改
版本控制不能做的 -代码能否编译 -测试 -构思结构 -代码质量
Summary
>开发技术 -使用版本控制工具 -使用标记来跟踪项目的里程碑(Sprint/Iteration/Bug Fix/Release) -使用分支来维护带啊的独立副本(必要时)
>开发原则 -知道哪里需要修改 -知道代码放到相应的版本 -控制代码的修改分发
>本章要点 -备份版本控制的存储目录 -提交代码时提供完整的信息 -利用标记 -提交前的Merge, 保持代码更新 -利用优秀的版本控制GUI
---Section6 End---
Section 6.5 Automatically Building
Build Tool, Deployable Unit >好的代码易于使用, 理解
软件可用 保证调出的代码可以正常工作
Java Build Tool: Ant (build script) 项目 Project 属性 Property 目标 Target 任务 mkdir...
构建工具让团队中的所有人使用同样的过程将源码变换成可以运行的程序
Visual Studio -MSBuild, .NET -NAnt, Ruby -Rake, Perl, PHP, Maven, Continuous Integration System
>良好的构建脚本 生成文档, 编译项目, 清理产生的文件
>超越基本功能 参考库3rdparty, 运行应用程序, 生成说明文档, 调出代码, 运行测试, 复制构建到归档目录archival directories, 加密文件, email发送, SQL执行
每个构建代码服务一个Component, 引导程序bootstrap/主构建文件把所有事情整合起来.
Build Script也是代码, Source and Deployment descriptions... CrossPlatform, Timestamps, Repository, 属于版本控制系统, 需要版本号和标记来保存
要点 -构建工具使构建项目容易 -构建脚本中指定命令集和外部文件和资源 -创建清理脚本 -构建脚本属于代码 -构建工具是服务于整个团队
Summary
>开发技术 -用构建工具来构建脚本, 打包, 测试和部署软件系统 -IDE大多已有构建工具, 要熟悉UI背后的内容(script) -脚本属于代码
>开发原则 -构建项目是可重复和自动化的 -构建脚本为其他自动化工具奠定基础 -构建脚本还可以捕捉编译和部署的逻辑决策
>本章要点 -除了极小项目, 所有项目具有有价值的构建流程 -单一指令捕捉需求和自动化 -Ant for JAVA
-遵循普遍命名约定, 有利于他人熟悉项目和外部工具集成 -构建脚本和代码一样放入版本控制系统
---Section6.5 End---