1 禅道介绍
1.1 关于禅道项目管理软件
1.2 禅道介绍PPT下载
1.3 如何获得支持
1.4 关注我们
2 安装禅道
2.1 选择适合您的安装方法
2.2 使用云禅道在线项目管理服务!
2.3 windows用一键安装包安装(推荐)
2.4 linux用一键安装包
2.5 linux下用lampp集成包安装
2.6 使用源码包安装(各系统通用)
2.7 禅道虚拟机运行环境安装(virtualbox)
2.8 华芸NAS在线安装
3 升级禅道
3.1 选择和自己环境对应的升级方式
3.2 通过源代码方式升级(通用)
3.3 windows一键安装包的升级
3.4 linux一键安装包升级
4 创建分组和用户
4.1 建立部门结构
4.2 添加一个帐号
4.3 批量维护帐号
4.4 设置分组,建立权限体系
5 最简使用
5.1 使用禅道来进行项目任务管理
5.2 只使用禅道来做bug管理
5.3 只使用禅道来进行产品管理
5.4 个人使用禅道来做事务跟踪管理
6 基本使用
6.1 禅道使用的基本流程和产品、研发、测试之间的三权分立
6.2 敏捷开发及scrum简介
6.3 禅道和scrum的对应关系
6.4 禅道的新手教程
6.5 创建第一个产品
6.6 添加第一个需求
6.7 开始第一个项目
6.8 确定项目要完成的需求列表
6.9 为需求分解任务
6.10 提交bug
6.11 视频教程:第一个演示项目
6.12 维护联系人
6.13 禅道的自定义功能
6.14 导入excel、csv参考文档
6.15 文档管理
7 进阶使用
7.1 使用流程
7.1.1 禅道使用流程图解
7.2 个人管理
7.2.1 使用待办进行个人事务管理
7.2.2 关注需要自己处理的任务、需求、bug
7.2.3 通过我的档案查看或者修改个人信息
7.2.4 视频教程:禅道使用之个人篇
7.3 产品经理篇
7.3.1 维护产品
7.3.2 创建和评审需求
7.3.3 变更和评审需求
7.3.4 需求的状态和研发阶段
7.3.5 需求的注意事项
7.3.6 维护产品模块
7.3.7 建立发布计划
7.3.8 建立发布
7.3.9 路线图
7.3.10 文档管理
7.3.11 主持产品会议
7.3.12 参与项目管理、演示和总结
7.3.13 需求的基本统计报表
7.3.14 视频教程:禅道使用之产品经理篇
7.4 项目经理篇
7.4.1 建立项目
7.4.2 组建项目团队
7.4.3 确定项目要完成的需求列表
7.4.4 组织进行任务分解
7.4.5 召开每天的站立会议
7.4.6 通过燃尽图了解项目的进展
7.4.7 通过各种列表的各种功能了解项目进展
7.4.8 召开演示会议和总结会议
7.4.9 项目任务基本的报表统计
7.4.10 视频教程:禅道使用之项目经理篇
7.5 开发团队篇
7.5.1 参加项目计划会议,分解任务
7.5.2 领取任务,并每天更新任务
7.5.3 通过看板和树状图查看任务
7.5.4 创建版本
7.5.5 申请测试
7.5.6 解决bug
7.5.7 文档管理
7.5.8 确认bug
7.5.9 视频教程:禅道使用之开发团队篇
7.6 测试团队篇
7.6.1 维护bug视图模块
7.6.2 提交bug
7.6.3 验证bug,关闭
7.6.4 激活bug
7.6.5 找到自己需要的bug
7.6.6 维护测试用例视图
7.6.7 创建测试用例
7.6.8 管理测试任务
7.6.9 执行用例,并提交bug
7.6.10 查看报表统计
7.6.11 视频教程:禅道使用之测试团队篇
8 维护配置
8.1 维护禅道
8.1.1 初始化管理脚本
8.1.2 备份禅道
8.1.3 恢复删除的资源
8.1.4 如何更新燃尽图
8.2 配置禅道
8.2.1 设置是否允许匿名访问
8.2.2 如何配置email发信
8.2.3 禅道云发信
8.2.4 如何成为超级管理员
8.2.5 配置禅道系统为静态访问
8.2.6 去掉禅道访问地址中的zentao
8.2.7 集成禅道和svn
8.2.8 集成禅道和git
8.3 导入其他系统
8.3.1 导入bugfree数据
9 定制开发
9.1 二次开发机制
9.2 禅道的目录结构
9.3 找到要修改的文件
9.4 禅道的数据库结构
9.5 公用模块--common
9.6 如何登记菜单
9.7 示例:如何修改禅道的语言提示?
9.8 示例:创建bug时可以设置优先级字段
9.9 使用在线扩展编辑器
9.10 禅道项目管理软件打包规范1.1版本
10 其他相关
10.1 禅道所使用到的第三方代码
10.2 禅道FAQ
10.3 如何帮助禅道项目
10.4 禅道商业服务
10.5 禅道项目的贡献者
10.6 历史修改记录

