# 硝烟中的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的情况，时间估计，成员和投入程度。