2015-01-13 10:34:00 weixin_30267785 阅读数 36
  • 2019Java微服务架构2.0

    全网最新《微服务架构2.0》课程旨在推动并普及微服务架构思想,技术选型紧跟阿里系开源生态方案及服务网格等技术,规范微服务开发流程,让您真正体会互联网微服务开发的独特魅力。 本视频教程为之前《微服务解决复杂问题》的升级版本,主要升级亮点为:优化了课程学习顺序、升级了依赖版本号、摒弃了一些过时的技术、增加 Kubernetes + Istio 服务网格相关技术、完整的项目管理流程、完善的编程方法论(敏捷开发、十二要素应用、无状态应用等)及完整的项目案例。

    6311 人正在学习 去看看 千锋

最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,因此名字都叫成互联网软件产品开发项目管理规程,大家在实际嵌入到公司的过程中可以参考下,不能照搬。

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://www.cnblogs.com/xiangpiaopiao2011/p/4220631.html

2016-05-15 22:49:17 u014231523 阅读数 4059
  • 2019Java微服务架构2.0

    全网最新《微服务架构2.0》课程旨在推动并普及微服务架构思想,技术选型紧跟阿里系开源生态方案及服务网格等技术,规范微服务开发流程,让您真正体会互联网微服务开发的独特魅力。 本视频教程为之前《微服务解决复杂问题》的升级版本,主要升级亮点为:优化了课程学习顺序、升级了依赖版本号、摒弃了一些过时的技术、增加 Kubernetes + Istio 服务网格相关技术、完整的项目管理流程、完善的编程方法论(敏捷开发、十二要素应用、无状态应用等)及完整的项目案例。

    6311 人正在学习 去看看 千锋

