《It's All Upside Down》作者访谈录

敏捷流程与指导

原创于 2017-07-17 17:23:00 发布 · 66 阅读

0 ·

CC 4.0 BY-SA版权

本书探讨了敏捷团队如何通过关注原则而非具体步骤来改善流程，并介绍了在职培训相较于正式课程的优势。作者分享了如何运用Essence框架来提升团队表现，以及技术领导者如何发展其指导技巧。

\
关键点：
\\
敏捷团队仍然需要流程\\t
如果您希望团队绩效得到真正的改善，那么在前面就把流程和衡量方式规定得很细不是一个好方法\\t
让流程注重原则和目标，而不是步骤\\t
在职培训的投资回报大大高于正式的课室培训\\t
利用Essence来激发讨论，找出根本原因和有效的解决方案\

在《It's All Upside Down》这本书中，Paul McMahon提供了来自受助于颠倒原则的软件开发团队案例和应用它们的指导技巧。他解释了您如何能用Essence来改善流程，获得更好的组织绩效。

InfoQ的读者们可以下载阅读《It's All Upside Down》的样章。

InfoQ采访了Paul McMahon并讨论了很多问题，包括：当组织采用了敏捷方式时，为什么还需要流程？为改善流程所做的工作，哪些有用，哪些没有用？怎样处理不完整或模糊的需求？团队能从指导中获得什么好处？技术领导者如何提高其指导技能？为何选用Esssence来解释软件开发案例？对那些想要利用Essence来改善其绩效的组织有什么建议？

InfoQ：您写本书的原因是什么？

\
Paul McMahon：本书的副标题：“我所学到的关于软件开发的知识，为什么其看起来与老师教的都相反”，跟我写本书的动力有很大的关系。仅仅在过去的几年间，作为一个指导者，我已经在如何帮助软件开发团队上做了大幅的改动，看起来像是我在跟我的客户推荐与很多成熟的长期软件工程原则完全相反的东西。这是促使我写本书的主要动力。我希望跟大家分享我们最近在实践中所发现的对成功的软件开发团队真正有效的东西。本书第一部分中的8个案例都发生于2015年和2016年。
\

InfoQ：本书适合哪些人阅读?

\
McMahon：在本书中，我强调了26个颠倒原则，以及颠倒原则的澄清思想。我也强调了18个指导技巧。如果您想知道一本强调指导技巧的书是否适合您，那么答案是肯定的。我认为组织中的每个人应该把自己看作是个指导者。本书特别适合那些在组织中能够影响软件开发决策或被其影响的人阅读。
\

InfoQ：敏捷软件开发宣言建议大家关注人而非流程。当组织采用敏捷开发时，还需要流程吗？

\
McMahon：是的。团队总是需要合适的指导来确保团队理解自身的使命，以及如何处置团队面对的常见情形。不幸的是，如今有太多人把流程（或实践）等同于过重的书面指导。只要您接受我对流程的定义：流程是对团队适当的指导，那么总是需要流程的。我们面临的挑战是如何决定合适的水平和合适的媒介物来提供指导。我最近发现的见解之一是如何通过对原则的关注来捕获适合敏捷组织的流程。原则更多地关注于目标，而流程（或实践）更多的是关注于实现目标的步骤。我现在把原则看作“迷你实践（mini-practices）”（或迷你流程）。这个方法有助于团队关注正确的行为以获得更好的绩效。
\

InfoQ：您是否能举几个例子，来讲讲您从不要为改善过程而工作中学到的东西？

\
McMahon：这问题问得好。事实上，“对于改善流程不起作用的事物”可以作为本书的副标题，因为这真是整本书都在讲的东西，书里还讲到了很多有作用的东西。因此，我在这里就举几个例子。不起作用的东西的其中之一是，在您的团队已经在实际项目中证明了某个“流程”之前，试图通过书面定义流程细节来“改善”流程。这没用，因为我们已经知道，不管您之前在定义流程上花多少精力，一旦团队开始在实际的项目中使用流程，就会学习重要的新东西。另一样没有用的东西是花钱买教训的想法，您必须先定义措施来确保您有所改进。您真的需要措施来确保您不糊弄您自己，这个说法是对的，但是当实际项目的改进正在实施时，才会发现一些最好的措施。本书的“案例一”中可以找到这样的一个例子。第三样没有用的东西是认为要获得重复的结果，重复性的流程是必要的。有时候，获得重复的结果的最好方式是允许团队改变他们的流程来解决其面临的具体挑战。这是“案例二”中的要点。
\

InfoQ：您学到的哪些东西是有用的？

\
McMahon：我学到的最重要的东西是认识到这一点：当敏捷行动已经强调了很多健全的做法，即大多数项目有具体的限制或者法规的要求，需要对“纯敏捷”的做法进行一定程度上的剪裁。因此，最有效的就是要认识到这一点，以及指导团队和团队领导者如何去寻找适合其文化和环境的 “混合证明最佳实践（hybrid proven best practices）”的最佳水平。太多的组织认为“剪裁”只是跟项目的开始相关（如果有的话），而实际上，剪裁是在整个项目进行的过程中必须不断考虑的事。与此同时，无节制的剪裁会滋生混乱。因此，我发现的另一样有用的东西是提供一套最小化的“必做事项”的指南，同时，这套指南永远都不能被“剪裁”掉。
\

