资讯专栏INFORMATION COLUMN

如何确定敏捷是否适合你的团队?

Lemon_95 / 918人阅读

摘要:但敏捷是不是真的如坊间传闻的那样,是一个可以解决所有项目困境的万能药当然不是但敏捷的确是一种比较好的项目管理方法。因为协作的团队成员可以随时访问和更新故事板,这将有助于团队协作的顺利开展。敏捷教练希望创建一个积极并表现出主动性的团队。

对从事项目管理的人员来说,敏捷已经成为一场席卷全国的风潮。但敏捷并不是什么新事物,它已经有20多年的历史。正如社交媒体圈子所说的那样,敏捷的声势与流行程度正在逐年见长。但敏捷是不是真的如坊间传闻的那样,是一个可以解决所有项目困境的万能药?
当然不是!但敏捷的确是一种比较好的项目管理方法。敏捷为项目负责人及其团队提供了一些独特的优势。


我们之前将敏捷方法与传统的瀑布流方法进行了比较。敏捷这种软件开发领域的项目管理办法,在过去数年有着强劲的发展势头。它解决了产品需求与开发等方面的不确定性。与之相较的瀑布流方法则试图将项目生命周期的各阶段,即启动、计划、执行和收尾等,按照严格的结构顺序进行组织。

什么是敏捷");

要确切定义何为敏捷非常困难。不同的人可能会给出不同的答案。敏捷这个大范畴内包含下面几个体系,如Scrum、XP Extreme、 Lean 和 Kanban Software Development 以及Crystal Clear。
敏捷将项目规划变成了一个贯穿整个项目生命周期的迭代过程。“fail-fast”这个术语体现了对迭代的渴望,即通过先将开发出的不完美的产品提供给客户使用,以收集客户的反馈。
客户的反馈至关重要。传统的项目管理方法要求项目需求在项目开始之前就要收集并确定好。但敏捷方法则不同,敏捷更加实用和高效,要求产品负责人和关键利益相关者在产品开发过程中,参与构建和测试。
这样做能够大大节省时间。为什么我们需要花上三个月的时间收集需求,再花上四个月的时间开发产品,到最后才发现开发的产品并不是客户真正想要的?为什么我们不能够开发一部分之后,展示给客户,将反馈整合到产品的开发中,然后不断重复这个过程并在更短的时间内构建客户想要的产品?简而言之,这就是敏捷的目标。

使用敏捷的最佳条件是什么?

当我们无法确定产品的需求是什么时,最好使用敏捷方法。从收集用户故事开始就让产品负责人和Scrum团队参与进来能够让我们更高效地利用时间。用户故事是产品负责人希望开发的功能和特征的简要描述。
然后,根据这些软件功能,产品负责人和Scrum团队创建一个名为Product Backlog的待办事项列表。建立Product Backlog后,Scrum团队就会创建Sprint Backlog。客户所需的产品功能将会被安排在不同的Sprint中完成。因此,Sprint中是下一个版本中的功能,这么做的目的是为了每次都开发和部署产品的一小部分功能。

产品负责人和Scrum团队将召开每日站会来review开发进度。这种方法有助于解决产品或需求中的不确定问题。所以整个产品开发流程就是:开发部分功能—测试—收集反馈并继续开发—直至产品负责人对最终产品满意为止。

什么情况下敏捷不是最佳选择?

敏捷并不总是最好的方法,例如需求基本是确定的。当项目具备可靠的历史记录作为开发基准时,我们最好采用瀑布式开发方法。
数据中心的构建就是一个很好的例子。需求和任务开发顺序都很明确,无需做太多的规划。因此,如果按照前文所述的“部分开发-反馈-继续开发”这一流程进行显然是不切实际的。

那么,何时步入敏捷?

现在,我们已经清楚了解了敏捷的定义,适用条件及在什么情况下最好使用传统的开发方法。下面,让我们了解一下在什么情况下最好使用敏捷。具体情况可能比较多,仅在下文中列举几类主要情况:

产品需求不确定时

这种情况下,敏捷可以使项目更快启动,并让产品负责人参与到开发过程中。用敏捷的方式,我们就不必在不确定客户是否会满意的情况下花六个月的时间记录产品需求。产品负责人可以在开发新产品功能时,根据他或她的反馈作为开发过程的一部分,以最快的速度将功能呈现出来,从而确保产品可以更快交付。

敏捷是软件开发项目的最佳选择

因为软件开发过程本身就允许整个系统中的部分功能先进行开发、测试和交付。这就意味着某些特定功能的交付时间会早于其他功能。Sprint则允许开发团队多带带测试和部署这些功能,从而确保开发效率。

协作的团队可从敏捷方法中受益(每日站会)

敏捷方法的关键是每天的站立会议。会议上,团队可以讨论当前的开发进度、遇到的问题和来自产品负责人的反馈。如果有人能够负责召开这些会议并将会议结果更新到敏捷看板上就好了。因为协作的团队成员可以随时访问和更新故事板,这将有助于团队协作的顺利开展。

这一点可以通过Worktile的迭代故事板可以做到,在每日站会的时候迭代负责人可以拖动需求看板来改变需求状态及时更新需求进度。

积极参与的产品负责人

