我和敏捷开发的故事--结对搭建开发框架

在整个团队经过三面墙的快速对整个项目的三个方面进行整理了解之后,接下来便开始了开发的流程.

因为项目是新开始的,没有一个现有的开发框架或平台,所以初始阶段搭建框架的工作显得十分迫切.如果没有一个基本的开发框架的话,其他的开发人员也是没有进行相关的开发.

因为基本的项目架构的内容已经设计完成,接下来需要根据架构来搭建相关的开发框架,所设计到的技术都有Kissy,Bui,SpringMVC,Spring,Dubbo,Zookeeper,Ibities,MySql集群等.这些技术是组成开发框架的基本支撑,因为涉及行业及相关的保密协议,这里不再对具体框架的内容进行说明了.

搭建开发框架的任务落在我跟另外一个同事的身上,我们两个运用了敏捷开发里的结对编程方式对整个系统的雏形开始动手了.

大概我们两个人用了一个星期的时间(中间加班到十点十一点是很正常的事情……)从数据库底层到页面上层的分布式框架基本搭建成功.这个过程我还是比较欣慰的,因为虽然在过程中遇到了很多的问题和困难,但基本上都能够解决,两个人结对编程的默契度还是非常的高的.我们遇到主要的困难是集中在分布式这块,因为dubbo和Zookeeper这块是我们之前没有接触过的内容.对于新的事物我们还是比较兴奋的,在这个过程中通过学习,解决问题再学习.

另一个遇到比较大的困难时没有网络,由于工作性质的原因,银行内部开发是对安全非常的重视,我们的工作机里的系统都是行里统一给分配的虚拟机,大家都是在虚拟机里进行开发和设计.因而以前给力的巨人--网络,我们基本上是指望不上了.可以想象一下没有网络工作的样子,不过现在反过头来看,快两年的时间基本上已经习惯了无网络的工作环境.但总感觉有点与世隔绝的味道.

所以在没有网络的环境下,结对编程可以在一定程度上能够把无网络的不利因素化解一些.

这里要对结对编程进行一下说明.

敏捷开发是十几种开发方法的统称,极限编程就是这十几种开发方法之一。极限编程包括了十几种实践(就是一些具体做法),结对编程是极限编程的一种实践。

结对编程技术是一个非常简单和直观的概念,能达到事半功倍的工作效果。但是,人与人之间的合作不是一件简单的事情,尤其当人们都早已习惯了独自工作的时候。两个有经验的人可能会发现配对编程里没有什么技能的转移,但是让他们在不同的抽象层次解决同一个问题会让他们更快地找到解决方案,而且错误更少。

在我们平时的编程当中,如果遇到一个非常难解决的问题(困难到对该项目产生厌烦的态度),那么你势必会希望录求帮助,无论是从信息量庞大的网上(这个路暂时在我的工作环境中是不通了),还是从身边的同事那里,我们都会努力去解决。这个时候不妨采用结对编程试一下,其它的不说,可能感觉就不同。搭建开发框架是笔者对结对编程一次感觉良好的实践体验.

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-10-17 18:04:04

我和敏捷开发的故事--结对搭建开发框架的相关文章

我和敏捷开发的故事--敏捷角色PO

在前面的三篇文章中对敏捷开发进行了一个背景铺垫,是以笔者个人的经历为主线来逐渐从个人的角度来理解敏捷开发. 通过结对编程完成了开发框架的搭建,在搭建框架的时候其实我们的正式敏捷流程还没有开始,真正开始是大家都可以行动的时候.当敏捷开始的时候整个团队定是在相关的分工下完成任务,所以不同的人有不同的角色,接下来主要对敏捷开发中的角色进行了解. 第一个要说的角色是PO 敏捷开发中的PO即ProductOwner,字面意思是产品或业务负责人,即熟悉该产品所有业务相关的逻辑.流程.设置等方面事宜的人员,一

我跟敏捷开发的故事--背景

关于敏捷开发,本人在很早之前已经了解相关的概念,第一次对他了解是在准备软件考试的时候了解到的,然而真正的在实际的项目中运用是从去年一月份,到现在也差不多快两年的时间了,在这两年的实际对敏捷开发这个东西从陌生到熟悉,然后又从熟悉到陌生,一路走下来感觉这个东西还是很有味道的,接下来的内容主要是聊聊这个所谓的敏捷开发. 当然,官方有很多关于敏捷开发的解释,先看看下面的解释. 敏捷开发以用户的需求进化为核心,采用迭代.循序渐进的方法进行软件开发.在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子

