项目开发流程

宏观项目流程

通常项目的Sprint周期为1个月。

sequenceDiagram
    actor Sanjel
    box 开发团队
        actor 项目经理
        actor 开发团队
        actor 财务
        participant 账单
    end

    box 工件
        participant 项目计划
        participant 开发方案工件
        participant 开发工件
    end

    Sanjel->> 项目经理 :下发需求
    项目经理->>项目计划 :项目经理整理需求确定项目计划中任务性质

    par 下一阶段需求分析
        loop 对每一个下一阶段需求分析
            项目经理->> 开发团队 :根据客户需求进行技术评估
            par 
                开发团队->> 开发方案工件 : 根据客户需求准备各种开发方案工件
                开发团队-->> 项目经理 :反馈技术可行性和评估工作量
            end
        end

        项目经理->> 项目计划 :根据客户需求和开发团队的反馈制定交付计划

        项目经理->> 财务 :提交工作计划财务审核请求
        财务->> 项目计划 :审核工作计划
        财务-->> 项目经理 :工作计划审核通过
        项目计划-->> Sanjel :提交项目计划
        Sanjel->> 项目计划 :内部审核项目计划
        opt
            Sanjel->> 项目计划 :修改项目计划
        end    
    and 审核后任务
        loop 审核后任务
            项目经理->> 开发团队 :按项目计划分配人员及任务
            par
                开发团队->> 开发工件 : 根据任务中要求设计和实现各个功能点并创建必要的开发工件
                开发团队-->> 项目经理 :反馈实际工作量
            end
        end

        开发团队->> 开发团队 :内部验收
        opt 内部验收通过
            开发团队->> Sanjel :发布UAT环境，Sanjel验收
            opt 验收通过
                开发团队-->> Sanjel :到期交付
            end
        end
    end

    项目经理->> 账单 :整理账单（工件：账单）（周期：一个月）
    项目经理->> 财务 :提交账单审核请求
    财务->> 账单 :内部审核
    财务->> 项目经理 :通知审核通过
    项目经理-->> Sanjel :发送账单
    Sanjel->> 财务 :付款
    财务->> 财务 :确认收款

参与者

Sanjel
开发团队
1. 项目经理
2. 开发团队
3. 财务
4. 账单
工件
1. 项目计划
2. 开发方案工件
3. 开发工件

活动

Sanjel下发需求给项目经理
项目经理整理需求确定项目计划中任务性质
下一阶段需求分析任务
1. 对每一个下一阶段需求分析
  1. 项目经理安排开发团队根据客户需求进行技术评估
  2. 开发团队协同并行工作
    1. 开发团队根据客户需求准备各种开发方案工件
    2. 开发团队向项目经理反馈技术可行性和评估工作量
2. 项目经理根据客户需求和开发团队的反馈制定项目计划
3. 项目经理向财务提交项目计划审核请求
4. 财务审核工作计划
5. 财务通知项目经理工作计划审核通过
6. 项目计划提交给Sanjel
7. Sanjel内部审核项目计划
8. Sanjel根据审核结果修改项目计划
Sanjel审核后的任务
1. 对每一个审核后任务
  1. 项目经理安排开发团队按项目计划分配人员及任务
  2. 开发团队协同并行工作
    1. 开发团队根据任务中要求设计和实现各个功能点并创建必要的开发工件
    2. 开发团队向项目经理反馈实际工作量
2. 开发团队内部验收
3. 若内部验收通过
  1. 开发团队发布UAT环境，Sanjel验收
  2. 若Sanjel验收通过
    1. 开发团队到期交付Sanjel
项目经理整理账单（工件：账单）（周期：一个月）
项目经理向财务提交账单审核请求
财务对账单进行内部审核
财务通知项目经理审核通过
项目经理向Sanjel发送账单
Sanjel向财务付款
财务确认收款

Sanjel决策流程

以下是以Sanjel的角度与MetaShare合作的流程。Sanjel内部机制对MetaShare来说并不需要知道细节，它也是在不断完善的过程。目前确定的是与MetaShare的沟通机制，所有确定的MetaShare的工作范围，都以Backlog中的ticket为准。所谓的Project，只是一个任务的容器，大到一个应用，小到一个bug fix。目前的付账周期是一个月，并不限于是只一个project，可以是几个project，或是一个project的一个阶段，或者是一个混合。这是由于Sanjel和MetaShare合作的性质决定的。项目开始后续的协作，在后面细化的流程中进行描述。

当tickets显示在Backlog中，MetaShare可以开始分析和评估，所有需要澄清的问题都在原ticket中与Sanjel相关人员进行沟通，因为Sanjel方面需要交付的是这些ticket所描述的需求。这些分析评估任务可以是当前迭代中的一个ticket。

