UDN-企业互联网技术人气社区

板块导航

浏览  : 1938
回复  : 0

[持续部署] 给一个团队写的敏捷实践方案

[复制链接]
开花包的头像 楼主
发表于 2016-7-20 18:45:39 | 显示全部楼层 |阅读模式
2.webp.jpg

  刚接触敏捷时,感觉挺好,当实际执行时,却是半敏捷半传统的路数,毕竟要实行真正的敏捷需要超强的队员,对口的研发环境,以及普遍的认可度。敏捷在国内已推行多年,实施起来难度还是很大,应该说很多团队都不算是真正的敏捷。既然不算,我给X团队写的一篇方案,自当书面文档,当然据我所知也没有实行推动起来,毕竟每个团队都有自己的现状。

  内容大致如下,也算是对我之前的两个团队敏捷实施的总结吧,虽说实施效果有时候也走样,毕竟也是个经历。

  大前提 : 要求全员整体参与产品的研发过程,从需求,设计,到开发测试等等。

  准备阶段

  分析原始需求,整理大体流程,画原型图/为提高全员对需求的理解程度,可全员参与,初步分析出数据结构,搭建开发环境等开发过程中所必备的技能,各岗位角色安排到位。确定整体迭代过程,及第一迭代的内容。测试可确定测试计划。

  每日站会,内容只涉及昨日工作内容,今天准备做什么,目前有什么问题。切忌深入讨论细节问题,占用大家大量时间。

  看板,工作完成后,主动更新看板,将工作进度时刻暴露在外,大家心中有数,一旦工作进度无法保证,可协调其他队员帮助完成或移至下迭代开发。

  开发习惯的问题,开发节奏较快,要求大家尽量保持良好的习惯,好的注释,变量命名,日志输出,面对面交流等等,一切提高效率的做法都应该被提倡。

  迭代按两周一个周期。

  迭代

  迭代首日,开迭代计划会,人员,全员参与,包括开发,测试,产品,业务等相关干系人。内容,由产品业务人员讲解本迭代内容,全员讨论需求存在的问题,记录有歧义内容。全员评估本迭代需求任务复杂度,确定工作量。基于现有情况可确定本迭代能否完成。各开发人员认领需求,并复述需求内容,确保与产品要求一致,开发拆解需求为具体任务,并确定工作量。会后录入系统中,统一管理。测试人员可离场编写本迭代测试案例。

  周二至下周三周四,是实质开发阶段,开发前不着急编码,需要有一定的设计识别过程,较复杂的情况,需要评审过后再开工。

  开发完成做好单元测试,更新任务状态并口头通知测试、产品人员测试。验证功能。

  测试在此期间编写完案例,开展测试,并与产品业务讨论下迭代需求内容。

  中间可穿插半天讲解下迭代需求,提前熟悉内容。

  周三周四可部署稳定版本,全面测试,并修复bug。若上迭代遗留bug影响关键流程的,马上解决,其余可按时间安排修复。

3.webp.jpg


  周五

  上午迭代验收会,开发确保全部功能开发完成,不要遗漏功能。下午迭代回顾会,回顾本迭代流程中存在的问题及可改进的地方,再下迭代中完善。

  迭代过程中若需求有变动,工作量不大的可动。大的需要评估,移到下迭代或某个周期内完成。

  集成测试,全部迭代结束后,安排一段时间做系统性测试,测试,产品,用户均可参与进来。

  投产演练,为确保上线顺利,上线周期及一旦上线失败后的还原措施,都需要在此阶段不断尝试,以防在正式投产时出现意外。

  敏捷实施具体某一个迭代,还是传统瀑布开发,从需求分析,概要设计,再到开发测试。两种过程相辅相成,切不可割裂开来。

原文
作者:霍琛布鲁茨   来源:开发者头条

相关帖子

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部