我跟敏捷开发的故事--三面墙

在上篇文章中提到,敏捷开发并不是万能的,而是要结合自己公司的特点和问题摸索出适合自己的一套模式.而项目刚开始的时候,也就是我们整个团队开始摸索敏捷开发的时候. 第一次开始正式进行会议是把所有的相关人员都集合到一个会议室,在这会议室有三面墙,一面是窗户玻璃. 为什么要提会议室的三面墙呢? 这时候是敏捷教练开始让大家一起活动了,首先因为整个团队是新组建的团队,对整个系统的框架,架构,业务,流程等内容都不是很了解,敏捷教练为了让大家能够在最短的时间内去消化这些内容,就依托这三面墙来对比较核心的内容进行

敏捷开发之故事墙

需求澄清后,SE把所有的故事卡贴到故事墙上,等待开发人员的开发.故事墙的模板为: 分析      : 需求澄清完成后,SE把所有的故事卡都贴到分析阶段 等待开发: 开发人员和SE确认了需求,明确了做什么以及怎么做以后,把故事卡从分析阶段移到等待开发 开发中   : 开发人员一次只开发一张故事卡,把相应开发的那张卡移植到开发中 阻塞      : 如果开发过程中,由于配合的原因,导致故事卡无法继续走下去,则把该卡移动到阻塞阶段 开发完成 :如果开发完成,并向SE  SHOW CASE以后,开发人员

项目管理(十一)- 敏捷开发搜集故事

你怎么收集故事?本文章告诉你如何与用户一起工作,如何和他们沟通来发现故事 下面四个是收集故事最有效的一些方法 一.用户访谈 1.是许多团队用户获取用户故事的默认方法,访谈成功的关键点是访问正确的受访者 2.不要只询问“你们需要什么”,大多数用户不太善于理解,更难以表达他们的真实需求 3.最好从背景无关的问题开始提问.这样就能从客户那里获得更多样化的回答 例如: “为了让我们的产品在浏览器里面运行,你愿意舍弃什么?" 用户可能有很多种回答,无论那种回答,对我们来说都会有很大的意义 二.问卷调查 1

20155327 实验三 敏捷开发与XP实践

20155327 实验三 敏捷开发与XP实践 实验内容 任务一 参考 http://www.cnblogs.com/rocedu/p/6371315.html#SECCODESTANDARD 安装alibaba 插件,解决代码中的规范问题. 在IDEA中使用工具(Code->Reformate Code)把下面代码重新格式化,再研究一下Code菜单,找出一项让自己感觉最好用的功能.提交截图,加上自己学号水印. public class CodeStandard { public static v

用户故事与敏捷开发方法笔记06

用户故事得到这么多人的肯定,是因为它自身的优势有很多:1.用户故事强调口头沟通,因为传统的通过各种文档进行表达,每个人对于文字的含义的理解都不同,所以在阅读文档的过程中可能会因为理解的不同对项目的完成造成影响:2.人人都可以理解用户故事,并且用户故事可以增强人们对各种事件的记忆:3.用户故事的大小适合做发布规划以及进行编程和测试:4.用户故事适合于迭代开发,项目过程中可以写出一部分故事然后就进行编码和测试5.用户故事鼓励延迟细节:6.用户故事支持随机应变的开发,因为用户故事注重口头交流,而且很容

《用户故事与敏捷开发》阅读笔记02

 <用户故事与敏捷开发>阅读笔记02       这周读了<用户故事与敏捷开发>的第四至七章,第四章讲述的是如何搜集故事,也就是如何正确的去找到用户需求.作者明确指出"引用"和"捕捉"是不合用的.所谓"引用"和"捕捉",我想是通过用户对功能的表述,开发人员从中获取需求信息吧.如果是这种方法来获取需求,正如作者所说,用户不会知道所有的需求,所以只靠着这方法是远远不够的.对于故事编写的数量以及程度,作者认为

敏捷开发(四)- 故事验收测试

接着上篇 "估算故事"讲,故事估算完成以后就要开始考虑如何进行验收测试了,只有验收通过故事才算开发完成. 对于一个故事,开发人员和客户可能会讨论很多,讨论的内容可以以测试用例的形式记录下来,这样就为我们故事测试做了铺垫,目前敏捷开发中测试大约有如下2个步骤    1.将测试要点记录到敏捷的故事卡的背面,任何时候发现新的测试,都可以记录到故事卡背面     2.将测试要点变成全面测试,这些测试用来演示故事已正确.完整的实现 下面说一下什么时候写测试用例,以及测试的方法.  在编写代码之前