Show Menu
主题×

管理项目——最佳实践清单

管理项目以实施Adobe Experience Manager(AEM)需要进行规划和理解,以确保您了解需要做出的问题和(相关)决策(在实施项目之前和期间)。
为帮助您,最佳实践包括:

项目心跳控制板

项目 心率工作表 ,以图形形式概述了您的项目的关键指标:
  • 相位质量
  • 阶段健康
    • 项目的高级状态指示器;用于突出可能存在风险的区域。
  • 阶段完整性
    • 在项目期间的任何时间点,它都表示已为项目的每个阶段完成了多少。

状态(按角色)

“按 角色 ”状态工作表按“健康”、“质量”和“完整性 ”阶段的“完​ 阶段和里程碑 角色 ​整性”。

阶段和里程碑

项目计划分为不同的(高级)阶段。
每个阶段都包含其自己的里程碑。 对于每 个人物 (或角色),将列出相关里程碑,以及生成定义的可交付内容所需的文档。
单个必需文档与交付件之间不存在直接的1:1关系。

准备

准备项目是整个项目的基础。 您需要为以下各项定义关键要求以及明确的目标和期望:
  • 业务原理
    • 开展该项目的根本原因和理由。
  • 范围和计划
    • 应提供基本范围和大致的时间表来定义所需内容,以及时间范围;如果有助于澄清情况,您还可以定义范围之外的内容。
您准备、计划和运行项目以及实施解决方案的方式将受到您在固定预算、固定时间线、内容数量和所需质量等操作限制的影响。
与往常一样,调整任何因素都会影响其他因素。 例如,缩短时间,但要求相同质量的产品可能会提高价格,同时减少您可以满足的内容数量。 预算往往是关键因素,因此这种关系不能被遗忘。
四个因素:

Milestones

  • 验证
    在此阶段,您需要验证并确认项目目标;例如:
    • 您希望实现/提供什么?
    • 谁将受益?
    • 范围是什么?
      • 如果有助于澄清情况,您还可以定义范围之外的内容。
    • 您如何定义成功?
    • 如何衡量成功?
    • 要求、业务和技术是什么?
    • 是否有旧版系统需要替换,如果需要,是否有要迁移的数据?
    • 谁会参与进来?
    • 你如何衡量进度?
    • 您在项目生命周期中多长时间审查进度?
  • 预算
    在开始任何项目之前,您需要对实施成本进行可靠而真实的估计:
    • 使用来自验证里程碑的信息作为估计的基础。
    • 在您的估计中保持真实。
    • 考虑并遵守客户可能受到的任何客户准则、流程或限制。
    • 考虑在以后阶段需要审查或完善预算时的应急和审查程序。
    • 记住,成本有多种形式;购买、使用资源及费用等。

规划

计划项目可整合准备。 在此,您需要开始将目标和期望转化为一个明确定义的路线图,其中包括明确沟通的具体任务,并严格审查进度。

Milestones

  • 移交
    干净的移交可确保适当的人物/组了解他们在项目中的责任。
    应提供/生成完整的详细信息,以确保他们全面了解所有相关方面,包括路线图、范围、目标、要求和关键绩效指标。
  • 风险评估
    为避免令人不快的意外,请使用风险评估来识别和量化任何潜在风险及其影响和可能性。
    应在项目生命周期的早期进行此项工作,以确保确定和评估任何可能性。 根据调查结果,您可以向利益相关方报告是否可以实施全部要求,以及是否可以根据需要计划采取和跟踪适当的行动。
  • 通信
    沟通始终是任何项目成功的关键。 您需要清晰、高效地沟通,以确保每个人:
    • 努力实现相同的基本目标
    • 从同一信息库
    • 使用相同的渠道
  • 启动
    启动会议用于提高对项目开始的认识。 这是一个很好的机会:
    • 邀请所有感兴趣的方(或至少是小组代表)。
    • 提供有关项目的重要事实。
    • 回答问题。
    • 确保每个人拥有相同的知识库。
    • 从所有参与者那里获得承诺——这一承诺必须得到实现。
      • 通过在项目开始时让主要玩家(包括潜在作者)参与,您可以增加他们致力于项目的机会。

开发准备

规划开发是确保您的项目由拥有所需知识的团队在可靠的设计基础上构建的关键。