产品负责人的实时反馈是敏捷成功的关键。这样不仅可以取代繁琐的需求文档,还能确保清晰的传达产品负责人的需求。产品负责人参与并为开发团队提供持续的反馈,能使团队更快地开发出正确的产品。产品负责人应该参加每天站会,并表达自己的期望、喜好和不满。这样能确保开发团队开发出产品负责人想要的产品。

团队工作与协作——积极主动的团队成员

社会责任是敏捷方法的关键驱动因素。敏捷希望创建一个能在一定程度上实现自我管理的团队环境。敏捷教练希望创建一个积极并表现出主动性的团队。如果团队成员没能赶上进度或积极参与,那么敏捷教练希望其他团队成员能够互相帮助、鼓励和激励。敏捷教练将以身作则,奠定团队中相互鼓励和问责的协作基调。

从失败中学习的意愿

快速试错更快速地从失败中学习。原型设计和反馈是敏捷的重要工具。传统的开发方式试图在项目启动前描述所有的需求,这么做会浪费大量时间,尤其是在开发新产品时。所以一旦有了想法就应该立刻进行开发,即使当前的产品并非产品负责人想要的。这样做的目的是要通过不断的反馈来调整产品方向并继续开发。

管理层支持敏捷框架并具备团队赋权的企业文化

敏捷可以为企业带来文化和期望层面的转变,因为它鼓励团队赋权,让团队负责做出决策并承担相应的风险。与之相反的是,在传统的开发团队中,项目经理需要提供明确的方向,而在敏捷开发中,敏捷教练则会鼓励开发团队提出最适合产品开发和产品负责人的方案。管理层必须赋予团队必要的自由,仅提供能让团队快速成长的指导和方向,而不是控制团队的每一步行动。

拥抱敏捷使人兴奋。因为它让项目负责人多了一种项目管理方法,来解决项目进度中的各类问题。但与其他方法一样,敏捷的应用也存在限制,也有其不适合的任务。总而言之,敏捷为项目经理提供了更多的选择,让他们有可能更好地管理项目。

项目管理工具让项目经理可以更好地完成本职工作,正确的项目管理工具让我们能够在预算范围内,按时保质地完成工作。Worktile在这方面可以发挥巨大作用。作为一个项目管理工具,它为您提供了实时规划、监控和报告的方法。


文章来源:Worktile敏捷博客

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

文章转载请注明出处。


文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/6933.html

相关文章

  • DevOps是如何出现的?前因后果

    摘要:是如何出现的前因后果更多物联网高并发编程知识请移步软件开发的演变多年来,从现有的软件开发策略方法发展而来,以响应业务需求。数据表明超过的项目最终都是以失败告终的。团队应该定期反思如何能变得更有战斗力,然后相应地转变并调整其行为。 DevOps是如何出现的?前因后果 更多物联网高并发编程知识请移步:https://www.yuque.com/shizhiy... 软件开发的演变 多年来...

    XBaron 评论0 收藏0
  • 私有云计算项目:下一个热点开发领域

    摘要:用户将连接至一个私有云以访问应用程序和数据云计算架构师必须设定一个如何授权那些云计算用户访问的策略。最终用户的接受程度往往是私有云计算成功实施的一着胜负手。任何云计算项目实施的目的都在于创建一个能够随业务增长和需求而变化的稳定环境。 虽然云计算发展的春天已经来临,但是众多企业仍然希望保持对IT环境和物理资源的控制。通常情况下,法律或法规会阻止企业实施从数据中心到公共云计算的转变。这就成全了...

    luodongseu 评论0 收藏0
  • 阿里巴巴敏捷研发的探索与实践

    摘要:阿里巴巴内部也在不断进行敏捷实践。在加入阿里之前,从事多年敏捷教练工作,负责组织的敏捷实践和转型的指导工作。 摘要: 今天你敏捷了吗?敏捷产品开发提倡快速迭代、小步快跑,以便更灵活地应对变化,目前逐渐演变为行业潮流。阿里巴巴内部也在不断进行敏捷实践。 点此查看原文:http://click.aliyun.com/m/43286/ 今天你敏捷了吗?敏捷产品开发提倡快速迭代、小步快跑,以便...

    zorro 评论0 收藏0
  • 为什么你的公司还没有为DevOps做好准备呢?

    摘要:你的公司可能没有准备好的四个原因就是我是的忠实粉丝。简言之,必须成为由及其职能团队推动的组织文化。对影响和结果有明确了解的区域和组织领导。但是,与任何潜在的优势一样,贵公司必须为之努力。你的公司可能没有准备好DevOps的四个原因就是:我是DevOps的忠实粉丝。它已被证明可以提高质量、减少问题和缩短开发周期。对于希望改变其开发、生产和运营生命周期的大型组织来说,它通常被认为是一种灵丹妙药。...

    Bmob 评论0 收藏0
  • Simon Brown:架构师与程序员的区别

    摘要:从根本上讲,架构师是一个技术领导者的角色,这就是最大的区别。对于这个问题来说,没错,有一些相关主题没有出现在这本书中,这些主题可以构成一本与程序员必读之软件架构相互补的书。我从软件架构的视角特别能注意到这件事。 非商业转载请注明作译者、出处,并保留本文的原始链接:http://www.ituring.com.cn/article/178034 Simon Brown 是全球知...

    Turbo 评论0 收藏0

发表评论

0条评论

Lemon_95

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<