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

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