一般产品人员进行过需求采集,分析,筛选后就会进行产品的设计。
在产品设计的过程中会产生PRD(Product Requirement Document 产品需求文档 ),如果是新产品或者在大公司一般还会有BRD ( Business Requirement Document 商业需求文档)和MRD (Market Requirement Document市场需求文档 )。
当写好PRD之后就会画出简单的线框图,在画好线框图后,为了后面更好的评估开发难度和开发时间,这时产品经理就会和开发经理和开发人员进行一次简单的会议,会议主要是介绍产品的功能点和交互。
这时开发人员进行给出开发难度,如果功能点太难以实现或者比较复杂且优先级不那么高的可能就会先实现主要功能(主要为了降低开发成本,看上线后用户的反应再进行深度开发同时也是为了把试错成本降低)。
没有问题后,产品就会让UI人员给出高保真原型图,同时开发人员进行开发。主要步骤如:

  1. 确定需求后,产品人员写PRD和线框图。
  2. 产品人员和开发人员进行讨论,评估开发难度和开发时间。(如果开发迭代时间固定,主要是评估难度)
  3. UI根据线框图和PRD设计出高保真原型图,同时开发人员进行开发,项目管理开始。
  4. 开发,测试,修改bug(开发中可能会出现需求更改的情况)
  5. 产品经理(项目经理)进项验收,没有问题上线。
    开发流程
    以前的开发大部分都是瀑布式开发,现在一把都采用敏捷开发。项目经理这个职位一般也是只有在稍大的公司会有,在创业的小公司一般有产品经理或者开发经理来担任。我们公司是由开发经理来担任开发进度管理,最后由产品经理验收。
    一般敏捷开发流程(每个公司的迭代周期不同,但大致流程相似。下面是两个星期一个迭代)如下:
    迭代

  6. 如果我们需要从第1周周一开始开发新的迭代(假定第5个迭代)。那么就要在上周的周三,产品人员和开发人员进行PRD评审,如有需要修改的地方进行修改。(第四个迭代开发持续中,UI按照优先级开始绘制已经确定需求的高保真图)

  7. 上周的周五产品进行修改后,再次和开发人员进行评审,确定没有需求没有大的变动。(UI设计持续,启动新的开发迭代(第5个迭代),进行上次迭代(第4个迭代)总结会议和新迭代开启会议),这时项目也会在进行拆分,比如按照epic-story-sprint-task的方式进行拆分。然后把这个迭代的任务拆分成各个小的task,然后进行人员分配。task的时间颗粒度一般不超过两天,分的太粗容易造成delay。task维护一般使用看板的形式,我们使用过的有Jira,kanbanflow,icafe等。(可以根据喜好使用,里面有相应的曲线图和燃尽图)
  8. 第一周周一上班,UI同学会给出一部分设计的好高保真图。这时服务端同学会根据安排好的优先级给出相应功能的接口文档。移动端的同学进行页面编码和设计。同时移动端同学会根据给出的接口文档先造一批假数据已备本地测试(如果有相应的接口测试工具会更好,我们是用的自己开发的接口测试沙箱,可以根据绑定的真假接口进行真假数据的测试)。同时,每天下班前都要有站会。站会主要说自己的三个问题:1.今天做了什么2.有什么问题3.明天做什么
  9. 开发持续进行,到第一周周四时,会先发个测试包,让测试人员进行测试。当然开发过程中也在不断测试。出现问题就进行修复,bug修复不再安排时间,不会在看板上建新的task来修复bug,开发任务继续。
  10. 到第二周的周三,要确保开发任务基本完成。然后发个测试包,进行测试。有bug进行修复。同时产品经理进行查看。同时和产品进行下的迭代(第6个迭代)的PRD评审。
  11. 到第二周的周五,再发个测试包,进行测试。有bug进行修复。产品经理验收。(没有问题,一般会在夜里凌晨1-2点上线。)上线后可能要安排人员进行值守,看有没有问题。同时周五还要和产品进行确认最终新的开发。同时开总结会议和新迭代启动会议,这两个会议也可能放在周一开。
    至此,一个迭代开发周期完成。
    注意:

    • 在开发的过程中,项目经理每天要通过看板或者询问开发人员的进度是不是符合原来的预订计划,如果出现delay现象,可能就要通过加班来把进度提上来。
    • 测试人员也要参与需求的评审,方便后面业务测试。
    • 开发人员要对自己写的代码负责人,写好后要进行代码review和自测,不能把没有测试的代码进行提交。
2016-08-12 13:38:43 diyal 阅读数 1485
  • 2019Java微服务架构2.0

    全网最新《微服务架构2.0》课程旨在推动并普及微服务架构思想,技术选型紧跟阿里系开源生态方案及服务网格等技术,规范微服务开发流程,让您真正体会互联网微服务开发的独特魅力。 本视频教程为之前《微服务解决复杂问题》的升级版本,主要升级亮点为:优化了课程学习顺序、升级了依赖版本号、摒弃了一些过时的技术、增加 Kubernetes + Istio 服务网格相关技术、完整的项目管理流程、完善的编程方法论(敏捷开发、十二要素应用、无状态应用等)及完整的项目案例。

    6311 人正在学习 去看看 千锋

##游戏敏捷开发项目管理之我见(三) 沟通

一、沟通过程中的思路
这里写图片描述
1、询问信息

* 明确要问什么,沟通一定要带着目的性,否则就是扯闲篇了。最好是列好条例。
* 信息是否完备,沟通的信息是否完备了,是否都得到自己想要的答案了。
* 信息是否准确?是否掺杂感情色彩,或是片面之词。

2、工作任务

* 安排的工作任务,明确需要对方知道的信息有哪些?安排一个模块开发,首先要让对方知道,这个模块是要干什么,什么时候完成,任务否否紧急,你的诉求是什么,是否有困难,困难的解决方案是什么,通过什么帮助或者调整可以解决这些这些困难?如果delay了怎么办等等。
* 确定对方已经理解,最好是通过反问的方式来确定
* 最重要的是明确任务完成的时间节点,开发者肯定会觉得这个时间没办法给出,毕竟在什么都没干的情况下,谁都不敢轻易给出具体时间。所以最好是在开发者给出的时间留出一定的弹性。

