燃烧JAVA

1. 写UT时还无代码实现，但要包含对外的接口，这时就有设计，这里就将开发融合到了具体场景里去了，而在传统的开发模式中，服务接口前期并未直接参与到具体场景，都是完全实现后的再调用，凭空设计的风险就要大。2.  传统的设计,可以说是based on assumptions and experiences.     敏捷的设计,可以说是based on fact and usage

Product Owner 产品负责人，代表了客户的意愿，负责编写用户需求（用户故事），排出优先级，并放入产品订单（Product Backlog），从而使项目价值最大化的人。ScrumMasterScrum教练，作为Team Leader和Product owner紧密工作在一起，及时给团队成员提供帮助，促进协作，保护团队，使之免受外界干扰。time-box时

在Spring环境下做单元测试常常遇到很多问题，Controller层还好说，Spring本身提供了很多方法来支持，这个可以看我的另一篇文章http://blog.youkuaiyun.com/ynwso/article/details/8672310但是在服务层和持久层，如果是使用注解注入的方式来设计的话，用Mock来替换真实的注入类就很麻烦了，还好我们有Mockito框架。但一段代码，

最近在搞敏捷，发现了很多的问题，在传统的开发过程中，如果是规范的大公司，通常都很重视文档，各种流程也会比较规范和完整，但是这样的公司毕竟不多，很多大公司表面上是CMMI，RUP之类的，但是实际开发还是走的瀑布，而且前期的分析设计文档通常也不是很完善。我知道很多人就是因为这些不规范的流程，不专业的设计文档，于是跳槽去找规范的公司，但是跳到新公司后发现面试的时候说的那么好，开发的时候和原来的公司也没多

之前在公司有推敏捷，但是由于没有好的项目来实践，一直也没有很好的实际应用起来。我们的敏捷工具用的是scrumworks，这个虽然好用，但是感觉还是没有看板那么直观和效率高，不过用工具可以保存记录，看板就没办法做到了。        今天在公交上突然有一个想法，既然目前没有项目在做，事情比较杂，何不用看板来管理日常任务呢，于是说做就做，一到公司就把一个大白板拖到了办公室，标识出了to do,do

早几天产品上线，发现了一个bug，而这个bug之前是不存在的，也就是说是我修改了另一个功能的时候导致了原来正常的一个功能出现了问题。这个bug的原因很简单，我有一个对象，在页面上会用到，而我现在需要把这个对象存到数据库，里面有一些信息是不需要的，为了避免存入过多的东西到数据库，我在存之前就清空了这个对象里面的一些数据。我忘记了我是在操作同一个对象，我的这个清除操作同时影响到了这个对象在页面上的展示

今天刚参加完2013深圳敏捷之旅，有幸在一天收获那么多敏捷知识，听那么多大牛分享管理经验，真是非常不错。        今天的议题比较多，吴穹老师的自动化测试，华为胡伟分享的打造自组织的敏捷团队，李小波的coding dojo，最后腾迅两个项目经理搞的ball-point游戏，还有中国平安的单超分享的敏捷经验都让我印象深刻。        吴穹老师的演讲恢谐幽默，同时内容也是非常丰

经过两天的CSM的培训，颠覆了我们很多的旧有想法，先简单的记录一下培训中的一些要点：约定大于监管：监管是管理层面的，还是旧有的模式，而约定是团队自己的法规。工具：传统的管理工具是服务于管理者的，更多的是PM在使用，而敏捷中的工具是服务于个体的，比如白板，便签等。会议与过程：       需求预定义过程：发生在sprint会议前，更确切的说，这不是一个会议，而是一个过程，

1. 下载scrumworks，下载地址：http://www.collab.net/downloads/scrumworks， 在Try ScrumWorks Pro on-site 项点击download. 需要注册会员。 小团队或是学习目的话建议下载HSQL版本的，不需要安装和配置数据库，如果是Mysql版本的，需要另外安装Mysql并配置数据库。2. 安装过程中会需要下载jboss和一

