是利益相关者的积极参与是一个扩张的做法极限编程(XP)的年代描述需要现场客户现场访问的人,通常用户或他们的代表,他们的权力和能力提供信息系统的构建和有关要求,相关和及时决策和优先级。虽然这种程度的参与是使您的软件开发工作有效所必需的，但在许多组织中，尤其是在那些政治而非理性成为家常便饭的组织中，这种参与常常是不够的。项目成功通常需要项目干系人更多地参与:域和技术专家应该积极参与建模(是的,创建实际模型,不仅给modeler)信息,高级管理层需要公开和私人项目支持,操作和支持人员必须积极处理你的项目团队对生产环境让你准备接受你的系统,其他系统集成工作团队必须与你的支持,维护开发人员必须努力熟悉系统使用的技术和技术。本文的重点是探讨如何成功地促进敏捷交付团队中积极的涉众参与。

内容

• 谁是利益相关者?
• 为什么利益相关者的参与很重要?
• 合作策略
• 获得与涉众的联系
• 影响利益相关者参与的因素
• 项目团队实际上在做什么?
• 权利和责任

1. 谁是利益相关者?

我定义项目的利益相关者是谁直接用户,间接用户,用户的经理、高级经理、操作人员、基金项目的“金老板”,支持(服务台)工作人员,审计人员,程序/投资组合经理,开发人员在其他系统集成或与一个正在开发,或维护人员可能影响软件项目的开发和部署。

从这个定义可以看出，业务人员(如直接用户及其经理)并不是项目的唯一涉众。正如您所知道的，有很多人可能受到新系统的影响，因此，要成功，您必须理解他们的需求，然后将他们的需求综合成一个有凝聚力的远景。这是使软件开发变得困难的原因之一:每个项目涉众都有自己的需求、自己的愿景和自己的优先级。但它也使软件开发变得有趣。

在这个定义中，我选择了排除正在开发项目的开发人员。乍一看，这似乎有些奇怪，因为开发人员在他们所从事的项目中显然有着重要的利害关系。是的，开发人员绝对是项目涉众。为什么我要继续区分开发人员和项目涉众?因为我想要方便的术语来区分它们，所以我真的不喜欢“开发人员涉众”和“非开发人员涉众”，而且因为它们在项目中扮演不同的角色。