二、沟通技巧,说话的艺术

1、不要说“但是”,而要说“而且”
“我觉得这种想法很好,而且,如果在这里再稍稍改动一下的话,也许会更好……”

2、不要说“首先”,而要说已经
跟老板汇进度,“首先”一词出口,就让人觉得你还有很多事要做,却不会认为你已经做了一些事情了。而且这样的讲话会给人一种悲观的感觉,而往往项目开发需要良好积极乐观的氛围。
“是的,我已经相当熟悉这项工作了……”

3、不要说“错”,而要说“不对”
一个leader最让人钦佩的,是让成员甘心情愿付出,当然犯错误是在所难免的,所以我们必须要注意的是,不要说“错”,而是说“不对”,这样在语气上,更让人接受。总之不管什么情况,你要有跟成员一起面对错误的态度。
“你这样做的确是有不对的地方,咱们最好是为此承担责任”

4、不要说“仅仅”
在一次Bug修改会议,或是一个需求评审的时候,你是这样说的“这仅仅是我的一个建议……”
这样说是绝对不可以的,这样一来,你的想法、功劳包括你的价值都会大大贬值。本来利于项目,团队的一个主意,反而让同事觉得你的自信心不够。
“这就是我的建议”

5、不要说“本来”
你和你的谈话对象对某件事持不同看法,你却轻描淡写“我本来持不同看法的”。这样不但没突出你的立场,反而让你没了立场。类似还有“的确”和“严格来讲”
有威信的领导都是直截了当“对此我有不同看法”

6、不要说“务必”而是“请你”
7、不要再说“老实说”

2015-11-03 16:30:22 uxyheaven 阅读数 17959
  • 2019Java微服务架构2.0

    全网最新《微服务架构2.0》课程旨在推动并普及微服务架构思想,技术选型紧跟阿里系开源生态方案及服务网格等技术,规范微服务开发流程,让您真正体会互联网微服务开发的独特魅力。 本视频教程为之前《微服务解决复杂问题》的升级版本,主要升级亮点为:优化了课程学习顺序、升级了依赖版本号、摒弃了一些过时的技术、增加 Kubernetes + Istio 服务网格相关技术、完整的项目管理流程、完善的编程方法论(敏捷开发、十二要素应用、无状态应用等)及完整的项目案例。

    6311 人正在学习 去看看 千锋

敏捷开发知识体系整体框架

敏捷开发工程实践

项目管理

  • 迭代开发
  • 风险价值生命周期
  • 多级项目规划
  • 完整团队
  • 每日站立会议
  • 任务板
  • 燃尽图

需求管理

  • 需求订单
  • 业务流程草图
  • 用例驱动开发
  • 用户故事

架构

  • 演进的架构
  • 演进的设计
  • 基于组件的架构设计

开发

  • 结对编程
  • 测试驱动开发
  • 重构
  • 代码规范

测试

  • 单元测试
  • 并行测试
  • 测试管理

变更管理

  • 持续集成
  • 自动构建
  • 团队变更管理

敏捷开发管理实践描述

  • 定义和特征说明
  • 主要角色
  • 主要活动和最佳实践
  • 主要输入输出
  • 工作流程

敏捷开发工程实践描述

  • 定义和特征说明
  • 应用说明
  • 案例说明

敏捷开发核心价值观和原则

敏捷软件开发宣言

个体和互动 高于 流程和文档
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说, 尽管右项有其价值, 我们更重视左项的价值.

敏捷软件开发的核心价值观

敏捷开发的核心理念就是以最简单有效的方式快速打成目标, 并在这个过程中及时地响应外界的变化, 做出迅速的调整.

核心价值观

  • 以人为本
  • 目标导向
  • 客户为先
  • 拥抱变化

