敏捷开发管理_项目管理《敏捷软件开发原则模式与实践》与《敏捷项目管理》 - CSDN
  • 原文地址:https://www.zhihu.com/question/54626462管理工具:1.需求管理工具confluence 是一个基于...2.基于敏捷管理的sprint、backlog、开发task、bug管理工具jira 是一个基于java的issue(问题、事项)管理器,...

    原文地址:https://www.zhihu.com/question/54626462

    管理工具:

    1.需求管理工具

    confluence 是一个基于java企业知识平台,基本上是一个企业博客,他有一些工作流管理功能,也支持很多插件(如UML、思维等等),容易定制。

    2.基于敏捷管理的sprint、backlog、开发task、bug管理工具

    jira 是一个基于java的issue(问题、事项)管理器,类似的产品有禅道,github也有简单的issue管理,支持很多插件,而且可定制。

     3.代码管理

    gitlab 是一个类似于github的东西,它是采用ruby开发的,支持自己的一套智能提交,并且非常开放,易于集成。

    4.部署打包

    jenkins 是一个java实现的持续集成工具,图标是一个绅士小老头很搞笑,在我这边一般它会工作在触发后执行打包脚本,进行自动化的集成部署,完成后会发送邮件提示,通知结果。后期我这边将它和nexus进行了整合,改变了一些使用方法,但是大致还是这样子。虽然这个是java写的,但是完全可以用作其他语言的持续部署,它很神奇,很省心,也很易用。


    费用?

    jira & confluence & 插件

    也应该看到了,我这边用的是正版,不推荐D版,请支持正版。
    官方有费用的介绍,国内有代理,可以开发票是可以比较方便走账的,价格相对而言还是比较可观。
    最低有10人10美元授权,其实巧妙分组使用此授权可以在更多人数的团队中使用(就是说不是一套JIRA),但记得其实人家授权协议中是不同意这样子做的(其实我也没仔细看)。

    插件
    插件大多支持试用一段时间,大可以装上试用下,感觉好了再付费。
    google可以搜到很多人的评价,在 http://stackoverflow.com 和 Hot Questions - Stack Exchange 中也有很多评论可以参考,慢慢搜索就行了。

    对硬件的要求?

    内存:
    在实际使用中发现,jira 和 confluence 很吃内存,分配小内存使用起来效果并不好,我在内部服务器上配置了48G内存,给乱七八糟的服务去使用,使用起来体验还可以。

    处理器:
    对于cpu等吃的并不厉害。

    硬盘:
    对于硬盘 iops 相对于内存次要敏感,我这边是配置了两张 ssd 做的 raid1(mdadm做的),使用中感觉还可以。

    网络:
    延时还是要低些吧,你放到美国的vps上300多ms的延时估计用起来是不会开心的。

    在实践中需要应用的其他工具或产品?

    linux服务器 应该不是必须的?据说可以用windows?我没考证过,所以写在这里吧。

    tomcat 这是apache下的开源项目,是一个 JSP/Servlet 容器(就是跑java网站用的服务端),另外还有jboss等,但是我们用不到ejb,所以tomcat是个好选择。

    nginx web服务端,也可以作为反向代理(实际上用作反向代理比较多)

    postgresql 一款学院派风格的关系型数据库(虽然也支持nosql),性能很不错,使用起来坑也比较少,对于一些特性他比mysql兼容的好,我这边大量在使用。这个不是必须的,用mysql,sqlserver(这个我没试过)是可以替代的。虽然他支持nosql数据库,但还是不要用的比较好。

    双向证书验证 一般的https是单向的,即服务端装证书,客户端验证,而双向证书顾名思义就是双向的,客户端也要有,服务端会验证客户端的证书,没证书,访问不了。
    我这边吧服务都放在了公网,虽说代码本身是不怕同僚离职时带走,但是考虑到其他方面这显然不太安全,所以采用了双向认证的方案。
    在实施中吧个人证书与自建CA的根证书分发给同僚,进行安装后即可访问,但是没有证书访问页面就会404,制造出没有这个页面的假象。

    自建CA 因为采用了公网部署双向证书验证的方案,口袋里又没有钱都去用正规CA的证书,所以这个基本不可少。

    可选技术?

    docker 这个当下非常火,不必多说了。在实际使用中我尝试过吧这几个项目部署到docker里,但是就体验来说效果不好。在实际使用中主要是吧 docker 来结合 spring cloud 来使用。

    nexus 一个开放的自建maven,可以代理中央服务器,也可以上传内部的包让团队成员共享与使用,做java方面的开发这个可谓是不可不用。

    ss-local 这个我不展开了,毕竟你懂的。这是一个神奇的梯子工具的客户端,我在内部服务器(即跑这些应用的服务器,而不是内网中的服务器)中进行了部署,连接到东京的linode,来给nexus加速。在安装这一堆乱七八糟的过程中使用此神器可以大大加速下载速度,如果你在国外应该用不到这个。

    privoxy 一个代理服务器,ss-local提供的是一个socks5代理,但是毕竟用socks5很多地方不方便,比如终端下并不能简单的使用,而很多应用也只支持使用http代理,所以就用它来进行socks 到 http 的转换。

    jira git 插件 一个可以和git库进行集成的插件,对双向证书支持不好,只能在nginx给此插件开小灶不走双向认证。

    jira gantt-charts 插件 一个jira展示甘特图的插件,体验很不错,排版容易混乱,但并不影响使用。

    confluence draw.io 插件 画图用的,基本上常见的图都支持,但是体验一般,可以安装其他插件进行优势互补。

    jira 和 confluence 中文汉化包 顾名思义,对于像是我这种只有小学英语水平的人尤为重要。

    zsh 一个神奇的shell,用他来增加终端使用git的体验

    oh-my-zsh 顾名思义,用zsh几乎必备

    如何使用这一堆乱七八糟?

    至于集成与账号创建等我会在配置安装章节进行阐述,在此只提供一个用例。

    感觉码字好麻烦,只写基于默认的情况下一种符合大多数情况的案例吧,供大家参考:

    项目定下来后首先用 jira 建立项目,首推:

    这个使用起来效果是很不错的。另外你也可以很方便的建立自己的类型,让他符合自己的需求,但在此不展开了。

    然后进行必要的项目配置,这里的甘特图选项请设置好,要不甘特图有些功能会有问题。

    创建版本

    然后跑到 confluence 建立库,推荐选择这个:
    同理也可以建立自己的来用(不复杂,摸索下即可)。
    选好项目关联好,并创建:

    这时候一般会开个会议大家考虑下战略、任务怎么分配以及怎么下手去干,这时候创建一个会议记录。


    对会议内容进行记录。
    在参会内容中对参与人员进行'@'即可: 

    其他按照模板项进行填充,其中行动项请务必填写,这个很实用。

    这样子保存后参会人就会收到提示,如果配置了邮箱提醒还会看到邮件。
    然后扫中展示的行动项,建立jira任务:

    此时会看到已经关联。
    jira中也已经有了
    分配好经办人,新建一个sprint并且把任务拖进去将经办人分配好,在此例中分配给我了我自己。如果要拆分子任务也请此时进行。

    然后开始sprint,这时在甘特图中已经可以看到了,在active sprints中也可以拖动任务了。

    任务拖动到其他阶段后,confluence就会更新,

    大家都能看到做到哪里以及做的怎么样了。
    在这里因为要求做需求,创建一个产品要求在里面。左侧 产品要求->Create product requirement 把需要的项目都填好。
    问题过滤器中这里就直接获得所有没结束的,实际使用中可以按需要获得,比如获得属于这个需求的,等等。
    我采用的是列表展示20条,这会导致排版不好看,但是实用些,如果感觉不舒服可以换形式,或者减少展现字段。


    剩下的按照模板填写。
    保存后就会看到调用的问题
    一个比较可用的方案是自定义模板,但是在此就不展开了,有需要可以查看官方教程。
    决策日志,和回顾等大同小异我不再赘述。
    开发过程中,一定要使用jira的智能提交,这非常好用。
    在gitlab中创建版本库,并且添加必要的README等等,另外就是配置好 Project services 集成好jira 

    点击 test 试试看是不是配置正确。点击issues 来试试是否能跳到展现页面。
    在gitlab里给这个项目加入一个JIRA的新成员
    去jira git 插件中查看webhooks 

    吧webhooks给设定好(在你的jira中git插件里面查看,就上面那个)
    保存测试成功了才可以。
    回到JIRA去更新下GIT插件的索引

    把项目克隆到本地然后测试一下智能提交,确定ok。
    为了方便演示智能提交加上这个项目还没README,所以就拿加入README来演示,首先在JIRA创建一个任务并且开始做这个任务。
    然后我们来做这个任务(这里你也看到我用了zsh和oh-my-zsh,其实是可以用ga gp 之类的,你也可以用用看)
    这里很显然我配置过key,没有配置请先配置。
    (平时我使用了ssh的~/.ssh/config 配置文件来设定服务器的,此处可以直接使用常见的git形式,不必像这里一样去ssh://,此处仅为演示,实际使用推荐还是采取ssh config配置文件+远程地址无关的形式比较好,因为这样子换域名换端口,同僚可以不必一个一个去修改git的config,而是改一个 ssh config 即可)
    这时如果你在另外一个屏幕上开着JIRA的话应该已经自动移到Done里面了(并不需要刷新)
    甘特什么的也已经更新了,要是关注过问题的人也会收到提醒。
    这种神奇的效果就是刚刚那句 commit 命令,这个就叫做智能提交,gitlab-shell会去调用gitlab,gitlab又去通过刚刚设定的web钩子去拽一下jira,jira去刷新库(以下不再赘述运行过程,不必要的感觉),这个实际使用中体验还是不错的。这里用的这个是改变当前状态的。格式是:
    git commit -m "JIRA的任务KEY #目的状态 解释"
    

    如果你有多个任务可以用空格间隔重复前半部分,不需要提交多次。
    对于智能提交jira官方是有详尽说明的,我放连接,需要的可以去慢慢研究,一般在使用中我是会弄个环境变量或者脚本来方便提交 issue key ,毕竟有的项目会把KEY搞得很长,输入起来并不是很方便,有的同僚是采取IDEA中设定ISSUE的方式,这些都是比较好的办法。
    Atlassian Documentation

    (如果没有设定过本地 git 的 config 请按照gitlab下面的步骤来做一下,不去设定的话会发现提交后不会关联到对应用户,它是按照邮箱进行的索引,所以邮箱是尤为重要的)

    (另外扯一句题外话,我曾经见过一些同行,不知道代码洁癖还是有要求怎么的,git提交错了,push了,消尖了脑袋去改git的提交,莫非跟绩效挂钩?在我看来这是大可不必的,提交错了重新提交一次即可,大可不必在这里钻牛角尖,要不天天改提交,哪天手抖输敲错了就心塞了反而麻烦。至于代码审核也请不要基于提交为单位展开,要不真会逼人去改提交,而且代码审核这种事最好是上下文都要看到才好,不知道上下文的话突然插进来不要谈审核,哪里是那里都不知道。)




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

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

    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

    展开全文
  • 瀑布模型:简单说就是先定好需求和相关文档,然后构建框架,然后写代码,然后测试,最后发布个产品一旦文档需求确定,开发人员就按文档开发,直到产品开发完后,才会拿出来给客户。不过这种方式基本不适应现今快速...

    瀑布模型

    简单说就是先定好需求和相关文档,然后构建框架,然后写代码,然后测试,最后发布个产品

    一旦文档需求确定,开发人员就按文档开发,直到产品开发完后,才会拿出来给客户。不过这种方式基本不适应现今快速发展的市场现状了。

    弊端:

    1.接力棒的协作模式带来信息差:瀑布模式下,业务、产品、研发三方很少共同参与讨论。需求如同接力棒从业务方传递给产品经理,再从产品经理传递给研发团队。信息每经过一次传递都有损失,研发团队不了解需求背后真正的业务诉求,业务方不了解技术方案背后的权衡。

    2.难以响应变化瀑布模式下,所有的需求分析和设计工作在开发前完成,并假设需求不会改变,研发过程只需遵循最初的项目计划和范围。事实上,对需求的发掘和理解,应该是一个持续的过程,需要不断地反馈。”


    敏捷开发:

    敏捷(Agile)作为一种开发流程, 目前为各大公司所采用, 敏捷流程的具体实践有XP 和Scrum

    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征


    Scrum:

    目的

    1. 适应变化。Scrum 的一个基本假设,就是外部需求模糊而难以理解。Scrum 对此的理念是:让客户直接看到半成品,他们才知道自己要什么。很多 Scrum 的原则都是围绕如何解决这个问题的:比如每个 Sprint 结束时由 Product Owner 为客户进行展示,又比如任务细化一般不超过一个 Sprint。理解了这一点,才会理解为什么 Scrum 似乎总在变化,因为需求总在变化。
    2. 快速迭代。Scrum 的另一个基本假设,是团队生存在一个快速变化且充满竞争的世界。如果自己一年半才能发布一个新版本,而竞争对手半年就能发布,那么几年之内,我们就会被对手甩得远远的。Scrum 对此的理念是:发布即 Milestone(里程碑),宁可每次发布二十个功能发布五次,也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点,才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。
    3. 我们作出的决定中, 50% 都是错误的。早早失败,早早学习。因为发布周期缩短,团队没有能力保证作出的每一个决定都正确,很多开销都必须花在试错上;快速发布实际上导致 Scrum 团队的抗风险能力弱于瀑布模型团队,因为一个人的离职或病假都可能对单一功能的进度造成影响,不利于短期频繁发布。

      Scrum 对此的解答是:不要试图不犯错误,而是保证小的错误能被尽快发现从而不会酿成大错

    流程:

    1.首先我们需要确认一个 PB ( Product Backlog , 即按优先顺序排列的一个产品需求列表) ,这是由 PO(Product Owner) 负责的

    2.ST(Scrum Team) 会根据 PB 列表,进行工作量的预估和安排

    3.有了 PB 列表,我们需要通过 Sprint Planning Meeting( Sprint 计划会议)来从中挑选出一个 Story 作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog

    4.Sprint Backlog 是由 ST 去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成)

    5.在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)

    6.做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员

    7.当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消)

    8.最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中


    极限编程:简称XP

    思想:交流、简单、响应和勇气:加强交流;从简单做起;寻求反馈;勇于实事求是


    敏捷开发的特点

    1)敏捷开发中更加强调沟通,沟通频率可能比以前更高,沟通时间可能会比以前更长,占用更多的个人工作时间,反而可能因此导致实际开发时间起过原来开发出某个功能的时间; 

    2)敏捷开发是从用户视图出发,可能会要求工程师成为所谓“全栈工程师”,使开发人员反而感觉工作量增加了,短时间内会表现出开发效率的下降,而且要求所有开发人员对需求的理解能力也要求更高了,所以很多人会感觉敏捷开发对人员的要求更高,其实是因为对人员要求的改变导致现有开发人员能力木桶效应现象发生。 

    3)快速的迭代使重构工作量增加,会感觉功能不断被修改导致了很多浪费。这种感觉如果不能正确认识,不仅会误以为影响了工作效率,而且会使程序员很受伤,因为他们认为是在不停地返工。 

    4)信息的透明性要求较多的数据收集,敏捷成熟度越高,收集的信息就越多,收集这些数据会占用一定的精力,如果不能够正确的理解这些数据的价值,会让程序员感觉浪费了很多时间在做无用功,反而降低了开发效率。 


    敏捷开发的流程:

    需求评审:

    (1)首先,一个story被PM提出时,需写好用户故事卡片和详细描述;

    (2)接着,PM会找RD、QA的leader进行讲解,并交review,review人提出问题及改进意见;

    (3)然后,PM和负责具体开发RD、测试QA进行讲解和讨论,RD、QA提出问题、疑问,PM解答,并对详细描述进行修改。

    (4)最后,所有参与者觉得没有问题后,PM辅助QA补充详细的验收标准,RD对其进行review,并作为自测和自动化case编写的参考。

    (5)此外,在开发和测试的过程中,若发现新问题,PM随时响应,答疑解惑,修改设计的不足。


    敏捷开发的思想

    1)拥抱变化:各种因素都会影响计划的执行,所以计划要短,及时调整才能响应一切变化导致的计划的不可行性,避免走弯路。 

    2)快速响应:市场环境的变化,越来越要求产品、服务的响应及时。比如按照传统方式,规划半年一个版本,一旦需要调整需求,后面所有的计划都得改变,会为项目管理带来极大的挑战,变化的成本奇高,多数情况下会因为多数人的反对而不了了之。响应变化胜过遵循计划

    3)快速将功能推向市场变现:迅速占领市场更显得尤其重要,这是在向时间要效益。比如做个用户系统,按照程序员的想法,一次性把用户注册登录、修改密码、忘记密码、记住密码、登录验证码、注销等功能设计完,而如果按功能逐版本开发而不是一次开发完成,而是放在不同的版本里,可能需要更多天数,因为里面会有重构、修改界面等,但是应用可以在第3天就上线。争取了15天上市时间,有哪个系统因为没有验证码在上线后第3天就就被恶意注册?有几个用户会在6天后就忘记密码?有几个人会在9天后就修改密码?有几个人会因为登录频繁因为没有记住密码功能而不在使用?,讲到这里,那位朋友想起他们在上一个版本中的一个功能,如果这个功能按照敏捷的方式开发,可以早3个月推向市场,每个月有上千万的收(上线后的效果统计数据),这才是敏捷真正的价值所在。 

    4)做最值得做的事:什么事最值得做,什么事就优先级最高,也就是ROI最高,ROI是评价需求优先级的唯一指标。其实ROI是一个综合指标,非常复杂的综合指标,它与开发工作量、市场需求迫切程度、技术关联性、市场价值等因素有关,需要全方位评估。


    敏捷开发的误区

    1)敏捷开发不是用来管理开发人员的,不是用来提高开发人员的工作效率的,而是企业全面提升团队绩效的方法

    2)瀑布开发模型是以文档为驱动的,把需求文档写出来后,根据文档进行开发的,而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。 

    3)在敏捷开发中每次迭代都被成为一个sprint,中文意为“冲刺”,可见其速度与效率

    4)尽管对敏捷开发的变通运用,可以带来巨大的效益,但现实情况是,多数变通能力需要经历学习曲线的规律。当人们和组织在学习的过程中,在经历阶跃变化前,交付能力可能还会下降,当经历这个转变后,才开始获得交付能力的提升。

    5)当敏捷开发被大爆炸式地应用于大型项目、方案或整个组织时,存在一个显著的风险,即一个敏捷开发模式的好处可能不会被意识或理解。组织及其员工常常会继续着他们一直在做的事情,却自认为已经使用了一个“敏捷”方法。转变能力是一个长期的学习和改变的过程。企业在发展,同时执行业务最好的方式也在不断转变。因此,执行一个大爆炸式的“敏捷”转型后,想当然地认为进一步的改进不再必要,是一个错误认识。

    6)没有MRD,如何管理好需求?使用story模式来管理需求,将庞大的MRD划分为一个个可独立交付的story(通常每个story能在1~5天内完成,包括设计、开发、测试),需求清晰明了可节省大量的需求评审时间。

    7)项目一开始,XP 就强调通过对软件的不断测试来获得反馈,程序员尽可能早的把软件交给客户,并实现客户对软件需求提出的变化,有了这些基础,XP 程序员就可以自信的面对需求和软件技术的变化。从这里可以看出通过一个个短小的迭代周期,我们就可以获得一个个阶段性的进展,并且可以及时形成一个版本供用户参考,以便及时对用户可能的需求变更作出响应。

    8)敏捷是万能的么? 我上学的时候老师教我们 “形式化的软件开发方法 (Formal Method)”,  “里程碑式的开发 (Plan-driven development)”, 它们都被淘汰了?  答: 不是, 和任何武功和战术一样, 敏捷有它最适用的范围, 我借着酒劲, 画一个表:

    客观因素\最适用方式敏捷 (Agile)计划驱动 (Plan-driven)形式化的开发方法 (Formal Method)
    产品可靠性要求不高, 容忍经常出错必须有较高可靠性有极高的可靠性和质量要求
    需求变化经常变化不经常变化固定的需求,需求可以建模
    团队人员数量不多较多不多
    人员经验有资深程序员带队以中层技术人员为主资深专家
    公司文化鼓励变化, 行业充满变数崇尚秩序, 按时交付精益求精
    实际的例子写一个微博网站;开发下一版本的办公软件; 给商业用户开发软件开发底层正则表达式解析模块; 
    科学计算; 复杂系统的核心组件
    用错方式的后果用敏捷的方法开发登月火箭控制程序,  前N 批宇航员都挂了。用敏捷方法,  商业用户未必受得了两周一次更新的频率。敏捷方法的大部分招数都和这类用户无关, 用户关心的是:  把可靠性提高到 99.99%,  不要让微小的错误把系统搞崩溃! 

    专有名词:

    PB: Product Backlog , 即按优先顺序排列的一个产品需求列表,只能有一个产品backlog

    poProduct Owner产品负责人

    Sprint Backlog有了 PB 列表,我们需要通过 Sprint Planning Meeting( Sprint 计划会议)来从中挑选出一个 Story 作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog

    sprint backlog和Product Backlog的关系


    每个矩形都表示一个故事,按重要性排序。最
    重要的故事在列表顶部。矩形尺寸表示故事大小(也就是以故事点
    估算的时间长短)。

    sprint每次迭代都被成为一个sprint,中文意为“冲刺”

    story:翻译是故事,本意是产品的功能,backlog中包含了许多story,故事中包含了如下字段

    1、id

    2、name,也即功能名

    3、重要性,越高越重要

    4、初始估算,该故事所需工作量,单位是故事点,3个人需要4天时间,就是12故事点

    5、如何做演示,测试规范

    6、注解

    例如:



    注意点:

    1、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品

    2、Scrum 对此的理念是:发布即 Milestone(里程碑),宁可每次发布二十个功能发布五次,也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点,才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。

    3、sprint计划会议:

    内容:

    (1)制定Sprint目标

    (2)团队成员名单

    (3)Sprint backlog(Sprint中包括的故事列表)

    (4)确定sprint 演示日期

    如何做:

    创建索引卡,放到墙上,这种用户体验比计算机和投影仪好得多。


    每个故事下面有多个任务,任务只会存在于故事下面,而不会存在于product sprint中


    4、们已经完成了 sprint 计划会议,应该创建 sprint backlog 了。它应该在 sprint 计划会议之后,第一次每日例会之前完成,这样规划:没做的,正在做的,已经做的,和燃尽图


    经过每日scrum后变成这样:


    最后变成这样:


    对于燃尽图:


    5、每日例会,时间15分钟,每个人都会一边描述昨天已经做的事情和今天要做的事情,一边移动任务板上对应的即时贴,如果他讲的是一个未经计划的条目,那他就新写一张即时贴贴到板上。如果他更新了时间估算,那就在即时贴上写上新的时间,把旧的划掉。

    如果有人不知道今天干什么,解决方法

    (1)请人添加更多的即时贴上去。接下来我就会对觉得自己没事可干的人说,“我们已经过了一遍任务板,你们现在对今天要做的事情有想法了么?”。希望他们有点儿概念了。

    (2)如果他们还不知道该干什么,我会考虑他们是不是可以去跟其他人结对编程。

    (3)从任务板右下角的“Next”区域中拿出一两个故事,放到左边的“not checked out”列中。接下来重新进行每日例会。告诉产品负责人一声,你已经把一些条目加进了 sprint

    6、对于大部分的团队sprint长度为三周,一个sprint包含10个故事左右

    7、对于故事的任务量估算需要每个成员都参与,每个故事的估算,需要每人给出一个故事点,如果两人故事点相差太大,要讨论为什么,直到把所有工作估算完

    8、Sprint 演示(有人也叫它 sprint 回顾)是 Scrum 中很重要的一环,且所有的 sprint 都结束于演示

    9、Scrum 注重的是管理和组织实践,而XP 关注的是实际的编程实践。这就是为什么它们可以很好地协同工作——它们解决的是不同领域的问题,可以互为补充,相得益彰

    10、测试驱动开发(TDD):测试驱动开发意味着你要先写一个自动测试,然后编写恰好够用的代码,让它通过这个测试,接着对代码进行重构,主要是提高它的可读性和消除重复。整理一下,然后继续

    11、把测试人员放到 Scrum 团队来提高质量。如果团队在做 TDD,从第一天开始,大家都会花时间来编写测试代码,此时测试人员应该跟编写测试代码的开发人员一起结对编程。

    12、多项目一起进行,那么两个项目的sprint应该是同步的


    同步进行的 sprint 有如下优点:
    可以利用 sprint 之间的时间来重新组织团队!如果各个sprint 重叠的话,要想重新组织团队,就必须打断至少一个团队的 sprint 进程。
    所有团队都可以在一个 sprint 中向同一个目标努力,他们可以有更好的协作。
    更小的管理压力,即更少的 sprint 计划会议、sprint 演示和发布

    13、团队构建:




    参考资料:

    1、https://blog.csdn.net/nocky/article/details/51236848

    2、https://blog.csdn.net/xinxing__8185/article/details/46708439

    3、https://blog.csdn.net/baynkbtg/article/details/52402727

    4、https://blog.csdn.net/liyangbing315/article/details/5387129

    5、https://blog.csdn.net/ostrichmyself/article/details/5375223

    6、http://www.cnblogs.com/xinz/archive/2011/04/27/2031118.html

    7、https://blog.csdn.net/b0Q8cpra539haFS7/article/details/79245096

    8、https://www.zhihu.com/question/19638322

    9、scrum and xp chinese version.pdf


    展开全文
  • 目前软件行业敏捷开发管理最大的问题在于太看重具体的形式,而忽略了敏捷的初衷。 很多公司请几个敏捷教练建立流程,把会议室的椅子都搬走宣布从今以后大家站着开会了,使用敏捷管理工具建立迭代、建...
  • 敏捷开发中的需求管理大致分为三个阶段:需求调研,需求分析和需求确认。 需求调研阶段 产品立项后,产品经理便开始了和需求打交道的漫长过程。第一步就是需求的调研工作。需求调研的质量,会直接影响到后续产品...
  • 其中的很多理念都是从敏捷开发管理引申过来的,比如:持续反馈,持续改进,持续业务计划等等,越来越觉得敏捷开发管理,DevOps和微服务是天作之合,如果能够结合企业的愿景和成熟度来规划整体建设,那么企业转型成功...
  •  不同与传统的软件开发模式,敏捷开发模式有着自己鲜明的价值和方法。  其中,敏捷测试部分也同以往的软件测试流程有所不同。这对测试人员提出了新的要求,带来了新的挑战。 第一部分:敏捷软件开发简介 敏捷...
  • 无论是“需求”,还是“BUG”,或是“任务”,都是“事务”的一种,所以Jira可以胜任非常多的角色:需求管理、缺陷跟踪、任务管理等等……因为Jira提供了专门的Scrum视图和Kanban视图,所以特别适合敏捷开发团队使用...
  • 以前使用GitHub一般就作为版本管理+bug管理,都是个人使用,这次公司全部统一使用GitHub企业版进行开发管理,在使用过程中感觉还蛮不错的。可以实现类似看板的功能,还很便于交流。
  • 【什么是敏捷开发?】资深程序员之路(5)--agile开发 敏捷开发(scrum, agile)相对于瀑布流开发(waterfull)更适合现在快节奏的商业模式需求,它将一整个项目拆分为相互独立的小块,我们成为sprint(冲刺),每个...
  • 工欲善其事,必先利其器,那我给大家介绍一款敏捷开发项目管理工具-Leangoo。 它是由国内最早推广敏捷 也是最权威的 Scrum中文网 研发打造,完美支持Scrum敏捷开发中的所有元素,我们一起来具体看看吧! ...
  • 做过项目经理,使用过一些管理软件后,就有自己亲自动手做一个项目管理系统的想法。要做就要做到与别人不一样,除了自己用,还要让更多的人去用。不但要用,还要觉得好用,对工作有真正的帮助。首要我要考虑系统的...
  • 敏捷开发是快速迭代,快速交付的开发模式。这也就要求迭代周期内任务量不宜过大,以保证在预期内能够按时完成开发计划。敏捷开发中怎样保证开发任务的适宜呢?答案是任务分解。而任务分解的前提则是需求确认。 敏捷...
  • 前段时间给大家整理了敏捷开发的流程,最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际...
  • 因为我们的工作中有各种事物要处理,我们需要这样的敏捷开发工具来帮助我们解决问题并清晰的展开工作。Leangoo可以帮助我们管理事务,需求管理,迭代管理,缺陷管理,测试管理,排列优先级等,随时随地可以了解到...
  • 敏捷开发流程总结

    2015-12-14 16:36:10
    Agile——敏捷开发,作为CMM神话崩溃后被引入的一套新的软件开发模式,这几年来被广泛引起关注,并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知,但以下总结了我所在公司的敏捷开发试验,希望可以达到...
  • 现在许多开发团队在学习敏捷开发,根据调查,2018年有80%以上的开发团队表示他们使用了敏捷方式,敏捷项目与传统项目相比,至少可以提升30%以上的成功率。 笔者查看了3年以来使用人数较多的项目管理工具,从中挑选...
  • 敏捷开发中,绩效管理管理层非常关心的问题,而敏捷(或Scrum)中没有关于绩效的定义或做法。本文是Ken Rubin基于自己20多年的敏捷开发经验总结出来的、敏捷团队中如何进行绩效管理。 几乎我教过的每堂课或辅导...
  • 说一下你对敏捷开发的理解,为什么要使用敏捷开发? 》瀑布模型的典型问题就是周期长,发布烦,变更难。 》敏捷开发就是快速迭代,持续集成,拥抱变化。     所谓“敏捷”,顾名思义,可以通俗...
1 2 3 4 5 ... 20
收藏数 89,042
精华内容 35,616
关键字:

敏捷开发管理