InfoQ：当团队在处理不完整或模糊的需求时，您对他们应该做什么有什么建议？

\
McMahon：这个问题也问得好！我喜欢帮助团队做的事情之一是：与其讲理论，不如分享那些有用的案例。我最喜欢分享的案例之一是跟不完整或模糊的需求有关的。多年前，我参与了一次客户研讨会，该客户为美国海军开发模拟训练软件。在我们讨论不完整的需求时，一个参与者插话进来：“让我来跟你说说我与我客户之间的问题吧”。他接着说，当他正准备让其客户澄清模糊的需求时，其客户回答到：“我们需要飞得又高又快的模拟导弹”。随后，他问其客户：“多高？多快？”其客户回答到：“我不知道，尽管去做，然后我们会让你知道你做的东西是否足够好。”
\\
最有趣的是，其他研讨会参与者关于这实际上是否是个问题的讨论没有达成一致意见。一个参与人员回应到：“我一直用这种方式跟我的客户打交道，他们看起来很喜欢我们！”而另一个人说：“这是个大问题，因为我的客户总是在抱怨我们无法控制成本和进度。”
\\
这个案例的要点是，要决定一个场景是否是个问题，您就必须理解您的客户和项目情况。您必须先多问一些问题，比如：“您的客户有多少资金？”及“您的客户是否了解用迭代这种方式来找出需求的成本？”
\\
如果您的客户不合作，而您的预算和进度是不可变的，那么这会是个巨大的问题，您也许需要马上采取行动。但是，从另一方面来说，如果您的客户了解以迭代方式找出需求的成本，并希望您帮助其找出需求，也有足够的钱来支付费用，那么您也许只需要做您的客户要求您做的事，并让客户支付相关的费用。
\

InfoQ：团队能从指导中获得什么好处？

\
McMahon：仅仅在过去的几年间，我才意识到指导是多么的有价值。我习惯于把大量的精力投入到为我的客户组织正式的研讨会，包括数百张我在研讨会上要用的幻灯片，这些研讨会通常持续三天或更多天。我的确针对具体的客户需求，对这些研讨会进行了剪裁，都受到了好评。因此，我最近几年都是这么做的。
\\
但是，在2015年，我开始意识到某些重要的东西，它们是我正式课室培训中所缺乏的，而有了它们，我能够提供更有效的在职员工培训。当研讨会的参与人员坐在课室里时，对他们来说，很难把他们正在学的东西转化成如何让这些新知识对其实际项目任务产生影响。因此，更多时候，当他们离开课室，面对工作上的情形时，那些我曾经在课室里教过他们的东西，他们并没有应用到实际中去。这是因为他们只是回到了旧时的习惯上，而这对我们大多数人来说都是很自然的。指导者的优势在于，作为一个指导者，您能够更接近学生面临着的真正挑战，由此能够识别出在所要求的时间点采取新行为的机会。当我们和我们的客户之间的交互被限制在一个正式的课室培训中时，我们会错失这个机会。
\\
有些人认为，指导，特别是一对一的指导比起课室培训要昂贵得多，但这不一定。
\\
很多组织仍然通过送其员工参加长达几天的正式研讨会来进行培训。但是，用精简的课室培训来代替那些冗长的研讨会，辅以按需指导，会更高效和有效。这样能节省正式培训的费用，也允许指导者和更多客户并行工作，他们可以根据情形所需，通过电子邮件、简短的通话、专门的网络研讨会提供指导。
\\
这种方式被证明对指导者和客户双方来说都是更高效和有效的。强调指导而不是正式的课室培训的优势在于，对于客户来说，不必将其看作是纯粹的“开销”成本，因为指导者和学生在一起面对的是一个真正的项目挑战。
\

InfoQ：技术领导者如何提高他们的指导技能？

\
McMahon：首先，我想指出的是，当我还是个年轻的软件开发员，头两次我的经理试图让我做技术领导者时，我讨厌那份新工作，并尽快辞了工，做回软件开发员。事后看来，我意识到我这样做是因为在技术领导者的职责和如何履行这些职责方面，我没有受到任何培训或指导。我想就这个话题指出的第一点是，组织应该向从业者明确说明谁对技术领导方面负责以及如何获取技术领导技能。
\\
如今，我认为成为技术领导者，包括放弃软件开发，不应该是开发人员必须要做的一个选择。最好的技术领导者应该也是个开发人员，以便了解最新的实践、工具和开发人员面临的问题。因此，在如今的世界上，技术领导地位应该来自那些您的团队所需要的已有知识的地方以及所需要的时候。
\\
鉴于这一思路，提高技术领导者的指导技能更多地跟团队沟通和了解团队成员的职责有关，而不是任何技术问题。那是先聆听，了解您的团队面临的问题，然后和那些有经验、能够提供帮助的人们接触。这意味着需要告诉每一个团队成员，他们的职责包括跟其他成员分享必要的知识，以及在其他成员需要帮助的时候帮助他们。
\

