今天去听了一个干货满满的讲座, 解答了我的一些敏捷的疑问, 也更加确定了我以前的一些想法和做法.

这次由leangoo和scrum中文网组织的讲座, 主讲人是廖靖斌, <<Scrum敏捷软件开发>>的第一译者, 也为很多公司做过内训, 经验丰富.

按讲演的顺序谈谈体会:

一. 敏捷思维

这个包括三部分:

* 价值驱动. 这一点就是要交付, 并且尽快交付有价值的东西. 这次的更深体会是, 一切有价值的需求都是驱动力, 不只是产品, 还包括技术需求, 测试, 重构, 改BUG, 甚至撰写文档.提到一个Zappos的典型案例.

* 适应变化. 这个主要是快速迭代了. 大家并不陌生.  内涵包括频繁交付, 频繁确认, 频繁交付正确成果. 后面两点, 是需要自动化测试, 持续集成保证的了.

* 自组织团队. 这个以前并不够关注, 也没有足够的方法. 这里面提到, 将用户与团队直接对接的重要性, 举了小米的例子, 要求开发团队每天要泡45分钟论坛. 目的是对用户的使用情况有直观的感受.

讲到从契约模式到共享责任这一点, 我们猫宁团队目前还在很努力的去探索. "一荣俱荣, 一损俱损"的方式.

二. SCRUM框架和流程

包括三个角色: PO, SM, 开发团队, 大家一条船, 又是讲前面的 "一荣俱荣, 一损俱损".

三个工作: 产品Backlog, sprint backlog, 燃尽图.

里面比较有感受的是四个会议+1, 分别说一下:

* +1 的会议, 是需求准备的会议, 在开Sprint计划会议之前几天, 提前将准备好的需求,UI,UX等, 与开发沟通清楚. 不清楚的需求补充好, 或者不在此次开发.

* Sprint计划会议. 对应我们猫宁团队, 就是每次迭代前的需求讲解, 用户故事划分为任务,  然而又有几个重要不同: a. 计划会议大约2~4小时, 需要在会上确定前后台接口, 将用户故事划分为任务, 按优先级依次排列用户故事. 但不去确定谁来开发.

* 每日站会. 15分钟内. 这个会议上才去确定谁去做哪个任务. 非常重要的一点是.A. 大家要按优先级去做用户故事. B. 大家要做同一个用户故事, 交付后才能一起做下一个故事 C. 大家自己领取任务, 做完了再继续领取别的任务. 哦, 可是我做IOS不会Java后台啊... 这里提出了要去学习其他的能力, 帮助其他人做事情, 从简单的文档, 测试等开始做起.

* Sprint评审会议. 这个目前我们没有做. 举了个例子, 某个北京的公司 , 周五下午, 老板什么也不做, 就是看各个scrum团队讲这次迭代开发的内容. 全公司其他人有兴趣的都可以参加, 包括市场, 销售等.团队要解答参加者提出的问题. 评审前, 要将产品发布到预发布环境中, 也就是上线前的测试环境.

* Sprint回顾会议. 团队内进行的查漏补缺. 在下一次Sprint时候改进. 这一个我们目前也做的不够.

三. 用户故事地图

我们之前用的是需求池, 感觉结构上类似. 用户故事地图更好的地方在于, 横向上再次用用户角色进行划分(不同泳道), 并且将用户的业务流程从上到下依次排列. 业务下面再划分用户故事. 其他纵向的按Sprint划分, 与我们现在按版本划分差不多.

四. 其他

* 可视化协作. 看板放在一个人人都能随时看到的地方非常重要, 对所有人都有很好的督促作用. 所以他建议买一个大电视一直用来放看板. 而且也确实有公司这么去实践了.

* 自动化. 自动化是解决技术债务的唯一方式了. 把那些无聊的重复的工作都自动化了吧! 不用再有疑问了.

* 文档. 目前出现的接口文档和实际接口不一致的问题. 那么把文档也作为验收标准, 作为需求的一部分吧!

标签: none 阅读量: 1498

添加新评论