敏捷开发项目管理流程_scrum敏捷项目管理 开发流程 - CSDN
  • 敏捷项目管理框架及流程:在敏捷项目管理框架下可应用FDD(特征驱动开发)+ XP(极限编程)等方式
  • 敏捷开发项目管理规程

    千次阅读 2017-05-08 09:49:19
    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小组将过程文档和经验教训总结进行归档。

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

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

    展开全文
  • 敏捷开发流程

    千次阅读 2015-08-31 20:27:22
    随着带的团队做的事情越来越多, 发布的产品也越来越多, 关于软件开发流程的思考也越来越多.前段时间的高效虚拟自适应团队是在历经困难后磨练出来的方法的总结, 在此基础上,又经过几个版本发布的洗礼,对之前的认识...

    随着带的团队做的事情越来越多, 发布的产品也越来越多, 关于软件开发的流程的思考也越来越多.前段时间的高效虚拟自适应团队是在历经困难后磨练出来的方法的总结, 在此基础上,又经过几个版本发布的洗礼,对之前的认识又有了更新,更深入的看法. 在此特提炼出一套方法论, 供大家参考.

        一个软件从开发到上市(我们抛去维护部分), 一般需要经历阶段有 需求分析, 方案设计, 开发方案设计(包括概要设计, 详细设计等), 测试, 交付. 相信这些名词在软件工程中大家都能找得到, 那在这些过程中, 具体怎么实施呢?

        先看下面的流程图:

        卓有成效的敏捷开发流程

    一. 前期准备阶段

        有很多人不太重视前期的准备, 或者不太在意这方面的事情. 还有一个问题, 前期的准备要准备到什么程度?

        在我这里, 前期要做好三件事: 需求分析工作, 数据分析工作, 概要开发方案

        需求分析: 这部分就是我们的专业需求人员所要处理的事情. 主要负责把本次版本中的功能分析清楚.我们一直强调一点, "需求要明确", 不允许在需求文档中出现类似"跟XXX一样"等这种含混不清的字眼. 一般来讲, 分析到此业务的背景, 解决的问题, 用户的操作场景, 有这些信息有可以了.

        数据分析: 尤其在我们的计价软件中, 定额库是不可缺少的东西. 他是你程序能够运行的前提.对于数据如何制作, 用何种方式制作能,制作成什么格式是最省力的, 对开发, 对数据人员的加工量是最少的, 能否支持程序运行. 数据的存储的介质,格式决定了后面的开发方案

        开发方案分析: 目标达到能说清楚这件事怎么做就可以了. 内容格式方面可以自由扩展. 可以以下面的我的分析方案为参考:

       可参考我之前的博客:<<概要设计 --需求定义及描述方式>>

         http://blog.sina.com.cn/s/blog_48258fbe0100b54a.html

        卓有成效的敏捷开发流程

      图2(需求分析格式)

       

     二. 方案评审

        这一步是必须的. 让业务专家, 或者有经验的人给你把下关.这样对你的方案是一个很大的补充. 一个人的想法很难保证想的很全, 所以, 可以经过这个环节进一步充实你的方案.等这一步完成后, 你会形成项目列表. 就是针对每个开发功能, 拆解为详细的开发步骤, 并估算出工时, 如下图所示:

       卓有成效的敏捷开发流程

      图3(任务分析明细图)

    这样有助于你完成更为详细的开发计划. 一定要把任务项列细了, 越细, 对后面的进度控制就越有帮助.

     

    三. 项目启动会议

        正如我上上篇文章所说, 这个过程的好坏会对后面的开发任务有很大的影响.在这个过程, 重点是进行需求交底. 把前面的分析结果再加上已经评审通过的内容做成PPT, 给整个团队成员做讲解. 让团队中的每个成员都能知道

         我们很难保证让团队中的每一个人都能把所有的业务都理解的很清楚, 这是很难办到的, 但可以保证的是,当这个任务为某个人做的时候, 他会更专心的去听这块内容, 对于要执行者,他是最为关注的. 这样当需求交底完成的, 可能是大部分人对需求都有所了解, 理解度在20%~60%左右吧, 但执行此任务的人理解度应该能达到90%左右. 不用担心, 我们后面有办法让那些只理解20%的人也能掌握另外的没掌握的内容.

        当需求交底完成后, 就要开始进行方案交底了, 一般你会把之前分析的内容给大家讲出来, 并给出自己的一套默认的开发方案,然后由大家来评审这个方案如何.

        在这个过程,有开发, 有测试, 有需求, 有数据,都会从不同的角度去分析此问题.在讨论过程中,那些本来可能还是太懂的人, 结过这么讨论,就会更明白了许多. 这样, 其理解度会上长到50%应该是没问题的.做为主持者, 当你发现某些人确实不在状态时,可采用单独提问方式来让他加深记忆,这都是可以的.

        还有不太清楚业务的, 没关系, 下面我们就要根据前面敲定的方案来排定任务了. 因为已经经过了前面的方案讨论, 所以对开发的时间应该有所把握, 这时,对于不清楚业务而无法估算出时间, 或者为了估算出正确的时间以至不会让自己任务拖延的, 也要再熟悉一遍需求. 经过这样, 需求基本上就都搞清楚了.那最后就要出我们的作战图了:

       卓有成效的敏捷开发流程

       图4(作战图示例)

     

        之前也说过, 作战图的作用, 就是把事情盘点清楚(当然你也可以理解为"网络图"), 让每一个人所做的的任务都能具体到整个过程的位置, 地位, 清楚自己的任务在整个项目中处在什么样的关键位置上.

        这就是作战图的优势, 把团队的目标凝聚在一起.

    四. 迭代开发

       如上幅图所示, 我们有很多任务点, 任务项, 我如何能让在开发过程中, 让我们的团队更具有凝聚力, 更能向上呢, 答案就是自适应团队. 那如何才能实现呢.

        那就是短周期迭代. 我们可以把每一个任务做成一个小周期的迭代. 你这个迭代必须是有交付物的, 没有交付物, 那就没办法验证你的成果.

        在这个过程中, 我们只需要回答两个问题就足够了: 1. 能不能用. 2.有什么用. 当你进行完这个迭代后能回答这两个问题, 那么, 我就可以认为这个迭代完成, 可以进行一下个周期的迭代.

        以前我们在排定任务的时候, 总是在想着这个任务开发完成后再交由测试去测.这样相当于开发与测试在并行, 相互的交集就比较少. 开发只管开发的事, 完了后修改BUG就行了. 而测试呢, 只需求不停的测试版本就行了, 什么也不用管. 这样带来的问题就是修改BUG不及时, 有可能会出现开发成了这个功能好久后测试才提出这个问题, 开发再去修改. BUG越往后修改效率就越差的. 所以, 应该想办法让任务风险前移.

        当我给定一个开发任务时, 当他提交时, 应该是严格结过测试, 需求确认的. 测试的验证, 保证了该功能是"能用"的问题, 而需求的评审通过意味着该功能的"有用的", 自然也就是有价值的. 有用, 但不能用, 价值无法传递出去; 能用(可以使用), 但没用(此功能没有意义), 相当于做无用功. 所以在交付时, 一定是回答了"能不能用", "有什么用"之后的. 

        这样, 在排定任务时, 就把开发, 测试, 需求无形中绑定在一起了, 自适应何愁不来.

        在迭代开发中, 过程监控的方式手段很多, 比如我们常用的: 晨会, 夕会, 周会, 每日汇报. 项目可的可视化方式也有很多, 比如常用的任务燃烧图, BUG趋势图, 明细任务显示图等.   

        说到这不得不提下每日汇报的内容. 每日汇报, 就是把当前的工作内容以可视化的方式呈现出来. 有本书叫"一页纸项目管理", 里面介绍的方法就很好, 我又把它本地化了下, 显示的方式如下图所示:

     卓有成效的敏捷开发流程

      图5(每日汇报明细)

      点击查看大图

     

        这种方式能让你控制每一个小的迭代细节中, 能让你的控制更加周密. 大家可以不防试试.

     

     关于任务任务燃烧图, 他是从整体项目上对你当前产品的进度做出的评价, 有利于你及时调整项目中的瓶颈问题, 如下图所示的燃烧图: 他的做法就是总工时, 已剩余工时之前的关系来决定的.

        卓有成效的敏捷开发流程

     图7(进度控制超前的燃烧图)

    卓有成效的敏捷开发流程

     图8(进度失控的项目)

      结合这两种分析方式, 就可以看出项目中存在风险的项目是什么了.

    五. 集成测试

        在这个过程中, 最重要的反馈产品质量的就应该属BUG趋势图了, 可以反应出当前产品的BUG曲线, 来预测产品的质量. 关于BUG管理工具方面, 现在市面上也有很多, 比较有名的像BUGFree之类的, TD也不错的, 不要收费比较高.

     

    六. 最后就是发版了.

       自然要经过评审, 确认本次版本中依然存在的问题, 解决的问题内容.



    敏捷开发(Agile)是现在时髦的一个软件开发工程管理方式,其中的很多特征,例如scrum,pair coding,standup meeting等,有很多文章描述,这里我想聊一下敏捷开发中的文档和需求分析。


    在传统的软件工程中,无论是瀑布式还是所谓的V型模式或测试驱动模式,基本上需求分析都是要进行的第一步,然后是概要设计,详细设计,编码和单元测试。传统的软件工程对文档要求比较高,而很多公司也为自己做过的大量文档而骄傲,标榜为规范。对于文档量很少甚至没有的软件项目斥之为山寨。

    典型的,在这个项目过程中,需求分析占20-30%的时间,然后概要设计20%左右,详细设计也基本上20%左右,编码通常仅仅占10%-15%,剩余的时间机动给测试和需求变更。一旦需求变更——这个几乎是一定会发生的,根据长鞭效应,就会导致一连串的变更,设计,代码和测试,一切都随之变动。最后往往导致所谓的软件灾变。就是软件本身跟不上业务的变动,发布时间一再推迟。

    还有重要的一点,就我看到的程序员,几乎没有一个喜欢写文档的,通常把写文档归于无聊,无用的工作。大量的文档任务对士气是一个很大的打击。


    在敏捷开发中,号称拥抱变化,在一定程度上,能够降低需求变更和文档对项目的负面影响。

    首先,有两点,是我们看待需求的基础:

    第一,需求和设计是不能分开的,设计是要实现需求所要求的功能,需求也是在现在技术条件许可下的对期望值的折中。

    第二,绝大多数客户实际上并不了解他们的需要,也不清楚他们想要什么产品。这一点,我相信在传统开发过程中,为不断的需求变更头痛的人一定是有体会的。(不过这个你可不要对你的客户说哦,人家会不高兴的)


    于是,在敏捷开发中,需求不再是一个一次性的工作,而是一个伴随整个项目进行的,逐步细化的工作。

    我们在开发中,设计和需求是混在一起进行的。设计文档有两种,Feature Design,这个可以说是功能设计,也就是类似与原来软件工程中的需求分析吧,另外一种就是Technical Design, 也就是类似原来软件工程中概要设计。

    不过不要把Feature Design想象成传统软件工程中动辄几百页得需求分析,通常一个一年的项目,这个Feature Design也就10页左右的文档量而已,基本上就是非常粗略地大颗粒地描述要实现的功能而已。往往只描述要达到的结果和效果,对具体的UI,业务流程或者游戏角色等不做描述。

    至于Technical design呢,文档量也不大,基本上就是模块划分,接口模式(不是格式哦),关键算法和数据结构等等框架的设计。对具体的数据格式和类型不做定义。

    至于费时的详细设计,通常由程序员完成的,在敏捷开发中是真正省略了,是依靠代码的可读性来实现。敏捷的观点是:好的代码本身就是最好的文档。

    总之,文档已经很弱化了,基本上就是一个design spec,当然对于软件自身的可读性和注释要求要多一些


    敏捷开发讲究的轻量快速迭代。

    也就是需求和设计实际上在一起进行的,进行的同时几乎就开始写代码。例如有了一个模糊的需求,就有一个前进的方向,例如可以写一些框架代码,定义一些消息机制和自动机的状态等,写一些接口类,基类,制定设计模式等。

    进一步细一些的需求出来,就可以写一些派生类和执行逻辑。继续地,更进一步的需求就会表现在一些派生类上成员和成员函数的添加。就这样逐步细化。

    敏捷开发中有迭代(Iteration)和里程碑(milestone)的概念,实际上开发的过程是和用户不断交流的过程,每个迭代基本上指实现一个或几个小Features,甚至是Feature中的一个部分,但是敏捷开发要求保证每个迭代出来的产品是能够使用和能够测试的,这样就可以有基础和客户交流获得进一步详细的需求。换句话说,就是每一吃迭代的工作都有可能得到用户的认可。

    每个Milestone可以根据时间来划分,更多是按功能实现的需求的来划分,也就是每个milestone能够推出一个部分满足客户一些需求的产品。

    所以在开发中,敏捷开发是一个小量递增,小步快走的过程,需求是逐步细化,设计也是逐步深入的,代码也是伴随这个过程不断生长的。需求分析是作为一个交互的过程,是在整个过程中和design/coding/test混合在一起。

    在我们的开发过程中,很常见的情况是最初的feature design只实现了其中70%的功能,但是却另外添加了起初没想到的30%的功能。这也许就是敏捷说声称的“拥抱变化”吧。

    这个就是现在时髦的敏捷编程啊,我感觉不错,效率比以前高多了,员工士气也比以前高。毕竟绝大多数程序员是不喜欢写文档的。

    好一些的项目管理,往往能够把本项目的alpha测试和debugging的时间和下一个项目的design,甚至frame coding的阶段重合在一起,以最大限度提升效率,或者说榨取程序员的价值。


    http://blog.sina.com.cn/s/blog_6296cebc0100pybx.html


    敏捷开发(Agile development)

    目录

    [隐藏]

    敏捷开发概述

      敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

    敏捷开发的路线[1]

      Image:敏捷开发的路线图.jpg

      图:敏捷开发的路线图

      Test-Driven Development,测试驱动开发。

      它是敏捷开发的最重要的部分。在ThoughtWorks,我们实现任何一个功能都是从测试开始,首先对业务需求进行分析,分解为一个一个的Story,记录在Story Card上。然后两个人同时坐在电脑前面,一个人依照Story,从业务需求的角度来编写测试代码,另一个人看着他并且进行思考,如果有不同的意见就会提出来进行讨论,直到达成共识,这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控制键盘,编写该测试代码的实现。如果没有测试代码,就不能编写功能的实现代码。先写测试代码,能够让开发人员明确目标,就是让测试通过。

      Continuous Integration,持续集成。

      在以往的软件开发过程中,集成是一件很痛苦的事情,通常很长时间才会做一次集成,这样的话,会引发很多问题,比如 build未通过或者单元测试失败。敏捷开发中提倡持续集成,一天之内集成十几次甚至几十次,如此频繁的集成能尽量减少冲突,由于集成很频繁,每一次集成的改变也很少,即使集成失败也容易定位错误。一次集成要做哪些事情呢?它至少包括:获得所有源代码、编译源代码、运行所有测试,包括单元测试、功能测试等;确认编译和测试是否通过,最后发送报告。当然也会做一些其它的任务,比如说代码分析、测试覆盖率分析等等。在我们公司里,开发人员的桌上有一个火山灯用来标志集成的状态,如果是黄灯,表示正在集成;如果是绿灯,表示上一次集成通过,开发人员在这时候获得的代码是可用而可靠的;如果显示为红灯,就要小心了,上一次集成未通过,需要尽快定位失败原因从而让灯变绿。在持续集成上,我们公司使用的是自己开发的产品CruiseControl。

      Refactoring,重构。

      相信大家对它都很熟悉了,有很多很多的书用来介绍重构,最著名的是Martin的《重构》,Joshua的《从重构到模式》等。重构是在不改变系统外部行为下,对内部结构进行整理优化,使得代码尽量简单、优美、可扩展。在以往开发中,通常是在有需求过来,现在的系统架构不容易实现,从而对原有系统进行重构;或者在开发过程中有剩余时间了,对现在代码进行重构整理。但是在敏捷开发中,重构贯穿于整个开发流程,每一次开发者check in代码之前,都要对所写代码进行重构,让代码达到clean code that works。值得注意的是,在重构时,每一次改变要尽可能小,用单元测试来保证重构是否引起冲突,并且不只是对实现代码进行重构,如果测试代码中有重复,也要对它进行重构。

      Pair-Programming,结对编程。

      在敏捷开发中,做任何事情都是Pair的,包括分析、写测试、写实现代码或者重构。Pair做事有很多好处,两个人在一起探讨很容易产生思想的火花,也不容易走上偏路。在我们公司,还有很多事都是Pair来做,比如Pair学习,Pair翻译,Pair做PPT,关于这个话题,钱钱同学有一篇很有名的文章对它进行介绍,名为Pair Programming (结对编程)。

      Stand up,站立会议。

      每天早上,项目组的所有成员都会站立进行一次会议,由于是站立的,所以时间不会很长,一般来说是15-20分钟。会议的内容并不是需求分析、任务分配等,而是每个人都回答三个问题:1. 你昨天做了什么?2. 你今天要做什么? 3. 你遇到了哪些困难?站立会议让团队进行交流,彼此相互熟悉工作内容,如果有人曾经遇到过和你类似的问题,那么在站立会议后,他就会和你进行讨论。

      Frequent Releases,小版本发布。

      在敏捷开发中,不会出现这种情况,拿到需求以后就闭门造车,直到最后才将产品交付给客户,而是尽量多的产品发布,一般以周、月为单位。这样,客户每隔一段时间就会拿到发布的产品进行试用,而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁,每一个版本新增的功能简单,不需要复杂的设计,这样文档和设计就在很大程度上简化了。又因为简单设计,没有复杂的架构,所以客户有新的需求或者需求进行变动,也能很快的适应。

      Minimal Documentation,较少的文档。

      其实敏捷开发中并不是没有文档,而是有大量的文档,即测试。这些测试代码真实的反应了客户的需求以及系统API 的用法,如果有新人加入团队,最快的熟悉项目的方法就是给他看测试代码,而比一边看着文档一边进行debug要高效。如果用书面文档或者注释,某天代码变化了,需要对这些文档进行更新。一旦忘记更新文档,就会出现代码和文档不匹配的情况,这更加会让人迷惑。而在敏捷中并不会出现,因为只有测试变化了,代码才会变化,测试是真实反应代码的。这时有人会问:代码不写注释行吗?一般来说好的代码不是需要大量的注释吗?其实简单可读的代码才是好的代码,既然简单可读了,别人一看就能够看懂,这时候根本不需要对代码进行任何注释。若你觉得这段代码不加注释的话别人可能看不懂,就表示设计还不够简单,需要对它进行重构。

      Collaborative Focus,以合作为中心,表现为代码共享。

      在敏捷开发中,代码是归团队所有而不是哪些模块的代码属于哪些人,每个人都有权利获得系统任何一部分的代码然后修改它,如果有人看到某些代码不爽的话,那他能够对这部分代码重构而不需要征求代码作者的同意,很可能也不知道是谁写的这部分代码。这样每个人都能熟悉系统的代码,即使团队的人员变动,也没有风险。

      Customer Engagement ,现场客户。

      敏捷开发中,客户是与开发团队一起工作的,团队到客户现场进行开发或者邀请客户到团队公司里来开发。如果开发过程中有什么问题或者产品经过一个迭代后,能够以最快速度得到客户的反馈。

      Automated Testing ,自动化测试。

      为了减小人力或者重复劳动,所有的测试包括单元测试、功能测试或集成测试等都是自动化的,这对QA人员提出了更高的要求。他们要熟悉开发语言、自动化测试工具,能够编写自动化测试脚本或者用工具录制。我们公司在自动化测试上做了大量的工作,包括Selenium开源项目。

      Adaptive Planning,可调整计划。

      敏捷开发中计划是可调整的,并不是像以往的开发过程中,需求分析->概要设计->详细设计->开发 ->测试->交付,每一个阶段都是有计划的进行,一个阶段结束便开始下一个阶段。而敏捷开发中只有一次一次的迭代,小版本的发布,根据客户反馈随时作出相应的调整和变化。

      敏捷开发过程与传统的开发过程有很大不同,在这过程中,团队是有激情有活力的,能够适应更大的变化,做出更高质量的软件。

    敏捷开发的特点

      敏捷方法主要有两个特点,这也是其区别于其他方法,尤其是重型方法的最主要特征:

      (1)敏捷开发方法是“适应性”(Adaptive)而非“预设性” (Predictive)。

      这里说的预设性,可以通过一般性工程项目的做法理解,比如土木工程,在这类工程实践中,有比较稳定的需求,同时建设项目的要求也相对固定,所以此类项目通常非常强调施工前的设计规划。只要图纸设计得合理并考虑充分,施工队伍可以完全遵照图纸顺利建造,并且可以很方便地把图纸划分为许多更小的部分交给不同的施工人员分别完成。

      然而,在软件开发的项目中,这些稳定的因素却很难寻求。软件的设计难处在于软件需求的不稳定,从而导致软件过程的不可预测。但是传统的控制项目模式都是试图对一个软件开发项目在很长的时间跨度内做出详细的计划,然后依计划进行开发。所以,这类方法在不可预测的环境下,很难适应变化,甚至是拒绝变化。

      与之相反的敏捷方法则是欢迎变化,目的就是成为适应变化的过程,甚至能允许改变自身来适应变化。所以称之为适应性方法。      (2)敏捷开发方法是“面向人” (people oriented)而非“面向过程”(process oriented)。

      Matin Flower认为:“在敏捷开发过程中,人是第一位的,过程是第二位的。所以就个人来说,应该可以从各种不同的过程中找到真正适合自己的过程。”这与软件工程理论提倡的先过程后人正好相反。 (续致信网上一页内容)

      在传统的软件开发工作中,项目团队分配工作的重点是明确角色的定义,以个人的能力去适应角色,而角色的定义就是为了保证过程的实施,即个人以资源的方式被分配给角色,同时,资源是可以替代的,而角色不可以替代。

      然而,传统软件开发的这些方法在敏捷开发方式中被完全颠覆。敏捷开发试图使软件开发工作能够利用人的特点,充分发挥人的创造能力。

      敏捷开发的目的是建立起一个项目团队全员参与到软件开发中,包括设定软件开发流程的管理人员,只有这样软件开发流程才有可接受性。同时敏捷开发要求研发人员独立自主在技术上进行决策,因为他们是最了解什么技术是需要和不需要的。再者,敏捷开发特别重视项目团队中的信息交流,有调查显示:“项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接受它的人。”

    敏捷开发的价值观

      实际上敏捷开发运动在数年前就开始了,但它正式开始的标志是2001年2月的“敏捷宣言”(Agile Manifesto),这项宣言是由17位当时称之为“轻量级方法学家”所编写签署的,他们的价值观是:个人与交互重于开发过程与工具;可用的软件重于复杂的文档;寻求客户的合作重于对合同谈判;对变化的响应重于始终遵循固定的计划。

      个人与交互重于开发过程与工具的原因:一个由优秀的人员组成但使用普通的工具,要比使用优秀的工具但由普通人组成、紊乱的小组做得更好。多年来人们花了很多时间试图建立一种过程,以便把人当作机器上的一个可以替代的齿轮,但结果却并不成功。敏捷过程是承认每个人都有特定的能力(以及缺点)对之加以利用,而不是把所有的人当成一样来看待。更重要的是,在这样的理念下,几个项目做下来,每个人的能力都从中得以提高。这种人的能力的提高,对公司是无价之宝。而不至于把人当成齿轮,随着时间的推移,人的能力慢慢被消耗掉,最后变成留之无用、弃之可惜的尴尬人物。

      可用的软件重于复杂的文档的原因:可用的软件可以帮助开发人员在每次迭代结束的时候,获得一个稳定的、逐渐增强的版本。从而允许项目尽早开始,并且更为频繁的收集对产品和开发过程的反馈。随着每次迭代完成软件的增长,以保证开发小组始终是处理最有价值的功能,而且这些功能可以满足用户的期待。

      寻求客户的合作重于对合同的谈判的原因:敏捷开发小组希望与项目有关的所有团体都在朝共同方向努力,合同谈判有时会在一开始就使小组和客户出于争执中。敏捷开发追求的是要么大家一起赢,要么大家一起输。换句话说,就是希望开发小组和客户在面对项目的时候,以一种合作的态度共同向目标前进。当然,合同是必需的,但是如何起草条款,往往影响到不同的团体是进行合作式的还是对抗式的努力。

      对变化的响应重于始终遵循固定的计划的原因:敏捷开发认为对变化进行响应的价值重于始终遵循固定的计划。他们最终的焦点是向用户交付尽可能多的价值。除了最简单的项目以外,用户不可能知道他们所需要的所有功能的每个细节。不可避免地在过程中会产生新的想法,也许今天看起来是必需的功能,明天就会觉得不那么重要了。随着小组获得更多的知识和经验,他们的进展速度会比开始的时候期望值慢或者快。对敏捷开发来说,一个计划是从某个角度对未来的看法,而具有多个不同的角度看问题是有可能的。

    项目的敏捷开发方法

      敏捷方法很多,包括 Scrum、极限编程、功能驱动开发以及统一过程(RUP)等多种法,这些方法本质实际上是一样的,敏捷开发小组主要的工作方式可以归纳为:作为一个整体工作; 按短迭代周期工作; 每次迭代交付一些成果; 关注业务优先级; 检查与调整。下图是典型的敏捷过程总图,下面介绍其有关的特点。

      Image:敏捷过程总图.gif

      1、敏捷小组作为一个整体工作

      项目取得成功的关键在于,所有项目参与者都把自己看成朝向一个共同目标前进的团队的一员。“扔过去不管”的心理不是属于敏捷开发。设计师和架构师不会把程序设计“扔”给编码人员;编码人员也不会把只经过部分测试的代码“扔”给测试人员,一个成功的敏捷开发小组应该具有“我们一起参与其中的思想”, “帮助他人完成目标”这个理念是敏捷开发的根本管理文化。当然,尽管强调一个整体,小组中应该有一定的角色分配,各种敏捷开发方法角色的起名方案可能不同,但愿则基本上是一样的。第一个角色是产品所有者,他的主要职责包括:确认小组成员都在追求一个共同的目标前景;确定功能的优先等级,以便总是处理最有价值的功能;作出可以使项目的投入产生良好回报的决定。产品所有者通常是公司的市场部门或者产品管理部门的人员,在开发内部使用的软件的时候,产品所有者可能是用户、用户的上级、分析师,也可能是为项目提供资金的人。

      2、敏捷小组按短迭代周期工作

    在敏捷项目中,总体上并没有什么上游阶段、下游阶段,你可以根据需要定义开发过程在初始阶段可以有一个简短的分析、建模、设计,但只要项目真正开始,每次迭代都会做同样的工作(分析、设计、编码、测试。等等)。迭代是受时间框限制的,也就是说即使放弃一些功能,也必须结束迭代。时间框一般很短,大部分是 2~4周,在 Scrum中采用的是 30个日历天,也就是 4 周。迭代的时间长度一般是固定的,但也有报告说,有的小组在迭代开始的时候选择合适的时间长度。

      3、敏捷小组每次迭代交付一些成果

      比选择特定迭代长度更重要的,是开发小组在一次迭代中要把一个以上的不太精确的需求声明,经过分析、设计、编码、测试,变成可交付的软件(称之为功能增量)。当然并不需要把每次迭代的结果交付给用户,但目标是可以交付,这就意味着每次迭代都会增加一些小功能,但增加的每个功能都要达到发布质量。每次迭代结束的时候让产品达到可交付状态十分重要,但这并不意味着要完成发布的全部工作,因为迭代的结果并不是真正发布产品。假定一个小组需要在发布产品之前对软硬件进行为期两个月的“平均无故障时间”(MTBF)测试,他们不可能缩短这两个月的时间,但这个小组仍然是按照 4 周迭代,除了MTBF测试,其它都达到了发布状态。

      4、敏捷小组关注业务优先级

      敏捷开发小组从两个方面显示出他们对业务优先级的关注。首先,他们按照产品所有者制定的顺序交付功能,而产品所有者一般会按照组织在项目上的投资回报最大化的方式来确定优先级,并且把它组织到产品发布中去。要达到这个目的,需要综合考虑开发小组的能力,以及所需功能的优先级来建立发布计划。在编写功能的时候,需要使工能的依赖性最小化。如果开发一个功能必须依赖其它 3 个功能,那产品所有者这就很难确定功能优先级。功能完全没有依赖是不太可能的,但把功能依赖性控制在最低程度还是相当可行的。

      5、敏捷小组检查与调整

      任何项目开始的时候所建立的计划,仅仅是一个当前的猜测。有很多事情可以让这样的计划失效:项目成员的增减,某种技术比预期的更好或更差,用户改变了想法,竞争者迫使我们做出不同的反应,等等。对此,敏捷小组不是害怕这种变化,而是把这种变化看成使最终软件更好地反映实际需要的一个机会。每次新迭代开始,敏捷小组都会结合上一次迭代中获得新知识做出相应调整。如果认为一些因素可能会影响计划的准确性,也可能更改计划。比如发现某项工作比预计的更耗费时间,可能就会调整进展速度。也许,用户看到交付的产品后改变了想法,这就产生反馈,比如他发现他更希望有另一项功能,或者某个功能并不像先前看得那么重。通过先期发布增加更多的用户希望的功能,或者减少某些低价值功能,就可以增加产品的价值。迭代开发是在变与不变中寻求平衡,在迭代开始的时候寻求变,而在迭代开发期间不能改变,以期集中精力完成已经确定的工作。由于一次迭代的时间并不长,所以就使稳定性和易变性得到很好的平衡。在两次迭代期间改变优先级甚至功能本身,对于项目投资最大化是有益处的。从这个观点来看,迭代周期的长度选择就比较重要了,因为两次迭代之间是提供变更的机会,周期太长,变更机会就可能失去;周期太短,会发生频繁变更,而且分析、设计、编码、测试这些工作都不容易做到位。综合考虑,对于一个复杂项目,迭代周期选择4周还是有道理的。

      MIT Sloan Management Review(麻省理工学院项目管理评论)所刊载的一篇为时两年对成功软件项目的研究报告,报告指出了软件项目获得成功的共同因素,排在首位的是迭代开发,而不是瀑布过程。其它的因素是:

      1、至少每天把新代码合并到整个系统,并且通过测试,对设计变更做出快速反应

      2、开发团队具备运作多个产品的工作经验。

      3、很早就致力于构建和提供内聚的架构。

      从这个报告中所透露出的信息告诉我们,认真研究敏捷过程对软件项目的成功是非常有意义的,它的意义在于:

      1)给开发小组的自组织提供了机会

      经典项目管理就好比一个具备中央调度服务的航空管理系统,这个系统是自治的,而且是封闭的,但现实中更庞大的系统,似乎并不属于中央调度控制系统,但也同样也是有效的。假如我们开车到某个地方,我们可以任意选择所需要的路线,我们甚至不需要准确计算停车,只要我们遵守交通法规,驾驶员可以临时根据路况改变某个转弯点,在驾驶游戏规则的框架内,依照自身最大利益做出决策。成千上万的驾驶者,并不需要中央控制和调度服务,人们仅仅在简单的交通法规的框架内,就可以完成综合起来看是更庞大的目标,很多事情从管理的角度只要抓住关键点,并不需要多么复杂的规则,往往会更有效。随着系统复杂度的提高,中央控制和调度系统面临崩溃。仔细研究交通系统的特点,我们会发现这样的系统中独立的个体在一组适当的规则下运行,并不需要设计每个个体临时变更的方案,而每个个体只需要知道目标和大致的状况,他们完全可以利用自己的聪明才智来决定自己的行为。

      2)缩短了反馈通道

      敏捷过程有效运作的另一个原因是,它极大的缩短了用户与开发者、预测目标与实施状况、投资与回报之间的反馈回路。在面对不断变化的市场、业务过程以及不断发展的技术状态的时候,便需要有一种方法在比较短的时间内发展完善。事实上,所有的过程改进都不同程度的使用着戴明循环,以研究问题、测试解决方案、评估结果,进而根据已知的事实来进行改进,这就称之为基于事实的决策模式,我们都知道,这比前端预测的决策方式更加有效。

      3)易于集思广益

      敏捷过程能有效应用的另一个原因在于,它可以就一个问题集思广益。我们的经验告诉我们当一个问题发生的时候,总有某些人员知道问题所在,但他的观点却遭到忽视。例如航天飞机在起飞阶段发生爆炸,事后分析出了各种原因,但这种调查也提供给我们一个惊人的事实,就是部分工程师早就意识到这些潜在问题,却无法说服他人重视这个担忧。对这些事实的深入思考,促使我们研究我们应该采取何种管理系统,使前线工作人员的经验、观点及担忧得到充分的重视呢?

    对敏捷开发的误解

      误解一:敏捷对人的要求很高

      很多人在尝试实施敏捷时说:敏捷对人的要求太高了,我们没有这样的条件,我们没有这样的人,因此我们没法敏捷。可是,敏捷对人的要求真的那么高么? 软件归根到底还是一种创造性活动,开发人员的技术水平和个人能力对软件的质量还是起着决定性的作用,各种过程与方法只是帮助开发人员、测试人员等角色能够更好的合作,从而产生更高的生产力。不管用什么方法,开发人员的水平永远都是一个主要的因素。

      从另一个角度来看:过程和方法究竟能帮开发人员多大忙?对于技术水平较低的开发人员,敏捷方法和传统方法对他的帮助是差不多的,因此看不到显着的效果,甚至有些时候还有反效果;而随着开发人员技术水平的提高,敏捷方法能够解开对人的束缚,鼓励创新,效果也会越来越显着。

      敏捷对人的要求并不高,而且会帮助你培养各种所需的能力,当然前提是你处在真正敏捷的环境中。

      误解二:敏捷没有文档,也不做设计

      这个误解从XP开始就没有停止过,XP鼓励“在非到必要且意义重大时不写文档”。这里面提到的“必要且意义重大”是一个判断标准,并不是所有的文档都不写。例如,用户手册是不是“必要且意义重大”?这取决于客户的要求,如果客户不需要,那就不用写,如果客户需要,就一定要写;再如,架构设计文档要不要写?复杂要写,不复杂不用写。通常架构设计只需要比较简单的文档,对于有些项目,一幅简单的UML图就够了。因此,写不写,怎么写,都要根据这个文档到底有多大意义,产出和投入的比例,以及项目的具体情况决定。实际操作时可以让项目组所有人员表决决定,尽量避免由某一个人(比如lead)来决定。

      至于设计,XP奉行的是持续设计,并不是不设计。这实际上是将设计工作分摊到了每天的日常工作中,不断的设计、改善(重构),使得设计一直保持灵活可靠。至于编码前的预先设计,Kent Beck等人确实实行着不做任何预先设计的开发方式,但是对于我们这些“非大师”级开发人员,必要的预先设计还是需要的,只是不要太多,不要太细,要有将来会彻底颠覆的准备。

      误解三:敏捷好,其他方法不好

      有些人一提到敏捷就大呼好,只要是敏捷的实践就什么都好,而提到CMMI等方法就大呼不好,不管是什么只要沾上边就哪里都不好,似乎敏捷和其他方法是完全对立的。牛顿说过,我是站在了巨人的肩膀上。敏捷同样也吸取了其他方法论的优点,也是站在了巨人的肩膀上,敏捷依然保持了很多历史悠久的实践和原则,只是表现方式不同罢了。

      从另一个方面来看,方法本没有好环,好与坏取决于是否适合解决你的问题。每一种方法都有他最善于解决的问题和最佳的发挥环境,在需求稳定、软件复杂度相对不高的时代,瀑布模型也可以工作的很好,而敏捷恰好适用于变化快风险高的项目 - 这恰恰是现在很多项目的共性。

      因此选择一个方法或过程,并不是根据它是否敏捷,而应根据它是否适合。而要了解一个东西是否适合,还是要尝试之后才知道,任何没有经过实践检验的东西都不可信。

      误解四:敏捷就是XP(极限编程),就是Scrum

      XP 和Scrum只是众多敏捷方法中的两种,还有很多其他的敏捷方法。龙生九子各个不同,敏捷的这些方法看起来差别也是很大的,可是他们之所以被称为敏捷方法,就是因为他们背后的理念和原则都是相同的,这个原则就是《敏捷宣言》。学习敏捷不仅仅要学习实践,还要理解实践后的原则,不仅要理解怎么做,还要理解为什么这么做,以及什么时候不要这么做。

      即使将XP或Scrum完全的应用的你的项目中,也未见得就能成功,适合别人的东西未必就适合你。敏捷的这些实践和方法给了我们一个起点,但绝对不是终点,最适合你的方式还要由你自己在实际工作中探索和寻找。

      误解五:敏捷很好,因此我要制定标准,所有项目都要遵循着个标准

      没有哪两个项目是一样的,客户是不一样的,人员是不一样的,需求是不一样的,甚至没有什么可能是一样的。不一样的环境和问题,用同样的方法解决,是不可能解决的好的。方法是为人服务的,应该为项目团队找到最适合他们的方法,而不是先确定方法,再让团队适应这个方法。因此也不存在适合所有项目的统一的方法。任何企图统一所有项目过程的方法都是不正确的。

      同时,对于同一个团队,随着项目的进行,对需求理解的深入,对技术理解的深入,一开始适合项目的过程和方法也会渐渐的不适合。这时候也需要团队对过程进行及时的调整,保证项目的质量和效率。敏捷是动态的,而非静止不变的,因为这个世界本身就是变化的,在变化的世界使用不变的方法,是不现实的。银弹从来就没有过,在有限的将来也不会存在。


    展开全文
  • 敏捷开发中的需求管理大致分为三个阶段:需求调研,需求分析和需求确认。 需求调研阶段 产品立项后,产品经理便开始了和需求打交道的漫长过程。第一步就是需求的调研工作。需求调研的质量,会直接影响到后续产品...

    产品的源头是需求。一切伟大产品的实现都是从需求管理开始的。敏捷开发中的需求管理大致分为三个阶段:需求调研,需求分析和需求确认

    需求调研阶段

    产品立项后,产品经理便开始了和需求打交道的漫长过程。第一步就是需求的调研工作。需求调研的质量,会直接影响到后续产品设计的工作。产品经理可以从以下渠道来调研需求:

    (需求的来源)

    1.从产品定位出发

    从产品定位出发指的是,产品经理应当对自己的产品有足够认知和把控。简单来说,就是我的产品是为了满足哪些人的哪些需求而做的。每款产品必定有其核心价值,基于此考虑往往能得到一些核心需求,摒除价值不大的需求。

    2.用户反馈

    用户反馈包括用户直接的反馈和间接的反馈。直接反馈指的是用户直接提出需求,如在产品的交流论坛,官方QQ群等用户提出的建议和需求。另外,用户访谈、调查问卷等方式也是比较常用的搜集用户需求的方法。间接反馈指的是通过对用户行为习惯(如习惯、偏好、使用流程等)的分析来获取用户的需求信息。

    3.竞争对手情况

    知己知彼百战不殆。竞争对手的产品优势及不足也是产品经理需求来源的重要渠道。竞争对手好的功能我们如何借鉴优化,不足如何规避,在反复探讨中也能获得好的灵感。

    4.相关人反馈

    这里的相关人包括任何对产品需求有贡献的人。主要有运营人员、客服人员、市场人员和开发人员的反馈。

    产品经理在收集需求的过程中需要注意的一点是,尽量保证需求的精准性,一是用户意图的准确,一是语言描述的精炼,否则接下来的需求整理工作必然变得非常吃力。用户需求在敏捷开发中称之为用户故事(user story)。通常的格式为:作为一个<角色>,我想要<功能>,以便于<商业价值>。这也是产品研发中用户需求描述的最标准格式。

    (禅道项目管理软件中的用户需求界面)

    需求分析阶段

    通过需求调研,此时产品经理已经掌握了很多用户需求,但这并不代表所有的需求都会为产品所用。产品经理需要对这些需求进行整理、分析与设计。需求分析主要有两个目的,一是挖掘用户的真正需求,二是评估可行性。

    在做需求分析时,产品经理可以从以下几个角度着手:

    1.定位分析

    产品定位就是满足什么样的用户在什么条件下的什么需求。如,购物网站是为了满足购物需求,社交软件是为了满足社交的需要。购物网站的社交需求,社交产品的购物需求一定是与产品的核心服务不统一的。在做需求分析时一定要多问一问是不是符合产品定位?好需求但不一定是适合的需求,说的就是这个道理。

    2.场景分析

    场景分析指的是要考虑什么环境(时间、地点、情境)下什么类型的用户基于什么动机,希望达到什么目的而采取的一系列行为。比如:

    基于什么环境:办公室/家里/公共场合/上下班途中/户外/室内/白天/夜晚……

    基于什么用户:老人/小孩/男士/女士/上班族/学生/家庭主妇……

    基于什么动机:省钱/省时/省力/打发时间……

    想达到什么目的:彰显个性/炫耀/获得认可/变美/变瘦……

    3.深层挖掘

    挖掘每个需求产生的原因:用户基于什么原因才提出这个需求?

    挖掘每个需求背后隐含的需求:用户提出这个需求,是为了达到什么目的?

    挖掘每个需求的重要性:这个需求是必须的吗?如果没有这个需求会怎样?

    通过深层挖掘往往会发现比原始用户需求更加合理的方案,也能发现那些用户没有说出口和没有想到的需求,而往往这些需求才是用户的真正需求。

    4.价值评估

    价值评估是指这个需求需要多少开发资源或运营能力,技术难度如何,时间花费如何等。可以从四个维度考虑:

    广度:该需求能覆盖多少目标用户?

    频率:该需求的使用频率是怎样的?

    强度:该需求对用户来说有多强烈?

    时机:该需求是否符合产品目前的规划?在当前的资源情况下能否具备可行性?

    (产品经理需要不断提出这样的疑问)

    需求确认阶段

    经过分析整理,产品经理已经获得了初步的需求列表,接下来需要对这些需求设计用例场景,并进行用例描述、流程分析、角色分析等。如,模块如何划分、流程如何设计、业务如何转换等,一般通过绘制行动图、状态图、用例说明来配合呈现,并最终形成《产品需求说明书》。

    很多时候,用例分析工作是产品经理、架构师、设计师等共同协作完成的,因为除了要考虑技术能否实现,还需要考虑产品性能、响应时间、设计风格等非功能性的需求。

    最后才是需求确认工作,确认工作一般通过需求评审会议来实现,由于是最终确认,参会人员可能包括运营、开发、设计、测试等成员,共同对需求说明书中描述的需求的正确性、一致性、完整性、可行性、必要性、可测试性进行确认。

    (用户需求的特性)

    在正式需求评审之前,产品经理可以提前与项目负责人做需求初评,目的是提前收集问题,沟通是否有技术难点,确认开发成本及是否有考虑不全的逻辑漏洞等。

    由于敏捷开发是快速迭代的开发模式,敏捷开发中一般由产品经理根据需求优先级整理近期待做需求,进行需求评审。评审会议叫做发布计划会议,在会上,由产品经理或产品负责人负责讲解需求,并对其进行估算和排序,制定出这一期迭代要完成的需求列表。

    需要提的一点是,在需求确认中一定要考虑到需求变更的确认。当需要进行需求变更的时候,一定要有书面的文档和签字手续。由于流程复杂,现在很多研发团队直接通过在项目管理软件中来记录需求的变更。如,禅道中凡是对需求 标题、描述、验证标准和附件的修改,都应该走变更流程。

    (禅道中的需求变更流程)

    至此,需求管理工作基本完成,接下来便步入产品设计环节。但这并不代表产品经理工作的结束,需求评审完成后,还需要进一步和开发、设计了解实现细节以完善产品方案并跟踪需求的实现。

    需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性和完整性。在整个开发过程中,确保所有的实现是以用户需求为基础的。

    需求跟踪有两种方式,正向跟踪与逆向跟踪:

    正向跟踪:以用户需求为切入点,检查《产品需求说明书》或《需求规格说明书》中的每个需求是否都能在后继工作产品中找到对应点。

    逆向跟踪:检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处。

    (需求管理流程)

    需求管理恰如裁缝的量体裁衣,它直接关系到最终产品的成型。需求管理的过程,其实是从需求分析开始贯穿整个项目始终,力图实现最终产品同需求性的最佳结合。

     

    资料借鉴:

    需求管理-百度百科

    禅道项目管理—产品经理篇

    1QCDgHLaJYqKFO.gif

    展开全文
  • 敏捷开发项目管理

    千次阅读 2018-04-11 16:02:32
    以下文章转载自知乎,暗灭-京华九月秋近寒,浮沉半生影长单.暗灭京华九月秋近寒,浮沉半生影长单366 人赞同了该回答前言================================================1.本回答从属于“IT修真院”收藏夹系列第二...
  • 敏捷开发项目管理流程

    千次阅读 2017-09-08 13:30:27
    前段时间给大家整理了敏捷开发的流程,最近在整理敏捷开发项目流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际...
  • 互联网敏捷 Scrum 和项目管理

    万次阅读 2019-07-05 10:16:35
    互联网敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多...本场 Chat 着重介绍互联网 Agile 敏捷的模型以及常用项目管理流程等内容。 本场 Cha...
  • 项目管理另称为瀑布流管理
  • 传统项目管理 VS 敏捷项目管理

    千次阅读 2019-10-08 19:33:50
    随着软件行业的发展,传统的敏捷项目管理模式,已经不适应于当前互联网行业快速迭代快速开发的需求,从而衍生出了 “敏捷项目管理” 传统项目管理敏捷项目管理有什么不同呢? 传统 VS 敏捷 传统项目管理是计划...
  • 基于JIRA的敏捷项目管理,实战笔记:包含Scrum开发的步骤等
  • 现在许多开发团队在学习敏捷开发,根据调查,2018年有...如果你的团队已经在使用敏捷开发,或者在 2019 年计划采用敏捷方法,以下几个免费项目管理工具中,也许会有至少一款正是你所要找寻的。 1、MyCollab MyC...
  • 项目管理敏捷开发总结

    千次阅读 2018-04-13 01:15:16
    瀑布模型:简单说就是先定好需求和相关文档,然后构建框架,然后写代码,然后测试,最后发布个产品一旦文档需求确定,开发人员就按文档开发,直到产品开发完后,才会拿出来给客户。不过这种方式基本不适应现今快速...
  • 纵观整个游戏开发周期,大部分时间都是在赶赶赶,赶开发进度,赶Bug进度,赶发布进度。搞得交投烂额,搞得最后大家筋疲力竭,最终商务、策划、boss都觉得开发不给力。所以我们有必要,也有义务去采取一些措施来管理...
  • 文章来自开源中国(微信ID:oschina2013) ...在这次工具推荐中,我们从一些比较受欢迎的开源项目管理工具中摘取了支持敏捷的几项。 无论您的组织已经在使用敏捷,还是正计划使用,相信这 7 个开源的项目管理...
  • 我们可以使用Leangoo可视化地进行项目需求、任务、问题和文档的管理和协作,随时随地跟踪团队工作进展,是一款专业的研发项目管理软件,完整覆盖了研发项目管理的核心流程。 Leangoo工具的设计融入了先进的敏捷管理...
  • 谈谈软件项目管理——敏捷开发

    千次阅读 2013-03-21 10:30:29
    敏捷开发(Agile Development) 随着“敏捷”一词出现在越来越多的项目中,于是,敏捷开发本身也被赋与了越来越多的意义,而敏捷的真正内涵反而变得越来越模糊。如何迈出敏捷开发第一步?是按照敏捷宝典、操作指南...
  • 项目流程敏捷开发

    千次阅读 2018-07-20 10:41:17
    大家好,我是IT修真院深圳分院第8期的学员,一枚正直纯洁善良的PM,今天给大家分享以下知识点是修真院pm任务十一中的项目流程敏捷开发的小技巧 正常产品项目流程: 可以是产品经理创造需求;可以是“灵光一现”;...
  • 软件开发模式之敏捷开发(scrum)

    万次阅读 多人点赞 2018-08-08 19:25:59
    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 敏捷开发管理流程

    2019-03-12 09:25:34
    敏捷开发经常遇到的问题 流程难固化 范围不清晰 计划不合理 进度不准确 风险不透明 质量难保证 团队进步慢 解决上述问题的关键 梳理研发管理流程,明确关键活动的目的及操作方法 通过信息化手段,减少工作量,...
1 2 3 4 5 ... 20
收藏数 54,867
精华内容 21,946
关键字:

敏捷开发项目管理流程