敏捷开发的原则

  • 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
  • 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
  • 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
  • 业务人员和开发人员必须相互合作,项目中的每一天都不例外。
  • 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
  • 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。
  • 可工作的软件是进度的首要度量标准。
  • 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
  • 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
  • 以简洁为本,它是极力减少不必要工作量的艺术。
  • 最好的架构、需求和设计出自自组织团队。
  • 团队定期地反思如何能提高成效,并依此调整自身的举止表现。

敏捷开发管理实践

Scrum

Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。

Scrum中的角色

“猪”角色

  • 产品负责人(Product Owner)
    • 通常由市场部门的人担任
  • 敏捷教练 (Scrum Master)
    • 通常由开发组组长担任
  • 开发团队 (Scrum Team)
    • 包括开发,需求,测试

“鸡”角色

  • 用户
    • 软件是为了某些人而创建!就像“假如森林里有一棵树倒下了,但没有人听到,那么它算发出了声音吗”,“假如软件没有被使用,那么它算是被开发出来了么?”
  • 利益所有者 (客户,提供商)
    • 影响项目成功的人, 但只直接参与冲刺评审过程。
  • 管理者
    • 为产品开发团体架起环境的那个人

主要活动和最佳实践

  • 迭代式软件开发
  • 两层项目规划 (Two-Level Project Planning)
  • 整体团队协作 (Whole Team)
  • 持续集成
  • 冲刺规划会议 (Sprint Plan Meeting)
  • 每日站立会议 (Sprint Daily Meeting)
  • 冲刺复审会议 (Sprint Review Meeting)
  • 冲刺回顾会议 (Retrospective Meeting)

scrum方法中得主要活动和交付件

主要输入输出

  • 产品订单(Product Backlog)
  • 冲刺订单(Spring Backlog)
  • 燃尽图(Burndown Chart)
  • 新的功能增量

工作流程

scrum方法全景图

项目管理过程

  • 在Scrum项目管理过程中产品负责人获取项目投资, 并对整个产品的成功负责.
  • 产品负责人协调个中利益干系人, 确定产品订单中初始的需求清单及其优先级, 完成项目商业价值分析和项目整体规划, 并任命合适的敏捷教练开展项目工作.

项目开发过程

在Scrum软件开发过程中, 每个冲刺就是较短的迭代, 通常为2~4周.

  • 在每个冲刺开始时, 产品负责人和敏捷教练通过召开冲刺规划会议和”两层项目规划”的最佳实践, 制定冲刺订单(类似迭代计划)
  • 产品负责人明确在本次冲刺中实现的需求清单, 响应的工作任务和负责人.
  • 在每个冲刺迭代中, 团队强调应用”整体团队协作”的最佳实践, 通过保持可持续发展的工作节奏和每日站立会议, 实现团队的自组织, 自适应和自管理, 高效完成冲刺工作.
  • 在每个冲刺结束时, 团队都会召开冲刺复审会议, 团队成员会在会上分别展示他们开发出的软件(或其他有价值的产品), 并从产品负责人和其他利益关系人那里, 得到反馈信息.
  • 在冲刺复审会议之后, 团队会自觉招开冲刺回顾会议, 回顾整个项目过程, 讨论哪些方法做的好, 哪些方面可以改进, 实现软件交付过程的持续, 自发的改进.

XP

OpenUp

Lean

敏捷开发工程实践

迭代式开发

敏捷迭代开发是指每次按照相同的开发方式短期的开发软件的部分, 或前期开发并不详尽的软件, 每次开发结束获得可以运行的软件, 以供各方干系人观测, 获得反馈, 根据反馈适应性的进行后续开发, 经过发福多次开发, 逐步增加软件部分, 逐步补充完善软件, 最终开发得到最后的软件. 每次反复开开发叫一次迭代, 在Scrum中成为Sprint, 中文常译为”冲刺”.

