敏捷开发项目管理规程_敏捷项目的效率和规范 - 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小组将过程文档和经验教训总结进行归档。

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

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

    展开全文
  • 敏捷开发(Agile Development) 随着“敏捷”一词出现在越来越多的项目中,于是,敏捷开发本身也被赋与了越来越多的意义,而敏捷的真正内涵反而变得越来越模糊。如何迈出敏捷开发第一步?是按照敏捷宝典、操作指南...

    敏捷开发(Agile Development) 随着“敏捷”一词出现在越来越多的项目中,于是,敏捷开发本身也被赋与了越来越多的意义,而敏捷的真正内涵反而变得越来越模糊。如何迈出敏捷开发第一步?是按照敏捷宝典、操作指南或是教父语录,还是因地制宜、因项目定方法?完成所有这些工作后,我们就真的“敏捷”了吗?

      一、前言

      Agile是指企业能够对外部环境做出速捷、有效的反应,是未来企业的必备素质。21世纪企业面临的竞争环境将是一个不断变化、不可预测的环境。由于高新技术的出现和更迭越来越快,产品的生命周期日益缩短,企业要面对这样的新的竞争环境,抓住市场机遇,迅速开发出用户所需要的产品,就必须实现敏捷反应。

      狭义地讲,敏捷企业就是将柔性的先进制造技术、熟练掌握生产技能、有知识的劳动力以及促进企业内部和企业之间的灵活管理三者集成在一起,对千变万化的市场机会做出快速、有效的响应。敏捷企业强调人、组织和技术的有机结合。通过这三者的紧密结合,敏捷企业可以发挥最佳的整体效益。评价一个企业敏捷性的具体指标是时间、成本、稳健性(Robustness)和适应范围。对敏捷企业的广义理解,可以认为敏捷企业是一个CIMS(计算机集成制造系统)、动态联盟、并行工程、仿真制造、高素质员工等多方面的系统集成,是一个基于CIMS、在CMS基础上发展起来的一个更高层次的集成大系统。

      二、变味的敏捷

      敏捷是大家在一起高效率地工作,清除所有沟通上的障碍,关注于增值的活动,从而使得开发更加成功。敏捷是大家肩并肩地工作,而不是什么都通过文档。敏捷是管理者积极地参加到项目管理中而不是整天去写状况报告,用那个来监督到底发生了什么事情。敏捷是开发人员和涉众(项目开发中涉及的从需求到最后交付的各种人员)在一起制定实际的计划,而不是用复杂的微软Project去制定一些几乎没人看的进度表。

      公平地说,很难设想敏捷术能如何发挥作用,尤其是在一些软件开发本身都问题重重的传统组织中,被误导过的敏捷更是难以帮上什么忙。

      敏捷开发,看到过这个词时,很多人一直没有什么深刻的体会,也没有仔细去研究到底什么才是敏捷开发。而一直在很多人的思想里,敏捷开发的印象就是,开发速度比较快。没错,做互联网的,快确实是一个制胜的法宝,那么敏捷开发似乎也就是在互联网应用的开发中最适合的方法了。那么敏捷开发中的参与者应该是什么状态?这似乎成了一直以来困扰很多管理者的严重问题。可以说,在敏捷开发中,并没有觉得有多敏捷,进度一拖再拖,问题一个接着一个,让我觉得我们是在进行慌乱开发。为什么会这样?

      另外,关于实施敏捷的效果也是充满置疑之声。我们经常看到一些号称Agile的国内项目,按照菜谱、操作指南和教父语录的提示,采用了许多花哨的技巧和实践(做法),是啊,表面上确实Agile了,那么结果呢?项目还是不能按时完成,甚至严重超支和超时,这能叫“敏捷”吗?

      三、敏捷十戒

      1、天报制度

      就算是进行远程开发或是两地使用开发,项目组的成员每天至少碰一次,不管是当面的,还是通过其它方式,如通过电话、email、Skype或其它。进行敏捷开发的时间,任何团队都不能以任何理由进行孤立的开发。

      2、例会制度

      即使每天通过Email给主管汇报工作,但有时主管还是无法及时准确的掌握项目组成员的状况及工作量。此时,通过每周一小时左右的例会将会有效的解决此问题。通过例会,大家面对面的就某些问题进行共同的探讨与讨论,找到共同的解决方案。

      3、版本控制

      如果没有一台干净的电脑来进行团队代码管理的话,则很有可能导致代码的混乱。而每天只须花很少的时间,哪怕一天一次,进行及时的数据提交与代码提交,则可以有效的保证团队之前代码的同步及代码的备份。

      4、需求失灵

      即使手里拿着30页且客户进行了签字的需求说明,有可能仍然不知所措。相对起那些良好的设计、精确的分析等,与客户持续的沟通、及时的反馈、不断的演示这些工作显得更加的有效果。可以有效的获得需求变化,减少误解,更加准确的把握用户的需求。

    5、单元测试是QA的工作

      很多开发人员,甚至一些高级的软件开发人员,对于单元测试没有足够的认识,在行动上也没有足够的注意。大家都一致的认为那是QA的事情。就开发人员来讲,单元测试应该是一种白箱测试,能从功能上充分的测试软件的功能性。而对QA来说,只能是一种黑箱测试,无法深入的去分析代码的优势,只是从用户的角度进行功能上的测试而已。

      6、质量保证是QA的责任

      自从有了质量管理这个词以及后来产生的质量管理部门后,很多开发人员就理所当然的认为质量保证是QA的责任了。其实每一个人都需要对软件的质量负责,特别是开发人员。Bug越最早发现,那么解决它的成本就越低。

      7、项目进度风险控制

      也许一个项目需要18个月左右才能完成,但在没完成之前,谁也无法进行比较准确的时间估计。无法确定需要多长的时间进行设计、编码及软件组件的组合。但进行项目设计、实现及融合的人应该相对比较准确的掌握与估计项目的时间。因此,需要进行项目进度的风险控制,风险总是存在的,但要进行有力与及时的控制。充分意识到项目中可能会存在的风险因素,在制定计划时预留一定的时间,如果在项目进行中出现了没有想到的问题,根据其重要性,考虑压后解决,要在计划的时间内把计划的事情完成好,并为后续解决问题争取更多的时间。

      8、架构师身体力行

      很多软件架构师基本上不写代码,这也许是好事。软件架构师嘛,当然是比较高级的,他们对环境、语言、类库方面都可能比软件开发人员要更加在行,但他们一般不编码。这样的架构师是危险的,特别是那些基本上不与首席开发人员进行沟通或咨询的架构师,离项目失败可能已经不远了。

      9、牵一发而动全身

      很多时间,在功能上做了一个很小的变动,往往导致花费好几天的功夫来进行软件的集成与整合。如果没有持续的整合、及时的回归测试、可靠的整体设计,一些看起来非常微小的修改都有可能导致很大的麻烦。

      10、加大管理执行力

      目前项目中,开发者或者说参与人的状态是混乱的,或者说是慌乱的。那问题在哪里呢?是工作流程出了问题?不应该啊!在项目启动前已经定了一个看似美好的流程,而且是经过参与人讨论一致通过的。那么问题在哪里呢?原来是沟通、传达出了问题,执行力不够。那么,就必须加大执行力,今日事今日毕,这是必须的。

      另外,在一些产品级的软件开发中,觉得要实施敏捷式开发,我觉得也有一个不好解决的问题:没有具体的客户!没有具体的客户,那你的沟通去哪里寻找呢?一般的做法也是给一些有兴趣的用户发布Alpha版本,或者是beta版本的软件。可是当软件都到了Alpha/beta版本的时候,软件还有迭代的余地吗?未必!从我个人理解的角度来看,敏捷开发的适用范围还是很有局限性的。个人认为最适合使用敏捷开发的软件必须要有非常明确的客户才能进行,而有明确客户的情况以定制型软件为主。所以,我觉得最适合用敏捷方式开发的软件应该是——定制软件!

      四、小结

      记得Jim Highsmith在他的《敏捷项目管理》一书中这样写道:敏捷是指在动荡的业务环境中,适应变化并创造变化,从而获得价值的一种能力。同时敏捷是平衡灵活性和稳定性的一种能力。由此可见,望文生义地把“敏捷”理解为“做得快”也颇可商榷。如果缺乏有效的实施指导、忽视严格的敏捷实践,单凭着高层面的理解甚至“文化”就开始盲目前行,往往会因为缺乏对质量的有力保障而失去平衡,最终欲速则不达。

    转自:本文出自 jessegao 的51Testing软件测试博客:http://www.51testing.com/?369515
    展开全文
  • 敏捷开发项目管理

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

    以下文章转载自知乎,暗灭-京华九月秋近寒,浮沉半生影长单.



    暗灭

    京华九月秋近寒,浮沉半生影长单

    366 人赞同了该回答

    前言

    ================================================

    1.本回答从属于“IT修真院”收藏夹系列第二篇,第一篇是IT职业介绍。

    第一篇对IT职业做了一个相对深入的介绍,给了想从事互联网职业的人一个了解各个职业的机会,已经有4000+赞了,我想是真的帮助到了很多人。IT行业都有哪些职位,初学者(0基础,新人)该如何选择,才能够快速进入这个行业? - xdyl 的回答

    第二篇是对敏捷开发和项目管理做了一介绍,这篇贴子还没写完,其实它的价值远远大于第一篇走马观花的介绍。只是大家还没有到能够理解敏捷开发的时候,所以我想了很久,决定暂时不写了。

    互联网公司的“敏捷开发”流程是怎么样的,每个职位的角色和分工是什么? - xdyl 的回答

    这是第三篇,写这个贴子的动机是因为,在修真院有不少人在问,我要学到什么程度才能找到工作,我是零基础啊,有没有视频和教程可以教我。有哪些IT初学者(新人)成长为技术大牛的真实经历? - xdyl 的回答

    顺手推荐一下修真院的专栏,各种IT行业的真实小故事。IT修真院 - 知乎专栏

    2.本回答和第一篇不同,纯属分享,并不需要有任何的广告。

    3.但是,本人依然不对分享出来的任何内容的可信度负任何的责任,也根本不保证是一篇公正,客观,完美的回答。

    4.这个回答,是任何一个初级或中级甚至是高级的程序员,产品经理,Leader都可以认真去思考和尝试的,某种程度上,这个回答比写两行代码更有效果。

    5状态:未完待续

    正文

    ========================================

    首先讲为什么需要敏捷开发。

    在几万年以前,软件项目的开发都是以年来计算的,这代表什么意思呢 ?需求设计了半年多,方案设计做了半年多,开发了三年多,测试了半年多,修改Bug用了半年多。总计花了很长很长的时间,然后上线后发现有很多需求已经不存在了,同时又出现了很多新的需求。

    怎么办?继续改。这一改又是半年多的时间过去了。马丹用户的需求还再改,怎么办?

    这是困扰软件开发项目的最大的问题,越大的项目,参与的人越多,风险越大。文档越规范,维护起来的难度就越高,导致项目中遇到的问题越来越多。

    不仅仅在几万年前,就是在现在,也是经常会有团队出现这种问题。不相信,你可以看看是否遇到了以下这些问题:

    1.需求总是在变动,反复变动,无限拖延。

    2.开发工程师做出来的项目,bug不但多,而且经常改不好。常常是改了一个Bug,出现另一个Bug,好不容易把一个Bug改好了,过了没多久又重现了。原本好好的功能,反而会因为改Bug导致出现的问题更多。

    3.做出来的东西完全不是产品经理想要的样子,沟通完之后才发现开发工程师的理解和产品经理的理解是完全不一样的。

    4.项目延期不是最坏的结果,最坏的结果是还从不知道项目倒底会延期多少,根本没办法去衡量工作量,团队的成员都在加班加点,然而完全看不出来问题出在什么地方。

    5.开发文档,产品文档,接口文档,测试报告和真实的代码从没有完美契合过。产品经理设计出来的原型和UI设计出来的页面和程序员开发出来的代码完全是一种不同的体系,三位一体的故事从没有真正发生过。代码的实现和接口文档根本不一致,最后索性干脆不看接口文档,完全口头交流。出错的时候各种撕逼扯皮,谁也分不清倒底谁错了。

    6.Team的战斗力和凝聚力不强,经常是对着干,对分配的任务总是各种报怨,出现问题之后第一反应是这个不关我的事,不是我的问题,是后端前端设计QAPM的问题。

    如果你遇到了这种情况,或者说你不甘于这种现状,那么恭喜你,你可以真的需要敏捷开发流程了。

    第二,敏捷开发包括了哪些内容

    敏捷开发总的流程如下:

    1.需求规划和分期

    2. 需求评审

    3. 需求讲解

    4. 方案评审

    5. 每日晨会

    6. 性能测试

    7.  CodeReview

    8.  Demo

    9. 测试阶段

    10.线上Bug修改流程

    表跟我说哪些东西不应该包含在敏捷开发流程里,如果你不喜欢,跟你的观念有冲突,你可以把敏捷开发这四个字换成任意四个字。总之,如果要解决这些问题,这是我目前看到的最佳实践,每一个节点都非纸上谈兵,而是经过无数个尝试和失败总结出来的。

    如果你是一个IT公司的管理者,如果你不知道该怎么去管理自己的团队,我强烈安列你按着我说的这种标准化方式去做,放心,出了问题我保证不会负一点责任。

    确切的说,我说的敏捷开发流程,并不仅仅是开发团队的事情,它背后隐藏着更多的理念。我可能整理的不够清楚,毕竟这是第一版。

    1.产品和开发必须是一个Team,大家只是分工不同,角色不同,并不是两个对立的团队。

    如果你的公司是把产品和开发分成两个部门,那么恭喜你,产品和开发之间的纠纷一定无限多。

    在所有我带的Team中,自始至终强调的理念就是:出了问题,别跟我说这是产品设计出来,这是开发团队实现不了的。我只知道这是你们一个开发小组所有人的责任,这个后果是所有的人都需要承担的。如果我们认真的区分这是什么问题,那么也只是为了避免下次出现同样的情况,用户只会知道是一个公司出了一款垃圾产品,没有人关心到底是产品还是开发的锅。

    这是做敏捷开发的大前提。或者不仅仅是产品和开发,责任共担,One Team这个理念是贯穿始终的。这并不是说,大锅饭,而是说,面对不好的结果,所有Team的人都必须共同承担。出现问题的原因仅仅是为了追溯和重现当时的场景,以避免后续会出现同样的情况。

    产品和开发必须是一个Team还体现在需求分期上。这一点在讲到需求分期的流程的时候,会提高的。实际上,需求分期如果没做好,敏捷开发只能流于形式。

    需求分期怎么做,这是MVP的事情,另一个话题。简单来说,每一期都要有一个提前的预测,这一期里要做的所有的功能都只为了检测自己的预测是否正确。并根据结果去不断的调整开发规划。

    2.职责明确,每个人要负责的事情必须清晰无误,谁该做哪些事情,必须要提前讲清楚。

    开发团队的推荐角色应该是这样的。

    PM 1个

    UI  1个

    CSS/js 1~2个

    Java    2~4个

    Android 1~2个

    IOS        1~2个

    QA          1个

    这是一个相对平衡的模板,这样的一个8~10人的小Team,是可以复制的。敏捷开发支持多个Team并行开发。理论上来讲。这种方式,可以支持五到六个小Team同时启动。

    在讲到最后多Team并发协作的时候,我也会提到的。

    除了这些项目小组的角色,还有各个Team的Leader。我比较推荐小组分成如下几种:

    1.产品Team  产品团队

    2.用户体验 Team  传统的UI团队升级为UE,升级为整个系统甚至是公司的用户体验师。

    3.后端Team  苦逼的后端

    4.前端Team  Android/IOS/JS  表问我为什么把这三个放到一起,我就是认为一个前端工程师应该三者通吃。可以在某一个客户端上了解的更深入,但是普通的项目上手还是应该没有问题的。

    5.QATeam      QA只需要做功能测试,回归测试,边界测试,并不需要做性能测试。这里也会在后面提到。

    那么来描述一下每个角色的不同职责。这些不同的角色牵涉到团队并行开发,所以并不是简单的随便扒拉到一堆就好了的。

    PM: PM的职责并不是画原型,而是去分产品的分期,确定产品要做的功能和优先级。

    对于产品来说,最大的职责并不是将原型画出来,而是要证明自己要做的功能是合理的。

    如果你证明不了自己要做的功能是合理的,是值的尝试的,就是产品经理的失职。

          可以参考MVP,有无数的办法可以提前验证,如果不能够提前验证,那么就证明这是有风险。做为PM,一定要有这种风险的意识,要知道自己身上担负的责任,PM花了两周时间设计的原型,8人的开发团队要折腾近三周左右的时间。

    原型和产品文档都是辅助的东西,我甚至不推荐产品经理去做原型设计,只拆分Story。

    原型设计交给传统的UI更合适。然而在真实实施的过程中,因为很少有UI具备原型的设计能力,所以实施起来会有一些难度。这个不算特别重要,慢慢培养。

            PM不需要为开发进度负任何的责任,这很重要,不要把PM当成项目管理来使用,如果你让PM去做了项目管理,恭喜你,Game 近乎 Over,产品经理没有时间再去思考如何做功能了。

            PM的职责就是把功能设计好,优先级排好,给开发团队讲清楚需求,结合Story优先级和功能实现的大概时间点去做排期。

            开发工期交给开发团队去做,Bug会和QA,开发团队一起来定。记着要在开发团队开发项目的时间里,去做好下一个产品迭代的设计。

    小组Leader:需求评审会的成员应该包括PM组的Leader,前端组的leader,后端组的leader,测试组的Leader,或者是其他公司的中层骨干。

    这应该是一个公司所有应该为这个项目负责的人的评审会,在评审会上的结论,就应该被坚定的执行下去了。不参与评审会的人,不应该再对需求指手画脚。

    需求评审会的目标就是确定原封不动的需求,所以在这里要格外的注意,PM拿出来的方案设计,一定是完整的,而且必须评细节。如果说,一个公司的中层骨干经过需求评审会议,仍然需求乱成一比,那就没什么可说的了,继续努力提升自己的水准,或者是补充真正的中层。

    而PM的目标就是吸引需求评审会的意见,尽量让自己的需求和设计通过评审。

    各个小组的Leader还应该承担的角色就是各个组的方案评审。这是中层骨干必须要起到的作用。

    小组的Leader还应该负责项目中风险的调控,考虑是增加人手,安排加班,项目延期,还是调整功能。

    与些同时,应该去审核最后的性能报告,看看是否达到系统的期望值,遇到了疑难问题如何解决。

    开发组成员:项目进入真正的开发阶段后,开发组的成员就应该是主动去控制项目的进度,和风险,以及主动去测试项目中存在的问题,在这个阶段,除了一些需求不明,或者是发生变动的情况出现,不应该去打扰产品经理。不要让产品经理做开发团队的保姆。

    开发组的成员的目标就是做好项目的进度控制,有风险就及时反馈给Leader,确保自己理解的需求是明确无误的,确保自己的测试是完整和严谨的,确认自己写出来的代码是可以维护的。

    一定要理解清楚,一旦PM通过Story讲解,将需求交付给开发组成员,那么开发组成员就应该主动而独立的为这件事情负责。

    当项目完工以后,开发组成员应该交叉去做CodeReview,并且出性能测试报告,以及组织Demo。

    测试组成员:测试级成员的职责不是做功能性的测试,也不是做性能测试。而是应该做边界测试和回归测试。功能性的测试主要应该由开发组成员完成,除了一些特别麻烦的,需要各种极端条件才能复现的,正常的操作过程中出现的问题,都应该是有开发组承担。性能测试同样是开发组人员自行完成,各小组Leader只需要知道一件事情,测试报告是否能够通过。

    所以测试组的主要做的就是准确的记录,以及bug的统计。也不应该去天催促开发组的成员去改Bug。只需要去反馈给开发组的Leader就好了。整个CTO或者是技术总监应该以此为标准去衡量每个小组Leader的绩效。

    回归测试是需要做的,但是也不是完全必须要做。如果能够积累足够多的自动化测试用例,就去正常使用它,如果不能,就尽可能少的减少回归测试。这需要跟开发人员沟通的比较清楚,他们往往更清楚,什么地方容易出问题。

    接受线上的反馈并且记录也应该是QA的职责,如果Team足够细,可能会有运营或者是客服统一对外收集,然后交给QA,QA再负责录入Bug系统中。

    基本的敏捷开发流程中的角色的职责大致就是这样的了。这不是一件容易的事情,其中的很多小细节,都照顾到了每个角色的职责和义务。理论上来说,如果有一张图的话,可以更清楚的画出来不同角色的功能。

    这种职责的划分,和传统的职责会有一些不同,反正,在我带过的Team中,这是最高效的,也是最能发挥出团队的能力的方式。你可以信,也可以不信,这中间的每一个细小的调整,都是经过无数个日日夜夜的验证而得来的,我还未曾看到过比这种职责划分方式更高效,更合理的做法,虽然我接触的Team也不够多,爱信不信~

    3.每个人必须学会主动去为自己的事情负责

    当有了第二条,你很快就能发现团队中,谁是能够尽守职责,更主动的人。第3条很难做到,特别在很多公司,并不注重对于团队凝聚力的培养,也不会注重和他们之间的交流,不知道他们想要什么。

    所以这也是我一再强调的,敏捷开发并不仅仅是一个开发流程,更是一种管理的方式,他牵涉到绩效考核,公司福利,上下班制度等等你看不到的东西。

    如果说你的团队成员并不能做到为自己的事情负责,那么你需要的就是,要么就是去更换团队,要么就是想办法去激励团队。这是另一个话题了,我心情好的话,可能会在这里提到,如果心情不好,可能会在下一个文章里,也可能根本就不会写了。

    这件事情其实也不算难,第一,明确这种职责的分工是合理的,第二,Leader都需要了解自己的团队的状况。第三,不断的去强化和培养这种做事的习惯。

    就够了。团队是需要打磨和改造的。这三点是敏捷开发实施的前提,而不是说,有了这三点,敏捷开发就一点能做好了。

    在具体的实施上,还有无数的细节是需要去整理和落地的。

    隔了好几天没写,我已经忘记了自己原本的思路是什么了,先写到这里再说。


    今天的分享就到这里啦,欢迎大家点赞、转发、留言、拍砖~

            技能树.IT修真院

            “我们相信人人都可以成为一个工程师,现在开始,找个师兄,带你入门,掌控自己学习的节奏,学习的路上不再迷茫”。

            这里是技能树.IT修真院,成千上万的师兄在这里找到了自己的学习路线,学习透明化,成长可见化,师兄1对1免费指导。快来与我一起学习吧~

    我的邀请码:17742750,或者你可以直接点击此链接:http://www.jnshu.com/login/1/17742750

    展开全文
  • 前段时间给大家整理了敏捷开发的流程,最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际...
  • 瀑布模型:简单说就是先定好需求和相关文档,然后构建框架,然后写代码,然后测试,最后发布个产品一旦文档需求确定,开发人员就按文档开发,直到产品开发完后,才会拿出来给客户。不过这种方式基本不适应现今快速...
  • DevOps敏捷开发流程

    2019-11-19 17:29:15
    近期根据我们DevOps开发团队敏捷开发项目的实践经验,将完整流程整理如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际过程中可以参考。 1. 目的 规范...
  • 其核心目的,是通过一个项目管理软件,来管理不同项目,然后通过项目的里的工作项,了解开发人员的工作量,效率,从而来管理开发人员,合理调配开发人力。 名词解释 项目:一系列独特的、复杂的并相互关联的活动...
  • 今天,这种迭代或增量方法影响着开发和业务的各个方面,包括项目管理。学习敏捷的最佳来源是什么?这篇文章涵盖了10本强大的书籍,可以提高项目经理及其团队的技能。 你读过的关于敏捷方法或项目管理的最新书是...
  • 一、项目管理 按照PMBoK,项目管理就是把各种知识、技能、手段和技术应用于项目活动之中,以达到项目的要求。项目管理是通过应用和整合启动、规划、实施、监控和收尾五大项目管理过程来进行的。 项目管理是伴随着...
  • 通常被称为“敏捷项目管理框架”,其重点是使用经验过程,使团队能够快速,有效,有效地做出改变。传统的项目管理方法确定了需求,以控制时间和成本; 另一方面,Scrum修复了控制需求的时间和成本。这是使用时间框,...
  • 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、...
  • 说一下你对敏捷开发的理解,为什么要使用敏捷开发? 》瀑布模型的典型问题就是周期长,发布烦,变更难。 》敏捷开发就是快速迭代,持续集成,拥抱变化。     所谓“敏捷”,顾名思义,可以通俗...
  • 它的设计融入了先进的敏捷管理思想,由多位业界知名敏捷管理顾问提供支持,并由专业的敏捷开发团队精心打造而成,完美支持Scrum敏捷开发和看板方法。 我们可以使用Leangoo可视化地进行项目需求、任务、问题和文档的...
  • 我们使用各种敏捷软件写feature,流转、跟踪任务,言必谈敏捷,然而我们是否真的走对了敏捷?显而易见,敏捷是绝对的结果导向,去文档化,去流程化,高效沟通和合作是究极奥义。去文档,敏捷管理者需要维护更为精细...
  • 敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于...
  • 敏捷项目管理可以应用于任何的JIRA项目中。无论你是Scrum大师或者是刚刚尝试敏捷开发的新手,JIRA Agile都能够帮助你在整个发布过程中管理待办事项(backlog)、计划冲刺(sprint)并且监测项目进度。 Trello 基于...
  • 敏捷开发(scrum, agile)相对于瀑布流开发(waterfull)更适合现在快节奏的商业模式需求,它将一整个项目拆分为相互独立的小块,我们成为sprint(冲刺),每个sprint都包含前期的需求分析,开发测试,客户演示和demo...
  • 摘要:本文先介绍了使用传统项目管理技术管理软件开发项目的方法,然后介绍了使用敏捷项目管理的初步实践,通过两者比较,提出了使用敏捷项目管理进行软件开发的方法。  关键词:敏捷开发、极限编程、XP、项目管理 ...
1 2 3 4 5 ... 20
收藏数 21,756
精华内容 8,702
关键字:

敏捷开发项目管理规程