现代软件开发和数字化转型可能比您想象的要多得多。敏捷(以Scrum、XP、FDD等为代表)、精益、DevOps和其他方法只能解决现代组织面临的一小部分问题。要在新经济中取得成功,我们需要更多,GROW Code 、GROW People和GROW capability。
在敏捷宣言中,“我们正在寻找更好的软件开发方法。。。。。。”
我们仍在寻找和发现在复杂、快速变化的环境中取得成功所需的条件。
GROWS Method ,旨在发现缺失的部分。
GROWS Method 是什么?
GROWS Method 继承“发现更好的软件开发方法”的传统,使用GROWS 成长指南(GROWS Thinking Guides )、从初学者到所有技能水平的习惯创建高成长软件组织。
成长方法(GROWS Method)重点在于让组织中的每个人更容易在瞬息万变的复杂环境中一起工作。仅凭抽象的原则是行不通的。单独的具体实践是行不通的。如果不理解为什么特定实践很重要,那么这将无济于事。此外,并非所有重要的事情都可以编入简单的实践中。
GROWS 方法 (GROWS Method) 是一种环境理念,可以让您在特定的环境中确定适合您、您的团队、您的管理层的方法。它首先为初学者提供支持,采取具体行动培养更好的习惯,始终强调简短的反馈循环——包括对新习惯本身采用的反馈。随着团队和组织技能的提高,新的习惯和技术开始发挥作用,但始终受当地成果、证据和技能水平的驱动。
GROWS 方法使来自敏捷和其他方法的现有良好的理念、价值观和实践,但提供了一个更具包容性和实用性的工作框架,可解决技术、项目和投资组合管理问题,以协调开发人员、高管和用户。
GROWS 方法将实验的理念提升为方法的一等位置,并促进团队和个人的技能成长。我们还利用技能增长的理念为初学者提供具体支持,并为更高级的从业者提供基于反馈的支持。
GROWS 方法:
拥抱人类学习技能时遵循的正常路径
为初学者提供清晰、明确的步骤
提供清晰的成长路径、以及是否遵循的明确选择
为开发人员以及经理和执行人员提供清晰、明确的步骤和培训(与其他仅以开发为中心的方法不同)
为每个人提供明确的机制来学习和调整他们的工作方式,以利用他们的特定团队和情况
GROWS 方法主题
- 紧密反馈循环(Tight Feedback Loops):对于流程采用和技术问题,GROWS 使用识别反馈(Identify Feedback)—--执行实验(Perform an Experiment)——获得反馈(Get Feedback)——进行小调整(make Small Adjustments)的循环,所有这些都在很短的时间内完成。GROWS 中的一切都是由实验和反馈驱动的,包括软件开发和交付、流程采用和修剪,以及个人、团队和组织的学习。
- 全员All-Inclusive:GROWS 是一种让所有人一起工作的方式,包括高管、开发人员、QA、测试人员、分析师、设计师、用户。。。。。。每个人都可以发挥作用,每个人都依赖其他人来实现我们的共同目标。
- 从种子中获得成功:GROWS 通过遵循少数可生成种子来培养习惯和方法:
Organic, not Robotic 有机,而非机械。系统不是建立的,是演进的。人是不可靠的,软件开发和数字化工作 更接近有机,非线性的、混沌的。
Intentional, not Accidental 有意,而非偶然。现代软件开发和数字化工作的全部基础是持续学习,学习和 解决问题需要是有意的,而非偶然。
Actuals, not Proxies 实际,而非代理。实际数据(事实)而不是代理。任何类型的代理都会导致信息失真。
- Thinking Guides™: 在成功所需的更困难和关键领域提供指导,包括以下主题:
- OODA 循环 OODA Loop
- 系统思维模型
- 批判性思维技能
- 不断成长的心理支持
- 用 Cynefin 确定正确的行动
- 人类动力学Human Systems Dynamics
- 使用 Wardley Maps 跟踪演变
- 预算和会计的动态模型
- ……以及连续范式
但这些想法只能在正确的环境中发挥作用,这就是 Thinking Guides™ 发挥作用的地方——尤其是在帮助确定正确的 Cynefin 领域以及在组织中建立和发展心理支持方面。
当然,任何特定的方法或具体的习惯都取决于团队成员的技能水平,这可以——而且应该——有所不同。你需要不同技能水平的不同习惯和方法。参考Dreyfus 模型GROWS 方法提供不同技能水平的习惯用于更复杂和更关键的方面。
GROWS Method 工作流程基于一个简单的 OODA Loop循环——观察、定向、决定和行动的变体。