在分析设计过程中，为实现原需求，可能涉及到若干系统，而分解为若干任务分布于若干系统中，那么原Ticket则升级为Summary。如果此时在一个系统中的一个任务体量过大，需要进一步分解，则上一层ticket升级为Summary。最终的任务必须是可执行、可测试、可交付、时间跨度不超过一周的由单一人员完成的任务。在这个过程中这些任务要完成估时，标注迭代标签。可以暂放Planning列。经过总体评估后，Metashare根据一个迭代内可用资源情况，提交迭代计划，供Sanjel审批。

每个迭代结束后，下一个迭代的ticket移入TODO列。后面MetaShare的流程我在阅读后再提反馈

sequenceDiagram
    box Sanjel
        actor Engineer
        actor IT Manager
        actor Architect
    end
    
    box eSerivce_Items
        participant Issue
        participant Project Plan
    end
    
    
    actor MetaShare
    Engineer->>Issue:Login Requirement
    Note right of Engineer :  New function request or bug
    Architect->>Issue:Review and solutioning
    Note right of Architect :  Add Architect Notes and Estimate
    Architect->>Project Plan: Build Project Proposal
    Note right of Architect :  Collect issues based on dependencies and priority
    Project Plan-->>Engineer: Review project scope and deliverable 
    Engineer->>Project Plan: Confirm Project Plan
    Note right of Engineer :  Discussion and Negotiation <br/> with Business Owner and Architect
    Architect->>IT Manager: Submit Project Plan
    Project Plan-->>IT Manager: Review project scope, budget and time 
    IT Manager->>IT Manager: Seek budget approval
    alt budget approved
    IT Manager->>Project Plan: Approve
    Architect->>MetaShare:Notify project plan
    Note right of Architect :  Assign issues to "Sanjel Sustainment Project" <br />and move them to Backlog column
    else
    IT Manager->>Architect: Revise the plan
    end
    MetaShare->>MetaShare:Work On the project 
    Note right of MetaShare: Collaborate with SanjelTeam for project implementation
    MetaShare->>Architect: Deliverables for review and test
    Architect->>Architect: Review design/code/test result
    alt review passed
    Architect ->>Engineer: Submit for UAT test
      alt UAT test passed
        Engineer->>Architect:UAT passed
        Architect->>Architect: Prepare release plan
        Architect->>MetaShare: Confirm Project Completion
        MetaShare->>IT Manager: Send Projct Invoice
        IT Manager->>MetaShare: Arrange Payment
      else
        Engineer->>Architect:UAT failed
        Architect->>Architect: Analyze failure
        Architect->>MetaShare:Provide feed back
    MetaShare->>MetaShare: Rework on the feedback 
    Note right of MetaShare: Re-submit for review and test
        end
    else
    Architect->>MetaShare: Provide feed back
    Note right of Architect: Failed test cases
    MetaShare->>MetaShare: Rework on the feedback 
    Note right of MetaShare: Re-submit for review and test
    end

