敏捷开发

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了敏捷开发相关的知识,希望对你有一定的参考价值。

参考技术A 一、目标

目标1:更快的交付价值,就是更早的交付。

目标2:有效学习和灵活响应变化。

二、价值观:

1.个人和交互胜过过程和工具。

2.可以运行的软件胜过面面俱到的文档。

3.客户合作胜过合同谈判。

4.响应变化胜过遵循计划

三、12条原则

1.通过尽早的、不断地提交有价值的软件来使客户满意。

2.即使到了开发的后期,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

3.以从几个星期到几个月为周期,尽快、不断地提交可运行的软件。

4.在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。

5.以积极向上的员工为中心,建立项目组,给他们提供所需的环境和支持,并对他们的工作予以充分的信任。

6.在团队内部,最有效、效率最高的传递信息的方法,就是面对面的交流。

7.测量项目进展的首要依据是可运行软件。

8.敏捷过程提倡可持续的开发,责任人、开发者和用户应该为能够保持一个长期的、恒定的开发速度而努力。

9.时刻关注技术上的精益求精和好的设计,以增强敏捷能力。

10.简单是最根本的。

11.最好的构架、需求和设计出于自组织的团队。

12.每隔一定时间,团队要反省如何才能更有效地工作,然后相应地调整自己的行为。

四、运作机制

1.一个团队有自己的代办事项,对代办事项进行拆小。

2.按客户价值进行优先级排序,产品经理负责价值排序。

3.小而稳定,跨职能团队。

4.多个团队松耦合(依赖性比较低),对齐迭代时间和战略目标。

五、团队角色

1.产品负责人

负责管理产品backlog(代办事项)的唯一负责人

代表客户/项目如责任人

定义产品的所有特性

负责产品的投入产出

负责最大化产品和开发团队工作的价值

2.主管(流程主管)

起到教练的职责,领导团队完成Scrum的实践以及体现其价值。

排除团队遇到的困难,使得团队紧密合作,使得团队个人具有多方面职能的工作能力。

确保团队能胜任其工作,并保持高效的生产率。

保护团队不受到外来无端影响

3.开发团队

每日例会:每日5分钟

评审会:1个小时左右

迭代回顾会:时间维持在30-60分钟内。

包括,定量分析和定性分析。

定量分析:迭代目标,迭代度量指标(包括速率、迭代燃尽图、迭代计划故事和实际完成故事、计划发布日期与实际发布日期、客户满意度、团队满意度、生产环境Bug数、生产Bug解决时间、用户故事等)。

定性分析:哪些工作良好(应该继续保持),哪些做的不好(应该停止)?哪些可以改进(团队选出1-2条在下一个迭代实现)?

“越敏捷越健壮”-开发中心敏捷开发培训有感

    2018年4月25日,我部邀请微软最有价值专家MVP徐老师为研发中心团队进行了敏捷开发培训,培训内容包括“敏捷开发概述”、“精益看板方法”、“Scrum和站会”。

    在培训的第一个环节“敏捷开发概述”中徐老师纠正了大家对于敏捷开发的误解,即敏捷开发不是一种为了快速交付而出现的方法,而是一种为了使团队更好地适应变化、提高团队健壮性而建立的方法

    笔者认为,敏捷开发方法刚好可以解决我们目前阶段工作中遇到的一大困难:“变化”。在过去的工作中我们经历了种种“变化”,而这些“变化”实实在在地影响到了团队的产出效率,其中最大的两种“变化”分别为:需求的变化和人员的变化。

    1.需求的变化    

“越敏捷、越健壮”-开发中心敏捷开发培训有感

    需求的变化主要体现在业务需求变更方面。由于我行处在起步阶段、业务发展迅速、方向变化快,提交给研发中心的需求经常出现反复的情况,例如第一周正式向研发中心提出A需求、第二周否定A需求重新提B需求、第三周否定B需求重新提C需求、第四周否定C需求又重新要求开发A需求。

    2.人员的变化    

    人员的变化则体现在外包人员的流动性方面。由于我行处在起步阶段、行内开发人员严重不足,相当数量的开发工作需要由外包人员来完成。而外包人员的频繁流动性等特点,给我行电子化的快速和稳定化发展带来了一定程度的制约。

    思考:怎样适应变化?    

    敏捷开发方法中提倡的“减小管理粒度”、“降低工程耦合”思想可以一定程度上帮助我们适应目前面临的各种“变化”。管理粒度被拆分到足够小时每个开发人员负责一个或几个功能点的开发工作,当发生人员流动时只影响到这几个功能点的开发进度,对全局影响较小。而工程耦合的降低主要通过加挡板的方式实现,即系统和系统之间加挡板、模块和模块之间也加挡板。这样不同模块的开发测试进度互不影响。当一份需求涉及到的所有模块均已开发测试完成后再撤掉挡板进行集成。这也和软件开发过程中的单元测试、集成测试方法不谋而合。由于系统被拆分成很多小的模块、模块和模块之间也是高度解耦合的,当需求发生变更时只需要调整所涉及到模块的开发工作,对于整个开发工作影响没那么大。

    事物的两面性    

    当然,马克思主义辩证法告诉我们,事物都是有两面性的。敏捷开发方法中的“减小管理粒度”、“降低工程耦合”思想虽可以提高团队面对变化的能力,同样也会导致管理成本的剧增。如何在这两方面进行有效平衡则是我们以后工作中需要探索的重点。

    徐老师在“精益看板方法”课程中给我们带来了哪些干货呢?研发中心团队对于“精益看板方法”又有哪些思考呢?且听下回分解...


    注:本文仅代表个人观点,文中所使用的图片来源于免费图片平台,本文中所出现的公司名称、人名均已征得对方同意。

以上是关于敏捷开发的主要内容,如果未能解决你的问题,请参考以下文章

如何多团队大规模实施敏捷开发

什么是真正的敏捷开发?敏捷开发与瀑布开发有何不同

敏捷开发签名人建议开发者放弃“敏捷”

开发模式-敏捷开发:什么是敏捷开发

什么是真正的敏捷开发?敏捷开发与瀑布开发有何不同

精益/敏捷开发框架_SAFe & LeSS