您可能会认为循环的第一步时您收集反馈的机会。在这一步,你收集最新的数据,无论多么非正式,关于团队上次的表现,公司的表现如何,有多少技术债务等。
第一次通过开发周期的循环,您可能需要采用非常广泛的方法并从多个级别收集数据,包括:
个体
团队
组织
对手
顾客
结果:可用数据
定向/判断Orient:构建全局
下一步是关于理解和情景构建。目标是获得清晰并可靠的、团队范围内的理解。这可能包括进一步和持续发现需求并将结果与愿景联系起来,包括业务目标和系统的整体架构愿景。
结果:知情理解
决定Decide:选择下一步做什么
决定做什么,不做什么,并创建一个工作列表。保持短且可管理。
结果:任务的优先级队列
行动Act:持续开发
上述步骤不会花费太多时间。采取行动,使用持续范式(Continuous Paradigm)来有效生成有效的、经过测试的功能,为用户提供新的功能。持续范式背后的理念是使用持续集成、持续测试、持续部署和持续监控,以便尽快获得反馈。
有效做到这一点,需要坚如磐石的自动化和部署实践,是软件组织必不可少的第一步。
代码增长并不是成长的唯一东西。持续开发适用于流程本身、个人和团队技能,以及最终的组织能力。
结果:用户能力、技能改进、流程改进
(重新)观察:专心观察
现在我们又回到第一步,评估反馈和观察。这一次(以及随后的循环中),您从项目本身获得了更多的反馈,更多的数据要收集,这是您第一次没有的。这可能包括以下领域:
- 发现技术债务(例如,通过软件 X 射线)
- 收集详细的用户反馈
- 回顾活动
做出必须做出的改变
不要忍受破窗,尽快修复损坏的东西。
结果:可用数据
GROWS 启动
GROWS 启动/起步归根结底,GROWS 不是规定性的。在更高的层次上,你会自己发现什么有效,什么无效。但一开始,您、您的团队和领导者需要采取更具体、更直接的步骤。
以下是我们建议您开始的方式:
- 您将迈出一小步,而不是一夜之间尝试改变一切。您将从一个试点计划开始。但是本着 Tracer Bullet Development 的精神,您的试点将是小型的,但会从头到尾进行:从执行/领导角色到开发团队,再到选择用户、产品经理和其他利益相关者。
- 从同意尝试开始。尽管组织中的每个人一开始都不会参与,但您需要征得将参与并受您的试点影响的参与者的同意。确保您已准备好开始,如本习惯中所述。
- 作为同意尝试的一部分,领导者和高管必须承诺建立心理安全。如果团队成员感到不安全,请在他们安全之前不要继续。我们建议使用匿名调查作为评估团队看法的第一步。
- 使用来自实验的答案作为将新习惯引入组织的基本引擎。
- 除非另有说明,否则您的第一个实验的默认持续时间是两周,并且不应超过两周。
- 从第一阶段的习惯开始,安全与健康。如果您已经在使用一种习惯,请确保在继续之前获得该习惯所期望和定义的反馈和结果。如果没有,请重新开始。
- 创建一个大而可见的图表,显示您的 GROWS 计划的状态。
这是步骤清单。在开始之前查看它:
- 获得第一批参与者和领导层的支持和同意尝试
- 确保参与的每个人都在尝试、表达意见和从失败的实验中学习时感到自在
- 为您的第一个实验安排启动会议
- 安排定期会议以检查您的实验结果并调整您的方法
- 发布您的 GROWS 进度表
请注意,这些只是开始步骤。六个月后你会以不同的方式做事。如果你不是——如果你在六个月后仍然以同样的方式应用 GROWS 方法——那么你做错了。你没有成长。你需要不断改进你的方法。