PB - Product backlog, 是一堆用户故事，用三个级别的用户故事，

这是

事实上，很多人经常错误地认为Scrum和敏捷是一回事儿。Scrum的大面积应用和流行已经使它成为很多公司实施敏捷的默认选择了。然而，随着近来看板的兴起，一些人则把看板作为敏捷演变过程中新的篇章。Abby Fichtner甚至认为看板就是新的Scrum。也许是因为我一直以来都在创业型公司工作，我很推崇Scrum自组织和持续反馈的理念，但接触了看板以后却被深深吸引，它将引领下一个敏捷时代，也将利用精益

原文地址：http://developer.51cto.com/art/200907/134068.htm敏捷开发对软件架构设计产生了一定的影响，让人产生敏捷开发中“轻架构设计”的印象。文章就笔者经验，和大家一起讨论一下敏捷中的架构设计这个话题。 首先，笔者认为敏捷开发是一种软件过程方法和工具，敏捷开发本身并不能代表架构设计。这就好比建筑架构设计和建筑工程管理之间的差别一样

scrum最传统，也是最直观的管理工具就是白板和即时贴。一个团队通过一个白板和即时贴来完成对scrum中story和task的跟踪管理。见下图：图一：任务看板：分为三列，todo表示为开始，doing为正在进行中，done表示已完成。团队的成员每天将自己负责的任务移动到相应的栏中，并且更新其剩余时间。图二、燃尽图：团队成员每天负责将所

敏捷流程scrum中的很重要的一个制度之一每日站立会议  为啥不用email汇报代替每日会议1. E-mail不能取代每日会议2. E-mail只会增加沟通成本3. 而且不能提供细节信息或者给他人问问题的机会4. 也不能帮助其他成员解决问题。  站立会议的目的1、 让所有人了解其他人在做什么当前项目计划进展如何 2、 帮助大家解决那些阻碍做事情的问题, 以

实践敏捷，我们用Scrumworks管理项目在实践中，我们选择用Scrum进行项目管理，选择的工具是Scrumworks Basic版本（V1.8.3），各个Stakeholders都可以通过Scrumworks Server来加入讨论，了解进展。具体我们是这样做的：1. 在公共服务器上安装Scrumworks Basic版本，加入用户，建立权限2. PO在“Uncommi

最近开始研究敏捷开发，公司的项目管理有些混乱，效率不高，一直想着有没有什么改进的办法，最后想到可以试试敏捷．昨天公司开会我提出了做一些改革的想法，希望公司开始慢慢推行敏捷来提高沟通效率，提升交付质量．领导层明确表示支持，但是可能没有那么快开始全面实行，而且公司现在基本上没有人在敏捷管理这块有经验，希望我们在一些小的项目上慢慢试行．因为没有经验，我最近买了不少书，也在网上找了很多的资料来了解Scru

1. 到http://www.collab.net/downloads/scrumworks 下载最新的scrum works pro，目前最新版本是6.1.0    下载linux版本的scrumworks-pro-6.1.0-mac_linux.tar.bz2     从http://danube.com/scrumworks/pro/installer/packages 下载需要的包

这篇文章的原文在这里（原文链接）（下文不是全译，也不是部分译，我只是把其总结，有我自己的发挥，但是原意大致不变），这篇文章完全是在调侃Scrum的，作者第一段就是一个免费声明，其说他是Scrum和其它敏捷方法的big fan， 他也认为Scrum 100% 对 软件开发可行。作者使用Scrum 5年了，也公开作过几次敏捷的分享会。他觉得写这篇文章只是为了好玩，因为他们戴上Edward de B