InfoQ：什么是Essence？

\
McMahon：Essence是基于软件工程方法和理论（Software Engineering Method and Theory，简称SEMAT）的倡议，是2009年底由Ivar Jacobson和两位顾问Bertrand Meyer及Richard Soley最先发起的。来自全世界包括工业界、学术界和研究界在内的很多人以志愿者的身份工作，形成了Essence Object Management Group（OMG）标准。虽然Essence成为唯一的OMG标准始自2014年，但可以追溯到2005年，当年Ivar Jacobson International（IJI）重新设计了Rational Unified Process（RUP）并将其改为ESSUP（Essential Unified Process）。SEMAT的主要动机之一已经在SEMAT网站上写明了的：“全世界有数以百万计的软件工程师们存在于无数的程序、项目和团队中；让世界运转起来的上百万行的软件程序见证了他们的聪明才智”。然而，作为一个社区，我们仍然觉得难以分享我们最好的实践、真正让我们的团队强大起来、把软件工程和其他工程学科无缝整合到我们的业务中、持续地殚精毕力、避免不必要的灾难性故障。整个业界在‘没有方法’和最新的‘真正方法’之间不断切换的习惯（这种令人悲伤的痛苦甚至影响到了敏捷社区）不是前行的道路。
\\
在关注这个趋势方面，SEMAT社区不是唯一的一个。多年来一直在软件质量、风险和最佳实践方面收集数据的Capers Jones告诉我，软件工程已经在人类历史上创造了比其他任何工程学科多得多的软件方法。
\

InfoQ：您为什么选择用Essence来解释在您书中提到的那些软件开发案例？

\
McMahon：在我书中的那些案例中，您会了解到很多问题，这些是我问过我的客户的问题，还有我给他们的指导技巧，以帮助他们克服常见的困难，获得更好的绩效。很多我问过的问题和我提供的技巧都来自于经验。但是，我认为Essence提供了一个简单的方法，在不能马上找到指导者时，从业者能以他们容易获得的形式分享这些问题和技巧。
\\
有时候，我把Essence称作“思维框架（thinking framework）”，但是，事实上，Essence比“思维框架”要丰富得多。Essence提供了与所有软件开发工作相关的“共同点”要素集合。这点和我前面的回答有关，我提到过必须要有一套最小化的“必做事项”指南，并且其是绝对不能被“裁剪”掉的。
\\
Essence包括一套清单，这个清单能激发我向客户提问。您能够从本书第一部分中的那些案例中提到的问题中学到更多的内容。Essence也为包括顾问、指导者、实践或方法的作者和从业人员在内的任何人提供了一种方法，以一种通用的语言表达他们的实践和技巧，突出其方式的独特之处。这种在Essence语言中表达实践的方法被称作“本质化（essentialization）”。这是在本书中，我选择Essence来解释软件开发案例的根本原因。
\

InfoQ：对于希望用Essence来改善绩效的组织，您有什么建议？

\
McMahon：我觉得开始使用Essence的最佳地方就是利用框架作为一种辅助手段来激发讨论，从而找到关键问题的根本原因和解决方案，因为那些关键问题阻碍组织获得更好的绩效。本书中有个很好的例子，是我们利用Essence研究NORO案例。NORO是一家小公司，它脱胎于一个大型CMMI第三级机构，该机构为美国国防部开发复杂的软件系统。NORO希望更灵活，因此，他们放弃了其先前上级机构繁重的流程，但是很快地，他们意识到自己走得太远了，需要增加一定程度的纪律性流程。
\\
NORO的目标是增加足够的纪律来解决其导致客户不满意的关键痛点，但是，不要加入那些有碍高效和有效运营的官僚主义。我们通过利用Essence进行根本原因分析，得以快速地识别出两个关键问题领域，其中包括：
\\
• 关键利益相关者没有充分参与
\• 不良的测试导致的缺陷遗漏
\\
后来，我们给NORO软件团队一些精简的培训，重点是关键目标，以及帮助团队解决这两个问题的一些简单实践。
\\
在短短的八周时间里，NORO团队能够达到100%可测的绩效改善，该结果是通过先前低满意度客户再次证实的。利用Essence来辅助根本原因分析不仅仅是Essence能有助于组织的唯一领域，但是，正如我们在NORO案例研究中所展示的，它是一个非常好的起点，展示了Essence帮助团队快速改善绩效的能力。
\

本书作者简介

Paul E. McMahon是PEM Systems的首席顾问，过去二十年来，他一直在用实际的方法指导大大小小的团队以提高敏捷性和流程的成熟度。McMahon刚刚出版了其第五本书《It's All Upside Down: What I've Learned About Software Development and Why Its Seems Opposite to Everything I was Taught》，在书中，您能找到更多关于软件开发团队成功颠覆的真实案例。McMahon不是在进行指导，就是在跑马拉松。他已经完成了12场波士顿马拉松。您可以通过pemcmahon@acm.org联系McMahon。