sequenceDiagram
    box Sanjel
        actor 财务部门
        actor 业务部门工程师
        actor 信息化部门经理
        actor 信息化架构师
    end

    box 开发团队
        actor 项目经理
        actor 开发团队
        actor 财务
        participant 账单
    end

    box 工件
        participant 项目计划
        participant 开发方案工件
        participant 开发工件
    end

    par 下一阶段需求分析
        业务部门工程师->> 信息化部门经理 : 提出需求
        Note right of 业务部门工程师 :  创建该需求对应的Ticket（Draft）并给出描述

        信息化架构师->> 信息化架构师 : 根据该需求描述确定是否是问题

        alt 该需求不是问题
            信息化架构师-->> 信息化部门经理 : 关闭该需求并给出原因或方案
            信息化架构师-->> 业务部门工程师 : 关闭该需求并给出原因或方案
            Note left of 信息化架构师 :  关闭该需求对应的Ticket（Close）并给出原因或方案的描述
        else
            信息化架构师 -->> 信息化部门经理 : 对问题情况进行初步评估并反馈情况
            信息化部门经理->> 信息化架构师 : 确定该需求对应的项目并给出优先级
            Note left of 信息化架构师 :  该需求对应的Ticket状态由Draft升级为Issue并指定对应的项目及优先级等
            Note left of 信息化架构师 :  该需求对应的Ticket（Issue）进入项目的置入看板No Status列

            信息化部门经理 -->> 信息化部门经理 : 根据预算等因素对进行需求财务方面的评估
            信息化部门经理 -->> 信息化架构师 : 确定启动该需求的下发及询价

            信息化架构师->> 项目经理 : 下发需求
            Note right of 信息化架构师 :  该需求对应的Ticket（Issue）置入看板Backlog列

            项目经理->>开发团队 : 项目经理协调开发团队进行方案和评估工作
            Note right of 开发团队 :  为管理分析设计架构等方案和评估工作创建Ticket估算工时置入看板Analysis列
            开发团队->>开发方案工件 : 开发团队进行方案和评估工作
            Note right of 开发团队 :  管理分析设计架构等方案和评估工作Ticket记录工时置入看板InReview列
            项目经理->>项目计划 : 项目经理整理对需求的方案和评估结果创建项目计划
            Note right of 项目经理 :  根据分析结果为Ticket（Issue）估算每个子任务工时和总工时

            项目计划-->> 信息化部门经理 :提交项目计划
            信息化部门经理 ->> 项目计划 : 根据预算等因素对项目计划进行财务方面的评估

            opt
                信息化部门经理->> 项目计划 : 修改项目计划
            end
        end
    and 审核后任务
        信息化架构师->> 项目计划 : 执行项目计划
        Note left of 信息化架构师 :  将Ticket置入看板Planning列
        项目计划->> 项目经理 : 协调开发团队
        项目经理->> 开发团队 : 协调开发团队完成分析设计和实现测试的工作
        Note left of 开发团队 :  根据分析设计结果为该Ticket创建子任务的Ticket并置入看板Planning列

        loop
            开发团队->>开发工件 : 开发团队细化实现方案并完成各种工件
            Note right of 开发团队 :  每个迭代开始根据优先级和人员负荷确定要完成的子任务Ticket从看板Planning列置入ToDo列
            Note right of 开发团队 :  团队成员领取子任务Ticket置入看板InProgress列，完成任务记录工时并置入看板Test列
            Note right of 开发团队 :  若团队成员实现过程中出现问题，则置入看板Blocked列，若问题则置入之前的列
            Note right of 开发团队 :  管理分析设计架构等工作完成则直接置入看板InReview列

            开发团队->> 开发团队 : 内部验收
            alt 内部验收通过
                开发团队->> 信息化架构师 : 发布UAT环境
                Note right of 开发团队 :  子任务Ticket置入看板InReview列
                信息化架构师->> 信息化架构师 : Sanjel验收
                alt 验收通过
                    信息化架构师-->> 信息化部门经理 : 到期交付
                    Note right of 开发团队 : 子任务Ticket置入看板Donew列
                else
                    信息化架构师 ->> 开发团队 : 提供问题描述
                    开发团队->>开发工件 : 开发团队分析解决问题
                    Note right of 开发团队 :  以较高优先级创建子任务Ticket置入看板ToDo列
                end
            else
                开发团队->>开发工件 : 开发团队分析解决问题
                Note right of 开发团队 :  以较高优先级创建子任务Ticket置入看板ToDo列
            end
        end
    end

    项目经理->> 账单 :整理账单（工件：账单）（周期：一个月）
    Note right of 项目经理 :  根据Tickets中的工时记录统计结果整理账单
    项目经理-->> 信息化部门经理 :发送账单
    财务部门->> 财务 :付款
    财务->> 财务 :确认收款

MetaShare内部开发流程-需求分析及方案评估阶段

sequenceDiagram
    actor 项目经理
    box 开发团队
        actor 业务分析
        actor 架构师
        actor 程序员
        participant 项目计划
    end

    box 开发方案工件
        participant 架构原型
        participant 方案说明
        participant 业务模型
        participant 用例描述
    end

    项目经理 ->> 项目计划 : 与开发团队共同评估
    Note right of 项目经理 :  在MetaShareAnalysis中创建该任务的Ticket分配给团队成员 
    par  架构级方案
        opt 若需采用新的架构
            项目经理->> 架构师 :确定架构级方案
            Note right of 架构师 :  架构师创建Ticket作为子任务 
            架构师->> 架构原型 : 
            架构师->> 方案说明 : 
            Note right of 架构师 :  架构师把Ticket置为InReview状态

            架构原型 -->> 项目经理 : 
            方案说明 -->> 项目经理 : 

            架构师->> 程序员 : 澄清技术实现方案
            架构师->> 项目计划 :确定周期，架构级任务内容，优先级
        end
    and 需求分析
        项目经理->> 业务分析 : 获取需求并整理拆分
        Note right of 业务分析 :  业务分析创建Ticket作为子任务 
        业务分析 ->> 业务模型 : 
        业务分析 ->> 用例描述 : 
        Note right of 业务分析 :  业务分析把Ticket置为InReview状态

        业务模型 -->> 项目经理 : 
        用例描述 -->> 项目经理 : 

        业务分析 ->> 程序员  :团队了解需求
        程序员 -->> 项目经理 : 评估工作量
        项目经理 ->> 项目计划 :确定项目计划的任务内容，工作量
    end

    项目经理 ->> 项目计划 : 确定项目计划的周期，任务内容，优先级，工作量
    Note right of 项目经理 :  核查该任务Ticket的所有子任务，Ticket置为Reviewed状态

