通常在产品需求文档中,我们会描述软件的功能。但在Scrum
中,是从用户的角度来描述功能,而且有固定的句式。比方说:作为设备管理人员,需要什么功能,得到哪些好处。Scrum
把它叫做用户故事(User Stories)。所有的用户故事的集合,叫做Product Backlog
,就翻译成“产品功能记录”吧。
然后决定哪些用户故事需要做到产品中。
这个工作谁做呢?Product Owner
,产品经理。
还需要一个Scrum Master
,项目经理。项目经理负责项目的进程,确保每个团队成员具备合适的工具,组织会议,监控进程,管理发布时间。
其余的团队成员包括:美工设计、前端、后端、测试、运维等等。
比如我们做宿舍公寓版解决方案,就可以设计一个Scrum
团队,包括一个产品经理,一个项目经理和其它相关成员,并设计一套绩效激励方案,和市场挂钩。
当确定好哪些需要做的功能之后,产品经理把这些功能被归入Release Backlog
,就翻译成“发布功能记录”。
然后确定这些功能的优先级,哪些需要先做,哪些后做,并确定每个功能所需要的时间,往往精确到小时。
然后把Release Backlog
需要做的功能分解,在Srum
中叫做Sprint
,就翻译成“迭代”吧。
每一次迭代一般在几天到一个月之间,每一次迭代结束都达到可发布的状态。
在每一次迭代过程,功能一个一个被完成,最终可发布的迭代结束,进入到下一次迭代。
而且每一次的迭代进程都可以通过图表可视化。X轴坐标代表每一次迭代的时间周期,Y轴坐标代表剩余的小时数。由项目经理每天统计了解项目进展。
下图的中斜率代表平均每天完成50个小时的功能,就能按期完成本次迭代。斜率=剩余的小时数÷剩余的天数。
如果斜率大一点,说明有可能提前完成本次迭代。
在每一次迭代的每一天结束,项目成员可以开一次简短的、站立会议,叫做Scrum Meeting
。项目成员描述今天完成了哪些,工作遇到哪些问题。
当每一次迭代结束,项目成员可以来一次迭代复盘会议。项目成员描述哪些地方做对了,哪些地方需要提高。
Product Owner:
--用户故事整理和版本管理(文件名:ProductBacklog):比如设备经理想要什么样的功能,这样获得什么好处
--筛选放入产品的用户故事和版本管理(文件名:ReleaseBacklog)
--需求评审
--产品需求文档(文件名:ProductRequirement):拆分成角色、功能,让设计人员、架构师、测试人员等理解,可能还配有用例图、流程图、泳道图、时序图、状态图
--任务分解:每个任务需要多少工时
--设计迭代版本:每一次迭代都达到可发布的状态
--原型图
Scrum Master:
--Scrum团队成员管理
--进度管理
--Scrum meeting:时间不常,每日一会
--Sprint meeting:每次迭代的复盘
--发布管理
其它成员
--美工设计
--Web前端
--管理后台
--苹果端
--安卓端
--后端架构
--后端开发
--测试人员
--运维人员
--市场人员
--安装人员
项目 | Product Owner | Scrum Master | 美工设计 | Web前端 | 管理后台 | 安卓端 | 苹果端 | 后端架构 | 后端开发 | 测试人员 | 运维人员 | 市场人员 | 安装人员 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
智能照明版 | 徐总 | 季建新 | 外协 | 季建新 | 季建新 | 外协 | 外协 | 季建新 | 季建新 | 季建新 | 季建新 | 徐总 | 项目经理 |
公司大屏版 | 徐总 | 季建新 | 外协 | 毛敏 | 无 | 无 | 无 | 季建新 | 季建新 | 无 | 无 | 无 | 无 |
公司运营后台 | 徐总 | 季建新 | 外协 | 毛敏 | 速e小组 | 无 | 无 | 季建新 | 季建新 | 无 | 无 | 无 | 无 |
中小企业版 | 徐总 | 季建新 | 从晓磊 | 无 | 无 | 外协 | 外协 | 季建新 | 季建新 | 无 | 无 | 无 | 无 |
宿舍公寓版 | 丛晓磊 | 杨安东 | 丛晓磊 | 毛敏 | 洋洋 | ||||||||
写字楼版 | 杨安东 | 杨安东 | 崇 | ||||||||||
物流版 | 丛晓磊 | 丛晓磊 | |||||||||||
对外合作版 | 季建新 | 季建新 | |||||||||||
网站 | 季建新 | 季建新 | |||||||||||
能耗版 | |||||||||||||
铁塔版 | |||||||||||||
工地管理版 | |||||||||||||
中小学版 | |||||||||||||
幼儿园版 |
我们现在所处阶段:原型打造