OpenParty "清雨榕香"

2010年8月的OpenParty "清雨榕香"活动 创下了各个话题参与人数的新高,很多话题的会议室都密密地站满了人,在各个热门话题的驱使下,大家的热情依然不减,在一个下午的时间里体验了一个又一个知识分享的小高潮。关于活动话题的详情,请参见`OpenParty网站`_上关于本次活动的`链接`_,下面简要记叙下我参与的几个话题的相关信息。 首先是来自淘宝网的苏宁带来的"淘宝广告技术部开发流程和Scrum实践",淘宝的Scrum实践一直应用于广告竞价系统的开发,取得了一些成果。想必大家都想要细细了解一下Scrum在大公司内部的实际应用案例,这个话题提供了很多相关的信息,帮助大家更好地了解Scrum以及实践Scrum时会遇到的一些问题。我的记录基本上遵循了讲解时的Slide结构,有一些内容是从现场的讲解中了解到的,也补充了进去。 Sprint 刚开始时

  • 使用excel来管理,自动生成燃尽图
  • 流程:产品经理提出需求->Sprint->产生Backlog->进行开发及测试,最终到产品上线->Review
  • 只有产品、开发、测试几个角色,角色比较少
  • 受干扰因素少,Scrum流程比较精简

现在Scrum开发流程

  • 功能需求数目增加
  • 很多时候都是项目进行一半的时候才引入Scrum
  • 团队中角色数目的增长

复杂的Scrum逐渐开始

  • 经常有工作中遇到的种种问题而引发的中断,此时Scrum要如何进行配合(明确分工,通过流程进行配合)

淘宝的Scrum角色

  • 产品
  • 架构师
  • TL/PM/Scrum Master
  • 开发
  • 测试
  • PE
  • 运维工程师

角色的作用

产品经理

  • 提出需求、提出产品文档,对项目进行验收
  • 需要注意的是,在淘宝,相对于一般的Scrum流程,对于文档的要求要更高一些。只有更高的文档要求,才能保证公司业务可以更从容地面对人员变动等情况。

架构师

  • 分析需求对系统架构、功能上的变动
  • 出台系统调整方案
  • 系统总体设计
  • 掌握系统改造成本

TL/PM/Scrum Master

  • 组织Sprint
  • 追踪项目开发进度
  • 沟通协调

测试

  • 需求提出之后,测试就会进来
  • 了解需求动机
  • 测试用例
  • 各种测试
  • TDD

开发

  • 模块
  • 代码开发
  • 单元/内部集成测试
  • Bug修复
  • 上线手册(这部分是必须的)要交给运维来Review

运维(产品运维)

  • 了解业务需求、系统瓶颈
  • 熟悉模块接口和数据接口
  • 故障应对措施
  • 流量增长模型
  • 实际上线操作

整体Scrum流程

  • 由产品经理和架构师来共同确定功能需求,完善比功能基本明确需求对于系统功能的变更和影响,产生未细化的Backlog
  • 然后将未细化的Backlog通过Sprint来产生细分的backlog,交由开发者进行开发
  • 开发人员在开发的过程中,需要和测试和运维一起进行协作来完成。在交由运维人员进行上线以前,运维人员必须从测试人员那里拿到上线许可。不经过测试人员认可的项目不能上线。

目标

  • 一切不以上线为目的的开发都是耍流氓

团队配置

  • 开发测试比例 2:1
  • 尝试结队编程,在一段时间内实行,后来发现成本比较高,就放弃了。

计划会/需求沟通

  • 需求点罗列
  • 需求的实现思路
  • 任务分解
  • 每日晨会的三个经典问题

Sprint总结会议

  • 头脑风暴,集思广益
  • 成功
  • 不足
  • 改进方案

任务分解:WBS

  • 规定了上线时间,能否完成?
  • 需要落实到每个人,每个人的各个工时,算出总工时,然后再确定上线时间。
  • 而需求要做到能分解的就分解掉
  • 如果需求提出方不能满足所计算出的上线时间,那么就要进行研究讨论看看砍掉哪方面的需求以达到更短的上线时间。
  • 人日的计算方法;通常一个人的工作还要有分工,60%开发,40%运维;按照一个人每天6小时的工作来计算

Scrum策略及工具

  • 调整工位:一个项目的人员坐在一起,减少沟通的成本

还举了两个案例,基本上讲述了在项目进行过程中,没有在早期就注意到影响项目的一些风险,导致风险被拖后 而项目进行过程中的变数非常大,经常有意想不到的情况来打断项目开发的过程,解决问题的成本非常高 对于工程师来说,要尽力产生可复用的代码 要多考虑风险,尽早解决危机,一个Scrum能解决的问题,不要带到下一个Scrum 淘宝内部使用的Sprint工具

  • Excel
  • Sharepoint + Project
  • XPlanner - (记录工程师实际的工作用时,最后自动生成burndown chart,但是最后由于工程师反映此项工作太耗时间,被搁置了)
  • Mindmap,现在主要使用mindmap来在一个巨大的脑图上记录各种信息。这个脑图非常细致,规定了各个人要进行的任务,任务的划分也非常细致,时间精确到小时

Sprint分解会

  • 开发人员自己领取任务。这部分淘宝的做法和Scrum的标准做法有些许不同。
  • Scrum模式本身的推崇由开发人员自己来规定并设计项目开发点,但是淘宝在实施上发现过于浪费时间了,于是就变成了由产品经理等需求提出人和架构师定出粗略项目,最后在开会前就定好要开发的功能点,只做任务分解

关于开发人员需要完成的上线文档的详述:

  • 其中包括文档信息,RPM包的版本信息,为测试部署的相关文档,包括上线操作、回滚操作的具体步骤
  • 上线手册应该手把手传达给运维人员如何进行操作,目标是做到无须询问开发人员就可以实现项目上线。所以淘宝对项目开发人员的文档水平要求都非常高
  • 这些上线的文档都要进行Review!

对于需求的要求:

  • 最好有最终的文字描述,用文字解释详细,并且有实例。

接下来是由豆瓣的工程师石头带来的"从豆瓣Pulse谈起 - HTML5 相关技术在实际项目或产品中的应用"话题

HTML5在视觉,交互等诸多领域,为Web带来了全新的体验 最大的问题:浏览器兼容性 - 应该有意识地去引导用户使用性能更高,功能更多的现代浏览器, CSS3技术非常的绚丽,很多

Posted 2010.09.12
Category: Event

Comments