每日站会（Daily Scrum）是大众所熟知的Scrum的代名词之一，作为Scrum中的标志性活动，却因为执行不易历来饱受争议。很多有心尝试Scrum的项目试行一段时间后，往往是在站会上最先打了退堂鼓，继而产生质疑。质疑的原因有很多，首当其冲的抱怨是“没劲”（low energy），这种情况下的站会被当作是例行公事的汇报会，听不到什么实际内容的讨论，枯燥无味；在另外一些团队中，站会又显得

敏捷教练与项目经理在被奉为“项目管理圣经”的PMBOK中，对项目经理在各阶段的职责有着清晰的界定，比如项目经理制定规则、安排进度、监控执行中的各项风险并实时汇报状态，等等。然而在敏捷的世界里，虽然对于Scrum master的职责也有界定，然而一名合格的敏捷教练（coach）的标准就没那么清晰了，更多了几分“只可意会，不可言传”的味道。“对团队提供适度的支持，既不能太多，也

每日立会！    昨天开始了第一次的每日立会，没有经验，所以只是提出了3个问题   1. 今天做了什么？   2. 明天的计划？   3. 有什么阻碍？   大家一开始不知道要说什么，我先是简要讲了一下我的工作更新，然后一个一个点名，大家也就是简单汇报了一下工作进展，感觉没有太大的意义。   今天又特意到网上找了很多的关于每日站会资料，发现我们的每日站会的确存在很多问题，我

在这个公司工作五年多了，因为项目不同，角色不同，层次不同，也见识与经历了我们在软件开发中的各个步骤， 花些时间，总结与回顾一下我们的开发流程。当然，先要说明一下前提：我们做的是产品开发，一年一release，而不是项目定制开发这是一个产品的持续开发、重构与维护，而不是从头搭建一个产品 2009年以前，我们采用的是十分严格的瀑布开发模型，在项目初期就能拿到非常详细的spec，但201

不知道是不是因为勾起了大家的牌瘾，最近一阵"扑克"估算很是火了一把，在几个项目尝试后很快蔓延开来，很多项目团队都跃跃欲试。尝试的过程中难免产生一些困惑，干脆在这里做个澄清，把我实践下来所理解的扑克估算的方方面面跟大家一一道来。 在开始之前，首先需要澄清的是，在某种程度上，估算其实是在预测未来！预测未来是件非常难的事情，我们看看天气预报，就知道人类在这项工作上有多

成功的变革不是完全的自上而下或者自下而上，团队成员的参与，与管理层的支持同等重要。ADAPT模型在很多变革推进的模型中，我们都会看到这个经典的模型。意识（Awareness），渴望（Desire），能力（Ability），推广（Promotion），传递（Transfer）意识提升工具：帮助团队意识到问题的存在和变革的必要通过沟通，说明问题的存在使用度量

主题正确的模式正面例子反面例子改进建议自组织团队成员都参与到其中, 对话和讨论发生在团队成员之间。团队成员争先恐后的从任务版上领取任务,识别不同分类的需求(QA 和开发人员一起工作)团队成员不是相互讨论，而是向领导汇报工作"看着你的鞋子" 技巧:

为什么Scrum对于我们team来讲，这其实是个被动的过程。我们部门之前在一些team实行过Scrum，可能是感觉效果还不错，而且觉得原来的瀑布模型太过古老和死板，于是决定今年年初开始全面实施Scrum。由于大家都是新手，公司采用了两个方法： 一是超密集的培训。请专门机构来培训；请US的同事来培训；请实施过Scrum的同事来培训...二是实战演练。组成几个临时的team，用两个

深圳敏捷之旅这次是第5次举办了，也是我第三次参加，本来买不到门票的，还好ShineScrum的朋友帮忙又弄了些票，这才有幸与深圳近300位敏捷爱好者共享了这次敏捷盛宴。       这次到会的嘉宾都特别给力，一天的分享让我有些消化不了，在这里简单总结一下，一方面帮助理解，另一方面也与大家分享一下。       第一位嘉宾是CCGI首席执行官苏于登，他分享的是突破敏捷的极限-45天草根天团的