敏捷编制

在软件行业,敏捷开发方法越来越重要,并将逐渐代替瀑布式开发。SAP 案例分析表明这一步对技术文档编辑意义重大。

敏捷软件开发已成为一种趋势。自 20 世纪 90 年代被引入以来,这些原本起源于汽车制造行业的“精益开发”法在软件行业受到越来越多的重视 [1]。

本文将根据 SAP 中的知识管理方法来展示软件文档精益开发模式所带来的机会与挑战,以及如何将此类精益开发应用于日常编制中。

SAP 的产品文档

产品文档是知识管理的任务之一,按照 SAP 产品标准,产品文档应包含客户所需的有关软件安装、配置和操作的全部信息。软件和文档共同组成产品,两者缺一不可。 通过“SAP 帮助门户网站”可以集中访问产品文档,网站囊括 400 多个产品版本的应用文档。

总体而言,SAP 共有 600 多名外部和内部文档编制人员,即文档开发人员,另外还有约 100 名内部译员。将敏捷方法引入开发之中,不仅改变了软件开发人员的工作方式,也从根本上改变了文档开发人员和译员的工作方式。

Scrum 敏捷软件开发

SAP 引入敏捷方法的主要原因在于,使用瀑布式开发会不时出现某些问题。瀑布式开发意味着要在分析和设计阶段投入更多的时间和精力。细节规划会被大量文档所桎梏,这些文档死板地规定开发团队应开发出什么样的软件产品。在产品最终交付前,不仅耗时巨大,也不能敏捷应对客户不断变化的要求。由于测试环节通常被安排在开发末期,因此,开发完成前的修正工作往往会成为整个团队巨大的工作负担。

从 2008 年引入 Scrum 这一流行的敏捷软件开发模式起,SAP的一切都发生了变化。过去,产品开发通常需要组建大型团队,而现在只需要组建分别负责特定主题块的小团队(Scrum 团队)。

在理想情况下,每个 Scrum 团队中的每个角色都应由专人担任。产品负责人,代表客户利益,并负责编制 Backlog(即一种工作列表),其中包含按计划开发软件单元所需的全部主题块(任务列表条目,即 Backlog-Items)。另外,每个团队都有一个 Scrum Master(Scrum 主管),其主要任务是排除障碍并保障团队内部沟通。此外,每个团队还包含开发人员、软件设计师、UI 设计师、质量管理专家、文档编制人员和译员。每款软件产品除一个或多个 Scrum 团队外,还有一个负责产品决策的产品团队。

Scrum 团队的工作按跨度相同且不断重复的时间区间推进,一般为两至六周,即所谓的周期或迭代 (Sprints)。团队在一个迭代中的具体任务都会被列入迭代任务列表 (Sprint-Backlog) 中。 

插图 1: Scrum 方法开发
来源:SAP

每个迭代的目的是在结束时输出可用软件。一个迭代包含待开发软件功能的所有瀑布式开发步骤——定义、开发、测试和验收。客户的过程验证有助于敏捷应对客户要求。主管 Product Owner(产品负责人)可以随时根据客户反馈和其它因素重新确定任务列表中各条目的优先顺序。

知识管理员眼中的 Scrum

每个 Scrum 团队都有各自的文档编辑人员和译员。从同一产品下所有 Scrum 团队的知识管理人员中确定一名代表,由其在产品团队中负责文档编制和翻译相关工作。产品团队中知识管理代表的角色相当于文档编制和翻译项目主管一职。其工作任务包括,如,与各团队的知识管理同事一起进行时间和精力估算以及文档编制量和翻译量规划。此外,产品团队的成员还负责在产品团队中汇报各 Scrum 团队的文档编制和翻译进度。

插图 2:产品团队和 Scrum 团队中的知识管理 (KM)
来源:SAP

Scrum 团队和产品团队中的工作到底需要文档编制人员和译员花费多少时间,取决于软件产品的规模和复杂程度。不同领域有不同的知识管理计算公式。以下示例以某个产品部门所积累的经验数据为基础,并为粗略计算人员的工作时间提供了依据:

  •  产品团队中的知识管理代表:全时当量 (FTE) 的 10% 至 30%。
  • Scrum 团队中的文档编制人员:全时当量的 40%
  • Scrum 团队中的译员:全时当量的 20%

但除 Scrum 团队的核心任务(软件功能文档编制)之外,文档开发人员还有其它时间成本,其中包含协调工作、编订产品指南、协同推进与制定全新文档编制概念相关的集中项目以及已交付软件文档的维护工作,另外还有培训新同事或为外部文档编制人员提供支持等工作,在指定计划时也应考虑在内。

任务协调

Scrum 团队的一个伴随现象是角色界限之间的相对渗透。比如当团队中的 UI 设计师暂时缺位时,可对文档开发人员进行相应培训并由其承担 UI 设计师的工作。这种敏捷性不仅可以确保整个团队高效运作,还能给团队成员提供更多职业发展和个人能力提升的机会。

但是,对于知识管理员来说,角色之间的“去界限化”是一个相当大的挑战。一方面,文档编制人员和译员可以尝试新领域的工作,进而提升其工作满意度和工作主动性。另一方面,文档编制工作范围的每一次扩展都意味着投入原来知识管理工作的时间和精力更少。因此必须在核心知识管理工作和文档开发人员和译员的职业发展机会之间找到一个平衡点。

文档编制人员眼中的 Scrum

