2017-05-08 09:53:58 qq_21586623 阅读数 1176

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小组将过程文档和经验教训总结进行归档。

2009-11-25 21:38:00 xingguo822 阅读数 236

 Scrum (英式橄榄球争球队), 软件开发模型是敏捷开发的一种。

 

  Scrum的基本假设是:

    开发软件就像开发新产品,无法一开始就能定义软件产品最终的规程,过程中需要研发、创意、尝试错误。Scrum 将软件开发团队比拟成橄榄球队,

有明确的最高目标,熟悉开发流程中所需具备的最佳典范与技术,具有高度自主权,紧密地沟通合作,以高度弹性解决各种挑战, 确保每天、每个阶段

都朝向目标有明确的推进。

 

   Scrum模型的一个显著特点就是响应变化,它能够尽快地响应变化。下面的图片使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素(内部和外部因素)的复杂度增加,项目成功的可能性就迅速降低。

    
    下图是Scrum模型和传统模型的对比:

    

 

1 Scrum 开发流程通常以 30 天(或者更短的一段时间)为一个阶段,由客户提供新产品的需求规格开始,开发团队与客户于每一个阶段开始时挑选该完成的规格部分,开发团队必须尽力于 30 天后交付成果,团队每天用 15 分钟开会检查每个成员的进度与计划,了解所遭遇的困难并设法排除。

--短迭代(渐进、迭代式的开发并始终维护可交付的产品,相对瀑布是的模型能够适应需求的变化,降低风险)与快速沟通(减少沟通成本,快速解决问题)

 

2 在每个迭代(sprint)开始前要开一个sprint planning meeting,将当前迭代周期的需求(blocking)划分成更小的模块,并确定各模块的优先级,并详细的讨论各个功能模块的详细设计并给出时间估算以小时计。

 

3 daily scrum meeting:每天15分钟的站立会议,主要交流3个方面,完成了什么,遇到什么困难,将要做什么--提高沟通效率,快速解决障碍

 

4 Sprint review meeting:在每个Sprint结束后,这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为4小时。

 

5 Sprint retrospective meeting:对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为3小时。

 

二)实施Scrum的过程简单介绍

    1) 将整个产品的backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力物力条件可以完成的。

    2) 召开sprint planning meeting,划分,确定这个Sprint内需要完成的任务,标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的,并不是按人天计算。

    3) 进入sprint开发周期,在这个周期内,每天需要召开Daily Scrum meeting。

    4) 整个sprint周期结束,召开Sprint review meeting,将成果演示给Product Owner.

    5) 团队成员最后召开Sprint retrospective meeting,总结问题和经验。

    6) 这样周而复始,按照同样的步骤进行下一次Sprint.

    整个过程如下图所示
    

 

 

敏捷软件开发宣言:

  • 个体和交互     胜过 过程和工具
  • 可以工作的软件 胜过 面面俱到的文档
  • 客户合作       胜过 合同谈判
  • 响应变化       胜过 遵循计划

持续的交付有价值的产品

欢迎需求的变化

开发期间,业务人员与开发人员零障碍的沟通(泡在一起)

鼓励面对面的交流

不断的关注优秀的技术和好的设计

简单即是根本

每过一段时间,团队要在改进效率方面进行反省和总结并加以改进

 

当软件开发需求的变化而变化时,软件设计会出现坏味道,当软件中出现下面任何一种气味时,表明软件正在腐化。

  • 僵化性: 很难对系统进行改动,因为每个改动都会迫使许多对系统其他部分的其它改动。
  • 脆弱性: 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
  • 牢固性: 很难解开系统的纠结,使之成为一些可在其他系统中重用的组件。
  • 粘滞性: 做正确的事情比做错误的事情要困难。
  • 不必要的复杂性: 设计中包含有不具任何直接好处的基础结构。
  • 不必要的重复性: 设计中包含有重复的结构,而该重复的结构本可以使用单一的抽象进行统一。
  • 晦涩性: 很难阅读、理解。没有很好地表现出意图。

敏捷开发依靠适应变化来获得价值,在设计上不做总体固定的假设,始终关注可扩展性和可维护性,保持结构的简单,并使用单元测试作为支持。这保持了设计的灵活性和易理解性,团队依靠这种灵活性持续的改进设计,以保证每次迭代之后产品更加适应最新的需求。

 