参与者

项目经理
开发团队
1. 业务分析
2. 架构师
3. 程序员
4. 项目计划
开发方案工件
1. 架构原型
2. 方案说明
3. 业务模型
4. 用例描述

活动

项目经理与开发团队共同评估项目计划，项目经理在MetaShareAnalysis中创建该任务的Ticket分配给团队成员
对于架构级方案
1. 若需采用新的架构
  1. 项目经理与架构师确定架构级方案，架构师创建Ticket作为子任务
  2. 架构师创建架构原型
  3. 架构师创建方案说明，架构师把Ticket置为InReview状态
  4. 架构师提交架构原型
  5. 架构师提交方案说明
  6. 架构师向程序员澄清技术实现方案
  7. 架构师与项目经理共同完善项目计划，确定周期，架构级任务内容，优先级
需求分析
1. 项目经理与业务分析确认获取需求并整理拆分，业务分析创建Ticket作为子任务
2. 业务分析创建业务模型
3. 业务分析创建用例描述
4. 业务分析创建测试数据，业务分析把Ticket置为InReview状态
5. 业务分析提交业务模型
6. 业务分析提交用例描述
7. 业务分析向开发团队提交需求相关工件并协助团队了解需求
8. 开发团队与项目经理共同评估工作量
9. 开发团队与项目经理共同完善项目计划，确定项目计划的任务内容，工作量
项目经理完善项目计划，确定项目计划的周期，任务内容，优先级，工作量，项目经理核查该任务Ticket的所有子任务，Ticket置为Reviewed状态

MetaShare内部开发流程-设计实现及测试发布阶段

