敏捷开发 研发体系_产品研发管理体系和敏捷体系 - CSDN
  • 产品研发管理体系敏捷体系 当您问产品所有者敏捷工具是否适合他们时,您会得到混合的,有时是负面的答复。 敏捷工具确实可以为敏捷团队提供帮助,但是它们不能提供产品所有者完成其工作所需的所有功能。 同样,...

    产品研发管理体系和敏捷体系

    当您问产品所有者敏捷工具是否适合他们时,您会得到混合的,有时是负面的答复。 敏捷工具确实可以为敏捷团队提供帮助,但是它们不能提供产品所有者完成其工作所需的所有功能。

    同样,敏捷工具的功能有限,无法帮助计划和投资组合经理。 敏捷工具通常提供有关团队,版本和史诗的报告,这些报告通常不足以帮助计划经理报告自上而下的战略计划。

    [了解您的企业如何在敏捷开发中脱颖而出 | 将您的敏捷职业提升到新的水平: 如何提高您的Scrum Master技能 | 不确定“敏捷”的真正含义是什么? InfoWorld 解释了敏捷方法 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

    因此,如果您团队中的产品负责人讨厌Atlassian的Jira,或者程序经理无法从Jira或Microsoft的Azure DevOps获得所需的报告,请不要感到惊讶。 这些工具仅充当团队工作职能的一部分。

    积压,冲刺板和Scrum报告不能完全解决产品经理构思出色产品所需的工具,也无法帮助计划经理使战略目标与敏捷团队执行的工作保持一致。 如果您经常参加与产品和程序经理进行的会议,以审查工作状态或通过PowerPoint演示文稿学习业务策略,则您的组织可能已准备好使用敏捷的产品管理或产品组合管理平台。

    诸如Jira和Azure DevOps之类的敏捷管理平台主要是为包括开发人员,测试人员和devops工程师在内的敏捷交付团队设计的。 他们有董事会来管理用户故事的状态以及致力于活动sprint的其他类型的工作,还拥有其他积压管理工具来帮助为未来的sprint审查,排序和确定故事的优先级。 它们带有内置的燃尽报告和其他报告,以帮助敏捷团队跟踪速度,检查区块,测量周期时间以及管理进行中的工作。 敏捷工具还可以帮助产品所有者编写故事,记录验收标准并查看故事点估计 他们使用这些工具为冲刺确定工作的优先级并跟踪进度。

    产品管理平台共享愿景并捕获路线图

    产品经理和所有者通过聆听客户和潜在客户,确定他们的需求,确定如何为他们提供业务价值,添加内部利益相关者的想法和战略要求以及定义可提供出色客户体验的产品和服务来开始工作。 在产品开发的早期阶段,他们的工作是研究市场,测试想法并将策略传达给利益相关者。

    在此过程中,他们经常制定产品愿景,业务模型,竞争分析,用户角色,业务目标和其他工件,以帮助将其目标传达给领导者和敏捷团队。

    产品经理用来捕获和传达这些工件的传统工具是PowerPoint和Excel的混合体。 尽管这些工具可以在产品开发之初就起作用,以征得利益相关者的认可并组建团队,但是在开发,发布和增强产品时,它们对于管理利益相关者的期望是不佳的选择。 为了管理这些职责,产品经理和所有者需要管理更高级别的功能待办事项,传达发布状态以及共享长期路线图。

    这些工具需要与敏捷原则保持一致,以使团队能够致力于交付,调整优先级并围绕提供解决方案进行自我组织。

    诸如Jira Align(以前称为AgileCraft),Aha和Version One Ultimate Edition之类的平台为产品经理提供了这些工具以及与敏捷积压和发布计划的集成。 它们包括一个用于产品经理交流其产品战略的集中平台,用于使利益相关者参与其想法的工具以及用于共享发布状态和路线图的报告机制。

    例如,Aha启用了与敏捷工具的多种集成,包括Jira,Azure DevOps,Rally和Trello,以汇总有关团队,用户故事,功能和发行版的信息。 然后,可以将该信息映射到几个Aha结构,例如功能积压,路线图,计划和目标。 这是自下而上的视图,使产品经理可以与利益相关者共享状态信息和计划。

    Aha还为产品经理提供了阐明其战略,捕获业务模型以及传达用户角色的工具。 使用这些工具的组织为产品经理提供了一种标准且集中的方式,使组织可以就目标,远景和优先事项进行组织。

    项目组合管理推动大型组织的一致性和标准

    开发面向客户的产品,工作流应用程序,集成,商业智能仪表板和其他技术可交付成果的企业还需要其他工具,以确保计划能够根据战略目标进行交付。 大型企业通常具有分层的组织层次结构,并且需要有关优先级和自下而上的度量的自上而下的通信,这些信息可以汇总到状态报告中。

    项目组合管理(PPM)工具已经存在了一段时间,可以帮助组织管理和跟踪战略计划。 但是,这些工具的许多早期版本旨在汇总传统的结构良好的瀑布项目进度表,包括具有定义的开始和结束日期的里程碑和任务。 这些工具无法轻松地聚合围绕冲刺和用户故事的敏捷项目,这些项目具有由自组织团队管理的日程安排和优先级不断变化的项目。 一些不支持敏捷框架的PPM工具具有复杂的数据集成功能,会在发行版和史诗版本上汇总敏捷数据。 更糟糕的是,由顶级调度和优先级驱动的PPM工作流通常会在投资组合经理和敏捷团队之间造成文化冲突。

    负责通过SAFe,DAD,LeSS和我自己的Driving Digital等框架扩展敏捷实践的 项目组合经理还需要投资组合工具,以监督多个敏捷团队并建立流程标准。

    诸如Jira Align和VersionOne Ultimate Edition之类的敏捷产品组合工具使您可以在敏捷团队正在完成的工作之上的一层管理计划。 它们提供了团队速度和能力的可见性,因此您可以为团队分配计划并预测时间表。 它们还提供了将业务价值分配给计划并适当调整团队,优先级和投资水平的工具。

    Jira Align不仅可以管理一系列计划,跟踪史诗,还可以汇总敏捷项目指标。 它具有可视化和管理团队之间的依存关系,跟踪风险以及与敏捷团队共享战略信息的工具。

    这些工具如何使敏捷团队受益

    传统上,敏捷工具已用于帮助团队管理积压,符合需求,致力于冲刺以及确定可靠的发布。

    在大型组织中,敏捷工具中的基础数据对于帮助管理层理解现状并使团队适应推动最大业务价值的计划至关重要。 为了有效地做到这一点,敏捷团队必须在如何使用工具,工作流和数据字段(尤其是围绕工作项,冲刺和发布)方面采用标准。 如果团队使用没有标准的工具,则会造成数据质量问题,并使产品管理和产品组合工具汇总指标和状态变得更加困难。

    如果没有良好的数据,您可能会期望召开许多有关产品和程序的会议,以讨论和掌握团队地位。 对于那些经常因开发功能和解决技术债务而费力的开发人员来说,这可能令人沮丧。 通过选择和检测正确的流程和工具,管理层可以获得驱动战略优先级所需的自上而下的工作流程和报告,而又不会给敏捷开发团队带来过多负担。

    翻译自: https://www.infoworld.com/article/3410294/agile-product-management-and-portfolio-platforms-explained.html

    产品研发管理体系和敏捷体系

    展开全文
  • 研发体系这点事

    2017-11-27 09:26:46
    研发体系这点事 早在读研究生的时候,自己负责着实验室的项目,就一直在思索如何建立一套简单又高效的研发管理体系,能够在保证项目高质量顺利进行的同时还能够提升团队成员的技术level。后来在自己在校的几次小的...

                                                     研发体系这点事

    早在读研究生的时候,自己负责着实验室的项目,就一直在思索如何建立一套简单又高效的研发管理体系,能够在保证项目高质量顺利进行的同时还能够提升团队成员的技术level。后来在自己在校的几次小的创业中,也做过一些尝试。直到毕业后进入前东家,在几个项目的参与过程中,见到了大公司的研发管理是如何进行的。直至加入目前的公司,将研发体系梳理一遍,且学且抄且实践,对这一套东西算是有了一定的实践感悟。


    对于一个研发管理体系,其核心是围绕着产品的整个生命周期来进行的。因此,根据一个产品的生命周期,可以把研发体系划分为几个关键的环节,如图所示:




    更为具体的一个研发流程则如下图所示,标注了每一个环节的参与角色。




    可知,即时沟通和技术提升虽然不属于研发流程中的某一个环节,但它们是贯穿整个研发体系不可或缺的一部分,有着不可替代的作用。此外,任务管理需要对任务做整个研发生命周期的管理,除了作为其中的一个关键环节,也是贯穿整个研发流程的。


    任务管理


    任务管理是产品整个生命周期首要的环节,其对研发体系也是至关重要的。项目生命周期模型,传统的有五种:瀑布模型、原型模型、螺旋模型、增量模型、V模型,而现在最为流行的是迭代开发模型,敏捷开发则是采用迭代模型的一种典型项目管理方法集合。Scrum是目前敏捷开发中最为大家熟知的开发模式(XP极限编程也是一种比较常见的敏捷开发模式),其开发流程的概览如下图所示:


    简单来说,Scrum是依赖于三种角色、四种会议的自组织、信息透明化、成员平等的一种敏捷开发流程。更为详细的描述,可参见此篇文章:http://blog.devtang.com/2014/09/13/scrum-introduction/


    除了Scrum之外,看板是最近兴起的另一种开发模式,在最近很火的美剧《硅谷》里面“魔笛手”就是采用的这种方式。看板将工作流程形象化,首先把工作细分成任务并根据需要将任务分为Pending、Analysis、Development、Test、Deploy等状态,然后根据任务的进行,在几种状态之间进行转换。对比Scrum,看板使用开发周期作为计划和过程改进的度量数据,不强调迭代的概念,也没有很强的时间期间概念,也不需要制定任何团队角色。对于看板方法论的详细介绍可见此篇文章:http://kanbanblog.com/explained/http://www.jianshu.com/p/e44b1038c9cf这篇则做了比较形象具体的说明。这里有一点需要注意,Scrum和看板并非是对立的,它们是可以结合起来使用的。使用看板来管理每一次迭代的任务是一种可取也是很常见的精益实践。


    依赖于任务管理方法论,市面上很多软件都做了相应的支撑,自己曾经使用过的任务管理软件如下:


    • Redmine:这个是自己最开始接触的任务管理软件,使用也比较广泛。比较遗憾的是,redmine安装有点繁琐,而且基于ROR,如果需要二次开发,需要重新学习ROR。

    • Tower.im:这是一个任务管理云服务,界面设计的简单优雅,一目了然。很多小的私有项目,我都会用这个进行任务管理。类似的还有teambeation等。

    • Jira:这款软件是商业版的任务管理软件,对于这一块做的是非常专业的,很多大公司都在使用。但是,它是收费的。所以,如果你要用,要么付钱,要么去破解。。。

    • 禅道:这款软件最早是叫做bugfree, 是开源且主要针对Bug管理的,后面慢慢发展成现在的集任务管理、bug管理、团队管理等的项目管理软件,并开启了收费策略。总体来说,功能很全,也比较专业,但是ui上有种传统it系统的感觉,流程上也不具有现在敏捷开发的一些优势。

    • Kanboard:是实现了Kanban方法论的任务管理软件。


    对于个人的项目,其实依赖于tower.im这种第三方云服务完全足够了。如果担心数据安全的话,那么推荐在内网搭建Kanboard进行看板任务管理。


    文档协作


    研发中首当其冲的就是文档撰写,这个很多情况下都决定了项目的可维护、可管理性。有人会说现在流行的是敏捷开发,根本不需要写文档,但其实这是对敏捷的误解。敏捷开发强调的是快速试错、快速迭代,而非简单粗暴,对比传统开发模型虽然并不强调文档,但并不代表不需要。对于一个项目,从开始就需要需求文档、产品原型文档、项目进度文档等等,而到了研发这一步,在系统实现、写代码之前最好的就是先“想”再做,而“想”的一种比较好的输出形式就是文档。对于一个软件系统,一般来说需要写的文档有以下几种:


    • 系统业务流程文档:描述系统业务逻辑的文档,能清晰的说明真个业务的流程。

    • 系统架构设计文档:对整个系统的架构的描述,需要包含系统的各个关键组成模块以及相关的各个关键技术点等。

    • 系统功能模块概要设计/详细设计文档:对于某一个模块的流程、逻辑的描述。

    • 数据DDL/DML文档: 与系统相关的数据库的DDL和DML文档,对于前者,是需要包含所有的操作的,而对于后者,必不可少的是查询语句,用来提供给DBA,来做查询sql的review,以保证索引的正确建立和查询语句的合理等。

    • 系统部署文档:描述系统关键部分部署在哪里,需要做哪些配置。

    • 系统发布ChangeLog:对系统每次发布的改动进行描述,包括数据库、缓存、数据队列、新增/变动了哪些依赖服务等。此外,对数据库、缓存这种关键服务的量化分析也可以写在这里。


    尤其对于一些相对复杂的功能来说,整理思路形成文档,不仅可以让自己逻辑清晰,也让后续维护的人能够更快地接手。当然,这些并不是死板要求的,应该根据实际的业务选择,不一定所有的文档都是必须的,也不一定要分开这几个文档写(可以将这些内容集成在一个文档中,这也是目前我经常采用的方式)。这些文档的范例可以见:https://github.com/superhj1987/awesome-tech-collections/tree/master/document


    而对于文档撰写协作的方式,我自己经历过的有以下几种:


    • 使用word撰写各种文档,提交到svn等版本管理工具上

    • 使用google doc进行协作

    • 使用word撰写文档,然后提交到项目管理软件中进行管理

    • 使用markdown撰写文档,提交到版本管理工具上


    我自己比较推崇的是使用markdown撰写文档,然后使用git、svn版本管理工具或者是其他团队协作工具做版本管理。之所以使用markdown, 能够极大地节省使用word时调各种格式、样式耗费的时间。对于程序员来说真的是如虎添翼。如果是对文档多人协同编辑有刚需的团队,可以选择使用google doc或者国内的石墨(http://shimo.im)。


    此外,在移动App开发中,还有一个非常关键的文档就是API文档,是服务端提供给客户端调用接口的说明文档。比较简单直接的方法就是定制一套API文档模板,然后在写接口代码之前或者之后,按照模板编写接口文档。此外,可以实现一套根据源码自动生成文档的机制,在代码编写的同时就能自动生成相应的接口说明文档。在使用Spring MVC开发的后端应用中,个人推荐SpringFox,使用此项目能够通过在Controller中加入相应的注解信息从而自动生成API接口文档,同时也提供了在线调试的功能,极大减少了API文档的工作量。


    代码协作


    对于一个技术团队,最最关键的肯定是写代码。一个人单打独斗那倒好说,但是这就像篮球场上,一对一靠个人硬实力,但是5对5,那就不仅仅是一个人实力强就赢得了的了。因此对于技术团队来说,代码协作是至关重要的一个部分。


    • 代码版本管理:Git + SVN


    几年前最流行的代码版本管理工具是svn(当然此前,更加古老的还有cvs之流),的确为程序员们的代码管理带来了很多便捷。但到了现在,相比起这种集中式代码管理,目前最为火热的当属git这种分布式代码管理工具,在Linux上直接搭建git服务器来构建项目的git系统的。而这几年随着Github以及类似系统的涌现,对于很多私人项目我都是采用oschina或者gitcafe提供的git私有代码管理来做代码版本管理的。当然,对于公司来说,有很多开源类github系统可以搭建在企业内网。详细的可以参见:搭建自己的github。当然,对比svn,git也是有缺点的。无法天然的支持对于目录级别的权限管理和基于目录的版本管理操作是目前不得不结合svn和git一起使用的重要原因。通常情况下,可以使用git做版本管理,辅以svn做基于目录级别的发布包管理。


    • 代码分支/Tag管理: Git Flow


    其实分支/Tag管理是代码版本管理包含的内容,之所以单独出来,是因为对于分支的使用其实还是有一定的原则和技巧的。并非如很多人一样,所有项目就一个master分支,所有修改都往这里塞。目前,最为流行的一种基于分支的工作方式就是:Git flow。介绍可以见: 基于git的源代码管理模型——git flow。简单概括就是:

    • master和develop作为主分支。主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。master是可以随时发布的分支,而develop则时刻保持最新的开发代码。

    • 辅助分支是用于组织解决特定问题的各种软件开发活动的分支。辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的缺陷进行紧急修复工作。这些分支与主分支不同,通常只会在有限的时间范围内存在。包括:


    • 用于开发新功能时所使用的feature分支;

    • 用于辅助版本发布的release分支;

    • 用于修正生产代码中的缺陷的hotfix分支。 对于此种开发模型,这里也提供了一个命令行工具:https://github.com/nvie/gitflow


    • 代码质量保证:结对编程 + 定期review + PR目前一种比较好的方式。结对编程这个是一个老生常谈的方式,两个人共同承担某一开发任务,互相保证对方的代码质量,在很大程度上能够提高代码质量。而定期review则是让团队所有的成员都能够参与到这个过程中,不仅仅能够保证被review者的代码质量,也能够让团队成员学习到好的代码是怎样的而差的代码又是怎样的。PR是Pull Request的简写,当开发完成的代码提交到主分支时,需要发起pull request,此时团队负责人需要review相关代码,确保没有问题之后,才能accept此次pr。当然,上面讲述的是如何通过人来保证代码质量。除此之外,还可以通过技术上的手段在一定程度上保障代码的质量,这一部分在后续的自动化测试机制会讲述。


    此外,在移动app项目中,一个很普遍的问题就是:在定义好API文档之后,客户端如何在后端并没有完成接口开发的情况下开发或者调试程序?这里有两种方案:


    • 客户端做好接口封装,在后端接口未完成前,客户端不经过网络io直接返回静态格式数据。这种方式最好是由客户端定义接口格式数据。

    • 后端将示例接口返回数据写在文件里,接口直接返回静态文件数据。此种方式,由后端定义接口数据格式。另外,有一个开源的工具: httpbin可以用来提供接口返回指定格式的数据,中文介绍可见:https://blog.phpgao.com/how-to-httpbin.html


    关于客户端和后端的接口代码协作,还有一个Chrome插件POSTMAN可以使用。后端可以使用此插件在编写完接口后进行自我功能测试,测试无误后可以将接口以文件或者url的形式分享给客户端供客户端参考和调试。


    质量保证


    当代码开发完成之后,需要质量保证机制的介入来保证功能的正常运行,从而保证代码是可发布的。一般来说,质量保证的手段就是测试,分为:


    • 代码质量测试

    • 功能测试

    • 性能测试


    代码质量测试一般是在编译打包代码之前进行,通常是自动化进行的。针对Java项目,自动化代码质量测试可以分为以下几步:


    • 源代码规范检查:对于Java来说,代码规范的检查一般使用checkstyle来检查。默认的规范非常严格,这里大家可以根据需要放宽一些规范。

    • 源代码静态质量检查: 常用的工具是pmd, 可以检查Java源文件中的潜在问题, 比如空try/catch/finally/switch语句块等。

    • 字节码bug检查:常用工具是findbugs,基于Bug Patterns概念,查找javabytecode(.class文件)中的潜在bug。如NullPoint空指针检查、没有合理关闭资源、字符串相同判断错(==,而不是equals)。

    • 单元测试:使用junit即可,当然在这里当使用mvn时,其test phrase会默认生成测试报告到${project.build.directory}/surefile-reports文件夹中。这里建议使用coverage生成单元测试报告,其中一个关键的单元测试覆盖率指标达到98%以上才为合格(根据需要自己调整即可)。


    以上提到的工具,都是有maven插件的。通常情况下,也推荐使用这些工具的maven插件来调用。目前流行的自动化ci工具jenkins、QuickBuild等结合各种丰富的插件可以提供这些功能,将他们集成到一个测试流程并形成最终的测试结果报表。


    在代码发布到线上环境之前,一个关键的步骤就是功能测试,通常都是工程师来进行的。需要测试工程师根据产品需求,形成测试用例,然后根据这些用例做相应的测试。测试用例的一个模板如下:


    用例ID 功能名称 用例名称 测试数据 前置条件 操作步骤 预期结果 测试结果 备注 review说明
    - - - - - - - - - -


    需要测试工程师根据需求创建并经过研发人员reivew确定测试用例,待到发布前进行测试以及反馈,直到所有测试用例都通过。


    对于移动app功能的测试,目前市场上有类似bugtags这种所见即所得提交测试工具,可以很方便的提交bug。


    功能测试通过之后,对于一些对性能有要求的项目,还需要进行性能测试。对于这种测试来说,通常有以下几种方式:


    • 测试工程师写性能测试代码来进行测试

    • 使用性能测试工具测试,如LoadRunner、ab等


    当然,所有这些测试都是在项目发布上线之前进行的,通常是在项目的测试、预发布环境中进行的。


    此外,对于测试任务的管理工作一般在任务管理软件中都做了集成。也有类似Mantis这种事专门做缺陷管理的。


    自动化部署


    对于Java项目的发布流程,如下图所示:




    使用ci软件可将以上步骤自动化的。


    如上图所示,对于一个项目,我们是划分为三种或者四种环境的。


    • 测试环境: 这个环境是一个相对来说比较宽松的环境,所有代码的提交都会触发jenkins的自动代码质量检查和部署。测试工程师也是首先在这个环境下进行功能、性能测试的。只有通过了,才能部署到后续的下一个环境。

    • 集成环境:这个环境不是必须的,只有当项目出现了两个大的分支并行开发,发布前需要集成两部分代码时才需要这样一个环境。一般来说只使用jenkins进行部署前的打包流程,部署流程由相关人员进行。这个环境也是需要测试工程师进行测试的。

    • 预发布环境:这个环境和线上环境是一模一样的,不同的是此环境下的服务器是不在线上服务器集群中的,并不为用户提供服务。此环境下的项目发布也是需要人工参与的,也必须由测试保证功能和性能的正常。

    • 线上环境:这个环境是比较严格的一个环境。在发布前,一般来说会进行发布确认等一系列上线评审工作后,由项目负责人或者运维人员部署发布。

      • 功能列表 vs 实现情况:检查是否已经实现所有计划的功能?如果有某些功能没有实现需要说明原因。

      • 软件演示

      • 测试结果和遗留问题列表:测试用例的情况,遗留的Bug以及情况说明

      • 上线确认

      • 后续任务计划


    其中,上线确认书的一个例子如下:


    xx项目上线确认书
    需求方验证结果 意见: 确认人:[由各个负责人签字]
    开发确认 意见: 确认人:
    测试确认 意见: 确认人:
    服务器是否需要重启 [是否需要自动更新那些App?] 确认人:
    服务器配置影响 [是否需要增加新的服务器ip,是否需要修改nginx/tomcat,是否新装软件,是否新建域名?] 确认人:
    数据库更改 [是否需要修改线上数据库?是否有初始化语句?索引是否正确建立?查询语句是否合理?量化分析数据(包括缓存)是否无误?] 确认人:
    数据初始化 [是否有初始化数据?如价格,默认分类等] 确认人:
    上线评审结论 [ ]通过 
    [ ] 未通过,不能上线 
     [ ] 未通过,但修改完制定Bug后可直接上线
    确认人:
    计划上线时间 2016-08-01


    后续任务计划,示例如下:


    问题描述 责任人 计划完成时间 状态
    xx xx xx xx


    故障管理


    由于各种客观原因如带宽、主机配置、流量异常或者程序逻辑不够严谨等原因,线上服务并非100%可用的。研发体系中最后把关的就是这一道故障应急机制。也就是说,一旦发生线上故障,如何快速反应并修复问题,如何避免下一次犯同样的错误。


    对故障的快速反应需要依赖于运维的监控机制,包括基础设施层面的监控以及业务层面的监控,一旦发生故障应该立刻发出告警到相关人员。这里可以使用nagios、cacti或者第三方服务(如:监控宝)实现,当然,如果你使用的是云服务,一般也会有相应的云监控服务提供给你的。后续的故障问题定位很多情况下则是取决于你的应用日志打的是否合理,是否有足够的覆盖面的,是否有足够的信息。ELK和请求链路监测系统(同染色日志系统)是目前比较流行的基于日志的故障定位解决方案。问题一旦定位到了,那么修复就是水到渠成的事情了。


    这里需要说明的一点是,上面讲述的是后端的故障快速反应和修复。针对客户端的故障,一般情况下都是由用户发现的。但是由于客户端发布流程的繁琐,很难及时修复一次发布版本的故障,只能等到下次解决。但是,目前一些客户端使用混合开发,其中的h5页面是可以在线修复的,另外,很多安卓app热更新方案也都能在线修复一些代码故障,如Nuwa、HotFix、dexposed。


    故障解决完并非最终的结果,之后的故障总结也是故障管理尤为关键的一点。大公司会根据故障产生的影响不同定义不同的故障级别,从而追责到个人,再进一步影响个人的职级评定或者绩效考核、奖金之类的。但这一套却并不适用于小公司,毕竟大多数小公司没有那么完善或者说根本就没有职级和绩效这么一说。其实,追责并不是主要目的,最主要的是如何避免再次出现问题。因此,对于小的创业公司来说,最需要做的就是如何对已经发生的故障做总结,吸取教训。构建一套故障总结wiki则是一种很好的方式。下面是一次故障总结模板;


    2016.08.01xxx故障总结
    故障等级 [故障等级]
    故障描述 [描述故障发生的现象]
    故障发现时间及发现人 [xxx于xxxx年xx月xx日 HH:mm 如何发现该问题。]
    故障影响 [影响时间范围、影响版本范围、影响产品范围]
    故障原因 [阐述故障发生的原因]
    解决方案 [详细记录如何解决此次的故障]
    故障教训 [如何避免下次出现类似的事故]
    责任人 [责任人签名]


    即时沟通


    显而易见,即时沟通是任何团队都必不可少的一个机制,同样也是研发团队必不可缺的。常用的就是QQ、钉钉或者企业内部的im软件。那么对于小公司或者创业公司,不想用第三方服务的该怎么办呢?之前蘑菇街开源过一个teamtalk的软件,不过后来由于某些原因已经下线。目前,有一款开源的web im软件可以供大家选择:Rocket.Chat,能够搭建出内网的slack服务(将分散的沟通方式聚集到一个地方,融入到一个信息流中)。


    此外,我自己还尝试过使用intellij自带的IDE TALK来进行研发团队的在线交流。使用这个比较好的一点是可以直接做基于代码的即时交流,比如能够发送一个代码片段给同事,他那边接收到之后是直接能在他的项目里相关代码处进行操作的。


    技术提升


    一个研发团队,很重要的一点是如何提高团队的战斗力。对于个人来说,在平时的工作中,提高技术的熟练度和深度,在业余补充学习专业知识,提升技术广度,这些都无须多言。那么如何在整体层面或者说是管理上促进团队成员的技术提升呢?可以采取的方式有以下几种:


    • 构建内部的技术wiki并建立技术分享机制,鼓励大家以演讲或者技术博客的方式分享自己的技术经验或者教训,既可以对自己进行review又可以给其他成员以启示。这一点,很多公司都是纳入绩效中的。

    • 将一些项目开源,让团队成员能够享受到开源项目带来的各种好处,比如提升个人在业界的知名度、提高编码的水准(毕竟不好的代码,你也不好意思放出去)。

    • 定期举办类似黑客马拉松的比赛,提高团队成员的凝聚力,也能够提升成员解决实际问题的技术能力。


    自己比较推崇的是第一种方式,但是开始的时候往往会发现很多人是不会主动去分享的。要么是觉得自己的东西技术含量都很低,要么就觉得自己的知识为何要分享给别人。可以采取的办法就是从最初的周期性安排人员进行技术分享,然后慢慢形成一种氛围和习惯,再到后续鼓励大家主动分享。当然,辅以奖品激励或者绩效奖励也是一种不错的方式,但切忌不要忽视一些业务能力很强但不爱或者不善于分享的工程师。


    至于项目开源,前提一定是团队的项目真的是高质量并且会对开源社区有贡献的,不能为了开源而开源。尤其是对于一个公司来说,一个开源的项目直接体现了公司技术水准的高低,会对公司的pr、招聘等都带来一定程度的影响。


    而黑客马拉松比赛这种方式,尤为关键的一点是要选择合适的主题。一般来说,围绕现实的业务场景来出题不仅能够提升大家解决问题的能力,也能顺便解决实际问题。比如”根据用户已有行为日志预测用户未来的行为”、“怎样构建合适的用户质量模型”都是比较合适的主题。此外,借鉴黑客马拉松的这种形式,可以采取类似“每周一题”的做法:在每周例会上给出一道和线上业务相关的问题,如“如何提高信息流的点击转化率”,然后每个人发散思维给出自己的解决方案,最终形成文章发布在内部的技术wiki上。对于每次主题,都会在下周的例会上针对每个人的解决方案进行讨论。


    此外,在安排团队成员去调研一种将要使用的新技术的时候,务必要深入到源码层面,这个观念是需要灌输到团队每一个人的意识中去的。去使用一个没有看过源码或者没有掌握其运行原理的开源软件是一件风险非常大的事情,极有可能造成巨大的线上故障。


    以上,是自己对于研发体系的一些实践和感悟,很多地方仍然有所欠缺或者并非最佳实践,也一直在探索更好的方案。


    作者:飒然Hang,架构师/后端工程师,working@中华万年历

    出处:http://www.rowkey.me/blog/2016/08/17/dev-manage/


    版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢。



    展开全文
  • 当下“互联网+” 已深入人心,软件行业也在适应时代变化要求,做出适应性变革:如何接纳并响应变化、加快研发速度、持续交付软件价值乃是当务之急!...汲取精华,打造属于我们自己的敏捷研发体系

    在开始之前还是先来做个对比:
    这里写图片描述
    通过以上对比,我们发现,每一种研发过程模型都是在一定的历史背景下形成的,而且有各自的使用场景。当下“互联网+” 已深入人心,软件行业也在适应时代变化要求,做出适应性变革:如何接纳并响应变化、加快研发速度、持续交付软件价值乃是当务之急!近年来敏捷研发过程已得越来越多地得到世界各地软件公司特别是中小型创业团队的亲睐,让我们以审视的态度一起来看看敏捷研发到底是怎样的?汲取精华,打造属于我们自己的敏捷研发体系!

    1. 敏捷(Scrum)是什么?
      这里写图片描述
      敏捷Scrum是目前国际公认的优秀管理实践! 近年来尤其在创业团队非常受欢迎!1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。敏捷一词来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者(他们发起组成了敏捷联盟)的聚会。
      Scrum是一种兼顾计划性与灵活性的敏捷开发过程,原词来自于橄榄 球中的“带球过人”。在橄榄球比赛的每次冲刺前,都将有一个计划安排的过程,但冲刺开始后则由队员在原计划的基础上随机应变。其实我们经常看到足球、篮球、乒乓球等运动教练都会有这样的冲刺迭代计划,而运动员们在场上在计划的基础上灵活机动地做出迅捷的冲刺。
      软件公司何尝不是这样呢?研发团队leader先做好迭代规划,排好需求功能开发优先级,调度各种资源,制定开发计划;开发中研发团队各就其职,每日反馈开发进度,根据实际情况灵活修整计划,最终给出软件产品。

    2. Scrum敏捷过程主要内容
      这里写图片描述
      ★ 3个角色
      产品负责人(Product Owner):负责产 品需求的提炼、条目化、优先级排序。
      Scrum Master:负责 维护Scrum方法的秩序,并协助解决非 技术问题
      Team(团队) :以“自组织”的相对扁平方式进行管理,负责完成开发工作。
      ★ 4个活动短会
      Sprint计划会议:团队Sprint中要完成的工作
      每日站会:昨天做了什么, 今天要做什么,遇到了什么困难
      Sprint评审会议:小组向产品负责人展示迭代工 作结果、产品负责人给出评价和反馈、是否成功交付评价任务完成情况?
      Sprint回顾会议:在每个迭代后召开简短的反思会,总结哪些事情做的好,哪些事情做的不好 ?制定改进计划
      ★ 1个看板(敏捷日常跟进)
      看板简单说就是把所有计划、正在工作的内容(UserStory),张贴到一个划分为用户故事、计划中、进行、结束等栏位的板状空间中,一般建议使用实物板。 见下图:
      这里写图片描述

    3. 敏捷Scrum6个原则
      a. 快速迭代
      相对那种半年一次的大版本发布来说,小版本的需求、开发和测试更加简单快速。一些公司,一年仅发布仅2~3个版本,发布流程缓慢,它们仍采用瀑布开发模式,更严重的是对敏捷开发模式存在误解。
      b. 让测试人员和开发者参与需求讨论
      需求讨论以研讨组的形式展开最有效率。研讨组,需要包括测试人员和开发者,这样可以更加轻松定义可测试的需求,将需求分组并确定优先级。 同时,该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高,大家更活跃,参与感更强。
      c. 编写可测试的需求文档
      开始就要用“用户故事”(User Story)的方法来编写需求文档。这种方法,可以让我们将注意力放在需求上,而不是解决方法和实施技术上。过早的提及技术实施方案,会降低对需求的注意力。
      d. 多沟通,尽量减少文档
      任何项目中,沟通都是一个常见的问题。好的沟通,是敏捷开发的先决条件。良好高效的沟通的重要性再怎么强调也不过分。
      团队要确保日常的交流,面对面沟通比邮件强得多。
      e. 做好产品原型
      建议使用草图和模型来阐明用户界面及交互。并不是所有人都可以理解一份复杂的文档,但人人都会看图,效果立竿见影。
      f. 及早考虑测试
      及早地考虑测试在敏捷开发中很重要。传统的软件开发,测试用例很晚才开始写,这导致过晚发现需求中存在的问题,使得改进成本过高。较早地开始编写测试用例,当需求完成时,可以接受的测试用例也基本一块完成了。

    4. 敏捷价值观
      承诺 – 愿意对目标做出承诺
      专注 – 把你的心思和能力都用到你承诺的工作上去
      开放 – Scrum 把项目中的一切开放给每个人看
      尊重 – 每个人都有他独特的背景和经验
      勇气 – 有勇气做出承诺,履行承诺,接纳建议

    5. 共勉
      只有适合团队的敏捷方法才是好的敏捷方法!
      千里之行,始于足下!

    展开全文
  • SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践...
  • Atitit 几大研发体系对比 Stage-Gate体系 PACE与IPD体系 敏捷开发体系 CMMI体系 艾龙 著 1. 3. 1.5:业界领先的研发管理体系简介 2 12. 《产品及生命周期优化法》(简称PACE——Product And Cycle-time ...

    Atitit 几大研发体系对比 Stage-Gate体系  PACEIPD体系 敏捷开发体系 CMMI体系 艾龙

     

    1. 3. 1.5:业界领先的研发管理体系简介 2 1

    2. 《产品及生命周期优化法》(简称PACE——Product And Cycle-time Excellence 1

    2.1. 七个相关要素 1

    3. 集成产品开发(Integrated Product Development, 简称IPD Ipd重点 CBB-重用、文档管理 公用构建模块(CBB 2

    4. Scrum体系 2

    5. RESCO体系 Ati RECycle SCO循环使用和缩短供应链 3

    6. 参考资料 3

     

    1. 3. 1.5:业界领先的研发管理体系简介 2

    3.1. 1.5.1Stage-Gate体系 3

    3.2. 1.5.2PACEIPD体系 3

    3.3. 1.5.3CMMI体系 3

    3.4. 1.5.4Scrum敏捷开发体系 3

     

    2. 《产品及生命周期优化法》(简称PACE——Product And Cycle-time Excellence

    1986年,PRTM提出了产品开发流程的PACEProduct And Cycle-time Excellence,产品及周期优化法)这一概念

     

    PACE产品开发流程的七个相关要素:决策;项目小组构成;开发活动的结构;开发工具和技术;产品战略流程;技术管理;管道管理作分别的介绍。PACE还将帮助分析各公司在改进产品开发流程中所经历的典型阶段。这个框架可以帮助不同的公司定位自己处于改进的哪个阶段,然后确定进一步改进的目标。

    2.1. 七个相关要素

    编辑

    PACE中具有七个要素,分别用于项目管理和跨项目管理;这七个要素相互关联,只有将它们综合起来使用才能充分发挥效力。

    用于项目管理有四个要素,分别为:阶段评审流程与高效决策、项目组织的核心小组法、结构化的产品开发、设计技术和自动开发工具。这四个要素形成了PACE的基础,它们对于每一个产品开发项目都是必要的,掌握这些要素可以缩短产品的面市时间,准确安排项目进度,提高开发效率,避免对错误的产品进行投资。

    用于跨项目管理有三个要素,分别为:产品策略、技术管理、管道管理。这三个要素提供了必要的基本管理框架来综合管理所有的产品开发项目;通过掌握这些要素,可以使企业发现更好的产品机遇,更好地将技术开发综合起来,并从战略和策略的角

     

    3. 集成产品开发Integrated Product Development, 简称IPD Ipd重点 CBB-重用、文档管理 公用构建模块(CBB

    集成产品开发Integrated Product Development, 简称IPD)是一套产品开发的模式、理念与方法。IPD的思想来源于美国PRTM公司出版的《产品及生命周期优化法》(简称PACE——Product And Cycle-time Excellence)一书,该书中详细描述了这种新的产品开发模式所包含的各个方面。

     

    4. Scrum体系

    ★ 3个角色 
    产品负责人(Product Owner):负责产 品需求的提炼、条目化、优先级排序。 
    Scrum Master:负责 维护Scrum方法的秩序,并协助解决非 技术问题 
    Team(团队) :以“自组织”的相对扁平方式进行管理,负责完成开发工作。 
    ★ 4个活动短会 
    Sprint计划会议:团队Sprint中要完成的工作 
    每日站会:昨天做了什么, 今天要做什么,遇到了什么困难 
    Sprint评审会议:小组向产品负责人展示迭代工 作结果、产品负责人给出评价和反馈、是否成功交付评价任务完成情况? 
    Sprint回顾会议:在每个迭代后召开简短的反思会,总结哪些事情做的好,哪些事情做的不好 ?制定改进计划 
    ★ 1个看板(敏捷日常跟进) 
    看板简单说就是把所有计划、正在工作的内容(UserStory),张贴到一个划分为用户故事、计划中、进行、结束等栏位的板状空间中,一般建议使用实物板。 见下图: 

     

    5. RESCO体系 Ati RECycle SCO循环使用和缩短供应链

    重文档方便找到recyle

    来自于猎鹰活动的循环使用和缩短供应链

    供应链管理(Supply chain managementSCM)是一种集成的管理思想和方法,它执行供应链中从供应商到最终用户的物流的计划和控制等职能。

     供应链优化(Supply Chain Optimization)

     

    6. 参考资料

     

    IPD_百度百科.html

    Scrum敏捷研发体系初探 - CSDN博客.mhtml

    PACE(项目管理理念)_百度百科.mhtml

    Scrum敏捷研发体系初探 - CSDN博客.mhtml

     

    Atitit title 头衔  头街  称号 v19

     

     

    作者:: 绰号:老哇的爪子claw of Eagle 偶像破坏者Iconoclast image-smasher

    捕鸟王"Bird Catcher  kok  虔诚者Pious 宗教信仰捍卫者 Defender Of the Faith. 卡拉卡拉红斗篷 Caracalla red cloak 万兽之王  纵火者

    简称:: st Emir Attilax Akbar 圣 埃米尔 阿提拉克斯 阿克巴

    全名::st Emir Attilax Akbar bin Mahmud bin  attila bin Solomon bin adam Al Rapanui 圣 埃米尔 阿提拉克斯 阿克巴 马哈茂德 阿提拉 所罗门 本亚当  阿尔 拉帕努伊

    常用名:艾提拉(艾龙),  

     

    头衔:

     

    uke

     Emir Uke部落首席大酋长,ati协会创始人

    uke总部o2o负责人,全球网格化项目创始人,

    圣阿提拉克斯国王

    科技领域

    UTSC uke技术标准化委员会委员长 uke 首席cto   软件部门总监 技术部副总监  研发部门总监主管  产品部副经理 项目部副经理   uke科技研究院院长 uke软件培训大师

    Ati组织科研研究院创始人

     

    文艺领域

    ,  ,, uke机车协会主任 uke纹身协会

    uke交友协会会长  uke捕猎协会会长

    Ati文艺协会会长  ati文学协会

     

    行政领域

    Gchsp总裁  gchsp常委  GsP创始人

    媒体传播领域

       uke出版社编辑总编  宣传布道总策划

    Ati传媒总部

     

    渔猎军事领域

    uke保安部首席大队长

    Uke 户外运动协会理事长  度假村首席大村长

    Ati打猎协会

    法学

    法学研究会 制度研究会

    管理领域

    工商管理学 公共管理与社会服务

    ,uke制度检查委员会副会长

    教育领域

     uec学院校长, uecip图像处理机器视觉专业系主任   uke文档检索专业系主任

    Uke图像处理与机器视觉学院首席院长

    uke终身教育学校副校长

    靓号研究院

     

    经济领域

    uke波利尼西亚区大区连锁负责人 汤加王国区域负责人 uke克尔格伦群岛区连锁负责人,莱恩群岛区连锁负责人,uke布维岛和南乔治亚和南桑威奇群岛大区连锁负责人

     Uke软件标准化协会理事长理事长 Uke 数据库与存储标准化协会副会长

    直达巴士西北区负责人   直达巴士长沙与西安分部部长

    润昌通讯软件事业部总裁 执行长 分部负责人  执行委员会主席

    Ati经济研究所

    历史领域

    历史事业部  ati历史研究院

    社会科学领域

    社科学院  ati文化部

    自然科学领域

    Uke研究院院长兼首席研究员 科学家

    Ati自然科学研究院

    宗教神学领域

    uke宗教与文化融合事务部部长  大师master

    uke制度与重大会议委员会委员长    ati宗教事务所

    医学领域

       Uke医院 与医学院方面的创始人

     

     

     

     

     

     

     

     

     

    转载请注明来源:attilax的专栏   

     

     

    --Atiend  v19

     

     

    修改历史记录

     

    V18增加了GsP 头街  v19增加了圣字头街与  圣阿提拉克斯王国国王头街

    V17 增加了ati组织的头街

    V16 结构化表格化头街 ,并且 头街增加一些。充实了空虚。

    V15 增加了知乎空间  微博大小号

    V14  增加小号,以及通讯公司与直达巴士分部

    V12 增加机构utsc

    V10 增加了microblog

    万兽之王本来这个是湿婆的。。

    V7  增加了研究院title

    V8 去了奶牛科技的东东

    V9 融和俩个v8版本。。

    增加了cnblogsurl

     

     

     

     

    展开全文
  • 敏捷开发和迭代开发

    2018-07-10 17:20:56
    敏捷开发与迭代式开发是整体与局部的关系   敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过...
  • 敏捷开发 vs 传统模式

    2015-05-28 22:41:00
    说起敏捷开发,并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多敏捷咨询服务商神话了,这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。 ...
  • 前段时间给大家整理了敏捷开发的流程,最近在整理敏捷开发项目的流程和管理制度,其整理的项目管理规程如下,这份规程也不完全算是敏捷专属的项目管理规程,主要是在结合我们公司实际的情况下编写出来的,大家在实际...
  • 谈谈敏捷开发模型

    2019-08-01 23:36:56
    谈谈敏捷开发模型 我对敏捷开发是源于10多年前看了一本关于迭代开发的书,从而对迭代开发有了一些...但是在接触敏捷开发这个体系之前,自己有机会做一个项目,那个时候我开始将自己认为更有利于项目的管理工作做了...
  • 敏捷开发初步了解

    2019-09-02 10:34:44
    敏捷开发  敏捷开发,现在大多数团队都在推崇敏捷开发模式  笔者最开始理解的时候,也在疑惑到底什么是敏捷开发,带来的好处又是什么?  笔者也只是一个入行没多久的新手,以下只是笔者自己对于敏捷开发的一些...
  • 随着软件开发技术的不断发展,现在出现了很多种不同的开发模式,其实敏捷开发已经成为现在很多企业开发应用程序都想要选择的开发方案。那么什么是敏捷开发呢?下面一起来了解一下相关的知识吧!  常用的 4 种开发...
  • 什么是敏捷开发

    2019-10-31 15:50:18
    本篇分享的是:【什么是敏捷开发 】 目录: 1.几种开发方法 1.1瀑布式开发 1.2迭代式开发 1.3螺旋式开发 2.敏捷开发 2.1 敏捷开发的诞生 2.2敏捷开发宣言 2.3 敏捷开发 3.敏捷开发方法 ...
  • 敏捷开发中QA如何做质量管理? 经常有人会问我,敏捷模式下,QA的职责是什么?QA有什么价值?我们还需要QA吗?敏捷转型中遇到的问题,QA能帮助解决吗?这些问题以前也思考过,笔者就是QA出身的,曾经在中兴通讯做过...
  • 敏捷开发-快速迭代

    2013-05-08 19:57:45
    今天跟大家分享的是“敏捷开发、快速迭代”。我们大都采用的是“瀑布开发模式”,有了问题,就得返工,虽然最终的产品会比较齐全完善,但是开发周期太长,开发人员会产生排斥,甚至厌恶的心理。经过YH系统的开发,也...
  • 力软敏捷开发框架是基于.net平台研发出的一套采用面向构件技术实现企业级应用开发、配置、运行集成一体的综合技术平台。平台可以开发企业整个应用软件体系,并为其提供一个组件化、低代码、可视化的软件开发模式。 ...
  • 精益开发 我先把精益开发的概念和七条基本原则列一下,然后再逐条原则表述一下我的理解。 概述 精益(Lean)管理的思想起源于丰田公司,旨在创造价值的目标下,通过改良流程不断地消除浪费。这种方法现已被广泛用于...
  • 敏捷开发的主旨: 一:个体及交互比流程与工具更具价值 二:可用的软件比冗长的文档更有价值 三:与客户的协作比合同谈判更有价值 四:对变化的响应比遵循计划更有价值直接聊宗旨有些抽象了,举些栗子就会发现这...
  • 力软敏捷开发框架 7.0.6 源码下载 ...力软敏捷开发框架是基于.net平台研发出的一套采用面向构件技术实现企业级应用开发、配置、运行集成一体的综合技术平台。平台可以开发企业整个应用软件体系,并为其提供一个组..
  • 最近一段时间,我一直在反复思考一个问题:我们的软件研发管理体系应该是怎样的?在不断思考的过程中,...关于研发管理,百度百科中这样定义:研发管理就是在研发体系结构设计和各种管理理论基础之上,借助信息平...
  • 在前面的文章中,我曾和大家分享了软件研发管理体系建设的一些见解,其中涉及对软件...今天要谈的这个话题主要包括以下几点: 1、研发体系框架 2、人员组织能力 3、项目管理能力 4、技术研发能力 5、持续交付能力 6...
1 2 3 4 5 ... 20
收藏数 10,630
精华内容 4,252
关键字:

敏捷开发 研发体系