持续集成

持续集成(Continuous integration)是指当代码提交后, 马上启动自动编译, 自动部署金额自动化测试来快速验证软件, 从而尽快的发现集成错误.

多级项目规划

多级项目/产品规划, 在软件开发领域, 是指以迭代开发为基础, 形成多层次的, 逐步细化的项目或产品计划. 这些层层相关的项目/产品规划包括:

  • 项目/产品愿景
  • 项目/产品路线图
  • 版本发布计划
  • 迭代计划
  • 每日实现

项目/产品愿景

在计划阶段, 首先, 项目stakeholder, 项目/产品负责人将参与并组成工作组, 他们负责阐述项目的重要性, 给出项目成功失败的关键标准以及项目整体层面”完成”的定义; 在过程中, 可以利用形成项目愿景的一些个工具, 包括愿景盒子(Vison Box), 业务收益矩阵(Business Benefits Matrix), 项目范围矩阵(Scope Matrix), 滑动器(Slider), 成本收益矩阵(Cost/Benefit Matrix)等; 最后, 项目愿景需要使用尽量简要的文档固定下来, 并保证项目团队成员都能了解.该文档需要包括:

  • 当前的问题
  • 机会描述和理由(描述项目的重要性)
  • 项目的价值
  • 项目如何和组织的战略目标达成一致
  • 解决方案综述
  • 项目包含的关键功能
  • 项目必须服从的技术和约束条件
  • 项目范围
  • 项目的关键时间线
  • 项目收益分析
  • 项目和其他项目的依赖性
  • 项目的相关风险以及如何消除

项目/产品路线图

主要描述为了达到产品愿景而需要交付的关键功能和特性, 这些特性基本处于Epic和特性层面, 不包裹用户故事(User Story). 它从时间的维度来表述对愿景的支持和实现. 它从时间维度来表达对愿景的支持和实现. 当项目/产品需要发布多个版本时, 项目线路图就非常重要, 否则, 它和发布计划相同, 项目/产品线路图由项目负责人和项目经理维护, 并保持更新. 通常, 会形成路线图问题或幻灯片, 使用大图标显示重要的里程碑, 包含的功能和发布日期等, 让所有项目/产品相关人员都清楚产品各个组件的可能发布日程.

版本发布计划

版本发布计划由团队成员和项目/产品负责人共同制定, 并通过版本发布计划会议讨论通过. 它包括了当前版本需要交付的, 达成一致的关键功能, 并经过优先级排序, 可以包含EPIC和User Story. 版本发布计划中常使用的概念包括:故事点, 迭代团队速率和优先级排序. 通常, 项目/产品负责人提出本次发布的目标, 团队成员根据目标和功能特性的重要性对故事进行排序, 并依据团队速率觉得本次发布需要包含的故事点. 前几次版本发布使用估算值, 其准确性随着项目/产品的时间持续而逐步精确. 版本发布计划是剧本适应性可调整的计划, 会随着项目演进而改变.

迭代计划

迭代计划是对版本发布计划的再次细化, 同样由团队成员和项目/产品负责人共同制定, 并听过迭代计划会议讨论通过. 迭代会议负责两件事情:

  • 根据当前状态确定是否需要对版本计划做出更新
  • 为当前的迭代计划制定迭代计划

迭代计划中常使用的概念包括: 拆分Epic和User Story, 任务, 任务估算. 在迭代会议上, 成员首先根据当前的项目变化对发布计划进行更新, 然后根据更新后的, 重新排序过的故事制定当前迭代需要完成的故事, 并对这些故事进行详细的任务拆分. 成员在认领完任务后, 会对任务的实现时间做出估算, 估算值需要具体到这些估算信息可以方便任何成员追踪任务的进度.

每日实现

没事实现是团队成员完成任务的具体过程, 它依据任务估算值并根据任务最终实现情况更新该值. 在敏捷方法中, 使用每日站会议来报告进度. 通过15分钟的站立形式, 团队成员报告故事或者任务的完成,未完成状态, 而解决层面的问题则在会议之后处理.

