应用禅道进行敏捷软件开发过程管理.pptx

1、现状：,大部分项目都还是采用传统的瀑布式管理。开发周期比较长，对市场的变化响应不灵活。产品经常延期发布。产品的质量总是不能满足预期。团队长期加班，工作没有成就感。,敏捷宣言,个体与交互 重于 过程和工具可用的软件 重于 完备的文档客户协作 重于 合同谈判响应变化 重于 遵循计划,敏捷背后的十二个规则,我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。 欢迎对需求提出变更即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。 项目过程中，业务人员与开发人员必须在一起工作。 要善于激励项目人员，给他们以所需要的环境和

2、支持，并相信他们能够完成任务。 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。 可用的软件是衡量进度的主要指标。 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。 对技术的精益求精以及对设计的不断完善将提升敏捷性。 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。 最佳的架构、需求和设计出自于自组织的团队。 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。,和瀑布式开发相比较,敏捷的开发周期更短，最长不超过一个月持续的交付可以工作的软件。客户的充分参与。坐在一起的团队，面对面的沟通和交流。团队的自组织和管理。,敏捷开发的两种流行方式,

3、极限编程极限编程，偏重于开发实践。采用一系列的开发实践了保证代码的质量和按期交付。单元测试，持续集成，TDD，结对编程，重构scrum偏重于宏观的项目管理，并没有规定具体的开发实践。scrum + xp,需要有一个合格的scrum master,scrum master要协调PO 和 Team，保证迭代的完成。scrum master像教练，保姆，要帮助团队解决困难，推动团队前进。但scrum master和项目经理很大的不同是 scrum master没有决策的权力。所有的决策，应当由Team来完成。,产品经理角色的转变,不再是撰写复杂的需求说明书，而是将产品分解为一个个的user stor

4、y，并为期估计优先级，进行排序。对产品进行规划，制定发布计划(release plan)积极参与项目过程，随时和团队进行沟通。验收产品，参加演示会议，获得反馈。,开发人员的转变,由以前的被动执行，改为自我组织。项目过程中的决策，都是由团队自我完成。真正达到Team work。尝试采用极限编程的开发实践，找到自己适用的实践并执行。（或者TDD）,过程的变化,计划会议 产品经理召集每天的站立会议 Scrum Master召集每天更新自己的任务和燃尽图演示会议总结会议,借助于工具,禅道,核心功能组织管理部门管理、用户管理、分组管理、分组管理、权限管理产品管理产品管理、需求管理、计划管理、发布管理、路

5、线图项目管理项目管理、任务管理、项目需求管理、团队管理、工时管理、build管理、燃烧图。质量管理Bug管理、测试用例管理、测试任务管理。我的地盘TODO管理、我的需求、我的bug、我的任务,基于SCRUM的完整涵盖产品管理、任务管理、测试管理的开源管理软件,用户角色,系统管理员(Admin)系统管理员主要负责添加用户，分配权限。产品人员(product owner)产品人员主要负责产品管理。开发人员(developer)开发人员负责产品的研发。测试人员(QA)测试人员保证产品的质量。项目经理(Project Manager or scrum master)通过项目，协调产品人员，开发人员，测

6、试人员完成产品。scrum里面，该角色称为scrum master。,基本概念,组织视图：部门结构、用户和分组产品视图：产品、需求、计划、发布和路线图项目视图(Sprint)：项目、任务、产品、需求、bug、build、燃烧图、团队QA视图：Bug、测试用例和测试任务我的地盘：todo、任务、项目、需求、bug,首先产品人员维护需求列表，需求有优先级和预计工时。召开产品计划会议(Planning Meeting)，与会人员有产品、研发和测试，大家就当前项目（固定的时间和人）所需要完成的需求达成一致，形成项目的需求列表。项目团队对需求进行WBS任务分解(分割成完成时间不大于2天的若干子任务)，开

7、始开发。测试人员根据需求创建自己的测试用例。当有版本提交以后，建立相应的测试任务，记录缺陷。研发人员修复bug。项目结束之后，大家召开演示会议，团队向相关人员（产品人员及所有感兴趣的人）展示该项目所取得的成果。大家提出的反馈由产品人员整理成为需求。开始下一轮的循环。,禅道和scrum的对应,产品管理,产品管理是至关重要的一环添加产品维护产品模块添加需求需求详情需求处理流程计划发布路线图,产品管理至关重要,很多项目管理软件中只有单纯的任务管理，没有产品管理。乃至很多的软件将产品和项目混为一谈。在禅道中，项目是一个动态实施的过程，项目的产出是可以交付的产品。在禅道中，所有的一切都是围绕产品展开的。

