读硝烟中的scrum和XP笔记

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

上一篇:内存拷贝渲染视频的研究


下一篇:理解 iOS 和 macOS 的内存管理