sequenceDiagram
    participant 项目计划
    actor 项目经理

    box 开发团队
        actor 业务分析
        actor 架构师
        actor 程序员
        participant 开发方案工件
    end

    box 开发工件
        participant 用例分析文档
        participant 界面原型
        participant 测试用例
        participant 测试数据
        participant 设计实现的原则与实践
        participant 系统源代码
        participant 内部测试结果
        participant 系统文档
    end

    项目计划-->> 项目经理 : 执行项目计划
    Note right of 项目计划 : 选择业务分析cklog中的Ticket为Parent Task 
    Note right of 项目计划 : 在以下的分析和设计活动中创建Tickets作为Child Tasks并放在Planning中
    Note right of 项目计划 : 根据优先级和人员情况把Planning中Ticket移入Todo中
    Note right of 项目计划 : 选择Todo中Ticket执行

    项目经理->> 架构师 : 与架构师确定架构实现任务

    loop 每一个架构级任务
        开发方案工件-->> 架构师  : 复审，特别是架构级用例实现方案
        项目经理-->> 项目计划 : 安排架构级实现任务
        Note right of 项目计划 : 把对应实现任务的Ticket优先级调整为High
        Note right of 项目计划 : 创建业务分析任务Ticket，优先级调整为最高High
        Note right of 项目计划 : 创建架构师任务的Ticket，优先级调整为高High
    end

    loop 按优先级顺序完成Ticket中的任务
        par 业务分析任务
            项目经理->> 业务分析 : 业务分析任务
            Note right of 业务分析 : 业务分析任务Ticket变为InProgress
            业务分析->> 开发方案工件 : 复审，特别是完善业务模型
            业务分析->> 用例分析文档 : 细化用例，完善用例分析文档
            
            alt 模型驱动开发（元元方）
                业务分析->> 系统源代码 : 选择合适的转换方案并生成代码至代码库
            else
                业务分析->> 界面原型 : 
                业务分析->> 测试用例 : 
                业务分析->> 测试数据 : 
			end
			
            业务分析-->> 项目经理 :反馈实际工作量
            Note right of 项目经理 : 业务分析任务Ticket变为InReview
        and 架构级任务
            用例分析文档->> 架构师 : 参考
            Note right of 架构师 : 架构师任务Ticket变为InProgress
            架构师->> 架构师 : 架构级任务的实现
            架构师->> 设计实现的原则与实践 : 对用例分析并总结实现模式
            架构师->> 设计实现的原则与实践 : 完善实现模式，确定业务模型中领域类的实现模式, 及对应实现类的代码模板
            alt 模型驱动开发（元元方）
            	架构师->> 架构师 : 完善基础代码
            	架构师->> 架构师 : 根据业务模型中领域类的实现模式完善转换
            	架构师->> 架构师 : 制作对应实现类的代码模板
                架构师->> 系统源代码 : 选择合适的转换方案并生成代码至代码库
            else
                架构师->> 系统源代码 : 实现代码提交至代码库
            end
            架构师->> 系统文档 : 完善相关系统文档
            架构师-->> 项目经理 : 反馈实际工作量
            Note right of 项目经理 : 架构师任务Ticket变为InReview
        and 实现任务
            用例分析文档 -->> 程序员 : 参考
            开发方案工件 -->> 程序员 : 参考业务模型和用例描述
            设计实现的原则与实践 -->> 程序员 : 参考

            opt 任务未分解或任务过大
                架构师->> 程序员 : 通过培训、结对、设计或代码复审指导
                架构师->> 程序员 : 确定实现模式
                架构师->> 程序员 : 任务分解
                Note right of  架构师 : 根据用例的实现模式进行任务分解在Planning中创建Ticket为Child Task
            end

			loop 直到所有测试和验证通过
                系统源代码-->> 程序员 : 程序员获得系统源代码
                Note right of 程序员 : 实现任务Ticket变为InProgress

                程序员->> 系统源代码 : 根据业务模型和用例描述实现用例
                程序员->> 系统源代码 : 使用测试数据对用例运行所有测试用例
                程序员->> 架构师 : 设计和代码复审
                程序员->> 系统源代码 : 在架构师的协助下进行集成测试
                程序员->> 内部测试结果 : 提交内部测试结果
                程序员->> 系统文档 : 完善相关系统文档
                Note right of 程序员 : 实现任务Ticket变为Test

                系统源代码-->> 架构师 : 程序员提交代码给架构师， 架构师发布到开发环境并验证

                架构师-->> 项目经理 : 开发环境验证通过，通知发布测试版本
                Note right of 架构师 : 实现任务Ticket变为InReview

                系统源代码-->> 架构师 : 发布系统测试版本
                架构师->> 业务分析 :通知业务分析进行系统测试

                业务分析-->> 项目经理 : 系统测试版本测试通过，通知客户验收

                break 若任何测试和验证不通过
                    alt 若为需求获取问题
                        业务分析 -->> 项目经理 : 复审其对所有相关实现任务的影响
                        项目经理->> 架构师 : 架构师评估受到影响的实现任务
                        Note right of 架构师 : 根据影响程度，实现任务Ticket变为InProgress或Planning
                    else 若为架构问题
                        架构师 -->> 项目经理 : 复审其对所有相关实现任务的影响
                        项目经理->> 架构师 : 架构师评估受到影响的实现任务
                        Note right of 架构师 : 根据影响程度，实现任务Ticket变为InProgress或Planning
                    else 若为实现获取问题
                        架构师->> 程序员 : 进一步设计和代码复审确定原因并修正
                        Note right of 架构师 : 实现任务Ticket变为InProgress
                    end
                end
			end
			
        end

        项目经理 -->> 项目计划 : 修正项目计划，记录实际工作量
        Note left of 项目经理 : 核查该任务Ticket的所有子任务，Ticket置为Reviewed状态
    end

参与者

项目计划
项目经理
开发团队
1. 业务分析
2. 架构师
3. 程序员
4. 开发方案工件
开发工件
1. 设计实现的原则与实践
2. 用例分析文档
3. 界面原型
4. 测试用例
5. 测试数据
6. 系统源代码
7. 内部测试结果
8. 系统文档

活动

项目经理执行项目计划，并根据以下原则创建Tickets
1. 选择业务分析cklog中的Ticket为Parent Task
2. 在以下的分析和设计活动中创建Tickets作为Child Tasks并放在Planning中
3. 根据优先级和人员情况把Planning中Ticket移入Todo中
4. 选择Todo中Ticket执行
项目经理与架构师确定架构实现任务
对每一个架构级任务
1. 架构师复审开发方案工件
2. 项目经理修正项目计划，安排架构级实现任务，并根据以下原则创建和调整Tickets的优先级
  1. 把对应实现任务的Ticket优先级调整为High
  2. 创建业务分析任务Ticket，优先级调整为最高High
  3. 创建架构师任务的Ticket，优先级调整为高High
按优先级顺序完成Ticket中的任务
1. 业务分析任务
  1. 项目经理安排业务分析任务，业务分析任务Ticket变为InProgress
  2. 业务分析复审开发方案工件
  3. 业务分析细化用例，完善用例分析文档
  4. 业务分析提交界面原型
  5. 业务分析提交测试用例
  6. 业务分析提交测试数据
  7. 业务分析向项目经理反馈实际工作量，业务分析任务Ticket变为InReview