8、产品管理的核心是需求。在scrum里面，简化为story(用户故事)。即像讲故事一样来描述一个需求。,添加产品,维护产品模块,产品模块就像一棵树，用来组织需求。,提示,添加需求(1),添加需求(2),添加需求的时候，应该选择对应的模块。如果有产品计划，可以选择相应的计划。默认刚刚添加的需求为草稿，需要进行评审。如果团队中不需要走评审流程，可以将“不需要评审”选上。需求可以上传附件。,需求详情,通过需求详情页面可以看到需求的所有信息，以及历次的修改记录。,提示,需求处理流程(1),需求有一个状态(status)字段，总共有四种状态，分别是草稿(draft)、激活(active)、已变更(chan

9、ged)和已关闭(closed)。对应为需求的流程操作共有：创建、变更、审核、关闭、激活。需求还有一个阶段(stage)字段，用来描述激活的需求在研发过程中所处的阶段。目前总共有等待、已计划、已立项、开发中、开发完毕、测试中、测试完毕、已验收、已发布。,需求的处理流程(2),变更需求,审核,关闭,通过,撤销否？,新增需求,审核,立项,开发,测试,验收,发布,通过,拒绝否？,拒绝，给出拒绝原因，关闭,有待明确,项目团队确认,变更任务、用例,关闭,继续原来的研发过程,有待明确,验收,发布,需求所经历的各个阶段,未通过,未通过,添加计划(plan),凡事预则立。计划可以帮助产品人员宏观把握产品，做到

10、心中有数。,提示,为计划关联需求,发布(release),路线图,计划、发布、build和路线图,计划主要是给产品人员规划需求使用。它和实际的项目没有直接的对应关系。一个项目中做的需求可能和计划完全一样，也有可能涉及多个计划。build是在项目过程中产生的，主要用来测试使用。build是对内的。经过若干项目之后，产品人员可以选择发布一个版本，发布是对外的。而且发布肯定和一个build对应。已经发布的版本加上未来的plan，构成产品的路线图。,项目管理,添加项目组建团队关联产品、需求分解任务工时管理燃烧图build,添加项目,项目代号和团队名称应用团队自由设置，体现自主管理。,提示,组建团队,每

11、个人在项目中的角色可以自由设定，工时一般都应小于8，因为基本上每个人每天都需要处理一些其他事情。,提示,关联产品,一个项目可以关联多个产品，禅道系统中，支持项目和产品之间的矩阵关系。,提示,关联需求,关联需求的过程，是对产品中的需求列表进行排序的过程，也是项目团队达成契约的过程。项目中的需求列表是产品视图中的需求列表的子集。,提示,分解任务,分解任务时，可以设置任务的类型，比如是设计，还是开发。任务也可以不用关联需求。任务需要给一个估计值。,提示,工时管理,项目中每一个成员每天都应该更新自己负责的任务的预计剩余时间。,提示,燃烧图(burningdown),系统通过定时任务，自动计算项目中所有

12、未完任务预计剩余时间之和，画出曲线图。燃烧图可以告诉我们很多东西。,提示,Build,build管理对于开发来讲是很重要的，它属于scm的范畴。在禅道中，暂时将其简化。在项目开发过程中，如果有若干功能已经开发完毕，需要提交测试，这是应当创建一个build，然后提交给QA进行测试。后续的bug管理和测试任务管理都应当基于一个build展开的。源代码地址可以给出svn的存储路径或者其他版本控制系统的路径。如果没有源代码地址，需要给出build包的存储地址。,提示,质量管理,测试用例管理测试用例模块添加测试用例测试用例详情测试任务管理创建测试任务管理用例执行用例查看结果创建BugBug管理Bug处理

13、流程创建bug解决bug关闭bug激活bug编辑bug,测试用例模块,测试用例有自己单独的模块划分，独立于产品视图中的模块划分。为什么独立开，是因为使用角度不同，产品视图中的模块是给产品人员使用的，而测试用例模块是为了维护用例使用的。,测试用例管理(1),当项目关联需求之后，QA人员应当针对当前项目所要开发的需求创建测试用例。虽然可以不写测试用例，直接进入bug测试环节，但这样会有缺漏。在禅道系统中，测试用例是分步骤的。,测试用例管理（2）,测试用例详情,创建测试任务,关联测试用例,执行测试用例(1),执行测试用例(2),用例执行结果,创建Bug,如果某一次用例执行失败，可以根据这个结果创建Bug，系统会自动生成bug的重现步骤。,Bug管理,Bug管理的流程同BugFree,我的地盘,前面所有的一切最终体现在每一个人每天的行动上面。我的地盘中列出了需要自己处理的任务、需求、bug等。还可以通过todo来管理自己每天的日程。todo类型分为三种，一种是和项目任务管理，一种是和bug关联，还有一种是自定义。这样可以将项目中的任务或者bug转换为每天的todo。,