将文档编制人员和译员固定分配到 Scrum 团队中意味着他们从项目伊始就伴随在开发团队左右。因此,他们不仅能够长期负责某个主题并全面了解某个产品,进而有可能独立完成撰写工作;此外,文档质量上还会体现出更强的客户需求导向性。由于整个团队都对软件和文档负责,文档编制工作的地位和受重视程度也随之提高。

但是,在 Scrum 模式下工作也面临诸多挑战。其中之一就是讨论磋商时间更长。根据交叉任务的规模,一名文档编制人员有时会被分配到不止一个 Scrum 团队中,但通常不会超过两个 Scrum 团队。而译员则通常是在若干个团队中工作,而且并不是总能直接、及时地沟通,因为这些团队可能分布在全球各地,因此导致协调时间增加。就软件行业的现实情况而言,纯精益理论要求在固定驻地组建长期团队的愿景并非总能实现。

定期进展交流会

示例中以四周为一个迭代,将清晰地呈现出规划磋商和团队磋商的时间需求。第一周开始时立即召开规划会。会上,Product Owner(产品负责人)首先介绍当前周期或迭代的概况——持续约一至两个小时。

图 3:每个迭代和 Scrum 团队的会议
来源:SAP

之后是详细规划。其目的在于创建一个优先的迭代任务列表 (Sprint-Backlog)——持续约四至六个小时。在专用软件工具的支持下,每名团队成员在迭代任务列表条目规划期间为自己创建任务,并在迭代期间每天登记工作进展。因为一个软件产品往往有若干个 Scrum 团队负责,各团队的知识管理代表还会召开每周协调会议——持续约一个小时。此外,每个 Scrum 团队需每天召开 15 分钟碰头会,即所谓的“每日例会”。在“每日例会”上,团队成员汇报最新工作进展,并阐述其任务执行过程中可能出现的障碍。

最后,在每个迭代结束时会召开审查会议,持续约两个小时,以及回顾会议——持续约一至两个小时。前者旨在汇报迭代结果,并展示所开发出的功能。后者旨在持续优化工作进程。每名团队成员就最近一个迭代的进程给出反馈,并将优化建议应用于下一个迭代中。

按上述内容计算,在四周一迭代的模式下,每个月的磋商时间达到 15 个小时——即每个 Scrum 团队的磋商时间。在实践中,解决这个问题的具体方法就是文档编制人员和译员仅在指定日期参加每日例会。此外,在进行迭代规划时,可以与团队商定将知识管理任务磋商环节放在会议开始或结束时,因此,文档编制人员和译员不必出席整场会议。

另外,从文档编制角度来看,要求在每个迭代结束时输出可用软件也是一个挑战。在敏捷模式下,开发人员会生产出很多成型软件单元,并在最后一个迭代中将它们组合成完整产品。严格来说,在一个迭代中开发出一个软件单元的同时,还需在相关文档类型的对应迭代中完成“撰写-检查-翻译”循环。

在 UI 文本、信息或现场帮助等系统文档中能够良好运行的模式,在应用帮助(描述整体背景下的流程和功能)等文档类型中往往不可行,因此也不要求。“最终”文档可能仅在迭代结束时显示几行文字,用于描述所开发的功能。完整产品要到结束时才能成型,并且其必要前提是编订绪论和概况说明并且可以连接各个文档。因此,经常性反复调整同一文档是不可避免的。

插图 4:开发和文档编制中的迭代结果
来源:SAP

翻译一个迭代中所撰写的文本必然存在一定延迟。在这种情况下,流畅沟通也非常重要。因此应该把最终文本及时提交给译员进行翻译,以确保在迭代结束时完成翻译。如果预测必须再次修改某个文本,比如因为新开发了一个功能,则应及时告知译员,避免译员重复劳动。

经验和方法

对于所有参与人员而言,敏捷开发意味着持续学习和不断改进方法和流程。良好的规划、组织才能和沟通能力是文档编制和翻译专家最重要的工具。 经 SAP 知识管理所证明的经验和方法可简单概括为透明和合作两个关键词。

透明

• 在开发初始,即向 Scrum 团队概括介绍需要提交的文档,并明晰意图和职责

• 正确评估自己的时间和精力

• 根据具体任务规划其它角色的时间和精力,比如知识转移、创建原始文档、审查最终文档等任务

• 明确指定文档编制任务(功能 x、文档类型 y)

• 创建各文档类型的跨迭代任务列表项目,即确定一个迭代无法完成的项目

• 计划跨团队任务

• 在审查会议上介绍最终文档

合作

• 如果属于多个团队合作,则与团队协商确定参加会议的优先顺序

• 如果涉及分布多地的团队,则使用视频会议室或网络摄像头

• 如果与外部文档编制人员或译员合作,应指定一名内部知识管理同事为联系人

• 与翻译人员密切配合,以便更好地分配工作量

过去几年的经验表明,尽管 SAP 知识管理中存在诸多挑战,但在文档编制中引入敏捷方法已经带来了很多积极变化。但是,软件行业中常见的跨地域开发显然是阻碍敏捷方法最佳应用的条件之一。对文档编制人员和译员而言,这意味着要为全球化分布的团队工作。尤其是为多个团队工作时,更高的磋商时间成本不可低估。

但与此相对的是多重好处,其中之一是文档编制专家和翻译专家的地位更高。更好地融入开发团队以及更顺畅的信息传递,不仅有利于文档编制人员和译员独立工作,还使其能够更加专注于客户需求,进而提升文档质量。

以上 SAP 案例分析说明了如何在文档编制和翻译领域贯彻落实敏捷开发原理。不过,如何以最佳方式推行精益原则的讨论还将在 SAP KM 社区内部继续下去,力求精益求精。