我对项目涉众和开发人员的定义可能与您的不同，或者您更喜欢使用不同的术语。例如，XP讨论的是客户和程序员的概念，而不是项目涉众和开发人员的概念，并且定义略有不同，因为他们使用的术语与AM不同。另一方面，Scrum讨论的是敏捷团队成员(而不是开发人员)和产品所有者(而不是客户或更准确地说是利益相关者代表)。最复杂的利益相关者的定义,我见过在敏捷社区来自由外向内的软件开发,因为它显式地表明,有一个广泛的利益相关者,甚至将它们组织成四类:主体(的人买你的软件),最终用户(与它的人),合作伙伴(那些会使你的软件工作在生产),和业内人士(组织内部的人影响你的团队是如何工作的。软件开发的外部

2. 为什么利益相关者的参与很重要?

人们不太擅长定义他们想要什么，尤其是在细节上。然而，人们很擅长指出他们认为自己想要什么，然后当一个选项呈现给他们时，他们喜欢什么，不喜欢什么。换句话说，我们需要与涉众合作，确定他们认为自己想要什么，生成反映这种理解的东西，从涉众那里得到反馈，然后更新我们的解决方案，以反映我们改进的理解。其含义是，如果我们要提供反映涉众实际需求的解决方案，我们就需要以一种更加进化和协作的方式工作，而且要做到这一点，我们必须与涉众密切和定期地合作。

传统的软件开发方法基于在项目早期定义详细的需求规范，称为“大需求预先(big requirements up - front, BRUF)”策略，在实践中证明是非常危险的。传统的项目团队，即使是“成功的”项目团队，在努力生成反映规范的解决方案时，通常也不会产生理想的结果。是的，团队可能会产生一些符合规范的东西，但是它可能不是涉众真正想要的，而是他们在过去某个时候认为他们需要的东西。我认为，一个有纪律的敏捷交付项目团队的目标应该是为他们的涉众提供一个解决方案，该解决方案在给定条件下尽可能有效地满足他们当前对涉众意图的理解，而不是构建符合规范的东西。

3.合作策略

很明显，为了取得成功，所有项目涉众都必须积极地与您的团队合作来实现这些目标。这种做法有几个含义:

• 及时决策。涉众必须准备好与团队共享业务知识，并就项目范围和需求优先级做出相关和及时的决策。
• 包容的建模。您需要采用基于以用户为中心的设计(UCD)和参与性设计原则的包容性建模技术，涉众可以轻松地学习和采用这些技术。
• 管理需要IT技能和知识。对于高级经理来说，要有效地支持您的项目，他们必须首先了解您的团队正在使用的技术和技术，了解团队使用这些技术的原因，以及使用这些技术的含义。有了这些知识，他们在组织的政治舞台上的努力更有可能在正确的时间以正确的方式有效。高级经理不可能仅仅通过阅读每周的项目状态报告或参加每月的项目指导会议来获得这些必要的知识。相反，他们需要投入必要的时间来学习他们管理的东西，他们需要积极地参与系统的开发。
• 生产人员从一开始就参与其中。您的运营和支持组织必须投入必要的资源来理解您的系统和它所使用的技术。您的支持人员必须花时间了解系统的细微差别，这意味着他们需要在系统开发时使用您的系统，并且/或者您的团队需要为他们提供培训。此外，您的操作人员必须精通系统的安装和操作。您可以选择在您的开发团队中包括一名或两名运维工程师，或者再次根据需要投资项目资源来培训运维人员。无论采用哪种方法，您的运营和支持组织都需要积极地参与到项目团队中。
• 从企业的角度来看。如果您的系统需要与其他系统集成，则需要与其他项目团队合作。例如，您的系统可能需要访问遗留数据库、与在线系统交互、处理由外部系统生成的数据文件，或者为其他系统提供XML数据提取。如果没有这些开发人员的积极参与，集成常常是困难的，甚至是不可能的:想象一下，如果大型遗留数据库的所有者拒绝提供关于该数据库的任何信息，那么访问包含在该数据库中的信息将是多么困难。一些初始的体系结构设想将有助于推动这一点。
• 不要直接交给维护团队。维护开发人员需要与您一起学习您的系统。当目的是部分或完全的传递系统的维护和其他开发人员,通常引入软件专业人员熟练的在维护和增强现有系统释放原始开发团队的成员,那么你的团队必须与这些人的工作,这样他们就可以接管您的系统。即使一些最初的团队成员仍然参与其中，也必须努力将知识转移给团队的新成员。

4. 获得与利益相关者真正接触的策略

我从未参与过IT项目，无论是敏捷项目还是其他项目，在这些项目中，我无法定期、直接地访问关键的涉众或他们的代表。从事过金融(包括经纪)、零售、电信、电子商务、软件产品开发、政府(包括军队)等项目。然而，我曾经参与过许多项目，在这些项目中，人们为自己找不到利益相关者提供借口(没有一个理由是站不住脚的)。常见的理由包括:

1. 理解涉众参与的重要性。首先，您需要理解为什么积极的涉众参与是重要的，以及如果没有它，对您的项目将会产生什么影响。在许多组织中，您将被要求证明为什么涉众需要积极参与IT项目，并且您越了解为什么IT项目很重要，您就越有能力为它辩护。
2. 从利益相关者那里获得支持。您的一些涉众可能会喜欢积极地参与到您的项目中，并且更多人可能会很容易地相信他们应该参与进来。
3. 高级管理教育。在许多组织中，高级管理人员需要确定并支持涉众的参与程度。为了做出这个决定，他们需要了解每一种选择和权衡。
4. 是灵活的。尽管您希望与涉众共享位置，并能够立即访问他们，但并不总是这样。你可能一天只能和他们交流几个小时，或者一周只能交流几小时。更多的访问通常是更好的，但是正如您在下面看到的，有几个原因可以解释为什么很难连续地访问它们。
5. 准备好与利益相关者代表合作。不管您可能听过什么空洞的花言巧语，您最终几乎总是要与代表更广泛的利益相关者社区的人一起工作(这对于产品所有者来说当然是正确的)。
6. 为它而战。积极的涉众参与对项目的成功至关重要，因为没有它，您将不知道涉众实际上需要什么。
7. 继续为之奋斗。在整个项目中，将会有压力将涉众从项目中转移出来，这样他们就可以专注于他们正常的“日常工作”。您可能需要保持定期的沟通流，感谢涉众的参与(无论如何，这始终是一件礼貌的事情)，并提醒他们他们对工作的积极影响。

获得利益相关者的参与，更不用说获得他们的积极参与，可能很难，原因有以下几点:

1. 我们培训了利益相关者以“放手”的方式工作。几十年来我们对利益相关者遵循传统串行/ IT项目方法——我们会做一些初始需求收集,我们经常要求他们签署的需求和项目计划,我们会给他们定期更新的项目,然后几个月有时几年后让他们参与验收测试。换句话说，要有短的、明确的介入时间，而在这段时间内几乎不介入。使用现代方法，比如敏捷，我们现在要求他们在整个项目中持续参与。
2. 许多利益相关者不信任我们。从涉众的角度来看，传统的解决方案交付方法在实践中并没有很好地发挥作用。根据2008年IT项目成功调查，传统策略在交付涉众积极想要的功能方面不是很有效，这一点得到了Standish Group的Chaos报告的支持(有关详细信息，请参阅BRUF文章)。
3. 这不是他们工作的一部分。许多涉众认为他们不需要积极地参与IT项目——IT工作毕竟是IT部门的工作。这可能是一个难以克服的文化问题。
4. 他们认为这太难了。许多传统主义者将使用复杂的图表，这些图表使用的符号是涉众不习惯看到的，也不是所有人都有兴趣学习的。敏捷主义者更喜欢使用包容性的工具，比如简单的旧白板(POWs)和纸张，以及草图来与涉众建模。
5. 他们认为正常的“日常工作”更重要。从利益相关者的角度来看，这是公平的，但从您的组织的角度来看，很可能不是。每当我遇到有人告诉我利益相关者太忙或他们的时间太宝贵的情况时，我就会质疑这种逻辑。如果这是真的，那么他们告诉你的是，他们日常工作的组织价值大于IT项目的价值。如果这是实际情况，那么投入到项目中的资源应该真正用于帮助涉众完成他们的日常工作。
6. 他们真的不是一直都有空。组织的正常活动仍然需要与IT项目并行进行。一些利益相关者可能无法在正常的工作时间。例如，我在经纪公司工作过，我们不能在交易时间与交易员互动，但在其他时间可以。一些涉众可能只有部分时间，也许一天中只有一两个小时。

5. 影响利益相关者参与的因素

有几个因素将影响涉众如何参与解决方案交付团队的性质和质量。表1总结了这些因素。

表1。影响涉众参与IT项目的因素。

Factor	Range	Potential Impact(s)
Participation style	Reactive <=> Proactive	Stakeholders who proactively participate with IT project may have a political agenda which they are trying to further. Stakeholders who are reactive to requests for information may slow the project because the team must wait for responses (minimally, the product owner will need to guess at the answer, increasing the chance of potential rework in the future) Reactive stakeholders may be a sign that the stakeholder community has a poor relationship with the IT department
Relationship	Negative <=> Positive	When the relationship between IT and stakeholders is negative the stakeholders will likely participate less frequently and to a lesser extent
Communication channels	Formal <=> Informal	Formal communication, such as written documentation in a specific format, can increase the bureaucratic overhead on the team, increase cost to the project, and increase the time it takes to deliver the solution. Communication will increase in formality in regulatory compliance situations. Informal communication strategies, such as face-to-face communication and sketching, lowers overall complexity and cost and often improves time to market.
Availability	Irregular <=> Continuous	When stakeholders aren't regularly involved with a project team the chance that the team will build the wrong thing increases. With continuous stakeholder participation the feedback cycle is reduced, improving overall chances of project success.
Interaction	Facilitated <=> Active	When interaction with stakeholders needs to be facilitated (someone needs to act as a go between to help the development team and stakeholders to communicate) you run the risk of miscommunication and increasing the team's time to delivery (the facilitator becomes a potential bottleneck).
Location	Co-located <=> Global	When the team is co-located with stakeholders it is much easier for them to interact regularly and actively with the development team. As the team becomes more geographically distributed, the chances of project success decrease (see the 2008 IT Project Success Survey for some figures).

6. 团队实际上在做什么?

到目前为止，我所描述的一切都很好，但是敏捷团队实际上在实践中在做什么呢?幸运的是，我的一些IT调查提供了一些见解。图1总结了2013年的一个问题的结果:您有多敏捷?调查列出了与涉众合作的几种策略，以及自称敏捷的团队中这些策略的采用率。正如您所看到的，有几个迹象表明敏捷团队正在与他们的涉众紧密合作:

1. 超过60%的公司定期与股东进行讨论
2. 一半的人花时间来确定他们的利益相关者是谁以及他们的目标是什么
3. 60%将可用性问题考虑在内(这需要与涉众紧密合作)
4. 超过一半的人正在积极尝试改进业务流程，这也需要积极的涉众参与

图1所示。为利益相关者创造价值的潜在策略。

图2还描述了2013年的结果:您有多敏捷?调查，在本例中探索敏捷团队如何验证他们的工作。在迭代演示中，团队向主要涉众展示了他们所做的迭代工作，几乎占到了60%。验收测试驱动开发(TDD)也是一项需要涉众积极参与的活动，占18%，而面向更广泛的涉众群体的“全手演示”占28%。

图2。敏捷的标准:验证。

在建模方面，2013年的项目启动调查发现，超过90%的人预先进行了某种类型的需求建模，这显然需要涉众的参与。图3显示了2008年建模和文档调查的结果，显示了使用包括白板和纸张在内的建模工具是非常普遍的，无论开发范式如何。

图3。主要建模策略。

7. 权利和责任

我曾经谈论过项目涉众的权利和责任，这是我从Karl Wiegers的优秀著作《软件需求》中采用的一个概念。不幸的是，我最近发现，敏捷建模中所描述的这些权利和职责并不像我最初认为的那样清晰，甚至可能产生分歧。因此，在对AM邮件列表进行了相当多的讨论之后，我决定从项目中每个人的角度重新定义权利和责任，而不仅仅是从涉众的角度。

人人的权利:

1. 被尊重。
2. 根据项目标准和原则，随时生产和接收高质量的产品。
3. 评估你积极参与的活动，并让其他人尊重这些评估。
4. 被提供足够的资源(时间、金钱等)来做要求你做的工作。
5. 来决定你的资源将如何投资。对于为项目提供资金的人来说，资金将如何使用，对于为项目工作的人来说(例如，投资时间)，他们选择从事什么任务。
6. 有机会获得与项目成功相关的知识。业务人员可能需要了解基础技术和技术人员来了解业务。
7. 及时作出决定。
8. 及时提供诚信的信息。有时这只是当时“最好的猜测”，完全没有关系。这包括但不限于业务信息，如优先级需求和详细的领域概念，以及技术信息，如设计和详细的技术概念。
9. 拥有组织的软件流程，在需要时跟踪并积极改进这些流程。

每个人的责任:

1. 在你愿意投入的资源范围内，创造一个最能满足你需求的系统。
2. 愿意与他人合作，尤其是那些你所选择专业以外的人。
3. 分享所有信息，包括“正在进行中的工作”。
4. 积极扩展你的知识和技能。

 

原文：http://agilemodeling.com/essays/activeStakeholderParticipation.htm

本文：https://pub.intelligentx.net/agilemodeling-active-stakeholder-participation-agile-core-practice

讨论：请加入知识星球或者小红圈【首席架构师圈】