zoukankan      html  css  js  c++  java
  • 敏捷开发的成熟度模型解析

          敏捷开发已在国内大多数的企业成功推行,它包括了管理实践和技术实践,但在很多公司,对于敏捷开发的衡量标准和活动的执行的标准仍有争议,有人说敏捷不需要流程,敏捷没有质量评价标准,敏捷只关注进度......这些观点均存在于各大公司的开发团队中,那么,跟CMMI一样,敏捷有没有度量的标准呢?

              根据共创力公司的咨询与培训的案例,结合业务著名的通信公司华为的实践,我们把敏捷分为五个层次:-1(阻碍)、0(中立)、1(协作)、2(操作)、3(适应)。

    • -1阻碍:当前的过程限制了敏捷的实行

    • 0中立:既不阻碍也不有利于敏捷软件开发

    • 1协作:具备实施敏捷软件开发的基础

    • 2操作:通过对相关技术的掌握和相应的纪律支持了敏捷软件开发的持续实施

    • 3适应:当前团队的过程已经足够成熟,能够良好地响应变化

           对于敏捷成熟度的评估主要从以下几个方面衡量:

    管理实践方面:需求管理、团队文化、迭代管理 ;

    技术实践方面:软件构建、测试、简单设计

    上图是一个敏捷的评估模型,针对每一个评估项有如下的问题可以对标:

    1)需求管理:

    1、需求是怎么获取的?
    2、需求如何跟踪?优先级是如何确定的?优先级在整个版本开发过程中会有什么样的变化?有哪些因素会导致优先级变化?                                      

    3、 需求变更是怎么进行的?会有哪些人参与?
    4、需求实现人员与需求提出人员之间是如何交流的?交流频率是什么样的?
    5. 谁来定义验收条件?谁做验收测试?什么时候做?

    6、需求估计什么时候做?谁会参与估计?

    7、用的什么需求管理工具?                                                                      

    8、当需求需要进行澄清时,怎么办?    

    2)团队协作:

    1、版本的人员间信息获取渠道有哪些?不同角色之间的信息需求是如何满足的?
    2、开发人员是否结对?怎样结对?在什么情况下结对?一般结对时间有多长? 

    3、是否交换结对?多长时间一次?   

    4、团队成员如何认领任务?                                                                     

    5、在文档权限、代码权限上,不同的角色是不是有区别?

    6、to PM: 哪个人的突然离开会造成项目损害?为什么?你如何应对?        

    7、项目状态是否大家都清楚?                                                                   

    8、是不是有规律的做迭代回顾?回顾中讨论什么事情?讨论结果如何处理? 

    9、在哪里/通过何种形式可以找到项目相关的信息和知识?                         

    10、当你解决了一个技术问题,你如何与他人分享你的经验?                     

    11、知识共享有没有建立?                                                                     

    12、面对面交流是否频繁 ?                                                                      

    13、新员工进入团队如何获得帮助?                                                          

    14、团队内部以及团队与外部的交流会议是否例行?                                  

    15、开发人员通过评审代码的方式,是否能达到质量保证和知识传递的目的?                                                                         

    16、开发人员是否只了解自己的工作?                                                       

    17、配置库的权限如何分配?是不是都有权限访问?     


    3)迭代管理

    1、计划的精细程度?整个项目只有一个计划,还是每个迭代都有计划?      

    2、计划有多长?几个月,还是几个星期?                                                  

    3、在项目进行中发现业务重心发生转移,如何应对?                                 

    4、交付是否分为若干次发布?                                                                   

    5、迭代计划谁来参与制定,根据什么制定?                                            

    6、每个迭代多长?周期固定么?                                                              

    7、项目状态报告如何获取?                                                                      

    8、如何更新进度?你如何了解项目进度?                                                  

    9、迭代是否交付可工作的软件,是否交付价值?                                       

    10、团队成员是否熟悉迭代流程和Story流程?                                          

    11、迭代中的Story能否独立测试?                                                            

    12、是否有有效的可视化管理手段?                                                          

    13、团队成员是否有迭代的意识?                                                             

    14、是否有风险管理机制?                                                                       

    15、如何处理需求变更?

    4)软件构建

    1 成功构建的标准是什么?
    2 构建是自动化的吗?每个人的构建过程是一致的吗?
    3 构建的频率是多少?每次构建的大概时间是多少?
    4 使用什么样的版本管理工具?
    5 配置管理工具是否支持原子提交?
    6 每日构建结果报告怎么通知?
    7、提交冲突如何解决?
    8、开发人员一般多长时间提交一次代码?                                                  

    9、开发人员每天check in 代码有没有什么规则?

    10、CI搭建在什么机器上,是不是有专人维护CI环境?持续集成的硬件资源环境是否充足?

    11、CI需要执行哪些测试?                                                                        

    12、是否有严格的持续集成纪律?                                                             

    13、如果有本地构建的话,本地构建包含哪些内容,时间大概多长?           

    14、CI构建的输出报告有哪些内容,是否有人关注?                                  

    15、自动化测试成功比率?自动化测试用例数量?


    5)测试

    1、当前的开发过程中,开发和测试人员主要开展哪些工作?之间是如何配合的?
    2、当前版本的测试活动主要有哪些?分别涵盖哪些内容,由谁进行?每类测试活动的周期比例(重点关注story测试、迭代验收测试、系统验收测试等)
    3、版本的测试策略与计划是如何制定的?都包含哪些内容?
    4、测试用例是否能继承,继承后的修改量是否巨大?
    5、测试能够做到自动化吗?哪些测试能自动化?
    6、测试活动在整个版本中人力是怎么一个分布趋势?测试E2E效率如何?(代码行/测试人天)                                                                                  

    7、开发人员是否写测试?写哪些测试?                                                     

    8、测试能够稳定的重复执行么?                                                               

    9、随着项目演进,大家积极维护重构测试吗?                                           

    10、什么时候写测试?哪些角色写测试?                                                   

    11、有回归测试包吗?其中包含了哪些测试?                                            

    12、使用什么工具来跟踪bug?                                                                 

    13、开发和测试人员怎样合作重现并修复bug?                                         

    14、什么时候写单元测试?单元测试覆盖率是多少?是不是所有人都写单元测试?是否有单元测试培训?                                                                  

    15、开发和测试是否结对ST,怎么做测试?                                               

    16、测试环境是不是共享?                                                                       

    17、开发者测试、story测试、迭代测试等分别使用什么工具来跟踪bug?各阶段测试bug分布比例? 

    6)简单设计

    1、设计文档包括哪些文档?                                                                      

    2、设计文档怎么写出来的?哪些人参与?                                                  

    3、那个文档对开发的指导性较强?怎么指导开发?                                    

    4、会不会出现后面设计变动较大的情况?                                                  

    5、设计需要更改的时候怎么处理?描述一下场景                                         

    6、什么时候进行重构?重构的频率是什么样子的?                                    

    7、重构有哪些具体实践?是否代码优化?                                                  

    8、如何保证重构的正确性?                                                                      

    9、描述一下重构是怎么做的                                                                      

    10、什么工具辅助重构?                                                                           

    11、接口、数据结构的演进怎么做的?                                                       

    12、架构如何演进,是SE决定还是与大家讨论?

  • 相关阅读:
    python基本数据类型(—)
    linux基本命令
    1、认识Mysql
    Flask-SQLAlchemy详解
    sqlalchemy基本增删改查
    pymongo方法详解
    uWSGI+Nginx部署
    uwsgi
    nginx负载均衡配置
    redis-sentinel主从复制高可用(哨兵)
  • 原文地址:https://www.cnblogs.com/mikeyond/p/11364047.html
Copyright © 2011-2022 走看看