上一篇浅谈敏捷开发及 Scrum(一)写了一些关于敏捷开发和 Scrum 的相关概念及个人理解, 这里来说说实施与遇到的一些困难.
Scrum.itlao5.com
如何实施
敏捷开发的实施, 我们是用的 Scrum 迭代开发, 关于 Scrum 的一些介绍上一篇已经说了, 这里说一下实施流程及其关键点.
一个 Scrum 迭代一般建议 2-3 周, 具体视团队情况而定, 一般团队中有一个 PO, 一个 SM, 以及 5-7 个团队人员(开发及测试, 而且这里面最好有 1-2 个以上的多面手).
迭代的管理, 我们用的是 leangoo,bug 管理是用的禅道, 下面是迭代流程:
Scrum 迭代
1,Scrum 开发中, 所有的需求都需要进入到 PO 的 Project Backlog;
2, 在迭代启动前, 由 PO 将里面的代办需求进行优先级排序, 并整理成能执行的有价值的 Story, 移入 Spring Backlog 中(注意: 这些 Story 是可执行的, PO 一般应清楚需求的验收点, 并对该 Story 有一个预估的时间点);
3, 在迭代周期内的第一天, 这一天主要是进行项目启动会(需求评审, 时间评估, 实现思路及细节讨论, 故事拆分, 时间安排等),PO 会对 Spring Backlog 中的 Story 进行描述, 团队成员进行细节询问后, 会进行一轮开发点评估(按团队成员进行一个增删改查业务为一个点来评估 Story 需要几个点进行开发或测试); 第一轮评估后, 会由团队成员阐述评估时间点的原因, 之后再进行 1~2 轮时间点评估. 团队成员之间评估相近, 且 PO 认为合理, 取最终评估点最大值(注意: 开发评开发时间, 测试评测试时间); 如果最终评估点过大(我们一般取 3 以下的点, 超过 3 则认为过大), 需要进行 Stroy 拆分, 拆分后继续评估;
4, 所有 Story 评估完毕后, 由团队成员自主领取任务, 每个成员能完成的任务量参考之前迭代的任务量(一般是几个迭代后, 才能比较准确的得到一个迭代团队和个人能顺利完成的任务点数);
5, 评估完毕后, 当天, 所有成员需要进行故事拆分, 拆分为每天或者每半天能完成的任务, 并给每个任务定一个时间点, 一般是开发先定完时间点后, 在开发的时间点基础上, 测试再加上相对应的测试时间;
6, 一般第二天或者第三天, 会进行测试用例评审, 这个主要是 PO 和测试参与, 有需要时可让对应 Story 的开发人员参与;
7, 每日站会, 在迭代中, 每天成员开始工作应该是先根据 leangoo 梳理每日的工作, 然后在每日站会上叙述昨天完成的内容, 今天计划做的以及面临的困难, 是否需要支持(这个会议时间不宜过长, 原则上是仅叙述, 不实际解决问题, 最重要的一点是 PO 闭嘴, 因为 PO 一旦说话, 肯定会聊到详细内容, 然后整个团队的时间就浪费了. 所以问题在会后解决, 当然, 更加提倡的时开发时候碰到问题立即解决, 而不是等待每日站会)
8, 项目验收会, 在迭代的最后一天上午, 我们一般会对项目进行验收, 由测试展示给 PO, 由 PO 最终决定每一个 Story 是否达标, 迭代是否顺利完成, 这是 PO 的验收会, 也是整个团队的成果展示会.
9, 在最后一天下午, 一般会进行迭代总结会, 会评选出迭代之星, 迭代中的优缺点, 以及缺点的解决方案, 并将解决方案分配到负责人, 下个迭代努力去改进.
10, 一般, 在迭代中途, 我们会有一些代码 ReView, 可以在成员的每次提交代码前进行 update 时看看别人的代码, 并建议每周花一两个小时进行团队的代码 ReView.
ps: 以上是一个迭代的主要流程(写得仓促, 但愿没遗漏).
需要注意的是: 1, 在迭代中, SM 需要保证团队不收到外界干扰, 所有的外界骚扰都先经过 SM 或 PO, 不能直接进入团队. 2,PO 需要在迭代前花费较多的时间来梳理清楚用户需求, 才能让迭代更顺畅, 不让等进入迭代遇到问题再去梳理用户需求. 3,PO 工作任务很大, 责任也是最重的, 必须保证一个迭代的任务是不轻易变化的, 不得已非要变化时, 需要进行 Story 替换. 4, 对于有线上维护任务的团队, 视情况预留线上支持的任务点. 5, 如果有团队成员需要休假, 最好在迭代启动会提出, 并预留时间. 6, 团队的稳定性非常重要, 团队稳定了, 才能准确预估一个迭代能完成的点数, 才能保证一个迭代顺利完成. 7, 迭代启动会对需求的讨论越详细越好, 这样在开发中才能少进行错误的或者重复的工作. 8, 开发中有问题及时沟通, 主张面对面沟通, 不建议问题留到开会时解决, 主张主动, 积极. 9, 迭代总结会是很重要的, 能让一个团队清除自己的长处和短处, 而更重要的是持续迭代中对于短处的改进, 这些将会让团队战斗力越来越强, 迭代越来越轻松. 11, 迭代是为了更轻松更合理更及时的完成用户需求, 所以强制给成员分配工作, 频繁的需求变更等都不应该存在, 这些会让迭代变得更沉重, 让成员觉得迭代开发毫无生趣.
大项目实施
然而, 一个大项目往往需要很多个迭代才能完成, 那么, 在大项目研发中, 如何进行迭代呢?
这就需要将一个大的开发周期 (几个月) 拆分为一个个小的开发周期(2-3 周), 然后进行一轮轮的迭代; 可以考虑在 2-3 个常规开发迭代后插入一个强化迭代(进行代码调整, 问题修复, 性能优化等), 确保前几个迭代完成的任务能保质保量; 在完成所有开发迭代后, 再进行 2-3 个强化迭代(不断测试及修复问题, 优化性能, 优化用户体验等); 当然, 最后还最好有一个发布迭代(用于整体回归测试, 发布准备等).
于是这个大项目的开发可能是这样的:
常规迭代 -->常规迭代 -->常规迭代 -->强化迭代 -->常规迭代 -->常规迭代 -->常规迭代 -->强化迭代..........-->强化迭代 -->强化迭代 -->强化迭代 -->发布迭代
Scrum.itlao.com
遇到的困难
在迭代中, 遇到一些困难时难免的, 重要的是想着怎么去解决它, 去保证迭代的正常进行, 这样, 迭代才会越来越顺利, 任务进度才能有保障, 成员才会越来越轻松.
1. 会议混乱, 偏离主题
会议偏离主题, 这个是我们团队迭代中存在了很长时间的问题, 往往讨论一个问题, 或者每日站会进行汇报时, 随着一个成员的介入, 主题越来越分散, 最后甚至变成框架不支持, 之前代码太混乱一类的抱怨.
针对这一问题, 我们这样改进:
1. 团队应该清楚任何讨论都是为了解决问题; 2. SM 应该把控好每一个问题讨论的范围, 适当中止并引导回到主题; 3. 在每日站会, PO 绝对不允许发表任何看法, 任何成员不能打断别人的叙述, 有其他意见, 站会后讨论;
2. 线上问题过多, 干扰正常迭代
因为我们项目已经上线, 而且主要是预约和缴费, 所以线上有问题大多需要及时解决(毕竟对于用户及公司来说, 涉及到钱的问题就是大问题), 于是, 刚开始的几个迭代我们做得很累, 同时迭代也往往是以失败结束.
针对这一问题, 我们这样改进:
1. 根据上个迭代的经验, 预留足够的任务点来作为线上支持; 2. 所有线上问题先经过 PO 或 SM 过滤, 保证开发人员不能被打断; 3. 一些常规问题尽量让运维解决; 4. 解决真正紧急且耗时不多的问题, 其他问题留到下个迭代;
3. 外部原因导致迭代任务无法正常完成
因为我们有很多第三方的依赖, 包括接口, 资源申请等, 往往在迭代中, 我们完成任务, 但第三方未能及时提供, 导致不能联调甚至我们自己开发的一些步骤无法进行下去.
针对这一问题, 我们这样改进:
1. 在迭代开发前由 PO 确定好第三方能提供接口或资仅源的时间, 降低任务的不确定性; 2. 使用工具进行接口模拟, 降低开发对第三方接口的依赖; 3. 在迭代故事中, 区分第三方的任务和我们自己的任务, 将开发与联调分离; 4. 当缺少第三方支持和资源时, 主动及时提出, 并找对方协商;
4.
简书: ThinkinLiu 博客: IT 老五
关于敏捷开发, 还在学习, 实践及总结中, 后续也会在这里记录新的问题和感想; 如果有什么意见, 欢迎共同探讨.
来源: http://www.jianshu.com/p/9968bec92467