敏捷开发保持软件的新鲜与面向对象的设计原则是分不开的

  • 单一职责原则(SRP)
    就一个类而言,应该仅有一个引起它变化的原因。--从封装变化的角度来看类的设计
  • 开放-封闭原则(OCP)
    软件实体应该是可以扩展的,但是不可修改。--程序的抽象层的修改时封闭的,对具体的实现层的扩展时开放的
  • Liskov替换原则(LSP)
    子类型必须能够替换掉它们的基类型。
  • 依赖倒置原则(DIP)
    抽象不应该依赖于细节。细节应该依赖于抽象。--最基本的原则了,以便利用多态实现开闭原则
  • 接口隔离原则(ISP)
    不应该强迫客户依赖于它们不用的方法。--尽可能开放最少的接口给客户
  • 重用发布等价原则(REP)
    重用的粒度就是发布的粒度。
  • 共同封闭原则(CCP)
    包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响,则将对该包中的所有类产生影响,而对于其他的包不造成任何影响。
  • 共同重用原则(CRP)
    一个包中的所有类应该是共同重用的。如果重用了包中的一个类,那么就要重用包中的所有类。
  • 无环依赖原则(ADP)
    在包的依赖关系图中不允许存在环。
  • 稳定依赖原则(SDP)
    朝着稳定的方向进行依赖。
  • 稳定抽象原则(SAP)
    包的抽象程度应该和其稳定程度一致。

敏捷设计是一个过程,不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。

 

2019-04-03 14:02:49 sunyaowu315 阅读数 161

转: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小组将过程文档和经验教训总结进行归档。

2017-08-30 15:21:43 wlly1 阅读数 3958


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

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小组将过程文档和经验教训总结进行归档。

2009-05-26 15:42:00 changemyself 阅读数 1369

敏捷软件开发模型--SCRUM

一 什么是Scrum?

Scrum (英式橄榄球争球队), 软件开发模型是敏捷开发的一种,在最近的一两年内逐渐流行起来。

Scrum的基本假设是:

开发软件就像开发新产品,无法一开始就能定义软件产品最终的规程,过程中需要研发、创意、尝试错误,所以没有一种固定的流程可以保证专案成功。Scrum 将软件开发团队比拟成橄榄球队,有明确的最高目标,熟悉开发流程中所需具备的最佳典范与技术,具有高度自主权,紧密地沟通合作,以高度弹性解决各种挑战,确保每天、每个阶段都朝向目标有明确的推进。

Scrum 开发流程通常以 30 天(或者更短的一段时间)为一个阶段,由客户提供新产品的需求规格开始,开发团队与客户于每一个阶段开始时挑选该完成的规格部分,开发团队必须尽力于 30 天后交付成果,团队每天用 15 分钟开会检查每个成员的进度与计划,了解所遭遇的困难并设法排除。

二 Scrum较传统开发模型的优点

Scrum模型的一个显著特点就是响应变化,它能够尽快地响应变化。下面的图片使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素(内部和外部因素)的复杂度增加,项目成功的可能性就迅速降低。
Water Fall

下图是Scrum模型和传统模型的对比:
     Scrum VS Water Fall  

三 Scrum模型

一)  有关Scrum的几个名词

backlog: 可以预知的所有任务, 包括功能性的和非功能性的所有任务。

sprint:一次跌代开发的时间周期,一般最多以30天为一个周期.在这段时间内,开发团队需要完成一个制定的backlog,并且最终成果是一个增量的,可以交付的产品。

sprint backlog:一个sprint周期内所需要完成的任务。

scrumMaster: 负责监督整个Scrum进程,修订计划的一个团队成员。

time-box: 一个用于开会时间段。比如每个daily scrum meeting的time-box为15分钟。

sprint planning meeting: 在启动每个sprint前召开。一般为一天时间(8小时)。该会议需要制定的任务是:产品Owner和团队成员将backlog分解成小的功能模块,  决定在即将进行的sprint里需要完成多少小功能模块,确定好这个Product Backlog的任务优先级。另外,该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。

Daily Scrum meeting:开发团队成员召开,一般为15分钟。每个开发成员需要向ScrumMaster汇报三个项目:今天完成了什么? 是否遇到了障碍? 即将要做什么?通过该会议,团队成员可以相互了解项目进度。

Sprint review meeting:在每个Sprint结束后,这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为4小时。

Sprint retrospective meeting:对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为3小时。



二)实施Scrum的过程简单介绍

