资源描述
现状：,大部分项目都还是采用传统的瀑布式管理。
开发周期比较长，对市场的变化响应不灵活。
产品经常延期发布。
产品的质量总是不能满足预期。
团队长期加班，工作没有成就感。,敏捷宣言,个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划,敏捷背后的十二个规则,我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
项目过程中，业务人员与开发人员必须在一起工作。
要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
可用的软件是衡量进度的主要指标。
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
对技术的精益求精以及对设计的不断完善将提升敏捷性。
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
最佳的架构、需求和设计出自于自组织的团队。
团队要定期反省如何能够做到更有效，并相应地调整团队的行为。,和瀑布式开发相比较,敏捷的开发周期更短，最长不超过一个月
持续的交付可以工作的软件。
客户的充分参与。
坐在一起的团队，面对面的沟通和交流。
团队的自组织和管理。,敏捷开发的两种流行方式,极限编程
极限编程，偏重于开发实践。采用一系列的开发实践了保证代码的质量和按期交付。
单元测试，持续集成，TDD，结对编程，重构……
scrum
偏重于宏观的项目管理，并没有规定具体的开发实践。
scrum + xp,需要有一个合格的scrum master,scrum master要协调PO 和 Team，保证迭代的完成。
scrum master像教练，保姆，要帮助团队解决困难，推动团队前进。
但scrum master和项目经理很大的不同是 scrum master没有决策的权力。所有的决策，应当由Team来完成。,产品经理角色的转变,不再是撰写复杂的需求说明书，而是将产品分解为一个个的user story，并为期估计优先级，进行排序。
对产品进行规划，制定发布计划(release plan)
积极参与项目过程，随时和团队进行沟通。
验收产品，参加演示会议，获得反馈。,开发人员的转变,由以前的被动执行，改为自我组织。
项目过程中的决策，都是由团队自我完成。
真正达到Team work。
尝试采用极限编程的开发实践，找到自己适用的实践并执行。（或者TDD）,过程的变化,计划会议 – 产品经理召集
每天的站立会议 – Scrum Master召集
每天更新自己的任务和燃尽图
演示会议
总结会议,借助于工具,禅道,核心功能
组织管理
部门管理、用户管理、分组管理、分组管理、权限管理
产品管理
产品管理、需求管理、计划管理、发布管理、路线图
项目管理
项目管理、任务管理、项目需求管理、团队管理、工时管理、build管理、燃烧图。
质量管理
Bug管理、测试用例管理、测试任务管理。
我的地盘
TODO管理、我的需求、我的bug、我的任务……,基于SCRUM的完整涵盖产品管理、任务管理、测试管理的开源管理软件,用户角色,系统管理员(Admin)
系统管理员主要负责添加用户，分配权限。
产品人员(product owner)
产品人员主要负责产品管理。
开发人员(developer)
开发人员负责产品的研发。
测试人员(QA)
测试人员保证产品的质量。
项目经理(Project Manager or scrum master)
通过项目，协调产品人员，开发人员，测试人员完成产品。scrum里面，该角色称为scrum master。,基本概念,组织视图：
部门结构、用户和分组
产品视图：
产品、需求、计划、发布和路线图
项目视图(Sprint)：
项目、任务、产品、需求、bug、build、燃烧图、团队
QA视图：
Bug、测试用例和测试任务
我的地盘：
todo、任务、项目、需求、bug,首先产品人员维护需求列表，需求有优先级和预计工时。
召开产品计划会议(Planning Meeting)，与会人员有产品、研发和测试，大家就当前项目（固定的时间和人）所需要完成的需求达成一致，形成项目的需求列表。
项目团队对需求进行WBS任务分解(分割成完成时间不大于2天的若干子任务)，开始开发。
测试人员根据需求创建自己的测试用例。当有版本提交以后，建立相应的测试任务，记录缺陷。研发人员修复bug。
项目结束之后，大家召开演示会议，团队向相关人员（产品人员及所有感兴趣的人）展示该项目所取得的成果。大家提出的反馈由产品人员整理成为需求。
开始下一轮的循环。,禅道和scrum的对应,产品管理,产品管理是至关重要的一环
添加产品
维护产品模块
添加需求
需求详情
需求处理流程
计划
发布
路线图,产品管理至关重要,很多项目管理软件中只有单纯的任务管理，没有产品管理。乃至很多的软件将产品和项目混为一谈。
在禅道中，项目是一个动态实施的过程，项目的产出是可以交付的产品。
在禅道中，所有的一切都是围绕产品展开的。
产品管理的核心是需求。在scrum里面，简化为story(用户故事)。即像讲故事一样来描述一个需求。,添加产品,维护产品模块,产品模块就像一棵树，用来组织需求。,提示,添加需求(1),添加需求(2),添加需求的时候，应该选择对应的模块。
如果有产品计划，可以选择相应的计划。
默认刚刚添加的需求为草稿，需要进行评审。如果团队中不需要走评审流程，可以将“不需要评审”选上。
需求可以上传附件。,需求详情,通过需求详情页面可以看到需求的所有信息，以及历次的修改记录。,提示,需求处理流程(1),需求有一个状态(status)字段，总共有四种状态，分别是草稿(draft)、激活(active)、已变更(changed)和已关闭(closed)。
对应为需求的流程操作共有：创建、变更、审核、关闭、激活。
需求还有一个阶段(stage)字段，用来描述激活的需求在研发过程中所处的阶段。目前总共有等待、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。,,需求的处理流程(2),变更需求,审核,关闭,通过,撤销否？,新增需求,审核,立项,开发,测试,验收,发布,通过,拒绝否？,拒绝，给出拒绝原因，关闭,有待明确,项目团队确认,变更任务、用例,关闭,继续原来的研发过程,有待明确,验收,发布,需求所经历的各个阶段,未通过,未通过,添加计划(plan),凡事预则立。计划可以帮助产品人员宏观把握产品，做到心中有数。,提示,为计划关联需求,发布(release),路线图,计划、发布、build和路线图,计划主要是给产品人员规划需求使用。它和实际的项目没有直接的对应关系。一个项目中做的需求可能和计划完全一样，也有可能涉及多个计划。
build是在项目过程中产生的，主要用来测试使用。build是对内的。
经过若干项目之后，产品人员可以选择发布一个版本，发布是对外的。而且发布肯定和一个build对应。
已经发布的版本加上未来的plan，构成产品的路线图。,项目管理,添加项目
组建团队
关联产品、需求
分解任务
工时管理
燃烧图
build,添加项目,项目代号和团队名称应用团队自由设置，体现自主管理。,提示,组建团队,每个人在项目中的角色可以自由设定，工时一般都应小于8，因为基本上每个人每天都需要处理一些其他事情。,提示,关联产品,一个项目可以关联多个产品，禅道系统中，支持项目和产品之间的矩阵关系。,提示,关联需求,关联需求的过程，是对产品中的需求列表进行排序的过程，也是项目团队达成契约的过程。项目中的需求列表是产品视图中的需求列表的子集。,提示,分解任务,分解任务时，可以设置任务的类型，比如是设计，还是开发。
任务也可以不用关联需求。
任务需要给一个估计值。,提示,工时管理,项目中每一个成员每天都应该更新自己负责的任务的预计剩余时间。,提示,燃烧图(burningdown),系统通过定时任务，自动计算项目中所有未完任务预计剩余时间之和，画出曲线图。燃烧图可以告诉我们很多东西。,提示,Build,build管理对于开发来讲是很重要的，它属于scm的范畴。在禅道中，暂时将其简化。在项目开发过程中，如果有若干功能已经开发完毕，需要提交测试，这是应当创建一个build，然后提交给QA进行测试。后续的bug管理和测试任务管理都应当基于一个build展开的。
源代码地址可以给出svn的存储路径或者其他版本控制系统的路径。
如果没有源代码地址，需要给出build包的存储地址。,提示,质量管理,测试用例管理
测试用例模块
添加测试用例
测试用例详情
测试任务管理
创建测试任务
管理用例
执行用例
查看结果
创建Bug
Bug管理
Bug处理流程
创建bug
解决bug
关闭bug
激活bug
编辑bug,测试用例模块,测试用例有自己单独的模块划分，独立于产品视图中的模块划分。
为什么独立开，是因为使用角度不同，产品视图中的模块是给产品人员使用的，而测试用例模块是为了维护用例使用的。,测试用例管理(1),当项目关联需求之后，QA人员应当针对当前项目所要开发的需求创建测试用例。
虽然可以不写测试用例，直接进入bug测试环节，但这样会有缺漏。
在禅道系统中，测试用例是分步骤的。,测试用例管理（2）,测试用例详情,创建测试任务,关联测试用例,执行测试用例(1),执行测试用例(2),用例执行结果,创建Bug,如果某一次用例执行失败，可以根据这个结果创建Bug，系统会自动生成bug的重现步骤。,Bug管理,Bug管理的流程同BugFree,我的地盘,前面所有的一切最终体现在每一个人每天的行动上面。
我的地盘中列出了需要自己处理的任务、需求、bug等。
还可以通过todo来管理自己每天的日程。
todo类型分为三种，一种是和项目任务管理，一种是和bug关联，还有一种是自定义。
这样可以将项目中的任务或者bug转换为每天的todo。,
展开阅读全文
相关搜索
