硝烟中的scrum和XP笔记

读硝烟中的scrum和xp的读书笔记，对scrum有一些整理。下面的条目并不以顺序代表重要性、顺序，或是其他的意思，只是我根据读到的相关内容整理到一起的。

计划的制定

要注意的一些东西

• 计划制定需要全部团队成员以及产品负责人参加，需要一起来估算，范围，时间，以及重要性，并且不能在质量上有让步。
• 计划制定中，可能会对故事的重要性，范围都会进行修改。
• 计划游戏中，需要为每一个Story设定一个分数，不同的重要程度，对应不同的分数。分数的值，只是代表两个Story之间谁比谁重要，而不能表示重要多少倍。分数需要拉开间距，以方便插入新的任务到某两个任务之间。

故事估算注意

• 故事的估算，是指整个故事中所有工作地估算，而不只是自己部分的工作。
• 时间的单位，小时OR天？其实大家平时估算的时候，大概也是用天数的，也就是一天或者半天这样，如果不足半天的，或者超过半天一点点的，其实也没啥问题

sprint计划会议

• 需要一个时间表一般包括（总体介绍，团队时间估算，选择需要放入sprint的故事，日会）
• book中他们的sprint的长度尝试过很多，他们觉得3周左右比较适合，这个我们可以自己考虑了，但是确定后，需要在长时间内坚持
• sprint目标是必要的

决定一个sprint需要包含的故事

• 在sprint中包含多少个故事，是团队来决定，而不是其他人
  • 团队决定故事数量可以依赖两种方式，个人估算（所谓本能反应），生产率计算（根据大家的生产率来计算团队能够输出的故事点数）
• 产品负责人需要对团队的决定产生影响
  • 如果需要做的事情超过了一个团队在一个sprint能做的故事点数，那么需要进行拆分和优先级调整

计划游戏产生的东西

• sprint 目标
• 团队成员和投入度
• backlog
• 演示日期
• 日会时间和地点

完成的定义

完成并不是一个Checklist或是其他的东西，而是故事符合大家认可的定义，建议在故事上可以有一个字记录什么是完成。

扑克牌估算法的误解

我曾经对扑克牌估算法存有误解，其原因是源于对scrum团队解构的误解，认为在大家并不擅长的领域无法作为比较好的参考，实际上这个方法，有下面几个需要注意的地方：

1. 强调每个人独立思考，估算的时候每个人独力估算，避免被影响力较大的人干扰判断
2. 在大家的估算存在较大的偏差时，团队先进行讨论，让大家对故事的内容达成共识，或是对大型的任务进行分解，再次重新估算，重复以至时间趋向一致

质量

不可以在质量上让步，可以分出内部质量和外部质量，内部质量差肯定外部质量会差。并且在质量上的妥协可能后面会带来更多的悲剧。

Story中需要包含的东西

推荐的字段

• id：唯一标识一个Story，以便以后改名了神马的也能知道是什么
• name：名字，表示这个Story要干啥
• imp：重要性，一个数字，大一点好，比如30，50之类的，表示某个Story更重要
• est：时间估算
• how to demo：表示这个故事在这个sprint中的如何进行示范，如何run起来，如果用TDD，那么这个可以是验收测试的伪码。
• note：注释，引用等

附加的字段

• type：类别，比如后台，优化，之类的
• components：根据后文了解到，这里说的技术组件，其实是这个故事完成需要哪些技术类型的人或物（例如数据库，后台开发，之类的）
• requester：提出需求的干系人，在后续可能会需要向他反馈
• bug id：bug跟踪系统中的id

Story 中需要注意的东西

• 所有的Story尽量停留在业务层次，如果某个Story是一个技术类型的，那么我们需要不断的从产品那里获取这个Story的信息，明白Story真正的目的是什么
• 产品知道每个故事是什么，为什么，不需要知道如何做。

信息发布的要素

发布当前团队的信息，当前的sprint，目标，backlog的情况，时间估计，成员和投入程度。