1) 将整个产品的backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力物力条件可以完成的。
2) 召开sprint planning meeting,划分,确定这个Sprint内需要完成的任务,标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的,并不是按人天计算。
3) 进入sprint开发周期,在这个周期内,每天需要召开Daily Scrum meeting。
4) 整个sprint周期结束,召开Sprint review meeting,将成果演示给Product Owner.
5) 团队成员最后召开Sprint retrospective meeting,总结问题和经验。
6) 这样周而复始,按照同样的步骤进行下一次Sprint.

整个过程如下图所示:
Scrum



The diagrams in this article are all from web site: http://www.controlchaos.com.  Thanks very much!

 

敏捷软件开发宣言

                 我们 正通过亲身实践 以及 帮助他人实践,揭示更好的软件开发方法

                              通过这项工作 ,我们认为:

                                                        人和交互              重于                 过程和工具

          可以工作的软件             重于                面面俱到的文档

                       客户合作               重于                 合同谈判

随时应对变化            重于                 遵循计划

虽然右项也有其价值,但我们认为左项更加重要。

原则

1.       我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。

2.       我们欢迎需求的变化,即使到了开发后期。敏捷过程能够驾驭变化,为客户创造竞争优势。

3.       经常交付可以工作的软件 ,从几个星期到 几个月,时间间隔越短越好。

4.       在整个项目开发期间,业务人员和开发人员必须朝夕工作在一起。

5.       围绕斗志昂扬的人构建项目。给他们提供所需的环境和支持,并且信任他们能够完成工作。

6.       在团队内部,最有效率也最有效果的信息传达方式,就是面对面的交谈。

7.       可以工作的软件是 进度主要的度量标准。

8.       敏捷过程提倡可持续开发。出资人、开发者和用户应该总是保持稳定的开发速度。

9.       对卓越技术和良好设计的不断追求有助于提高敏捷性。

10.   简单——尽量减少工作量的艺术是至关重要的。

11.   最好的架构、需求和设计都源于自我组织的团队。

12.   每隔一定时间,团队都要总结如何更右效率,然后相应地调整自己的行为。

极限编程实践

   完整团队            用户故事            短交付周期       验收测试            结对编码            测试驱动开发 

   集体所有权       持续集成            可持续的开发速度        开放的工作空间             计划游戏

   简单设计            重构      隐喻

避免设计的臭味

·         僵化性 rigidity ——设计难以改变。

·         脆弱性(fragility)——设计易于遭到破坏。

·         顽固性(immobility)——设计难以重用。

·         粘滞性(viscosity)——难以做正确的事情。

·         不必要的复杂性(needless complexity)——过分设计。

·         不必要的重复(needless repetition)——滥用鼠标进行复制、黏贴。

·         晦涩性(opacity)——混乱的表达。

设计原则

·         单一职责原则(SRP):一个类应该只有一个发生变化的原因。

·         开放封闭原则(OCP):软件实体应该对扩展开放,对修改关闭。

·         Liskov替换原则(LSP):子类型(subtype)必须能够替换掉它的基类型(base type)。

·         依赖倒置原则(DIP):a. 高层模块不应该依赖于低层模块。二者都应该依赖于抽象。b.抽象不应该依赖于细节。细节应该依赖于抽象。

·         接口隔离原则(ISP):不应该强迫客户程序依赖并未使用的方法。

·         DRYDon’t repeat yourself Principle。通过抽取公共部分放置在一个地方避免代码重复。

·         封装变化 Encapsulate what varies)。

·         面向接口编程而不是实现(Code to an interface rather than to an implementation)。

·         优先使用组合而非继承(Favour Composition Over Inheritance)。

包和组件的设计原则

  • 重用-发布等价原则(Reuse-Release Equivalence Principle, REP):重用的粒度就是发布的粒度。
  • 共同重用原则(Common-Reuse Principle, CRP):一个组件中的所有类应该是共同重用的。如果重用了组件中的一个类,那么就要重用组件中的所有类。
  • 共同封闭原则(Common-Closure Principle, CCP):组件中的所有类对于同一种性质的变化应该是共同封闭的。一个变化若对一个封闭的组件产生影响,则对该组件中的 所有类产生影响,二对于其他组件则不造成任何影响。
  • 无环依赖原则(Acycle-Dependencies Principle, ADP):在组件的依赖关系图中不允许存在环。
  • 稳定依赖原则(Stable-Dependencies Principle, SDP):朝着稳定的方向进行依赖。
  • 稳定抽象原则(Stable-Abstraction Principle, SAP):组件的抽象程度应该与其稳定程度一致。
没有更多推荐了,返回首页