敏捷方法适合什么样的团队?

敏捷开发适用于研发团队吗?

距敏捷开发宣言的发布已经过去了将近二十年,现在很多团队都在思考“敏捷”的工作方式。营销团队想要尝试Sprint的方式来加速盈利,运营团队正在采用Scrum敏捷项目管理,而人力资源团队则正在寻求如何为公司战略注入更多的灵活可变性。

那么对于研发团队而言,敏捷实际上只是一套帮助解决大型且复杂项目的方法论。在工作中,如何正确的运用敏捷方法哪种方式,一直存在很多争论。

是否采用敏捷开发?

通常而言,复杂、大型的研发项目需要跨部门的协调,项目经理总是希望可以快速实施并交付产品。但是当你想要调动全部资源去推动此项目时,这又将对其他部门的业务和工作产生影响,这是不现实的。因此在项目研发过程中,团队需要采用敏捷开发方法,并以不断迭代的方式来应对快速变化的需求。

敏捷并非意味着在项目开始之前就定义最终需求并安排好全部工作内容。但对于跨公司的庞大项目而言,需要了解产品需求和路线,否则每个人工作都有可能出现差错。那么是否有可能将敏捷开发应用于类似上述的庞大项目呢?

我认为是可行的,但需要实行真正意义上的的敏捷开发。

请记住,敏捷并不是每个人都必须遵循的一套固定规则。它是一种方法论,是帮助团队应对快速变化的需求、提高工作效率的一种理念和价值观。在产品研发过程中,团队通常使用Scrum或看板之类的框架来提高效率,但是对于这些框架不适用的工作场景,尤其是在项目的初期,也并不一定意味着无法实行敏捷开发了。敏捷可以很简单,例如确定项目目标,将其拆解为几项可以实现的小任务,然后以此为基点进行迭代和开发。

瀑布式开发

在产品研发过程中,通常团队采用瀑布式开发的方法是:每次聚焦于一个阶段,每当一个阶段的任务完成后,团队才会开始下一阶段工作。这将导致团队在开发过程中无法适应需求的改变,不断试错,需求变更成本也会随之增加。

整个开发工作的流程是相通的,但不一定会彼此适用。此情况就好比一个公司在价格相同的情况下,是应该购买多种不同类型的办公软件,还是购买一款可以解决不同场景的办公软件,答案一定是后者更能将工作简化,提高工作效率。

那么瀑布式开发的弊端如何改善呢?是在产品开发的第一个阶段就引入第二阶段的成员吗?如果多个需求互相关联,但每个需求的开发进度不一样,又该如何协调处理呢?

由于以上瀑布开发的种种弊端,敏捷开发逐渐打破了传统的瀑布开发方式。

研发团队如何进行敏捷开发?

当项目开始时,第一步要做的事情就是定义产品的业务需求和产品路线,等到所有业务需求和实施方案都落实敲定后,再开始编写第一行代码。敏捷开发的过程是需要团队全员参与的,从定义产品需求到不断迭代交付都是整个团队的工作,因此产品经理、研发工程师以及其他所有成员都应积极参与其中,在每个环节中都可以表达自己的声音和想法。在此过程中团队需要制定迭代计划并进行站立会议,以此来持续性的学习、发布、迭代,逐步完善产品。

不管您处于何种行业,在定义产品需求的阶段,应当首先考虑产品的合法、合规性,医疗、能源或制造业等重点监管行业更应注意这一点。这也会大大避免以此带来的交付时间延迟和项目预算超支。

不可避免的是,开发过程一旦开始,新的问题也会随之而来,比如产品上线后,用户的需求可能发生变化;新的政策可能会影响产品的合规性等等。因此敏捷开发提倡在项目开发阶段,通过每天的站立会议,来确认每个成员是否遇到的问题,从而确认问题并及时沟通解决,并以此来制定迭代计划。随着产品的不断迭代和新功能发布,企业也会获得更大的价值。

慢速平稳即是高效

人们开始逐渐意识到,时间管理成为了每个人都无法回避的问题,而有时必须放慢速度认真思考才会更有效率。随着每个团队对工作方式的认知从传统流水线的旧思维,逐步转变为紧凑且自我组织型团队的新观念,同时团队也需要更多地思考如何来实现敏捷开发, 而不是一股脑地去盲目试错。

由于敏捷开发中涉及大量的任务管理、计划、协调、监控等事务,我们需要使用统一的工具来管理这些需求并将它们可视化,建议大家可以试试Worktile Agile敏捷开发工具,它包含了需求管理、迭代规划、效能度量等功能,可以帮助团队实时追踪项目进度,并且可以和Testhub测试管理等产品打通,来实现一站式DevOps开发流程。

原文作者:Philip Braddock

译者:宋思慧

文章来源:Worktile敏捷博客

欢迎访问交流更多关于技术及协作的问题。

文章转载请注明出处。

原文地址:https://www.cnblogs.com/worktile/p/12162820.html

时间: 2024-10-08 08:22:03

敏捷方法适合什么样的团队?的相关文章

1.序言,敏捷不一样的开发团队管理方法

敏捷开发系列文章目录 敏捷开发在国内是不是只是一个理想化的工作环境? 经常有人问,你们搞敏捷开发工作量是由开发人员自己估的,而不是由经验丰富的技术主管估的,他们自己肯定会把工作量估得非常大,那什么时候项目才做得完?你们每天开那么多会,怎么不把时间放在好好写代码上面?一个迭代这么短的时间既要做设计.又要编码.还要测试,这么急着做出的东西质量肯定不高.系统设计肯定得经验丰富的老手做更靠谱.每当我听到有人说这些问题,我就知道他肯定没有真正的认识敏捷开发,如果真的有实践过,自然就会发现这些问题根本就不是

