精益开发实战这本书的作者就是硝烟中的 Scrum 和 XP 的作者 Henrik!scrumxp 精益看板, 这下齐活了对比上一本讲 Scrum 的书, 这本书中有很多地方值得注意:
1)团队规模 和 Scrum of Scrums
无论是 Scrum 之父肯施瓦伯的书应用 Scrum 进行软件项目管理, 还是硝, 都重点讲的是 Scrum 本身, 而 Scrum 团队的规模都不大, 按 Henrik 在硝中的说法, 团队规模应该在 5~9 人之间, 最好是 7 个人如果人数特别多, 就应该使用 Scrum of Scrums 将团队拆成几个更小的团队, 每个小团队各自使用 Scrum, 然后各个团队再派负责人参加团队之间的 Scrum 两本书关于 Scrum of Scrums 讲的都并不多, 硝讲了一些, 但它其实变化很大多团队之间并不是每日站立会议, 而是每周一次, 全员参与, 15 分钟以内, 沟通的方式不像是交流而更像是汇报
精中讲的案例则正好填补了这个空白, 讲的是一个由 60 人组成的团队, 这个大团队拆成了 5 支小团队, 共同配合本书很细致地讲解了怎么进行 Scrum of Scrums 当然, 它管这个叫精益, 并不是典型的 Scrum
5 支团队分别是: 1 支产品分析团队, 1 支测试团队和 3 支功能开发团队
其中产品分析团队和测试团队都会派人进入功能开发团队, 这些人是交叉团队, 即属于垂直的功能开发团队, 又属于横向的支持团队他们是 Scrum of Scrums 的重要元素
Scrum 中要求团队是跨职能的, 所以这样的安排对于三支功能开发团队来说, 是非常好的但产品分析团队和测试团队又该做何解释呢? 它们可不是 Scrum 中所说的跨职能团队呀书上说之所以会有这两支团队的存在, 是因为在产品分析和测试方面, 不仅需要深入开发细节的人, 也需要站在全局把握进度和方向的人
Scrum of Scrums 的每日站立会议会开三轮, 首先是 3 支垂直功能团队们开自己的站立会议包括属于这支团队的产品分析人员和测试人员接着是 2 支横向团队分别开会, 由交叉团队的成员, 分别汇报各个功能开发团队的当前进度和瓶颈, 横向团队据此了解了全局的进度, 进行相应的调整和计划最后是各个团队的负责人和项目的总负责人碰头
这三轮会议的时间是串行的, 每轮会议的时间都严格控制在 15 分钟以内也就是说, 每天早上都会开 45 分钟的会, 分三次开完有些人只会出席一个会议, 有些人会出席两到三个会议其中第一轮和第两轮会议, 分别有三支和两支团队同时进行, 这些团队都会集中在看板前, 相距不过几米, 如果有问题需要跨团队沟通, 走两步即可
硝中每周一次的全体站立会议, 从管理上更加扁平, 全员参与, 但这个真的感觉不到每日站立会议的精神了精中每天早上三次早立会议, 不要求全员参加, 从管理上来说, 让组织架构更深了, 多少有点官僚的影子进来了, 但至少更能感受到每日站立会议的精神
我知道每日站立会议对于 Scrum 的重要性, 但从没想过 Scrum of Scrums 时的壮观景象, 呵呵
2)测试团队如何融入 Scrum
关注 Scrum 的人都会问到这个问题, 理论上如果一切都那么理想的话, Scrum 团队编写出来的代码应该是质量非常高的, 团队成员是跨职能的, 自己能做测试工作, 每个轮次结束时代码都是可马上发布的但现实是, 专业的 QA 这一环肯定是必不可少的, 专业的测试人员具备一些工程师没有的技能, 工程师写单元测试的确可以帮助提高一下代码质量, 降低 bug 数量, 但专业的 QA 是不可替代的
肯施瓦伯没有讲如何让 QA 融入进来, 硝倒是有比较详细的讲解硝中的建议如下
提高代码质量, 尽量少产生点 bug
每个轮次少接受一点任务, 保证这个轮次完成的功能质量都很高, 可发布, 不抢功能, 重质量, 不抢速度
把测试人员放到项目组中, 让他在日常的工作中就开始检验其他成员的代码, 只有他检验通过的, 才能放到完成一栏去, 如果测试工程师没有事情做了, 就让他做一些辅助的工作, 比如组织文档, 编写发布打包之类的脚本, 拆分 sprint backlog
除了项目组中包含测试人员, 在项目开发完成后, 还是需要再由测试组进行一轮测试
在每个轮次开始时做计划会议时, 都预留足够的时间用于修复上个轮次结束时遗留的 bug, 理想情况下, Scrum 的情况是这样的:
但实际情况, 在 sprint2 的时候, 会受到测试团队反馈的关于 sprint1 的 bug 困扰
在开发新功能还是修复 bug 这个问题上, 采用可以开始构建新东西, 但是要给将旧功能产品化分配高优先级的策略
出于这个现实情况的考虑, Scrum 所推崇的每个 Scrum 周期结束后, 代码都可直接发布, 其实是很难做到的, 应该说不可能做到在这一点上, 无需过多纠结
精在讲测试这一块时, 有类似的建议, 希望测试团队能定期进行测试, 不要等到最后阶段, 等开发团队代码全提测了再进行测试从第一张图上, 三支功能开发团队的队伍中, 都含有测试人员, 就能看出这点
这种方式会招来测试人员的反感, 认为工作量太大, 而且代码会反复修改, 并不稳定, 测试工作不好做
精比较了一下两种测试方式的时间成本:
白色的部分表示的是测试用去的时间, 黑色的部分表示的是修复 bug 用去的时间
由这张图可以看出, 使用传统的测试方法, 测试的时间是比较短, 但用于修复 bug 的时间却会非常地长, 因为 bug 越晚被发现, 修复的成本就越高而后者虽然测试时间变长了, 但在修复 bug 上的用时却会明显变短
这里谈一下我个人的看法: 我虽然认同测试进入项目组, 并尽早开始测试, 但这事其实很难执行, 因为在绝大多数公司里, 测试人员都是归属在一个横向支持团队中, 而团队和项目组之间是合作的关系, 追求资源池的感觉, 支持完成了某个项目, 就直接回到池中等着下一个任务的到来所以测试一直跟进某个项目, 特别是还归属于项目组中去, 很难! 主要是行政方面会有很大的阻力
3)迭代周期 VS 前十的任务
在 Scrum 中, 有一个特别重要的概念就是 Sprint 周期整个 Scrum 就是围绕迭代周期来进行的, 每个周期之始进行本轮次的计划会议, 周期结束时进行验收会议和回顾会议, 在周期之内, 进行每日站立会议开发团队会有非常强的节奏感, 重视在一个很短的周期内完成一些功能, 并且在周期结束时, 代码可达到发布状态
精在很大程度上和 Scrum 有相似的地方, 比如也会开会挑选优先级高的用户故事, 压入待开发队列栈, 但精并没有 Sprint 周期的概念, 不要求开发团队估算下个轮次 (也就是未来几周内) 要开发完成哪几个任务, 不要求开发团队估算故事点精认为估算故事点非常耗时, 但意义却并不大在计划会议上, 唯一要做的事, 就是排出接下来要做的十个任务, 而这些任务什么时候完成, 并没有时间上的任何估算和承诺
这一点和 Scrum 有非常大的区别而事实上, 我更喜欢精的方式 Scrum 的计划会议, 虽然一再对工程师强调在未来的这个周期内, 大家只用做一个估算, 这个不是承诺, 完不成也没关系, 希望借此来让工程师放松, 更愉快地进行工作但在实际执行的时候, 估算很难不被承诺关联上, 工程师们总是会对估算有压力而且如果估算过于乐观, 在回顾会议上面对没有完成的估算, 沮丧感还是很强烈的
精只重视优先级, 并不重视一定周期内完成多少功能这可以让工程师毫无压力, 其实更符合敏捷的人性化精神
4)估算扑克牌
硝和精中都提到了估算扑克牌而且也都是在计划会议中使用的, 所以功能大致相同但其实两者又有区别硝中讲的是 Scrum 实践, Scrum 的计划会议需要工程师们估算出 Sprint backlog 的耗时, 根据团队生产力和各个 Sprint backlog 的耗时, 排出本轮次可完成的任务硝中的估算扑克牌就是用于团队估算每个 Sprint backlog 需要的故事点的, 它的单位是数字
而精的计划会议是用于确定接下来最重要的十个开发任务有 Scrum 中, 产品 backlog 拆分成 Sprint backlog 时, Sprint backlog 的粒度有要求, 不能太大, 如果大了, 就需要进一步拆分有精中也一样, 产品负责人列出的开发任务, 需要被开发团队估算是不是太大了不用像 scrum 那样, 进行过于细致地拆分和时间估算, 精并不提倡时间估算精认为开发任务的大小和开发实际使用的时间没有直接关系, 有可能一个小功能因为各种原因, 前后花了非常多的时间, 而一个大功能却可能很快就开发完成了精只是需要在排开发任务时, 保证这十个开发任务的粒度不要太大就行
精提供的估算扑克牌, 只有这么几张
其中问号和咖啡的意思和 Scrum 中一样, 但没有了代表故事点的牌, 只有表示小中大的三张牌产品负责人问开发团队某个开发任务的大小时, 开发团队抽出自己的牌压在桌上, 当大家一起亮牌时, 如果意见不一致, 那么进一步讨论, 如果结论是开发任务粒度太大的话, 那么产品负责人进一步将开发任务拆小
扑克牌玩法还是一样, 但意义已经完全不同了
5)任务墙 VS 看板
无论是任务墙还是看板, 都不鼓励使用电子系统, 而是使用实体墙, 这一点上两者是一样的事实上, 两者非常相似开发团队的每日站立会议都是在这面墙面前进行的, 而且墙上也都会划分待开发开发中待测试测试中完成等栏目, 也都会配上表示进度的图表
只是看板比任务墙更进一步
上面会陈列更多的任务, 比如总体产品 backlog 居然也在这面墙上(根据项目需要, 可以按自己意愿自由扩展这面墙的栏目), 所以看板会比 scrum 的任务墙更长, 更大先看个任务墙:
这是我以前在某个项目中布置的一个任务墙:
再看个看板:
怎么说呢? 任务墙是看板的一个子集看板将任务墙这种形式带到了一个更高的高度, 一种极致
看板将待开发功能进一步做了个整理, 清晰地划分出下十个新功能下五个技术故事下五个 bug 新功能是可以看到的新的功能, 技术故事是迁移数据库, 编写自动构建脚本, 重构代码等用户看不到, 但技术上确定占开发量的工作, bug 是遗留的待解决 bug
6)燃尽图 VS 开发速率图
Scrum 用一条左上至右下的斜线来表示开发进度, 用每轮次多少个故事点来表示团队的开发速度
而精用一条左上至右上的斜线来表示开发进度, 用每周或每月多少个开发任务来表示团队的开发速度
7) 发布计划
精和 Scrum 一样, 只保证当前正在进行最重要的功能, 开发的代码质量高, 可持续将功能集成起来, 产品可持续迭代, 小步快跑地发布新功能只保证当前在做最正确的事, 但不保证整体的开发时间所以精也需要在一开始就搞定领导, 如果领导坚持 x 月 x 日前, xxx 功能要全部开发完成, 那就没法玩了这应该是敏捷所有方法论都会遇到的问题
8)Sprint 周期 VS 限额
Scrum 的核心是 Sprint, 确定一个较短的 Sprint 周期, 然后通过计划会议将优先级最高的需求压到最近的 Sprint 周期中, 然后每日站立会议, 最后验收和回顾会议借 Sprint 周期来做项目的照明弹, 保持团队的成就感和活力, 同时保证新增的功能可持续集成至生产环境
精没有 sprint 周期的概念, 不是通过时间, 而是通过限额来降低开发团队在可视范围内的待开发任务量的, 比如看板上只能压入最新十个新功能最新五个技术问题最新五个 bug 这些最新都是优先级最高的, 超过这个限额的, 就不往看板上放这样, 可以保证开发团队不会承受过大压力
因为 Scrum 是有周期的, 而且每个周期内都有设计开发测试验收, 所以某种意义上来说, Scrum 的每个 Sprint 轮次都是一次小型的瀑布, 很完整而精益没有这种感觉, 它更像一种源源不断的流, 没有起点, 也没有终点, 任何时候看板上都填满了接下来需要开发的限额任务, 但高质量的产出却源源不断
精第 17 章的一组图很好地反映了看板的精髓图不好找, 建议大家自己买来看看很棒的一本书
来源: http://www.jianshu.com/p/b3d78ab9d6cf