specdd

SpecDD实践框架:

  • 理解和掌握大型开发项目的有效管理策略和多团队协作模型;
  • 提供敏捷与其它方法整合的优化框架;
  • 提供有效实现敏捷开发与需求& 质量、需求& backlog、项目& 资源、项目组合管理、QA& 测试团队的整合框架;
  • 阐述开发团队如何能用相同的办法来管理敏捷和非敏捷项目;
  • 开发工作被分解到开发空间,里程碑,和各个冲刺迭代中,同时Product backlog和需求管理是相互整合的;
  • 提供明确的指导方针,以及如何实践的做法,实现QA测试用例在迭代周期内被定义;
  • QA团队既能够独立工作,同时又能与回归测试相整合;
  • ……
团队管理

团队

可扩展的多团队开发模型

以Scrum为代表的单纯敏捷方法,提高了软件开发过程的有效性和生产率;但是它不能帮助团队实现可持续和能扩展的成功。它缺少对多团队协作大型开发项目的有效管理模型。现实中,更多的企业敏捷项目,采用了质量与需求整合的敏捷过程。

  • SpecDD强调和质量管理团队的整合。SpecDD中,QA部门既能够独立工作,同时又能与回归测试相整合,从而有效地和敏捷开发团队协作。
  • SpecDD强调和需求管理团队的整合。通过系统化地需求管理,实现需求的完全可追溯性,高效、灵活地推动了交付结果的正确性。同时,更好的将创造产品功能时所经历过的团队讨论与决定过程,进行管理。
开发和需求的整合
backlogo

产品Backlog

产品Backlog 是一组待处理的Story和开发任务列表。产品Backlog中的Story不是具体的需求,是基于需求生成的一次实现分配。我们可以直接将需求从需求空间分配到Sprint;也可以先将需求分配到产品Backlog,由产品负责人对Backlog中的所有条目统一进行优先级排序,然后选择能实现的部分放入Sprint中。一旦Story被分配到Sprint中,就自动从产品Backlog中移除。

Story

  • Story是对指定需求的具体实现
  • 包含功能 Story、缺陷Story
  • 独立的Story, 没有相对应的需求
  • 需要进一步分解为多个开发任务

用户故事

用户故事

backlogo

需求变更管理,并高效变更推送开发空间、测试空间

如果您的团队需要对需求变更执行严格的审批流程,DevSpec提供了需求变更管理视图,并可自定义需求变更审批流程。

您也可以简化,直接对需求列表做变更操作。业务部门评估需求变更的影响范围,通过需求变更标识子任务(Change Flagging Event),将变更内容自动推送到受影响的关联开发任务和测试用例,帮助团队轻松管理需求变更。

开发和测试的整合
测试

开发周期中做适量的测试

  • 在Sprint 开始之前,根据需求的质量标准,定义好测试用例
  • 测试人员将设计好的测试用例,紧密地与开发任务相关联
  • 开发和测试合作,完善并创造测试用例,达成有质量保证的开发结果

独立的测试部门,有效和敏捷开发团队协作,全面的测试覆盖面

  • 为新完成的相关产品功能,找到所有的测试用例,应用具体环境变量
  • 选中所有可能影响的测试区域,进行回归测试
  • 测试团队可以为多个开发团队开展测试工作
  • 发现的缺陷可以被提交到共享的或单独的迭代Backlog中

测试

流动的QA

  • 推荐1-2名测试人员加入开发团队,加入的测试成员主导测试工作
  • 通过QA测试协同子任务,将测试用例与开发任务相整合,并管理Sprint过程中的缺陷和质量保证
  • 测试结果,直接影响开发人员的剩余工作时间
需求和测试的整合
测试

测试和需求

  • 基于需求设计定义测试用例
  • 测试计划应用具体环境变量,生成测试任务

高效保证测试质量

通过调整环境变量复用测试用例,保证相同的产品在不同环境中的测试质量

测试
项目跟踪

specdd

工作流引擎

工作流引擎驱动的跟踪机制, 使得需求及任务流程不再混乱。可自定义的工作流程, 保证不同职能团队前后协调工作。

specdd

敏捷项目是否需要计划—YES!不过项目计划建立在需求层面。与项目计划紧密关联的任务管理机制,直观的条目化展现形式,让您不再使用白板和便签,信息量更大,管理却更加简洁。

完整的历史记录让任务可追踪,可追溯。

了解更多SpecDD 专题介绍和文章

售后服务平台登录

用户名:

密码:

登录