以IPD方法论为基础,采用原型+迭代的开发模式,并以质量优先为原则,持续对用户做价值交付. 使用JIRA+WIKI+SVN管理整个的研发过程:JIRA管理任务和进度:SVN管理代码和过程文档:WIKI管理计划.规范.过程报告等. 沟通机制以信息透明.对称为原则,目标是让项目组每个人都明确项目的当前进度和阶段目标,每日晨\夕会,每周例会,每月总结会. 研发状态报告:测试出日报,项目经理出周报,每个人每月写月总结. 研发决策组:开发主管.测试主管.需求负责人.研发项目经理…

项目背景 项目是基于一套公司自主研发的平台做企业信息化的项目管理业务,经过两个里程碑的交付,已经在客户现场使用,每次版本都能按期交付,延迟较少,客户满意度也高. 项目开发过程采用的敏捷的方法,用类Scrum的方式落实,但是项目开发过程太依赖团队Leader,过程记录较少,量化团队成员的工作较难,没有准确的数据支持. 需求管理采用:原型 + 业务描述文档 开发管理:SVN + Wiki 测试管理:Jira + Wiki 反馈管理:Jira 本次Jira敏捷方法论实践的目标:项目过程全部用Jira管…

敏捷流程在Jira中的运用…

每次迭代都分这5个阶段,但每个阶段的时间根据版本情况定,最终目标是:第一个阶段拿到交付范围,在第五个阶段都完成,并拿到本次版本团队所消耗的工时. Jira是项目过程管理的一种手段,跟多体现在工时跟踪,项目额外的风险和依赖性的计划通过Wiki单独管理…

从三个方面概述项目的现状 资源组织结构 资源中的特殊角色 •反馈问题接口人 –测试兼,处理实施反馈回来的问题,Bug复现后分配给开发负责人:需求指向需求做进一步的需求分析 •流程反馈处理人 –测试或开发兼,反馈问题中有很多很流程相关,跟踪问题特别消耗时间,所以单独把流程的反馈拿出来交由专人处理 •报表开发者 –开发兼,报表是跟单据相对独立的业务,并且之前的过程中报表支持的不够完善,所以需要一个开发单独跟平台的开发沟通解决 •平台接口人 –开发兼,把客户反馈.测试发现的平台相关的问题提交给平台,并…

项目当前版本的燃烧图是下面这样的 存在的问题: 1.任务在版本起始时期之后再细化,造成了绿线一直在红线上面.解决方案:版本起始日期定为任务录入结束后的日期 2.工时录入不及时,没有实时反映当前项目组的实际情况.解决方案:每天固定5点统一工时录入 3.客户现场的反馈问题需要重复在版本库中维护,没有好的解决方案,版本库修改完毕后再次修改反馈库…

微服务与敏捷开发(Scrum/Kanban)的核心思想之我见   关于"微服务"和"敏捷开发"的文章网络上有很多,所以这里不再重复叙述这些概念的解释和特点,而是就个人实际工作中对他们的核心思想的理解及运用分享给大家,希望能对大家有所帮助.   当下IT开发领域,"微服务"及"敏捷开发"越来越被各公司及团队重视.但是在交流中发现很多人对"微服务"及"敏捷开发"存在很大的误解,尤其在各公司的…

看板在现代应用开发过程中使用非常广泛,不管是使用传统的瀑布式开发还是敏捷开发,都可以使用看板管理.因为看板拥有简单的管理方法,直观的显示方式,所以很多软件开发团队选择使用看板进行软件开发管理.本文不在对看板管理理论进行过多的赘述了,只是在这里介绍一下如何使用TFS的看板功能.最新版本的TFS提供了功能强大的电子看板(最新发布的TFS 2015 Update 2.1中,也包含了对看板功能的提升),并且能对看板的显示进行大量定制,而且还加入了泳道的功能.开发团队可以根据自己的需求来定制属于自己团队的…

XP+devOps开发模式与scrum敏捷开发对比,docker虚拟化 我们现在用的就是典型的XP+devOps模式,已经放弃scrum了 现在还很多公司弄docker虚拟化docker非常复杂,当然如果只是用别人的只用记一个docker命令就行了docker虚拟化消耗额外的系统资源较少 传统虚拟化会占用一点系统资源.通常日志是写在挂载进去的盘 或者直接通过其它协议扔给日志中心服务器传统虚拟化 启动 销毁 部署 时间都较长docker部署这些就很短 把一个应用(nginx php node) 等…

之前我们分享过<CODING 如何使用 CODING 开发 CODING>的文章,时过境迁,现在 CODING 研发管理系统已经上线了如持续集成.缺陷管理.测试管理等 DevOps 中的重要功能,并增加了对 SVN 的支持.借此机会我们以自身的研发流程为例,来展示一下 How CODING uses CODING to build CODING 2.0. 企业级一站式软件研发协作平台 CODING 现在的团队有 100 多人,分布在全球各地(深圳.北京.成都.西雅图等),均使用 CODING…