2. 架构级任务
  1. 在业务分析完成相关用例分析文档后，架构师参考用例分析文档，架构师任务Ticket变为InProgress
  2. 架构师完成架构级任务的实现
  3. 架构师总结实现模式并对用例分析，并创建或完善设计实现的原则与实践
  4. 架构师完善相关系统文档
  5. 架构师向项目经理反馈实际工作量，架构师任务Ticket变为InReview
3. 实现任务
  1. 在业务分析完成相关用例分析文档后，程序员参考用例分析文档，实现任务Ticket变为InProgress
  2. 程序员参考业务分析提供的开发方案工件，主要是参考业务模型和用例描述
  3. 程序员参考架构师提供的设计实现的原则与实践
  4. 若任务未分解或任务过大，架构师需要帮助程序员完成以下工作
    1. 架构师通过培训、结对、设计或代码复审指导程序员
    2. 架构师帮助程序员确定实现模式
    3. 架构师帮助程序员完成任务分解，并根据用例的实现模式进行任务分解在Planning中创建Ticket为Child Task
  5. 程序员根据业务模型和用例描述实现用例功能相关的系统源代码
  6. 程序员使用测试数据对用例运行所有测试用例保证提交的系统源代码的质量
  7. 程序员提交内部测试结果
  8. 程序员完善相关系统文档
  9. 程序员向项目经理反馈实际工作量，实现任务Ticket变为InReview
项目经理修正项目计划，记录实际工作量，核查该任务Ticket的所有子任务，Ticket置为Reviewed状态

开发流程（Ticket）

sequenceDiagram
业务分析->> Developer :获取需求并整理，拆分成任务（业务模型、界面原型、Usecase描述），并在Git上创建对应的Ticket，位于Todo列
业务分析-->>业务分析  :编写测试用例、准备测试数据（TestCase、TestData）
Developer->> Developer :领取Ticket，Git上Ticket迁移至In progress 指派给自己，
Developer->> Developer :Git上在此Ticket上创建Branch，
Developer->> Developer :在分支中完成分析设计工作，并提交分析结果到Git的Ticket中，进行代码实现（code）
Developer->> Architect :Review代码分析结果
Architect->> Developer :反馈结果和建议
Developer->> Developer :单元测试
Developer->> Developer :集成测试通过
Developer-->> Developer :提交PR请求
Developer-->> Developer :（架构师或其他人）PR审核通过
Developer->> Developer :Git上Ticket转移到Test列
Developer-->> 业务分析 :发布Dev环境，通知需求验收
业务分析-->> 业务分析 :Dev环境验证
业务分析->> Developer :Dev环境验证通过，Git上Ticket迁移到InView列,通知发布Test版本
Developer-->> Developer :发布Test版本
Developer-->> 业务分析 :通知测试Test版本
业务分析-->> 业务分析 :Test版本验证
业务分析-->> Sanjel :Test版本测试通过，通知Sanjel验收
Sanjel->> Sanjel :Test版本验收通过
业务分析->> Sanjel :Release发布UAT版本
Sanjel->> Sanjel :UAT版本验证通过
Sanjel->> Sanjel :Git上Ticke迁移至Done列

业务分析获取需求并整理，拆分成任务（业务模型、界面原型、Usecase描述），并在Git上创建对应的Ticket，位于Todo列
业务分析-->>业务分析 :编写测试用例、准备测试数据（TestCase、TestData）
Developer:领取Ticket，Git上Ticket迁移至In progress 指派给自己，
1. Developer :Git上在此Ticket上创建Branch，
2. Developer :在分支中完成分析设计工作，并提交分析结果到Git的Ticket中，进行代码实现（code）
3. Architect :Review代码分析结果
4. Architect- :反馈结果和建议
5. Developer :单元测试
6. Developer :集成测试通过
7. Developer :提交PR请求
8. Developer:（架构师或其他人）PR审核通过
Developer :Git上Ticket转移到Test列
1. Developer-->> 业务分析 :发布Dev环境，通知需求验收
2. 业务分析-->> 业务分析 :Dev环境验证
3. 业务分析->> Developer :Dev环境验证通过，Git上Ticket迁移到InView列,通知发布Test版本
4. Developer-->> Developer :发布Test版本
5. Developer-->> 业务分析 :通知测试Test版本
6. 业务分析-->> 业务分析 :Test版本验证
业务分析 :Test版本测试通过，通知Sanjel验收
Sanjel :Test版本验收通过
业务分析 :Release发布UAT版本
Sanjel :UAT版本验证通过
1. Sanjel :Git上Ticke迁移至Done列

任务状态迁移

