潛龍，勿用

在上篇文章中提到,敏捷开发并不是万能的,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。而项目刚开始的时候,也就是我们整个团队开始摸索敏捷开发的时候.        第一次开始正式进行会议是把所有的相关人员都集合到一个会议室,在这会议室有三面墙,一面是窗户玻璃.        为什么要提会议室的三面墙呢?这时候是敏捷教练开始让大家一起活动了,首先因为整个团队是新

关于敏捷开发,本人在很早之前已经了解相关的概念,第一次对他了解是在准备软件考试的时候了解到的,然而真正的在实际的项目中运用是从去年一月份,到现在也差不多快两年的时间了,在这两年的实际对敏捷开发这个东西从陌生到熟悉,然后又从熟悉到陌生,一路走下来感觉这个东西还是很有味道的,接下来的内容主要是聊聊这个所谓的敏捷开发.        当然,官方有很多关于敏捷开发的解释,先看看下面的解释.

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

在前面的三篇文章中对敏捷开发进行了一个背景铺垫,是以笔者个人的经历为主线来逐渐从个人的角度来理解敏捷开发.        通过结对编程完成了开发框架的搭建,在搭建框架的时候其实我们的正式敏捷流程还没有开始,真正开始是大家都可以行动的时候.当敏捷开始的时候整个团队定是在相关的分工下完成任务,所以不同的人有不同的角色,接下来主要对敏捷开发中的角色进行了解.        第一个

通过上篇文章我们已经知道了敏捷角色中PO的角色内容,接下来的一个敏捷角色在敏捷开发中非常关键,但是往往很多项目实践中都没有很好的把控好这个角色,让他或多或少的没有起到相应的作用,这个角色就是ScrumMaster. Scrum Master（SM）        敏捷开发中的SM即ScrumMaster，字面意思是敏捷专家或者敏捷大师，即熟悉敏捷开发模式及敏捷实施流程的人员，一

在敏捷开发中除了PO跟SM之外,另外一个非常重要的角色就是TEAM,也就是我们的开发(有些包括测试)团队.      因为在每个迭代进行的过程中,真正的将需求实现为用户需要的产品是在团队的同心合作下进行的,因此将一个新的团队磨合成敏捷开发所要求的自组织团队是一个比较难得过程,尤其是在实际的开发进度和需求等不定因素的影响下.     因此提高Team的凝聚力是创建自组织团队一