敏捷开发管理规程_软件开发规程 - CSDN
  • 1.目的规范互联网软件产品开发项目管理过程,指导开展项目研发、管理等活动。2.适用范围本章程的作用范围为互联网软件产品开发立项至结项管理过程。1.对项目经理开展产品规划及设计活动以及项目管理手段和应遵循的...

    1.目的

    规范互联网软件产品开发项目管理过程,指导开展项目研发、管理等活动。

    2.适用范围

    本章程的作用范围为互联网软件产品开发立项至结项管理过程。

    1.对项目经理开展产品规划及设计活动以及项目管理手段和应遵循的开发流程提供了指导;

    2.对项目团队的日常管理活动及内容进行了指导;

    3.角色及职责定义

    项目经理:

    进行产品开发过程中的业务目标、进度、成本、质量控制。

    挑选项目团队并进行团队建设,激发、鼓舞和改进团队的生产效率。

    识别项目干系人,定期向干系人汇报,并作为团队和外部的接口,屏蔽外界对团队的干扰。

    确保项目中流程被遵循,组织、监督、培训项目各实践活动。

    产品策划

    确定产品的功能,拆分用户故事。

    需求功能确定优先级。

    接受或拒绝开发团队的工作成果。

    参与产品开发过程中的有关会议。

    UI

    根据用户故事,负责产品的功能交互及界面设计

    组织开展人机交互及用户体验,不断跟踪改进,提高产品表现力。

    参与产品开发过程中的有关会议。

    开发

    根据用户故事,负责产品的技术架构设计及功能开发

    评估、设计及维护产品相应模块,确保模块的稳定性、易用性、高效性。

    参加产品开发过程中的有关会议。

    测试

    根据用户故事,设计产品测试标准,确保产品品质满足市场需求。

    合理分配测试资源,组织产品测试并优化测试流程及测试标准,提高测试效率。

    编写产品测试用例,提交测试问题,编写测试总结报告,以测试角度来确定产品版本是否发布。

    4. 项目管理过程

    按照互联网软件产品项目开发过程,可将整个项目管理过程分为立项过程、规划过程、执行与监控过程、结项过程。下面分别阐述在每个阶段过程中该如何进行项目管理。

    4.1立项过程

    互联网软件产品开发项目的立项过程,通常是指从准备项目启动会到召开会议这个阶段,在立项过程中,需要完成项目目标,需求范围的初步确认,项目团队成员,其他资源的安排。

    确定项目的初步目标并达成共识

    对于项目目标,需要和干系人在以下几点上达成共识:

    项目的背景、目标用户、核心人员及产品定位是什么

    项目的资源投入预算是多少

    项目的资源投入是多少

    各人员在项目中扮演的角色和对项目的作用是什么

    准备启动会议文档

    文档内容包括:

    用户画像

    产品定位

    市场策略

    业务目标

    技术可行性

    研发成本预算

    路标规划

    召开项目启动会

    参加人员包括:

    管理层代表

    项目经理及项目团队

    其他干系人代表

    主要议题包括:

    申明项目目标范围及对组织目标的贡献。

    管理层正式任命PM,设定期望,统一思想

    文档内容的宣讲。

    与PM小组确定项目管理要求

    项目启动会完成后,需要与PM小组成员确定项目立项机制以及公司项目管理要求。

    4.2规划阶段

    在规划阶段,团队需要共同完成产品的版本规划,迭代计划

    版本规划

    从产品的关键特性列表中按照优先级规划产品每个版本需要完成哪些特性,在规划完成后需要在项目干系人内达成共识。具体可参考《版本规划样例》

    迭代如何划分

    迭代划分是指将特性列表拆分形成用户故事列表,并将其对应的主要任务划分到各个迭代中去,形成粗粒度的项目迭代计划。这个过程主要考虑以下几个因素:

    有些任务间是有依赖关系,某个任务的开始或结束是以另一个任务的开始或结束为前提,在划分时必须考虑这种前后依赖关系。

    在安排每个迭代的任务时,需要对各种因素进行综合考虑,如平衡每个迭代中任务的技术难度和价值差异。

    除了进行初步的迭代任务划分,还需要确定项目过程中迭代任务调整的规则,如迭代任务未完成时是将剩余任务延至下一迭代还是延长迭代周期。

    确定人员分工

    项目经理需要根据每个人员的能力和特点,初步拟定大致分工。在进行任务分工时需考虑以下因素:

    任务难度与人员能力相匹配,对于明显超出能力范围或过于简单的任务容易造成负面影响。

    耦合度高的尽量分配给同一个人,避免不必要的沟通消耗。

    鼓励团队内部“任务认领”,提高人员的工作积极性和主动性。

    确定迭代运行模式

    如一周迭代、两周迭代,每个迭代包含的工作内容等。

    具体的迭代计划可参考《迭代计划样例》

    制定其他辅助计划

    制定沟通计划、风险计划和质量计划是必要的,沟通计划主要包含以下几个方面:沟通对象、沟通方式、沟通频率即可,如:

    131031333864530.gif

    风险计划包括风险项、负责人、重要性、应对措施,如下:

    131032034951865.gif

    质量计划包括:bug分布满足何种条件可以发布,有几个致命bug必须停止开发新特性等。。

    搭建基础技术架构

    如果是一个全新的项目,需要重新开发系统框架,则这个工作应该在迭代0完成,否则会影响后期的工作开展。系统框架的每次改动必然会导致大量的重复工作量,从而给稳定的团队节奏带来很大的毛刺。

    3.3项目执行和监控过程

    迭代N的执行

    A、迭代N的需求细化

    考虑每个迭代需要完成的用户故事;

    用户故事需包含几个部分,工作量评估、功能性需求、非功能性需求。具体的可参考《用户故事模板及样例及拆分说明》

    用户故事编写完成后需要在团队内部进行需求评审,一方面是为了向团队成员解读该需求,另一方面团队成员也可在评审时给出指导性意见。

    B、测试用例评审

    测试人员根据用户故事要求编写对应的测试用例,并组织项目团队进行测试用例评审。根据评审意见修改测试用例

    C、开发

    将用户故事的需求开发的过程。

    D、开发自测

    在开发过程中,每完成一个功能点,都需要及时的进行开发自测并通知产品策划人员进行验收体验。

    E、验收

    开发完成后,产品策划需要对开发完成的成果进行验收,验证其是否符合用户故事的要求,验证通过后方可流到测试环节,否则需与开发详细讨论其不符合性,其验收的checklist可以参考《产品验收checklist及模板》

    F、测试和回归

    提交测试时,必须要有正确的版本。测试人员根据测试用例进行测试,在IT平台中提交测试bug,并根据测试的角度给出产品是否发布的意见,输出《测试报告》

    G、bug修改

    在IT平台中获取分配给自己的bug进行修改。

    H、showCase

    阶段性必须有可体验版本进行showCase.需要

    确定showCase时间:某个迭代开发、自测完成,准备提交测试前

    会议前1-2天发出体验版给到参与人员

    会议期间,由项目经理组织大家体验、反馈问题、记录问题。

    项目经理根据问题情况,与开发或产品确定问题的解决时间并发出会议纪要。

    I、灰度发布

    迭代一定版本后,由项目经理与团队共同决定是否需要进行灰度发布。

    监控方式

    每日站立会

    主持人轮流担任,负责控制节奏,记录问题,以备会后跟踪。

    每人讲自己昨天做了什么,有什么问题,今天的计划是什么;

    其他人了解别人的工作情况,并发现指出可能存在的问题。

    对于发现的问题,鼓励认领,其余由项目经理指定责任人。

    时间通常控制在15分钟内。

    会议期间,更新任务墙,任务墙样式如下:

    131033062616789.gif

    周报

    反馈项目计划的执行情况,强调本周工作要达成的目标

    暴露出项目的问题,特别是需要领导或其他团队需要协助的问题。

    周报可在IT平台中输出。

    月报

    反馈项目当月的执行情况,包括进度、人力及质量。

    反映项目存在的问题和风险。

    迭代回顾

    每人讲述本次迭代做的好的地方和不好的地方

    回顾上个迭代不好的地方,看看改进情况。

    让每个人发言。

    每次迭代回顾会议完成后,可更新燃尽图

    3.4结项阶段

    项目经理指导产品策划收集总结项目的产品运营数据,同时指导团队成员从自身角色进行总结,包括测试、开发、UI等。

    项目经理与项目团队成员给出项目总结报告,内容可参考《项目经验教训总结-项目团队》,《项目经验教训总结-项目经理》

    召开结项会议,各成员进行结项汇报。

    PM小组将过程文档和经验教训总结进行归档。

    展开全文
  • 前段时间给大家整理了敏捷开发的流程,最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际...


    前段时间给大家整理了敏捷开发的流程,最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际嵌入到公司的过程中可以参考下,不能照搬。

    1.  目的

    规范互联网软件产品开发项目管理过程,指导开展项目研发、管理等活动。

    2.  适用范围

    本章程的作用范围为互联网软件产品开发立项至结项管理过程。

    1.对项目经理开展产品规划及设计活动以及项目管理手段和应遵循的开发流程提供了指导;

    2.对项目团队的日常管理活动及内容进行了指导;

    3.  角色及职责定义

    项目经理:

    进行产品开发过程中的业务目标、进度、成本、质量控制。

    挑选项目团队并进行团队建设,激发、鼓舞和改进团队的生产效率。

    识别项目干系人,定期向干系人汇报,并作为团队和外部的接口,屏蔽外界对团队的干扰。

    确保项目中流程被遵循,组织、监督、培训项目各实践活动。

       

    产品策划

    确定产品的功能,拆分用户故事。

    需求功能确定优先级。

    接受或拒绝开发团队的工作成果。

    参与产品开发过程中的有关会议。

    UI

    根据用户故事,负责产品的功能交互及界面设计

    组织开展人机交互及用户体验,不断跟踪改进,提高产品表现力。

    参与产品开发过程中的有关会议。

    开发

    根据用户故事,负责产品的技术架构设计及功能开发

    评估、设计及维护产品相应模块,确保模块的稳定性、易用性、高效性。

    参加产品开发过程中的有关会议。

    测试

    根据用户故事,设计产品测试标准,确保产品品质满足市场需求。

    合理分配测试资源,组织产品测试并优化测试流程及测试标准,提高测试效率。

    编写产品测试用例,提交测试问题,编写测试总结报告,以测试角度来确定产品版本是否发布。

     

    4. 项目管理过程

    按照互联网软件产品项目开发过程,可将整个项目管理过程分为立项过程、规划过程、执行与监控过程、结项过程。下面分别阐述在每个阶段过程中该如何进行项目管理。

     

    4.1 立项过程

        互联网软件产品开发项目的立项过程,通常是指从准备项目启动会到召开会议这个阶段,在立项过程中,需要完成项目目标,需求范围的初步确认,项目团队成员,其他资源的安排。

         确定项目的初步目标并达成共识

         对于项目目标,需要和干系人在以下几点上达成共识:

         项目的背景、目标用户、核心人员及产品定位是什么

         项目的资源投入预算是多少

         项目的资源投入是多少

         各人员在项目中扮演的角色和对项目的作用是什么

         准备启动会议文档

         文档内容包括:

           用户画像

           产品定位

           市场策略

           业务目标

           技术可行性

           研发成本预算

           路标规划

        召开项目启动会 

         参加人员包括:

           管理层代表

           项目经理及项目团队

           其他干系人代表

         主要议题包括:

           申明项目目标范围及对组织目标的贡献。

           管理层正式任命PM,设定期望,统一思想

           文档内容的宣讲。  

         与PM小组确定项目管理要求

           项目启动会完成后,需要与PM小组成员确定项目立项机制以及公司项目管理要求。

     

    4.2  规划阶段

    在规划阶段,团队需要共同完成产品的版本规划,迭代计划

    版本规划

    从产品的关键特性列表中按照优先级规划产品每个版本需要完成哪些特性,在规划完成后需要在项目干系人内达成共识。具体可参考《版本规划样例》

    迭代如何划分

    迭代划分是指将特性列表拆分形成用户故事列表,并将其对应的主要任务划分到各个迭代中去,形成粗粒度的项目迭代计划。这个过程主要考虑以下几个因素:

        有些任务间是有依赖关系,某个任务的开始或结束是以另一个任务的开始或结束为前提,在划分时必须考虑这种前后依赖关系。

        在安排每个迭代的任务时,需要对各种因素进行综合考虑,如平衡每个迭代中任务的技术难度和价值差异。

        除了进行初步的迭代任务划分,还需要确定项目过程中迭代任务调整的规则,如迭代任务未完成时是将剩余任务延至下一迭代还是延长迭代周期。

    确定人员分工

    项目经理需要根据每个人员的能力和特点,初步拟定大致分工。在进行任务分工时需考虑以下因素:

        任务难度与人员能力相匹配,对于明显超出能力范围或过于简单的任务容易造成负面影响。

        耦合度高的尽量分配给同一个人,避免不必要的沟通消耗。

        鼓励团队内部“任务认领”,提高人员的工作积极性和主动性。

    确定迭代运行模式

            如一周迭代、两周迭代,每个迭代包含的工作内容等。

           具体的迭代计划可参考《迭代计划样例》

    制定其他辅助计划

        制定沟通计划、风险计划和质量计划是必要的,沟通计划主要包含以下几个方面:沟通对象、沟通方式、沟通频率即可,如:


        风险计划包括风险项、负责人、重要性、应对措施,如下:


     

    质量计划包括:bug分布满足何种条件可以发布,有几个致命bug必须停止开发新特性等。。

       搭建基础技术架构

        如果是一个全新的项目,需要重新开发系统框架,则这个工作应该在迭代0完成,否则会影响后期的工作开展。系统框架的每次改动必然会导致大量的重复工作量,从而给稳定的团队节奏带来很大的毛刺。

    3.3    项目执行和监控过程

    迭代N的执行

    A、迭代N的需求细化

    考虑每个迭代需要完成的用户故事;

        用户故事需包含几个部分,工作量评估、功能性需求、非功能性需求。具体的可参考《用户故事模板及样例及拆分说明》

        用户故事编写完成后需要在团队内部进行需求评审,一方面是为了向团队成员解读该需求,另一方面团队成员也可在评审时给出指导性意见。

    B、测试用例评审

        测试人员根据用户故事要求编写对应的测试用例,并组织项目团队进行测试用例评审。根据评审意见修改测试用例

    C、开发

        将用户故事的需求开发的过程。

    D、开发自测

        在开发过程中,每完成一个功能点,都需要及时的进行开发自测并通知产品策划人员进行验收体验。

    E、验收

        开发完成后,产品策划需要对开发完成的成果进行验收,验证其是否符合用户故事的要求,验证通过后方可流到测试环节,否则需与开发详细讨论其不符合性,其验收的checklist可以参考《产品验收checklist及模板》

    F、测试和回归

            提交测试时,必须要有正确的版本。测试人员根据测试用例进行测试,在IT平台中提交测试bug,并根据测试的角度给出产品是否发布的意见,输出《测试报告》

    G、bug修改

        在IT平台中获取分配给自己的bug进行修改。

    H、showCase

        阶段性必须有可体验版本进行showCase.需要

    确定showCase时间:某个迭代开发、自测完成,准备提交测试前

    会议前1-2天发出体验版给到参与人员

    会议期间,由项目经理组织大家体验、反馈问题、记录问题。

    项目经理根据问题情况,与开发或产品确定问题的解决时间并发出会议纪要。

     I、灰度发布

           迭代一定版本后,由项目经理与团队共同决定是否需要进行灰度发布。

     

    监控方式 

    每日站立会

        主持人轮流担任,负责控制节奏,记录问题,以备会后跟踪。

        每人讲自己昨天做了什么,有什么问题,今天的计划是什么;

        其他人了解别人的工作情况,并发现指出可能存在的问题。

        对于发现的问题,鼓励认领,其余由项目经理指定责任人。

        时间通常控制在15分钟内。

        会议期间,更新任务墙,任务墙样式如下:

     

    周报

        反馈项目计划的执行情况,强调本周工作要达成的目标

        暴露出项目的问题,特别是需要领导或其他团队需要协助的问题。

        周报可在IT平台中输出。

    月报

        反馈项目当月的执行情况,包括进度、人力及质量。

        反映项目存在的问题和风险。

    迭代回顾

        每人讲述本次迭代做的好的地方和不好的地方

        回顾上个迭代不好的地方,看看改进情况。

        让每个人发言。

        每次迭代回顾会议完成后,可更新燃尽图

    3.4    结项阶段

    项目经理指导产品策划收集总结项目的产品运营数据,同时指导团队成员从自身角色进行总结,包括测试、开发、UI等。

    项目经理与项目团队成员给出项目总结报告,内容可参考《项目经验教训总结-项目团队》,《项目经验教训总结-项目经理》

    召开结项会议,各成员进行结项汇报。

    PM小组将过程文档和经验教训总结进行归档。

    展开全文
  • 前段时间给大家整理了敏捷开发的流程,最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家...

    转:https://blog.csdn.net/wlly1/article/details/77716455
    感谢原文博主!


    前段时间给大家整理了敏捷开发的流程,最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际嵌入到公司的过程中可以参考下,不能照搬。

    1.  目的

    规范互联网软件产品开发项目管理过程,指导开展项目研发、管理等活动。

    2.  适用范围

    本章程的作用范围为互联网软件产品开发立项至结项管理过程。

    1.对项目经理开展产品规划及设计活动以及项目管理手段和应遵循的开发流程提供了指导;

    2.对项目团队的日常管理活动及内容进行了指导;

    3.  角色及职责定义

    项目经理:

    进行产品开发过程中的业务目标、进度、成本、质量控制。

    挑选项目团队并进行团队建设,激发、鼓舞和改进团队的生产效率。

    识别项目干系人,定期向干系人汇报,并作为团队和外部的接口,屏蔽外界对团队的干扰。

    确保项目中流程被遵循,组织、监督、培训项目各实践活动。

       

    产品策划

    确定产品的功能,拆分用户故事。

    需求功能确定优先级。

    接受或拒绝开发团队的工作成果。

    参与产品开发过程中的有关会议。

    UI

    根据用户故事,负责产品的功能交互及界面设计

    组织开展人机交互及用户体验,不断跟踪改进,提高产品表现力。

    参与产品开发过程中的有关会议。

    开发

    根据用户故事,负责产品的技术架构设计及功能开发

    评估、设计及维护产品相应模块,确保模块的稳定性、易用性、高效性。

    参加产品开发过程中的有关会议。

    测试

    根据用户故事,设计产品测试标准,确保产品品质满足市场需求。

    合理分配测试资源,组织产品测试并优化测试流程及测试标准,提高测试效率。

    编写产品测试用例,提交测试问题,编写测试总结报告,以测试角度来确定产品版本是否发布。

     

    4. 项目管理过程

    按照互联网软件产品项目开发过程,可将整个项目管理过程分为立项过程、规划过程、执行与监控过程、结项过程。下面分别阐述在每个阶段过程中该如何进行项目管理。

     

    4.1 立项过程

        互联网软件产品开发项目的立项过程,通常是指从准备项目启动会到召开会议这个阶段,在立项过程中,需要完成项目目标,需求范围的初步确认,项目团队成员,其他资源的安排。

         确定项目的初步目标并达成共识

         对于项目目标,需要和干系人在以下几点上达成共识:

         项目的背景、目标用户、核心人员及产品定位是什么

         项目的资源投入预算是多少

         项目的资源投入是多少

         各人员在项目中扮演的角色和对项目的作用是什么

         准备启动会议文档

         文档内容包括:

           用户画像

           产品定位

           市场策略

           业务目标

           技术可行性

           研发成本预算

           路标规划

        召开项目启动会 

         参加人员包括:

           管理层代表

           项目经理及项目团队

           其他干系人代表

         主要议题包括:

           申明项目目标范围及对组织目标的贡献。

           管理层正式任命PM,设定期望,统一思想

           文档内容的宣讲。  

         与PM小组确定项目管理要求

           项目启动会完成后,需要与PM小组成员确定项目立项机制以及公司项目管理要求。

     

    4.2  规划阶段

    在规划阶段,团队需要共同完成产品的版本规划,迭代计划

    版本规划

    从产品的关键特性列表中按照优先级规划产品每个版本需要完成哪些特性,在规划完成后需要在项目干系人内达成共识。具体可参考《版本规划样例》

    迭代如何划分

    迭代划分是指将特性列表拆分形成用户故事列表,并将其对应的主要任务划分到各个迭代中去,形成粗粒度的项目迭代计划。这个过程主要考虑以下几个因素:

        有些任务间是有依赖关系,某个任务的开始或结束是以另一个任务的开始或结束为前提,在划分时必须考虑这种前后依赖关系。

        在安排每个迭代的任务时,需要对各种因素进行综合考虑,如平衡每个迭代中任务的技术难度和价值差异。

        除了进行初步的迭代任务划分,还需要确定项目过程中迭代任务调整的规则,如迭代任务未完成时是将剩余任务延至下一迭代还是延长迭代周期。

    确定人员分工

    项目经理需要根据每个人员的能力和特点,初步拟定大致分工。在进行任务分工时需考虑以下因素:

        任务难度与人员能力相匹配,对于明显超出能力范围或过于简单的任务容易造成负面影响。

        耦合度高的尽量分配给同一个人,避免不必要的沟通消耗。

        鼓励团队内部“任务认领”,提高人员的工作积极性和主动性。

    确定迭代运行模式

            如一周迭代、两周迭代,每个迭代包含的工作内容等。

           具体的迭代计划可参考《迭代计划样例》

    制定其他辅助计划

        制定沟通计划、风险计划和质量计划是必要的,沟通计划主要包含以下几个方面:沟通对象、沟通方式、沟通频率即可,如:


        风险计划包括风险项、负责人、重要性、应对措施,如下:


     

    质量计划包括:bug分布满足何种条件可以发布,有几个致命bug必须停止开发新特性等。。

       搭建基础技术架构

        如果是一个全新的项目,需要重新开发系统框架,则这个工作应该在迭代0完成,否则会影响后期的工作开展。系统框架的每次改动必然会导致大量的重复工作量,从而给稳定的团队节奏带来很大的毛刺。

    3.3    项目执行和监控过程

    迭代N的执行

    A、迭代N的需求细化

    考虑每个迭代需要完成的用户故事;

        用户故事需包含几个部分,工作量评估、功能性需求、非功能性需求。具体的可参考《用户故事模板及样例及拆分说明》

        用户故事编写完成后需要在团队内部进行需求评审,一方面是为了向团队成员解读该需求,另一方面团队成员也可在评审时给出指导性意见。

    B、测试用例评审

        测试人员根据用户故事要求编写对应的测试用例,并组织项目团队进行测试用例评审。根据评审意见修改测试用例

    C、开发

        将用户故事的需求开发的过程。

    D、开发自测

        在开发过程中,每完成一个功能点,都需要及时的进行开发自测并通知产品策划人员进行验收体验。

    E、验收

        开发完成后,产品策划需要对开发完成的成果进行验收,验证其是否符合用户故事的要求,验证通过后方可流到测试环节,否则需与开发详细讨论其不符合性,其验收的checklist可以参考《产品验收checklist及模板》

    F、测试和回归

            提交测试时,必须要有正确的版本。测试人员根据测试用例进行测试,在IT平台中提交测试bug,并根据测试的角度给出产品是否发布的意见,输出《测试报告》

    G、bug修改

        在IT平台中获取分配给自己的bug进行修改。

    H、showCase

        阶段性必须有可体验版本进行showCase.需要

    确定showCase时间:某个迭代开发、自测完成,准备提交测试前

    会议前1-2天发出体验版给到参与人员

    会议期间,由项目经理组织大家体验、反馈问题、记录问题。

    项目经理根据问题情况,与开发或产品确定问题的解决时间并发出会议纪要。

     I、灰度发布

           迭代一定版本后,由项目经理与团队共同决定是否需要进行灰度发布。

     

    监控方式 

    每日站立会

        主持人轮流担任,负责控制节奏,记录问题,以备会后跟踪。

        每人讲自己昨天做了什么,有什么问题,今天的计划是什么;

        其他人了解别人的工作情况,并发现指出可能存在的问题。

        对于发现的问题,鼓励认领,其余由项目经理指定责任人。

        时间通常控制在15分钟内。

        会议期间,更新任务墙,任务墙样式如下:

     

    周报

        反馈项目计划的执行情况,强调本周工作要达成的目标

        暴露出项目的问题,特别是需要领导或其他团队需要协助的问题。

        周报可在IT平台中输出。

    月报

        反馈项目当月的执行情况,包括进度、人力及质量。

        反映项目存在的问题和风险。

    迭代回顾

        每人讲述本次迭代做的好的地方和不好的地方

        回顾上个迭代不好的地方,看看改进情况。

        让每个人发言。

        每次迭代回顾会议完成后,可更新燃尽图

    3.4    结项阶段

    项目经理指导产品策划收集总结项目的产品运营数据,同时指导团队成员从自身角色进行总结,包括测试、开发、UI等。

    项目经理与项目团队成员给出项目总结报告,内容可参考《项目经验教训总结-项目团队》,《项目经验教训总结-项目经理》

    召开结项会议,各成员进行结项汇报。

    PM小组将过程文档和经验教训总结进行归档。

    展开全文
  • DevOps敏捷开发流程

    2019-11-19 17:29:15
    近期根据我们DevOps开发团队敏捷开发项目的实践经验,将完整流程整理如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际过程中可以参考。 1. 目的 规范...

    近期根据我们DevOps开发团队敏捷开发项目的实践经验,将完整流程整理如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际过程中可以参考。

    1. 目的

    规范软件产品开发项目管理过程,指导开展项目研发、管理等活动。

    2. 适用范围

    本章程的作用范围为软件产品开发立项至结项管理过程。

    1.对项目经理开展产品规划及设计活动以及项目管理手段和应遵循的开发流程提供了指导;

    2.对项目团队的日常管理活动及内容进行了指导;

    3. 角色及职责定义

    Scrum Master——项目负责人、项目经理

    保护团队不受外界干扰,是团队的领导和推进者,负责提升 Scrum 团队的工作效率,控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化,他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念。

    Product Owner——产品负责人、产品经理

    确定产品的功能,拆分用户故事。

    需求功能确定优先级。

    接受或拒绝开发团队的工作成果。

    参与产品开发过程中的有关会议。

    UI

    根据用户故事,负责产品的功能交互及界面设计

    组织开展人机交互及用户体验,不断跟踪改进,提高产品表现力。

    参与产品开发过程中的有关会议。

    开发

    根据用户故事,负责产品的技术架构设计及功能开发

    评估、设计及维护产品相应模块,确保模块的稳定性、易用性、高效性。

    参加产品开发过程中的有关会议。

    测试

    根据用户故事,设计产品测试标准,确保产品品质满足市场需求。

    合理分配测试资源,组织产品测试并优化测试流程及测试标准,提高测试效率。

    编写产品测试用例,提交测试问题,编写测试总结报告,以测试角度来确定产品版本是否发布。

    4. Scrum中的产出物

    Product Backlog——Backlog 待开发项,积压的任务。

    产品 Backlog 包括了所有需要交付的内容,其内容根据业务需求的价值顺序排列,每个 Backlog 的优先级是可以调整的,需求是可以增减的,因此产品 Backlog 将根据不断增长来持续驱动维护。

    Sprint Backlog——Sprint 本意为“冲刺”,指迭代周期,长度通常是一至两周。

    在 Sprint 开始前,定义本次 Sprint 要讨论的“Sprint Backlog”,从中产生本次 Sprint 要完成的 “已定 Product Backlog”。

    已定 Product Backlog是 Sprint 计划会议的产物,它定义了团队所接受的工作量,在整个 Sprint 过程中它将保持不变。

    User Story、Task——用户故事、任务

    用 User Story 来描述 Sprint Backlog 里的项目,User Story

    是从用户的角度对系统的某个功能模块所作的简短描述。一个 User Story

    描述了项目中的一个小功能,以及这个功能完成之后将会产生什么效果,或者说能为客户创造什么价值。一个 User Story

    的大小和复杂度应该以能在一个 Sprint 中完成为宜。如果 User Story 太大,可能会导致对它的开发横跨几个

    Sprint,此时就应该将这个 User Story 分解。为了能够及时,高效地完成每个 Story,Scrum 团队会把每个 Story

    分解成若干个 Task。每个Task 的时间最好不要超过8小时,保证在1个工作日内完成,如果 Task

    的时间超过了8个小时,就说明Task的划分有问题,需要特别注意。

    障碍 Backlog——问题列表,积压的待处理事务。

    列举了所有团队内部和团队相关的和阻碍项目的进度的问题,Scrum Master 需要确保所有的障碍 Backlog 中的问题都已分配并可以得到解决。

    5. 项目管理过程

    按照产品开发过程,可将整个过程分为项目启动、需求设计、开发测试、上线、运营跟进。下面分别阐述在每个阶段过程中该如何进行。

    5.1 需求启动

    通常是从准备项目启动会到召开会议这个阶段,需要完成项目目标,需求范围的初步确认,项目团队成员,其他资源的安排。

    确定本次开发的初步目标并达成共识

    对于项目目标,需要和干系人在以下几点上达成共识:

    项目的背景、目标用户、核心人员及产品定位是什么

    各人员在项目中扮演的角色和对项目的作用是什么

    5.2 需求设计

    将确定的需求整理并输出WIKI文档及产品原型

    召开需求启动会

    参加人员包括:

    项目经理及项目团队

    其他干系人代表

    主要议题包括:

    申明本期开发目标范围及对组织目标的贡献。

    设定期望,统一思想

    文档内容的宣讲。

    5.3 开发测试

    A、迭代N的需求细化

    考虑每个迭代需要完成的用户故事;

    用户故事需包含几个部分,工作量评估、功能性需求、非功能性需求。

    用户故事编写完成后需要在团队内部进行需求评审,一方面是为了向团队成员解读该需求,另一方面团队成员也可在评审时给出指导性意见。

    B、测试用例评审

    测试人员根据用户故事要求编写对应的测试用例,并组织项目团队进行测试用例评审。根据评审意见修改测试用例

    C、开发

    将用户故事的需求开发的过程。

    D、开发自测

    在开发过程中,每完成一个功能点,都需要及时的进行开发自测并通知产品策划人员进行验收体验。

    代码提交可通过更新Jira任务的状态来关联Gitlab中代码的提交及状态更新。

    E、验收

    开发完成后,产品策划需要对开发完成的成果进行验收,验证其是否符合用户故事的要求,验证通过后方可流到测试环节,否则需与开发详细讨论其不符合性,其验收的checklist可做比较。

    F、测试和回归

    提交测试时,必须要有正确的版本。测试人员根据测试用例进行测试,在Jira中提交测试bug,并根据测试的角度给出产品是否发布的意见。

    G、bug修改

    在Jira中获取分配给自己的bug进行修改。

    H、预生产发布

    迭代一定版本后,在发布生产之前进行预生产测试。

    5.4 上线

    预生产测试通过后发布生产。

    5.5 运营跟进

    每日站立会

    组织者轮流担任,负责控制节奏,记录问题,以备会后跟踪。

    每人讲自己昨天做了什么,有什么问题,今天的计划是什么;

    其他人了解别人的工作情况,并发现指出可能存在的问题。

    对于发现的问题,鼓励认领,其余由项目经理指定责任人。

    时间通常控制在15分钟内。

    会议期间,更新任务墙,任务墙样式如下:

    周报

    反馈项目计划的执行情况,强调本周工作要达成的目标

    暴露出项目的问题,特别是需要领导或其他团队需要协助的问题。

    周报可在IT平台中输出。

    迭代回顾

    每人讲述本次迭代做的好的地方和不好的地方

    回顾上个迭代不好的地方,看看改进情况。

    6. 总结阶段

    项目经理指导产品经理收集总结项目的产品运营数据(度量指标),同时指导团队成员从自身角色进行总结,包括测试、开发、UI等。

    由PM将过程文档和经验教训总结进行归档并制定改进产品计划。



    作者:进击的桃纸
    链接:https://www.jianshu.com/p/bb383a11215b
    来源:简书
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    展开全文
  • 常用的敏捷开发模式

    2015-09-15 15:05:28
    速度是企业竞争致胜的关键因素,软体专案... 这正是Agile Process (敏捷的软体开发流程)于近年来兴起的主要原因,本文将介绍数种广为接受的软体开发流程,及其在运用上的建议。 1 Agile Process -敏捷开发流程  几
  • 敏捷软件开发宣言的第一个价值观指出“个体和互动 高于流程和工具”。“流程”对应的英文是“Process”,在有些地方也译为“过程”,下文中“流程”和“过程”为同义词。由于敏捷宣言和原则总共篇幅不长,并没有完全...
  • 一些著名的公司如Google, Microsoft和Yahoo和众多的中小公司都已经开始采用敏捷开发,尤其是Scrum。它们中的许多已经有了较长时间的经验。中国的许多开发团队这几年也在逐渐接受并应用这种开发模式。敏捷软件开发的...
  • 速度是企业竞争致胜的关键因素,软体专案的... 这正是Agile Process (敏捷的软体开发流程)于近年来兴起的主要原因,本文将介绍数种广为接受的软体开发流程,及其在运用上的建议。 1 Agile Process -敏捷开发流程
  • 敏捷开发智慧敏捷系列之一:序言 这是智慧敏捷系列的第一篇。(之一,之二,之三,之四,之五) 本文将解决各种敏捷中需要辩证思考的问题,包括:写文档还是不写文档?拥抱变更还是迭代期内无变更?持续交付的产品...
  • Scrum (英式橄榄球争球队), 软件开发模型是敏捷开发的一种,在最近的一两年内逐渐流行起来。Scrum的基本假设是:开发软件就像开发新产品,无法一开始就能定义软件产品最终的规程,过程中需要研发、创意、尝试错误,...
  • Lee, 技术顾问, IBM2006 年 8 月 15 日本 文来自于 Rational Edge:本文讨论了敏捷软件配置管理(Agile Software Configuration Management)的概念,一种适合于敏捷开发方法的 SCM 风格。文中还介绍了IBM Rational...
  • 敏捷的软件开发流程

    2009-08-08 03:04:00
    公司目前在开发上遇到了发展的瓶颈,大多数人都在考虑是否换一种开发平台,我认为原因不在于开发平台的好坏,关键还是在于开发管理的不规范性上,我觉得要解决一个公司的发展关键要一套好的管理规范,而一个好的开发...
  • 敏捷项目管理

    2019-08-07 18:26:15
    Scrum (英式橄榄球争球队), 软件开发模型是敏捷开发的一种,在最近的一两年内逐渐流行起来。Scrum的基本假设是:开发软件就像开发新产品,无法一开始就能定义软件产品最终的规程,过程中需要研发、创意、尝试错误,...
  • 敏捷软件需求管理

    2019-10-02 05:53:57
    title: 敏捷软件需求管理 date: 2017-10-23 10:29:39 tags: 需求管理 严格的来讲,这个标题的说法并不是很严肃,这篇文章的目的不是建立一个敏捷软件需求管理的流程,而是去探索一种需求管理的实践,解决现在工作...
1 2 3 4 5 ... 20
收藏数 700
精华内容 280
关键字:

敏捷开发管理规程