Milestones

  • 开发团队人员配备和培训
    在开始任何项目之前,您应确保开发团队的人员配备得当,并确保所有团队成员都已针对手头的任务接受过培训。
  • 内容架构
    内容架构定义和描述了内容的未来架构;包括:
    • 内容树;包括资产
    • 基本结构;包括营销活动等。
    • 多站点和多语言结构(MSM、翻译等)
    • 支持内容(包括标记和标记概念)
    • 缓存和内容重用策略
  • 系统架构
    系统架构定义了系统的概念视图;包括(其中包括其他资料):
  • 应用程序架构
    应用程序架构定义和描述了建议的应用程序的行为。
    重点是:
    • 他们如何相互和与用户交互。
    • 应用程序将消耗和生成的数据,而不是其内部结构。
    定义应包括:
    • 项目的基本代码结构
    • 代码伪像(包、包等)
    • 模板/组件及其关系的细分
    • 所需自定义的高级详细信息(稍后将发布特定叠加)
    • 解决方案所需的工作流程设计(例如,内容创建、批准、发布、转换、导入、导出等)
    • 对于任何复杂模块(如MSM、Commerce、第三方集成)的特殊考虑
  • 系统集成
    系统集成需要您计划(然后实施):
    • 如何将所有子系统和解 决方案集成 ,作为一个相干系统运行
    • 将如何集成任何第三方系统;以及任何特殊注意事项,如脱机/联机、客户端/浏览器端或第三方系统停机时的错误处理
  • 测试概念
    在开始开发之前,您应该对项目的所有测试要求制定一个深入 而全面 的概念。
    这应包括(其中包括):
    • 要执行的所有测试的详细信息
    • 准备这些测试所需的任何内容
    • 要使用的任何测试工具的信息
    • 对谁将参与测试的高级别指示;特别是QA团队之外的组
    • 测试自动化的详细信息;例如,使用Selenium或AEM Developer模式
  • Experience Design
    体验设计(XD)涉及为解决方案设计用户体验。
    应为作者和网站的最终用户分析和开发用户体验。
  • 支持设置
    在开发之前,所有支持流程(部署、发布、测试和报告问题所需)应当到位。
    另请参阅 Adobe支持门户

运营计划和运营

在类似的基础上,必须正确规划操作以确保您拥有项目生命周期所有阶段所需的环境。 您还需要相应的流程来维护它们。

Milestones

  • 权限
    您需要为将使用该解决方案的所有用户/组规划并实施角色和权限概念。
    例如:
    • 角色(即组)列表,其中每个角色的 read /访 write 问定义
    • 定义对发布环境产生影响的权限的使用;例如, replicate
    • 对于权限最小的用户,应定义工作流
    • 用户组中 editor 的用户不应具有 admin 权限,也不应属于该组的一 administrators 部分
    For more information, see User Administration and Security .
  • 监控和维护
    监控和维护是确保解决方案一旦投入使用即可顺利运行的关键方面。 为此,您需要定义:
    • 需要监控的内容
    • 维护任务;常规和特殊情况
    另请参阅 监视和维护 ,以了解更多信息。
  • 迁移
    应检查并验证来自传统系统的任何内容以进行迁移。
  • 恢复计划
    确保您已制定了恢复计划。 在紧急情况下,必须提供此功能才能确保AEM的生产使用。 这应包括备份、恢复、故障检修等情况。

开发

开发是一个关键阶段,需要的不仅仅是编码。

Milestones

  • 开发环境
    规划并记录您的开发环境,包括:
    • 架构
      • 典型环境包括:
        • 问题跟踪系统;如吉拉
        • 集成开发环境;如Eclipse
        • 构建管理工具;如Maven
        • 持续整合的工具;如詹金斯
        • 用于版本控制的工具;如GIT/SVN
        • 构建对象存储库管理器;如Archiva/Nexus
    • 第三方软件集成/依赖关系
    • 部署节奏
  • 测试系统
    规划并记录您的测试环境,包括:
    • 架构
    • 依赖于开发构建;包括夜间构建
    • 测试第三方软件集成/依赖性的可能性或限制
    • 测试工具
    • 自动化测试策略
  • 生产系统
    规划并记录您的生产环境,包括:
  • 集成
    计划、记录和测试系统和解决方案集成的所 有方面 ,包括:
  • 迁移
    规划、记录和测试内容迁移的各个方面;包括:
    • 内容架构
    • 迁移战略
  • 通信
    确保所有团队成员和项目角色在必要时保持最新。
  • 文档
    充分记录解决方案;包括:
    • 操作手册
    • 任何可能影响升级的自定义
    • 发行说明

性能和测试

新应用程序推出后,将需要进行严格的测试,包括功能和性
应允许任何测试团队保持中立并提供测试结果。
项目经理有责任评估结果的任何影响并决定采取适当行动。

Milestones

  • 最终用户接受测试
    用户接受测试 (UAT)对于确保:
    • 该解决方案满足用户/客户的要求
    • 客户/用户接受解决方案(功能、设计和性能)
    应该有一份正式的客户移交清单;最理想的自动化,并针对快照在夜间运行。 结果应发送给项目经理和开发团队
  • 性能和加载测试
    性能和负载测试用于确保解决方案在平均负载和峰值负载上满足所需的性能级别。
    有关性能测试的更多信息,请参阅:
    在正常使用AEM期间,此过程必须继续,但这些初始阶段是最关键的。

转出

推出新应用程序需要仔细规划,以确保顺利上线。 这包括确认高度的安全性、培训所有潜在用户并进行多次练习以确认已处理所有问题。