完整团队

Scrum团队必须具备的三个完整性:

团队职责完整性

产品负责人(Product Owner)

  • 确定产品的功能。
  • 决定发布的日期和发布内容。
  • 为产品的收益(profitability of the product)负责。
  • 根据市场价值确定功能优先级。
  • 在30天内调整功能和调整功能优先级。
  • 接受或拒绝接受开发团队的工作成果

敏捷教练 (Scrum Master)

  • 负责监督整个Scrum项目进程, 调整开发计划
  • 保证团队资源完全可被利用并且全部是高产出的。
  • 保证各个角色及职责的良好协作。
  • 解决团队开发中的障碍。
  • 做为团队和外部的接口,屏蔽外界对团队成员的干扰。
  • 保证开发过程按计划进行,组织 Daily Scrum, Sprint Review and Sprint Planning meetings。
  • 需要知道什么任务已经完成,哪些任务已经开始,哪些新的任务已发现,和哪些估计可能已经发生变化. 根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的燃尽图
  • 需要找出阻碍Scrum的障碍和依赖, 根据优先级指定计划解决这些障碍
  • 个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清,或通过内部的沟通解决,或向管理层和HR寻求帮助解决
  • Scrum Master需要知道什么任务已经完成,哪些任务已经开始,哪些新的任务已发现,和哪些估计可能已经发生变化。Scrum Master需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的Burndown Chart。 Scrum Master还必须仔细考虑进展中的开放任务数,进展中的工作需要得到最小化,以实现精益生产率的收益。
  • Scrum Master需要找出阻碍Scrum的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决,有些则要团队之间的协调,还有的要管理层的介入来解决.

开发团队 (Scrum Team)

  • 具有不同特长的团队成员,人数控制在5-7个左右, 跨职能, 包括开发, 需求, 测试
  • 弱化分工, 每个人都参与设计, 开发与测试
  • 确定Sprint目标和具体说明的工作成果。
  • 在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
  • 向Product Owner演示产品功能。

团队素质完整性

  • 要具备很强的集体协作精神.
  • 要具备良好的沟通能力
  • 必须能积极主动的接受新的事物, 要具备创新能力
  • 要具备极强的自我管理能力和积极主动的精神

沟通的完整性

  • Sprint启动会
  • 每日站立会议
  • Sprint回顾会

案例

验收测试驱动开发ATDD

TDD 只是开发人员的职责,通过单元测试用例来驱动功能代码的实现。ATDD在准备实施一个功能或特性之前,首先团队需要定义出期望的质量标准和验收细则,以明确而且达成共识的验收测试计划(包含一系列测试场景)来驱动开发人员的TDD实践和测试人员的测试脚本开发。面向开发人员,强调如何实现系统以及如何检验。

  • 挑选用户故事
  • 为故事写测试
  • 实现测试
  • 实现故事

结对编程

结对编程可以看做是一种敏捷化的Code Review

新结对编程

两位程序员新成结对小组, 每人一台电脑, 坐在临近的工位上, 两人合作完成一组功能(可以是两个或多个独立的模块)的设计, 代码实现. 但对已某一个模块来说设计和代码是分开的, 一个人负责设计, 另一个人负责写代码, 对于其他模块则反之.

确定冲刺计划

定义和说明

  • 目的: ST和PO共同决定在接下来的冲刺周期内的目标以及那些功能和任务需求要完成
  • 主要角色: ST, PO, SM
  • 主要输入: Product backlog, 团队的能力
  • 主要输出: Sprint Backlog

冲刺会议分两个部分
1. 解决本次冲刺要完成哪些需求
2. 解决这些选择的需求要如何被完成

案例

故事点估算