需求的注意事项

2012-06-04 15:51:55
王春生
26759
最后编辑:先知 于 2016-10-08 14:37:24
简介:本篇文章讲述了在禅道中如何撰写需求以及用户故事和原型图、需求设计文档之间的关系和区别。

一、禅道中需求的写法

在禅道中,我们默认给大家提供了一个需求的模板:作为一名<某种类型的用户>,我希望<达成某些目的>,这样可以<开发的价值>。这个模板是借鉴自scrum开发里面的用户故事(user story)的写法。只不过我们使用了相对比较中性的概念。

 

在这个模板中,总共有三个元素:角色,要做的事情,价值或者原因。我们平时在写需求的时候,往往会忽略角色和价值原因这两个元素,只关注了要做的事情。其实这有很多的问题。不进行用户角色的划分,会影响对产品功能的设计和定位,从而导致产品往往是给一个用户角色开发的,就是产品经理自己。:)而忽略开发的原因或者价值,会让开发人员感到困惑。他们可能并不理解你这样做的原因或者目的,不理解的需求实现起来自然会有问题。 

二、需求的INVEST原则

除了上面基本的模板之外,在撰写用户故事的时候,可以参考INVEST原则:(摘自http://duweizhong.blogbus.com/logs/112151436.html)

  • I dependent(独立的):一个用户故事对于另一个用户故事应该是独立的(尽可能的)。故事之间的依赖性使得增加了计划编制,确立有限级,故事估计这些工作非常困难。通常,可以通过组合用户故事或者分割用户故事来减少依赖性。
  • N egotiable(便于沟通的):一个用户故事是便于沟通的。一个故事的卡片是包含故事详情的简短描述。这些详情是通过讨论阶段来完成的。一张还有很多详情的卡片实际上减少了和客户的会谈。
  • V aluable(有价值的):每个故事必须对客户具有价值(无论是用户还是购买方)。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到一个用户故事并不是一个契约而且可以进行协商的时候,他们将非常乐意写下故事。
  • E stimable(可估计的):开发者需要去估计一个用户故事以便确定有限级并对故事进行规划。但是让开发者难以估计故事的问题来自:对于领域知识的缺乏(这种情况下需要更多的沟通),或者故事太大了(这时需要把故事切分成小些的)。
  • S mall(短小):一个好的故事应该在工作量上短小,描述具有代表性,而且不超过2-3人周的工作量。超过这个范围的用户故事,将会在划分范围和估计时出现很多错误。
  • T estable(可测试的) :一个用户故事是可测试的来用于确认完成,记住,我们不开发不能测试的故事。如果你不能测试那么你永远不知道你什么时候是完成了。一个不可测试的用户故事例子:软件应该是易于使用的。
一个编写良好的用户故事是敏捷开发的基础。它们应该相互独立,详情应该便于开发者和用户进行沟通,应该对用户有价值,应该对于开发者来说尽可能的清晰以便进行估计,应该短小,通过预定义测试用例的使用确保它是可以测试的。

三、禅道里面的需求和原型图、需求设计文档的区别

传统管理模式中,很多产品经理都在用原型图软件设计原型图或者非常完整的需求设计文档。设计完之后,交给设计人员进行页面设计,然后由开发人员合并代码。那么原型图和用户故事之间的关系和区别是什么呢?

  • 和user story相比,原型图或者需求设计文档是一个整体,可以给人宏观的把握。这是原型图的优点。比较直观。
  • 它是一个整体,所以就没有办法进行分解。你不可能分解成,做页面导航条,做页面的中间部分等。
  • 没有分解,所以原型图也就没有办法进行优先级的排序。比如页面部分,有的很重要,有的不重要。但在原型图里面是体现不出来优先级的。
  • 没有分解,自然也就无法进行跟踪。你没有办法得知原型图完成了多少。
  • 过于死板,给设计人员和开发人员留下的发挥的空间太少,后演变成被动执行。
  • 需求设计文档规定的比较细致,会让产品经理陷入太多的细节,对整体的把握会减弱。

虽然相比较于用户故事而言,传统的原型图或者需求设计文档有一些不足,但在实际的开发过程中,二者可以相辅相成。禅道从1.2版本中,已经增加了文档库管理。可以将原型图作为设计文档,上传到某一个产品相关的文档库中,和用户故事相互配合,是一个好的方案了。