我知道你在想,“又一篇关于敏捷 101 的文章!” 我们也这么想。有很多资源描述了什么是敏捷,讨论了这个概念的历史,并深入探讨了为什么它很重要。这篇文章不是其中任何一种——相反,我们希望你忘掉你被告知的一切;你所学到、读到或以其他方式通过误用该术语或错误实施而获得的一切。
在我们解读“敏捷”这个词之前,我们想设定一些背景。2001 年 2 月,敏捷宣言由 17 位代表各种不同软件开发方法的人撰写。虽然他们都代表不同的领域,但他们有一个共同点——他们都感到需要找到一种替代当时最常见的重量级软件开发流程的方法。正是这次会议,以及随后行业发出的集结号,将敏捷推到了今天的最前沿。
然而,由于互联网上关于“敏捷”的信息激增,以及公司倾向于转向某些方法而不是其他方法,通常会有一种默认的想法,即敏捷必须等同于 Scrum 方法。在红帽,我们认为这要简单得多。我们不是立即深入研究方法论以及如何做事,而是要求我们的同事关注宣言的第一句话……
“我们正在通过实践和帮助他人来发现开发软件的更好方法。”
……并在那里停下来——之后的一切都取决于你自己的经验,并且通常基于你的个人情况。
以下是这些词的含义。
发现更好的方法
这随意地指持续改进高于一切其他流程的理想。是的,这意味着要对什么是好的或不好的有所看法。但是,这远比这更简单。它指的是随着时间的推移,在你所做的事情上变得更好的简单行为,这包括你的人员、技术工具和工作流程。
通过实践开发软件
这些词语背后并没有太多隐藏的东西,尽管我们经常将其与能够消化需求、当场做出决策并自主工作以实现客户成果的团队的概念联系起来。这里的关键点是,它不是概念性的——你是在花费时间试验什么对你的客户有效,而不是在开始工作之前没完没了地讨论什么是可能的。
帮助他人做到
最后,这引入了敏捷的人性化元素——团队被鼓励交谈、分享、互相教导、一起安全地失败,并在一个充满压力、截止日期多的行业中工作时对每个人友善——希望鼓励人们热爱他们的工作。
虽然可能很难忽视宣言的最初意图与今天的敏捷面貌之间的并列,但人们越来越强烈地感受到要将其带回基本原则。做到这一点的最佳方法不是陷入完成工作的多种方式,而是专注于 2001 年撰写的原始文字的精神和意图。
3 条评论