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

在上篇文章中提到,敏捷开发并不是万能的,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。而项目刚开始的时候,也就是我们整个团队开始摸索敏捷开发的时候.

第一次开始正式进行会议是把所有的相关人员都集合到一个会议室,在这会议室有三面墙,一面是窗户玻璃.

为什么要提会议室的三面墙呢?
这时候是敏捷教练开始让大家一起活动了,首先因为整个团队是新组建的团队,对整个系统的框架,架构,业务,流程等内容都不是很了解,敏捷教练为了让大家能够在最短的时间内去消化这些内容,就依托这三面墙来对比较核心的内容进行互动. 
这三面墙分别是业务,技术架构和流程.

这里需要再进一步解释一下,因为对于乙方而言要做的内容是空白的,不知道具体的需求,技术,架构等内容,但是甲方已经对相关需求进行深入了解分析,架构也有一个模糊的模型,这三面墙下都有一个主负责人对其进行具体的解释和说明.

比如在技术墙前,架构师会对整个项目的架构进行说明,这里所有的人员都要进行仔细的听,看清楚,是所有的人员.因为当架构师讲完之后会找人来对其进行描述说明. 
从这里我们可以看到敏捷对个人的要求是比较高的,这点很重要.

哦,忘了说了,这里的墙都是玻璃可以写字擦除的墙,下面会有图片进行示例,当然,如果没有条件的话可以拿纸条往墙上贴.

具体流程是这样的,整个人员先分三组,三组人员各自在三个墙下,然后听各个主讲人进行讲解.(当时的场面我个人觉得还是比较混乱的…….)当讲述完毕的时候,主讲人会留下一个人,剩下的人然后轮转到下一个墙,然后新来的听众们就开始听留下人的讲述,当然主讲人会对他出现的错误和不足进行及时的纠正.然后大家就开始转圈圈了……

在这个过程中你可以提出你的问题,你可以在墙上画画写写,总之最大限度的把你不知道的内容不清楚的内容去了解它.

技术墙上的一角

整个项目团队通过三面墙的方式对整个项目的技术,业务,流程有了一个初步的认识,这里只是初步,因为在具体的沟通交流中还有很多疑问,很多未知点.这里没有什么是固定死的.

这个阶段还处于初始阶段,除了一些文档,没有任何代码.这三面墙就是让团队对要做的事情有初步的了解.

会有读者
到这里感觉三面墙好像跟敏捷还没有太大的关系,我也是这么认为的, 
而且接下来的事情跟所谓的敏捷也没有什么太大的关系.

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

时间: 2024-08-12 14:33:41

我跟敏捷开发的故事--三面墙的相关文章

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

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

敏捷开发实战(三)--每日晨会,是否只是摆设?

经过上面总结的两篇博文敏捷开发实践(一)–谈谈我对敏捷开发的理解和敏捷开发实战(二)–你真的了解Scrum吗?,我们已经对Scrum进行了整体的认识和学习,这篇博文我们一起讨论和学习,我在实施敏捷的过程发现的一个问题. 问题描述 相信实施过敏捷开发的博友,每天会在同样的时间和同样的地点召开会议,此会议在Scrum五大活动中被称为每日Scrum会议. 有这样的一种现象,团队中的新成员刚开始接触Scrum时,积极性会特别高,在会议中会比较积极的发言,但是对于大部分经过长时间开发的老成员来说,经常会在

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

在整个团队经过三面墙的快速对整个项目的三个方面进行整理了解之后,接下来便开始了开发的流程. 因为项目是新开始的,没有一个现有的开发框架或平台,所以初始阶段搭建框架的工作显得十分迫切.如果没有一个基本的开发框架的话,其他的开发人员也是没有进行相关的开发. 因为基本的项目架构的内容已经设计完成,接下来需要根据架构来搭建相关的开发框架,所设计到的技术都有Kissy,Bui,SpringMVC,Spring,Dubbo,Zookeeper,Ibities,MySql集群等.这些技术是组成开发框架的基本支

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

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

敏捷开发之故事墙

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

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

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

用户故事驱动的敏捷开发 – 2. 创建backlog

本系列的第一篇[用户故事驱动的敏捷开发 – 1. 规划篇]跟大家分享了如何使用用户故事来帮助团队创建需求的过程,在这一篇中,我们来看看如何使用这些用户故事和功能点形成产品backlog.产品backlog是敏捷开发中用来管理需求列表,排定优先级,形成迭代计划,组织开发/测试和交付过程的工具.可以说,产品backlog是一个敏捷团队管理开发过程的核心,所有的活动和交付物都围绕backlog来进行.一旦需求明确,我们就必须在开发过程中持续的跟踪backlog内容的实现和交付过程,确保我们的想法可以按

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

  <用户故事与敏捷开发>阅读笔记04 今天抽出了两个小时读了<用户故事与敏捷开发>的第十二.十三.十四以及十五章并写了这篇阅读笔记.第十二章标题为"故事不是什么".IEEE 830是一本关于如何编写软件需求规格的指南,最突出的特征是使用短语"系统应该.....",但作者认为以这种方式编写系统的所有需求实际是一个不可能的任务.因为用户看到正在开发的软件时总会有有效和重要的反馈循环.他们会改变之前的想法,而且每个需求的成本是不可见的,会造成分析

用户故事驱动的敏捷开发 – 1. 规划篇

敏捷开发现在已经不是新鲜事物了,我们都从各种渠道听到过不同的团队实施敏捷的胜果,听的时候觉得很美,回到家就发现那都是别人家的团队,结合自己的情况一看就发现问题一大堆.就算是最终打算一试,也经常会不知如何开始.这就是我希望编写这份文档的原因,能够找到一个遵循的敏捷项目管理模型,虽然我们都知道没有一个放之四海而皆准的方法,但在更高的层面上我觉得这仍然是可行的.也就是说,管理模型是一致的,但是其中采用的方法可能各有不同,最终目标是唯一的:打造一支可以快速适应变化的高质量团队,并输出高质量的产品! 今天