stateDiagram
[*] -->NoStatus : Sanjel的功能申请或bug<br/>注册在eService_WorkItems中<br/>准备交由MetaShare进行处理
NoStatus-->Backlog :Sanjel完成初步分析和估时，<br/>并获批开发预算，<br/>预标识迭代周期。
Backlog -->Todo :MetaShare完成需求确认和任务分解，<br/>移入本迭代进行开发。
Todo --> InProgress : Developer认领的Ticket，<br/>开发中
InProgress --> Test : Developer任务处理完成，自验验证通过<br />等待QA测试
Test --> InProgress : QA测试失败<br />Developer进行问题排查
InProgress --> Blocked : Developer遇到问题待确认<br/>或受限其他任务<br>暂停工作
Blocked --> InProgress : 问题已解决<br>可恢复开发
Test --> InReview : MetaShare QA测试通过<br>交付Sanjel UAT测试验收
InReview --> Reviewed :Sanjel UAT验证通过
InReview --> Test :Sanjel, UAT验证不通过<br>返回Metashare进行问题排查
Reviewed --> Done : Sanjel发布到生产系统<br>标注发布版本号
Done --> [*]

状态说明

No Status:
1. Raw Requirement 从用户处采集到的原始需求，它不限于形式，由业务分析员采用最适用于用户的沟通方式和表述方式，获取到用户对业务愿景、场景、期望、想法的描述。如用户故事、用例、图示、思维导图、界面原型，等各种方式。
2. Change Request，根据对原始需求的分析，分解用户期望目标，预估实现目标的最大系统边界，定义系统改变要求。
3. Bug：
  - 开发周期内，如果是当前开发的功能测试不通过，直接打回In Progress，把存在的问题写在回帖中，让开发员去修改，不需要重写测试步骤
  - 如果测试中发现的是其他问题，需要写重现步骤，在有文档的情况下，需要与原需求文档进行链接，如果是需求变化了，要补充需求变更文档。这时创建新的Bug，发回给Customer进行Review，确认是bug后，再发回到ToDo，确认优先级，安排修复。
4. 业务分析经过对需求的分析，通过设计，形成的一系列工作目标，每个工作目标应该只局限于一个系统或子系统或组件或模块的系统边界内。如有必要，可以根据实际需要形成层次结构。一个需求所产生的backlog的集合逻辑上与需求是等价的，并可以相互验证。
5. 业务分析获取到新的需求活任务后记录在此。
Backlog: Sanjel在完成对requirement、change request和bug的初步分析和解决方案指向确定后，确认获得开发预算，可进入计划和实施的任务。MetaShare可以进行进一步分析和设计，如果任务分解，原任务升级为Summary，子任务为具体工作任务并明确链接主任务，并按可用资源制定迭代计划。
To do：根据迭代计划，MetaShare在迭代开始时，移入当前迭代的所有任务。MetaShare系统边界内的进一步分析和设计，分解为可执行的任务，任务的粒度应控制在单个子系统环境可测试的规模，测试要求能够自动化运行。可用于开发人员的开发工作。如果任务分解，原任务升级为Summary。
- 管理任务和事物性任务，可以创建 Draft进行计划、跟踪和工时记录。完成后，移到InReview。
In Progress: 进行中的任务，领取任务后责任人将任务指派改为自己，完成对应的单元测试、集成测试后任务迁移到Test进行QA测试。
- 即时事物性任务，如早会、专题会议，可创建draft用来记录会议纪要和工时纪录，记录所有人总工时即可。完成后，移入InReview
Test：开发完成的任务后，MetaShare进行QA测试。
- 测试单元为原始需求任务，其子任务必须是全部完成（剩余时间为0）
- 测试任务可以创可以创建 Draft进行跟踪和工时记录，完成后，移到InReview
- 测试失败，需在原始需求任务中写明测试数据和复现步骤，移回In Progress由原开发者进行排查修正
- 测试通过，原始需求任务及其子任务同时移入InReview，交由Sanjel进行UAT测试
Blocked：In Progress、Test中的任务进行时被其他团队成员的进度所影响或者需要向Sanjel澄清需求而无法进行的工作迁移到此状态。
InReview：Sanjel通过UAT测试进行功能验收
- 验证通过迁移到Reviewed。关闭子任务，只保留原始需求任务。
- 验正失败，写明测试数据和复现步骤，移回In Progress由原开发者进行排查修正。
- 管理任务和事物性任务，Sanjel进行复核。在迭代汇总结算完成后，按迭代统一关闭。
Reviewed: 所有已通过测试验收的原始需求任务。规划新版本发布，标注版本号，移入Done.
Done: 所有已进入发布流程的任务，发布后，统一关闭。

任务链接

任务需要细分成多个子任务时，在子任务中增加父任务链接，父任务中增加子任务链接，可相互查看。

新增BUG中增加对应的任务或需求链接，并在需求或任务中增加BUG链接，可相互查看。

Blocked：任务中增加影响当前任务进行的任务链接，可查看由什么任务影响导致阻塞。