故事点是表述一个用户故事, 一项功能或一件工作的整体大小的一种度量单位. 数值本身不重要, 重要的是这些故事之间对比体现相对大小.

计划扑克

  • 开始时, 美人得到一张扑克, 上面有任务点(?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, 无穷).?代表无法估算, 无穷代表故事太大
  • 开始对故事进行估算, 先由PO介绍这个故事的描述. 接着澄清问题
  • 每一个组员从扑克中挑选可以代表这个故事的卡片, 集体亮牌
  • 最高分和最低分的组员像团队做出解释
  • 全组成员自由讨论几分钟
  • 重新打分, 直到全组统一.

敏捷估算2.0(Agile Estmating 2.0)

  • PO像团队成员介绍每一个用户故事, 确保所有需求相关的问题都在做估算前得到解决
  • 整个团队参与游戏: 一次由一人将一个故事卡片放在合适的位置, 规模小的在左,规模大的在右, 一样大的竖排. 轮流移动故事卡片, 直到整个团队都认同白板上故事卡的排序为止.
  • 团队将故事点(Story Point)分配给每个故事.

需求订单(Product Backlog)

记录用户需求的列表, 包括产品所有需要的特征.

  • 每一项包含了需求标题, 描述, 重要性, 故事点(或其他表示大小的数字)
  • 需求订单式开放的, 团队每个成员都可以编写和维护
  • 在整个项目开放生命周期内, 需求订单需要不断维护, 管理与跟踪需求变化

燃尽图

在项目完成之前, 对需要完成的工作的一种可视化表示. 燃烧故事点.每天更新一次

  • 具备可视性
  • 具备风险预估, 提醒团队目前完成情况
  • 具备可估量, 直接显示当前还需要的时间.

燃尽图常见问题

每日站立会议(Daily Scrum)

每日站立会议旨在让团队统一目标, 协调内部问题的解决, 绝非进度汇报.一般不超过15分钟.

  • 我们上次开会后你都干了什么
  • 在我们下次开会之前你要做什么
  • 每个你负责的、正在做的任务还剩下多少时间
  • 你的工作被阻碍了吗

任务板(Task board)

  • 为项目团队提供一个便利的工具用于管理他们的工作
  • 是团队成员对本冲刺的工作一目了然

任务板通常设立与项目团队日常工作的公共空间的一面墙上. 任务板上得信息包括该冲洗计划完成的用户故事和相应的任务, 分别卸载卡片上, 按照一定的方式贴在任务板上(To Do, In Progress, Done). 团队成员通过调整任务卡得位置和上面的信息反映任务的执行情况.

用户故事卡

每张卡片记录一条用户故事, 故事点.

任务卡

每个用户故事卡片通对应的多个任务卡. 每张卡片记录一条任务, 到目前为止完成该任务所需的工作量(小时).随着进展试试更新.

任务板的使用

用户故事

作为<某个角色>, 我希望<实现何种功能>, 以便<带来何种价值>.

如: 作为一个用户, 我希望在每次退出系统前得到是否保存的提示, 以便所有内容都被成功存储了.

测试驱动开发(TDD)

先开发测试用例, 然后再开发代码

2017-08-30 15:21:43 wlly1 阅读数 3958
  • 2019Java微服务架构2.0

    全网最新《微服务架构2.0》课程旨在推动并普及微服务架构思想,技术选型紧跟阿里系开源生态方案及服务网格等技术,规范微服务开发流程,让您真正体会互联网微服务开发的独特魅力。 本视频教程为之前《微服务解决复杂问题》的升级版本,主要升级亮点为:优化了课程学习顺序、升级了依赖版本号、摒弃了一些过时的技术、增加 Kubernetes + Istio 服务网格相关技术、完整的项目管理流程、完善的编程方法论(敏捷开发、十二要素应用、无状态应用等)及完整的项目案例。

    6311 人正在学习 去看看 千锋


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

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

敏捷开发

阅读数 2744

没有更多推荐了,返回首页