51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2353|回复: 0
打印 上一主题 下一主题

[转贴] 敏捷项目管理

[复制链接]
  • TA的每日心情
    无聊
    前天 09:06
  • 签到天数: 530 天

    连续签到: 2 天

    [LV.9]测试副司令

    跳转到指定楼层
    1#
    发表于 2018-12-18 16:41:58 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    本帖最后由 测试积点老人 于 2018-12-18 16:43 编辑

    为什么要用敏捷?如今,项目管理的步伐越来越快。项目管理需要更灵活、更积极地,响应客户的需求。使用敏捷项目管理方法,项目经理可以在不影响价值、质量和商业规则的前提下实现所有目。


    1.项目管理的目标与策略

    1.1 目标

    主要目标:在预算和时间范围内交付符合客户需要的高质量的软件产品

    其他目标:提高团队成员能力获得度量数据以改进流程和提供可预测性


    1.2 策略

    项目成功的关键:

    • 准确的需求分析——功能
    • 优雅的设计,简洁的编码——质量
    • 全面的测试,自动化构建和持续集成——可靠性
    • 透明、可控、可持续、可预测的⽣产过程——项目管理

    1.2.1 需求分析 —功能

    将需求转化成功能:用例( RUP),用户故事(敏捷)。


    1.2.2 领域建模 —理解业务领域

    如何实现领域建模:

    • 发现业务领域中的本质抽象和共同机制
    • 发现领域概念的类型层次结构和组成层次结构
    • 实现业务逻辑和业务规则。

    1.2.3 设计与编码 —质量

    如何保证代码质量:

    • 设计要优雅,编码要简洁
    • 领域驱动设计
    • OO原则、设计模式、重构
    • 简单性、一致性、灵活性、扩展性的对立统一

    1.2.4 TDD

    测试先行、自动化构建与持续集成保证项目的可靠性。

    • 测试先行,测试用例要做到全面测试
    • 自动化构建,自动化构建工具要做到自动测试
    • 持续集成,持续集成工具要做到频繁测试

    测试先行:

    • 测试先行为产品代码提供实现目标和验收标准
    • 测试先行保证有一套全面的测试集伴随产品代码终身
    • 测试先行保证系统在各种异常条件下的表现符合预期 测
    • 试先行保证修改和重构产品代码不会破坏现有功能
    • 测试先行为程序员提供信心、勇气和成就感

    工具: Concordion,JUnit, Mockito, DBUnit, Fitnesse, Selenium, jsUnit,这些工具可以帮助我们做到测试驱动开发。


    1.2.5自动化构建

    • 自动化构建减轻重复性的机械劳动
    • 自动化构建保证测试100%执行
    • 自动化构建可以自动编译、打包、部署和验收测试
    • 自动化构建保证构建的过程和结果可重复
    • 自动化构建可方便切换操作系统、中间件和数据库

      工具: Maven, Ant, Gradle,这些工具可以帮我们做自动化构建。


    1.2.6 持续集成

    • 持续集成保证频繁运行全套测试
    • 持续集成可以在任何时间交付可靠可靠产品
    • 持续集成在构建失败时及时通知正确的人

    工具: Jenkins, Hudson, Continuum ,这些工具可以帮我们做到持续集成。


    1.2.7 质量度量和设计评审

    开发人员的七宗罪
    设计评审
    复杂性
    是否实现了预期功能
    重复
    是否适合整体架构
    缺乏单元测试
    是否安全、可靠、高效
    不符合编码规范
    是否足够简单、清晰、可读
    注释不足或太多
    是否易于扩展
    潜在的Bug
    是否测试了各种边界条件
    意大利面条式设计
    能否提炼通用概念和逻辑

    工具: Sonar可以帮我们做代码评审,管理代码质量。


    2 敏捷项目管理

    2.1 敏捷宣言

    • 个体和交互 胜过 过程和工具
    • 可以工作的软件 胜过 面面俱到的文档
    • 客户合作 胜过 合同谈判
    • 响应变化 胜过 遵循计划

      虽然右项也有价值, 但我们认为左项更有价值。


    2.2 项目的敏捷开发方法

    • 敏捷团队作为一个整体工作,团队所有成员对项目拥有共同责任 .
    • 按短迭代周期工作,固定四周一个迭代,绝不延长 .
    • 每次迭代交付一些成果 ,每次迭代实现一批用户故事,交付客户使用.
    • 关注业务优先级 的功能,优先实现具有高业务价值的用户故事 .
    • 进行检查和调整 ,每次迭代根据上次迭代获得的新知识进行调整.

    2.3 估计故事规模

    • 用故事点估计用户故事的规模
    • 以某个众所周知的功能做参照系
    • 用波多那契数列1,2,3,5,8,13表示故事点 超出13点的故事要拆分为多个更小的故事

    估计方法:规划扑克 由开发团队估计故事规模,客户代表不干涉 。


    2.4 排定故事优先级

    根据业务价值和风险设定用户故事优先级 :

    • 高价值高风险
    • 高价值低风险
    • 低价值低风险
    • 低价值高风险

    由客户代表或产品经理负责排定优先级


    2.5 进度安排

    2.5.1 发布规划

    1.确定满意条件 2.估计用户故事规模 3.选择迭代周期长度   4.估计速度 5.确定用户故事优先级 6. 选择用户故事和发布周期

    2.5.2 迭代规划

    1.调整优先级 2.确定目标速度 3.确定迭代目标 4. 选择用户故事  5.把用户故事分解为任务 6. 对任务进行估计  

    2.5.3 每日例会

    1.每天固定的时间进行 2. 限时15分钟左右 3.每个人站立进行 每个人回答三个问题:1. 昨天做了什么? 2. 今天打算做什么? 3.存在什么问题?  

    2.6 跟踪与交流

    2.6.1 看板

    2.6.2 图表与度量

    • 速度图——每个迭代完成的故事点
    • 迭代燃尽图——迭代中每天剩余的故事点
    • 发布燃尽图——发布中每个迭代剩余的故事点
    • 故事/Bug比例
    • 开发人员生产力

    从下图可以看出每周实现的用户故事


    2.6.3 展示成果

    • 每天向团队展示已完成的成果
    • 确保每个人理解每个功能的实现
    • 纠正偏差,提供改进意见
    • 防止“各人自扫门前雪”
    • 让个人成果变成团队资产

    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-23 18:03 , Processed in 0.064853 second(s), 22 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表