SCRUM与极限编程笔记

1. backlog
   (1) 包括：需求，story, 特性；按照重要性排列
   (2) story项的内容：ID, name, 重要性，est（工作量估计：人/日），demo，notes
   (3) 分为产品以及sprint backlog
   一般产品backlog就是一个user story的stack
   
   sprint backlog是一个图表，他可以很大
   

sprint

1. sprint基本要素
   目标、结束日期、backlog

2. sprint计划
   (1) 会前必有backlog : 一个产品只有一个backlog与一个经理
   (2) sprint产出物：sprint目标、团队名单、backlog、sprint演示日期、scrum会议时间地点，以及其他附加项
   (3)
   [1] scope：范围，即到底要做哪些事，做多少
   [2] 这个三角是相互制约的，裨益其中一项些必然牺牲其他
   [3] 外部质量 vs 内部质量：
   外部质量是指用户的使用体验比如响应速度，界面好不好看；内部质量是指可维护性，如系统设计的一致性、测试覆盖率、代码可读性和重构
   外部质量是scope决定的，是可以取舍的；但内部质量永远要保证，不可牺牲

3. sprint会议讨论
   (1) sprint会议时间分配 ：sprint要简短；一旦决定时间盒就要坚持，有时候卡了就打断，继续干活
   (2) 确定sprint目标：“这段时间到底要干嘛，没必要干不如摸鱼”
   (3) sprint做哪些事：主要团队决定；像出栈一样，把优先级高的取出来放进一次sprint
   (4) 会议的时间估计：
   [1] 凭感觉
   [2] 理想的人日 X 投入程度
   投入程度是一个估计量，实际生产量/原始估计量（整个sprint的est和），默认值70%

4. sprint任务
   (1) sprint中将user story拆分成任务，使用索引卡，就像上述的sprint backlog的左半部分；而不在产品backlog中拆分，太乱
   (2) 大故事 --> 故事（进入产品backlog）–> 任务（头尾：1. 写测试 … n. 重构）

5. sprint backlog
   (1) 再次如图：
   
   (2)
   NOT CHECKED OUT：还没着手的任务
   CHECKED OUT：在做了
   DONE：做好了（可以由测试人员决定）
   燃尽图：est量剩余 X 日期
   NEXT：如果事情都做完了还有时间，就从这里拿
   UNPLANNED：没有在计划中的小任务
   (3)
   白色纸片：user story不含有技术细节
   黄色纸片：分成的小任务是技术实现，如写测试

6. sprint演示/回顾
   (1) 在一个sprint完成之后要演示可行的版本，但是不要说技术细节
   (2) 回顾时反思sprint执行

7. 经理在平时的讨论过程中尽量不参与，避免干扰技术细节

发布计划

8. 发布计划：产品的1.0版本什么时候能做好
   (1) 1.0版本必须要完成最重要的功能
   (2) 验收标准：按照重要性安排1.0要完成哪些功能：
   
   重要性 > 100 : 必须完成
   50 - 99 : 应该完成，不过也许我们可以在紧接着的一个快速发布版中完成这些。
   25 - 49 ：可以在以后的1.1版本中实现
   <25 : 不确定最终会不会实现
   (3) 时间估计：团队应该对最重要的条目快速粗略估计时间。很粗略，不是一个确切时间；接着估计生产率，接着生成发布计划
   
   (4) 此时也要进一步解释讨论最后的演示demo是什么样

极限编程 + SCRUM

9. TDD：测试优先
   (1) 建议每次代码check in（上传）的时候，进行测试
   (2) 验收测试：要由组外的他人手工测试
   (3) sprint中可以添加测试员，由他决定“Done”
   (4) 测试自动化，效率up up

10. 推荐代码的标准：
    Exception一定要输出stacktrace，捕获完要throw
    使用setter
    无效返回值不要无脑null，要带类型，比如空数组

11. sprint1有bug反馈于sprint2，则“修bug”高优先级进入sprint2的backlog

12. 地理位置分布的SCRUM
    (1) 每日例会上community
    (2) 讨论：语音
    (3) 共享backlog（产品 + sprint），燃尽图
    (4) 设置信息共享的时间