角色和职责

角色	职责	工件
业务分析	与客户沟通获取原始需求,并进行分解、分析，进一步的细化并整理为可实现的任务。可制定个人工作计划，并独立完成本职工作。	Use Case、用户故事、界面原型绘制，测试用例、测试数据的准备，系统功能验证，任务拆分Tikcet。
Developer	根据业务分析、系统分析结果实现功能，并完成单元测试、集成测试，有自主分析能力，可以提出合理的建议和意见。	制定个人工作计划、实现功能代码，单元测试代码，集成测试代码，及时确认和修复缺陷
Project Manager	跟踪项目进度、控制项目成本，规范团队内部工作流程，	项目计划，账单
Scrum Master	负责组织早会，协调项目组员之间的工作，帮助大家解决支撑类的工作问题。	工时记录
Architect	协助PM完成工作量评估，对于技术难点予以提供解决方案，并对团队的代码成果进行Review，确保代码符合架构要求，保证交付质量。	代码，架构原型

Process Review

Requirement Collection - Sanjel

Normally business requirement will be registered as a ticket in eService_WorkItems.

Workload Planning - Sanjel

When a requirement ticket is assigned to Metashare team for future iteration, it will be assigned to eService Sustainment Project without status.

Iteration Planning - Sanjel & Metashare

Ticket triage - Sanjel

When Sanjel is planning for a development iteration, the ticket will be moved to Backlog column. The iteration label will be set.

Analysis - Metashare

Metashare investigates the issue and clarify with Sanjel in ticket comments. Ticket body content should be updated once consensus is made.

Design & Estimate - Metashare

Metashare can break down big task to small tasks by creating new issues in the corresponding repositories. The parent task should be referenced in child tasks.
- For example, if a feature requirement have functions across multiple repositories, it should be slitted to specific tasks in every repository.
The parent task must be kept under eService_WorkItems as a shell to track the overall progress. The estimate hours and remain hours should reflect the total hours of its child tasks.
The end tasks must be transferred to an application repository, so it can be linked to check-ins and pull requests.
Every end tasks must have Estimate Hours filled in.

Iteration Scoping - Sanjel

Sanjel will review the task in 业务分析ck log per iteration, adjust the iteration label after evaluate the total estimate.

Iteration Execution - Metashare

When an iteration starts, Metashare needs to move all tickets for this iteration to Todo column.
Team member picks up a ticket to work on, the ticket needs to be moved to In Progress column.
Team member needs to update the remain hours by the end of day. Remain hours is the latest estimate for the effort needed. It can be greater than original estimate.
Team member needs to accumulate the workhours when remain hours is updated in actual hours.
When a task is moved to Test column, the remain hours needs to be set as 0.
When a task is moved by to In Progress column when the test fails, the new remain hours should be estimated right away.
All non-development tasks can be add as an item in eService Sustainment Project without converting to an issue. The Estimate Hours, Remain Hours and Actual Hours rules apply.

Project Management

Metashare needs to monitor the total effort for current iteration to keep it under budget.
The final total hours will be the number for Sanjel payment, the details will be exported as attachment.

交付流程 - CassiniLaw/KnowledgeBase GitHub Wiki

项目开发流程

宏观项目流程

参与者

活动

Sanjel决策流程

MetaShare内部开发流程-需求分析及方案评估阶段

参与者

活动

MetaShare内部开发流程-设计实现及测试发布阶段

参与者

活动

开发流程（Ticket）

任务状态迁移

状态说明

任务链接

角色和职责

Process Review

Requirement Collection - Sanjel

Workload Planning - Sanjel

Iteration Planning - Sanjel & Metashare

Ticket triage - Sanjel

Analysis - Metashare

Design & Estimate - Metashare

Iteration Scoping - Sanjel

Iteration Execution - Metashare

Project Management

⚠️ GitHub.com Fallback ⚠️

交付流程 - CassiniLaw/KnowledgeBase GitHub Wiki

项目开发流程

宏观项目流程

参与者

活动

Sanjel决策流程

MetaShare内部开发流程-需求分析及方案评估阶段

参与者

活动

MetaShare内部开发流程-设计实现及测试发布阶段

参与者

活动

开发流程（Ticket）

任务状态迁移

状态说明

任务链接

角色和职责

Process Review

Requirement Collection - Sanjel

Workload Planning - Sanjel

Iteration Planning - Sanjel & Metashare

Ticket triage - Sanjel

Analysis - Metashare

Design & Estimate - Metashare

Iteration Scoping - Sanjel

Iteration Execution - Metashare

Project Management

⚠️ **GitHub.com Fallback** ⚠️

⚠️ GitHub.com Fallback ⚠️