读《用户故事与敏捷方法》有感(五)

今天,读到了次本书的第三部分--经常讨论的话题,用户故事不是什么,用户故事的优势与不良征兆. 第一,用户故事不是软件需求规格的指南,这种需求规格指南强调的是"系统应该--",而且对于需求规格指南而言,在写下需求之前,每个需求的成本是不可见的.典型的情况是,一个或几个分析师花两三个月时间(通常更长时间)编写出冗长的需求文档.随后把文档交付给程序员.这时程序员告诉分析师(消息会被转告给用户),完成项目要24个月,而不是分析师所希望的6个月.在这种情况下,分析师在编写团队没有时间开发的四分之

敏捷方法之极限编程(XP)和 Scrum区别

敏捷(Agile)作为一种开发流程, 目前为各大公司所采用, 敏捷流程的具体实践有XP 和Scrum, 似乎很少有文章介绍这两者的区别, 发现一篇外文, 见解非常深刻, 特将其翻译一把. 原文(DIFFERENCES BETWEEN SCRUM AND EXTREME PROGRAMMING )在此: http://blog.mountaingoatsoftware.com/differences-between-scrum-and-extreme-programming 作者总结的大致区别如下

21天敏捷打卡--敏捷方法实现

常用的敏捷实践包含:精益.看板.Scrum.XP极限编程.水晶.DSDM动态系统开发.FDD功能驱动开发.AUP敏捷统一过程.OpenUP. <敏捷实践指南>将敏捷方法和看板方法是为精益方法的子集.因为他们都符合精益思想的具体实例,都反映了“关注价值”.“小批量”.“消除浪费”. 精益软件开发LSD TPS 面对场景 解说 原则 解说 过度 对员工和生产/研发过程施加不必要的额外压力 消除浪费 无法带来价值的事务就是浪费 违规 不切实际的需求导致过生产/研发程中的不均匀 尽快交付 短期迭代或小

《用户故事与敏捷方法》阅读笔记01

用户故事与敏捷方法第一章是对用户故事的概览.      首先第一个问题用户故事是什么?用户故事描述了对用户.系统或软件购买者有价值的功能.用户故事由三个方面组成,包括1 .一份书面的故事描述,用来做计划和作为提示.2.有关故事的对话,用于具体化故事细节.3.测试,用于表达和编档故事细节且可用于确定故事何时完成.      然后第二个问题细节,故事的细节可以用另外的用户故事来描述,多个小故事远远胜于一个庞大的故事.书上将大的故事成为史诗故事,那些史诗故事可以分为多个小故事.例如将"用户可以搜索工作

结合当前公司发展情况,技术团队情况,设计一个适合的技术团队绩效考核机制

结合当前公司发展情况,技术团队情况,设计一个适合的技术团队绩效考核机制 一.引言 要想制定绩效考核机制首先要先知道绩效考核的定义是什么,绩效考核指企业在既定的战略目标下,运用特定的标准和指标,对员工的工作行为及取得的工作业绩进行评估,并运用评估的结果对员工将来的工作行为和工作业绩产生正面引导的过程和方法. 绩效考核(performance evaluation),是企业绩效管理中的一个环节,常见绩效考核方法包括bsc.kpi及360度考核等.绩效考核是一项系统工程.绩效考核是绩效管理过程中的一种

敏捷方法Scrum概述

• 敏捷方法是一类软件开发流程的泛称: • 敏捷方法是相对于传统的瀑布式软件过程提出的: • 敏捷方法可以用敏捷宣言(4条).敏捷原则(12条)来概括: • 敏捷原则通过一系列的敏捷实践来体现出来: • 敏捷方法有很多种. 敏捷的方法: • Extreme Programming (XP)极限编程 • Scrum • Adaptive Software Development (ASD)自适应软件开发 • Crystal Clear and Other Crystal Methodologies

如何用敏捷方法做测试?

敏捷的核心就是个"快"字:快速开发,快速推出,快速验证产品方向.说白了就是管理每个小目标,保证他们能够按时完成. 想要运用敏捷方法,要注意几点: 1.开发做完一个小功能马上开始测试,减少等待时间. 2.测试的工作量更加分散,不会出现一段时间无事可做,一段时间忙的要死的情况. 3.每次的bug都是针对刚刚开发完的功能,开发处理起来会更得心应手,减少沟通成本. 在与同事沟通中,我还了解到,将bug加入开发计划会大大影响他们的目标完成进度,往往问题刚整理出一些思路,就因为某些bug需要处理而

DevOps - 与敏捷方法区别

章节 DevOps – 为什么 DevOps – 与传统方式区别 DevOps – 优势 DevOps – 不适用 DevOps – 生命周期 DevOps – 与敏捷方法区别 DevOps – 实施原则 DevOps – 工程师职责 DevOps – 自动化工具 DevOps – 总结 DevOps方法与敏捷方法的侧重点是不同的. 一个典型的软件开发各方合作过程,如下图所示: 敏捷方法解决客户和开发人员之间的鸿沟,如下图所示. DevOps方法解决开发人员和运维人员之间的鸿沟,如下图所示. 下