Milestones

  • 准备
    准备和规划将帮助确保顺利推出。
  • 培训
    确保所有相关人员都受过培训。
  • 经过培训的管理员
    确保您的解决方案管理员具有:
    • 已接受培训
    • 收到了适当的培训材料
    • 收到相应文档
  • 经过培训的用户
    确保您的作者具有:
    • 已接受培训
    • 收到了适当的培训材料
    • 收到适当文件;例如,用户指南
  • 渗透测试
    渗透测试模拟对计算机系统的攻击,以识别潜在的安全弱点。
  • 渗透/安全测试
    要确保解决方案的安全性,请执行特定的渗透测试以及范围更广的安全测试。

上线

您希望“上线”尽可能平滑。 最后的步骤同样需要规划以执行干净。

Milestones

  • 准备
    准备和规划有助于确保顺利上线。
  • 安全
    确认内部和外部用户及其内容的解决方案的安全性。
  • 回退
    在上线前,确保所有备用系统、过程和机制都到位。
  • 支持
    确保支持服务就地就绪并准备就绪。
  • 过渡
    规划并执行向生产环境和用户的过渡。
  • 转出
    准备并执行烟雾测试。

角色

核对清单由人物设计。 这些角色在项目生命周期中具有重要的参与性。
还有一些其 他角色 ,涉及特定任务。

项目发起人

项目发起人是:
  • 负责提供/呈现项目的业务案例。
  • 确定项目范围的关键;包括:
    • 成功的定义和标准
    • 主要关键绩效指标
  • 根据客户路线图提供主要里程碑。

项目经理

项目经理是:
  • 根据项目赞助商提供的要求(例如范围、关键绩效指标、成功标准和定义)负责项目的整体交付。
  • 负责定义预算并根据该预算为项目提供资源。
  • 项目中所有角色的主要通信点。

架构师

解决方案架构师:
  • 负责解决方案和系统的高层设计。
  • 帮助定义AEM的实施战略。 例如,是实施群集安装,还是冷待机,还是当需要内容交付网络(CDN)时。
  • 还可根据客户端要求定义AEM解决方案体系架构。 这可以包括用户角色(具有相关权限)的概念、模板与组件之间的关系,或何时使用多站点管理。

业务分析师

业务分析师:
  • 主要负责收集和分析高层需求,然后将这些需求转化为规范:
    • 供项目经理在规划开发时使用
    • 让开发团队在设计和开发过程中工作。
  • 与客户紧密协作以分析需求。 它们与以下内容相匹配:
    • 成功的定义。
    • 成功标准。
    • 关键绩效指标(基于业务和绩效)。

开发领导

开发领先:
  • 负责项目的技术交付。
  • 负责选择符合客户要求的开发方法。
  • 制定发展战略:
    • 确保它与业务和绩效KPI保持一致
    • 考虑成功标准和定义
  • 与架构师紧密协作(尤其是在制定AEM开发战略时),以定义模板与组件之间的关系、第三方应用程序的集成策略以及任何特殊功能等方面。

质量潜在客户

质量潜在客户:
  • 负责交付质量;确保满足成功标准以及客户定义的任何KPI。
  • 定义质量指标,与所有利益相关方保持一致,制定测试计划并确保它们得到执行。
  • 创建报告并向项目利益干系人提供。

系统工程师

系统工程师:
  • 负责监督项目基础结构。
  • 负责:
    • 内部开发和测试环境的设置
    • 将这些系统与客户端系统相匹配
  • 提供硬件建议,监控各种实施,并在上线前和上线后提供操作支持。

安全领导

安全领导:
  • 负责解决方案的整体安全概念,确保其符合客户的任何要求和策略。
  • 为任何基于硬件的安全概念提供安全概念、安全操作和建议;例如区域和防火墙。

其他角色

  • 利益相关者
    • 对项目成功感兴趣(参与)的人员(通常来自企业)。 他们经常为预算捐款。
  • 合法的
    • 在谈判合同时需要法律咨询。
  • 培训师
    • 根据项目的规模和性质,可以利用专门培训师为相关群体制定和举办培训班。
  • 技术作者
    • 根据项目的规模和性质,可以使用专业技术作者为特定群体编写准则和手册;例如,系统管理员的维护手册或作者的用户指南。
  • 系统管理员
    • 负责系统的持续运行。
  • 作者和最终用户
    • 将使用系统创建和维护网站内容的人员。

所需文档和交付件

核对清单涵盖每个 里程碑的“必需文档 和“可交付项 ”。
  • 两者之间没有1:1的关系;例如,一组必需的文档可能导致单个交付项。
  • 在同一里程碑期间,一个角色的可交付内容可以是另一个角色的必需文档。

必需文档

在制 作交付件时 ,相应角色需要必需的文档。
对于每个 必需文档 ,人物应指示:
  • Y/N :是否已收到。
  • 1-3 :接收文档的质量指示。

交付内容

对于每个里程碑,相应的角色负责提供特定文档,从而实现他们对特定里程碑的责任。
对于每个可交 付项 ,人物必须指示:
  • Y/N :是否已完成。
交付内容通常用作当 前或以后的里程碑 ,是必需的文档。

关键文档区域