Search Results for

    Show / Hide Table of Contents

    MSF 详细活动指导

    版次:2022年3月3日 第1版
    类型:程序文件
    部门:软件部
    上海维宏电子科技股份有限公司 版权所有
    
    文件版本 修改前文件版本 主要修订内容和原因 修订人 修订日期
    R1 新建 胡凯烽 2022.3.3

    目的

    针对研发平台和产品线的 MSF 实践团队,提供 MSF 各个历程实施指导,明确关键活动及其要求,为团队顺利开展 MSF 项目实践提供帮助和指导。目前主要涉及两大关键历程,展望历程和计划历程。

    阅读者及阅读建议

    MSF 团队的各个角色,特别是产品管理、程序管理、架构设计和 UE 四个代言群,重点关注在这两个历程中和所在代言群功能领域直接相关的活动和检查点。

    范围

    本文档主要涉及到展望历程和计划历程的关键活动、关键输出及评审要求。

    历程指导

    展望历程

    展望历程需要完成的主要活动是组成核心团队和撰写远景/范围文件。勾勒项目远景和辨识项目范围是两种截然不同的活动,但两者都是项目不可或缺的成功关键因素。远景是以无拘无束的方式来思考解决方案未来可能的样子。范围则是在项目的约束条件之下找出远景所要实现的部分。

    关键输出物

    • 远景/范围文件,主导代言群:产品管理
    • 项目架构文件,主导代言群:程序管理
    • 初始风险评估,主导代言群:程序管理

    关键活动

    • 初始化项目仓库

    由程序管理向软件部申请项目仓库, 并按照《软件项目目录及文件管理规范》组织初始目录及文件。

    形式要求:

    1. 由软件部创建仓库, 团队不得自行创建;软件部须为各团队维护一个仓库列表。
    2. 必须按照《软件项目目录及文件管理规范》组织初始目录及文件。
    • 确认利益关系人

    由产品管理识别并确认利益关系人。

    形式要求:

    1. $/pm/stakeholder.md 文件中清晰描述利益关系人。

    内容要求:

    1. 有种子客户;行业头部客户作为种子客户尤佳。
    2. 有种子客户的沟通计划尤佳。
    • 组建核心团队

    由程序管理招募组建核心团队。

    形式要求:

    1. $/pm/roles.md 文件中描述了团队成员,及给出初始评估。

    内容要求:

    1. 至少 3 位全职人员。
    2. 保证每个角色均有全职人员参与(除发布运维外)。
    • 远景范围分析

    由产品管理起草远景/范围文档并呈现在项目的 README.md 文件中,并同步起草 SRS 一二章节内容。

    由 UE 主导定义用户故事的验收标准。

    由架构定义设计策略, 并呈现在项目的 README.md 文件中。

    SRS 目录是以最终能形成一本书为目标。

    形式要求:

    1. 按照《软件项目目录及文件管理规范》编写 README.md 文件。
    2. 根据《软件项目目录及文件管理规范》及 GBT8325 组织 SRS 文档。
    • 初始风险分析

    由程序管理召集团队讨论初始风险,并汇总。

    形式要求:

    1. $/pm/risk.md 文件中描述了初始风险。

    内容要求:

    1. 着重识别出了 3 个最高优先级的风险。
    • 展望历程评审

    由程序管理召集展望历程评审,参加人员包括但不限于研发总监、产品总监、首席架构师、软件部经理、本部门经理。

    要求:

    1. 评审面向项目代码仓库进行;
    2. 软件部对会议评审出的团队评分(形式分及内容分)做记录。

    计划历程

    计划历程专注于构建的内容、构建的方式、构建每个部件的时间、 交付解决方案需要的支持环境。具体来说就是:团队将展望历程的工作成果转化为能完整描述解决方案的需求;通过功能的规格说明将需求文档化;建立起详细的设计和架构;准备工作计划;估计成本;为计划历程的每个交付成果制订出时间表。同样团队还要定义和构建出交付解决方案必要的支持环境。

    关键输出物

    • 功能需求的规格设计
    • 设计方案
    • 主项目计划与时间表

    关键活动

    • 规格设计

    由架构、UE 对功能需求进行分解与细化。SRS 目录是以最终能形成一本书为目标。

    形式要求:

    1. 根据《软件项目目录及文件管理规范》及 GBT8325 组织 SRS 文档。

    内容要求:

    1. 体现功能需求的价值

    2. 对功能需求 markdown 文件不做形式上的要求,但要求:

      功能需求层次拆分合理

      功能需求的说明清晰

      一个仓库下功能需求格式一致

    • 方案设计

    由架构识别出实现的技术难点,并形成设计方案。

    形式要求:

    1. 组内评审通过,得到团队成员的认可。
    • 计划构建

    由程序管理汇集各角色提交的计划,形成主项目计划。

    形式要求:

    1. 必须有沟通计划;
    2. 必须体现主项目时间表;(管理工具不限)
    • 方案汇报/评审

    由程序管理将组内评审过的设计方案,汇报到软件部;专家委员会评审设计方案。

    形式要求:

    1. 评审过的设计方案, 必须汇报到软件部。
    • 计划历程评审

    由团队的程序管理召集计划历程评审, 参加人员包括但不限于研发总监、产品总监、软件部经理、本部门经理。

    要求:

    1. 评审面向项目代码仓库进行;
    2. 软件部对会议评审出的团队评分(形式分及内容分)做记录。

    附录- MSF 评审表

    MSF 评审_CheckList-R1.xls

    • Improve this Doc
    In This Article
    Back to top Shanghai Weihong Electronic Technology Co., Ltd.