敏捷之痒

普天之下莫非王土,貌似是真理。。。额。。淡定淡定,土也有肥与不肥之分。。哈哈。

 

灰常有趣,现在公司开发模式采用了敏捷开发之scurm方法,最初也是神密与憧憬还夹带着疑问,嗯,是的,不了解则无法理解。于是就scurm进行中。。也许是太了解了就容易生厌,就好像夫妻有个什么七年之痒似的,我还没7年就有点痒了。最初的神密没了,疑问变成了反问,当然憧景还是有滴。

 

每当看到敏捷开发的文章都来一段《敏捷宣言》,立马站直抬头看天空,高喊:

个体与交互 重于设 计过程和工具      

可用的软件 重于 完备的文档      

客户协作 重于 合同谈判      

响应变化 重于 遵循计划

 

然而念多了就会觉得喊口号容易,干事情真难。于是乎就从反过来的角度思考宣言,才发现这宣言也是狗屁不是啊。说的好听点是废话。哦,我是不是得罪大多数敏捷开发者了??我才狗屁不是。。。对对,你们是狗屁,我不是。。哈哈

我们之所以会认可敏捷开发,一定程度上是因为之前的开发过程太纠结,无序的计划,无尽

的任务和无尽的交流加上无尽的BUG。所以想寻求一种开发方法来解决,敏捷开发是一种很好的方法,他解决了什么呢?

  1. 使用迭代来解决开发周期与目标的混乱
  2. 使用合理的交流方式来促进问题的分析与解决
  3. 有了好的迭代就如同有了可执行的计划,所以交付制品也更加快速,安全
  4. 提高了对个体的要求,一方面个体除了会完成任务外,还要会交流,交互,更重要是明白你不是一个人在战斗(哈哈)
  5. 领导放心了,因为他能看到任务在一个接一个的咔嚓掉。

 

除上面这些之外呢?也许有吧,哦,你会说:

完备文档被好的制品替代了?

和客户有交流了?

拥抱变化了?

 

老兄,这些问题你觉得哪一个开发方法不重视?如果不重视也不是开发方法的问题,而是具体执行人员的问题,这些问题即使使用了敏捷,你解决了吗??反问自己吧。

说了些打击自己和他人的话,也要找找解决的方法。最近因为工作上的原因,所以就看了一些关于敏捷的资料,也切身的思考了实际开发中对敏捷的应用。也发现很多人都在分析敏捷开发在实际应用中存在的问题,也有提出了解决方法的人。我不是高手,但别人不能阻止我像高手那样叼根烟。。。所以我也叼根烟。咳咳。。

Scurm的可谓是覆盖面够广呀,真是做到了个体的交互,“客户”的协作,响应变化。但是咱们拿出来分析一下:

 

个体的交互?

就是你和我交互了,我把可以说的随便说一下,不想说的不说,交互的结果就是你知道了又怎么样呢?

敏捷思想是希望能把需求也好、问题也好,拿出来沟通,但要让开发人员把这些东西拿出来说还是要靠方法滴。Scrum约定了很多会,最值得提的还是站会吧,这个是每天都要做的事情,做的好提高效率,做的不好就是浪费时间。借用网上一个家伙提到的例子:

站立会议=审问?

 

引用

 曾经在某处看到国外的Stand up:          而我们的Stand up :            

                                                    

   看到这两个图人员的站立形式,一切都懂了。本来站立会议是很随意的,但我们的却是一天中最恐惧的时刻。我们采用问答式,而不是讨论式。L:“你昨天做了什 么?”D:“呃~~,**功能还有一点问题没解决。”L:“为什么没解决?那什么时候可以做完?”D:“因为**原因,估计也许大概还要一个上午左 右……”

   一大清早给你来个这样的审问,还有什么心情工作?

我们自己想想,是不是这个样子?所以我们这些当兵的就只好把可以说的随便说说了,有问题?没有,咱们没问题。领导我保证完成任务。好吧,领导放心了。

我觉得吧,不能这样,既然是站立会议就是要快,要有效。把大家一起聚集起来是讨论问题的,领导也好、Master也好不要去问些无趣的问题,如果想要问问题就必须把每个开发任务都弄清楚,知道任务的关键点。

 

比如你问:HI,兄弟这个任务要搞定千万级数据缓存问题耶?你现在用的什么方法呢?

被问的人说:我不知道耶,正在想。

那好了,这个问题效果来了,不需要再解释了吧?

 

个体的交互,目的是交流沟通,把一些潜在问题消灭掉,而不是领导问进度,要充分相信自己共事的人,把问题分析清楚,不要把任务逼成潜在问题。

一个团队不要把阶层划的太过份,很多问题不一定是老手才能解决,有时新手也能有更加出色的点子,解决方法更加独特有效,要充分发挥团队的作用。

做为Leader更是要把外界的压力减到最低,让团队成员在执行任务时可以专心,不能因为自己压力大,就让成员也跟着无序,心急。否则要Leader干什么?同样的,团队成员也要负起自己的责任,把事情做好,有问题就要尽快交流。这样Leader才能知晓,调配资源。最终目的就是把开会变成沟通,而不是碰头,头都碰烂了,最后发现啥也没干。

 

“客户”的协作,交互可用的制品?

 

之所以敏捷开发会强调客户的作用,就是希望能让客户把问题充分描述,以保证开发的产品符合要求。在很多时候客户的需求不一定是合理的,如果不告诉客户,结果就是客户和开发都成了SB,不要以为收到了客户的钱就是成功。最后客户SB的发现自己付的钱没用时,会让你吐的更多,这时你更SB。

 

敏捷开发就是希望把问题解决在需求阶段,让一个个迭代来与客户交流,让客户了解制品,对产品产生概念,从而反馈到最真实的需求模型。好了,我们真的这么做了吗???

很多时候,我们开发人员又如何能知道客户真实的需求呢?需求背景描述?跟着现场人员讨论?与客户讨论?都是方法,那最终体现是什么呢?怎么算能认账?

敏捷不等于没文档,制品也不能代替文档,与客户交流就更加是了,说了一大堆,没有个记录,你敢说你交流的充分了?绝大多数时候,不写文档都是因为懒,然后敏捷说不需要完备的文档,这下好了,直接就可以欢天喜地了,不用写文档咯。。自己问问自己是不是这样?文档真的不是DOC,PPT,文档有很多形式,与客户交流时可以用用例模型,界面原型工具,有时文档就是一段话,甚至是一句话。比如:客户希望把登录按钮默认为按回车。

文档的目的是为了记录、传播、更加充分的讨论,你一个人懂了不代表所有人懂了。把自己的工作做踏实点,把建模过程做起来。从源头上提高交流的效率效果,文档有很多,我比较推荐的方法是:建模。

 

UML建模是软件开发领域的一种描述语言,他的好处是统一、规范、描述性强。从客户开始就可以有需求建模,界面原型建模等。这个工作客户如果没有能力就让需求分析人员做,让客户明白后再转到开发。这种事情不存在增加工作量,和客户交流总归是要有文档的,只不过是换种形式而已。

 

开发则更重要了,一个需求如何开发,一拍脑袋就这么干吧,拍脑袋的过程是在干什么呢?不就是在把需求分析成一个个的程序模型吗?为什么不记录下来呢?把分析的过程转成一种可描述的语言,这不是更好?除了你自己之外,还可以上其他人阅读。而且用模型工具也能一定程度上提高分析效果。同样的,UML建模之后再与市场人员进行交流时就更加充分了,UML不仅仅是只有开发人员懂。市场、测试甚至很多客户都具备这样的能力。而且图形化的描述,客户也更能理解接受。

 

响应变化?

 

计划赶不上变化,这大多数情况下就是事实。敏捷开发是想通过迭代及沟通来解决变化给项目的影响。然而更多的时候变化就是会影响到计划,而且让人很不爽又不得不干,理由很多,如:什么客户就要这么干,那个时候必须要,云云。。。其实这个事情真的很急,但是急有什么用?

所以我对响应变化的理解是:把计划做到容忍变化才是解决之道。通常公司有了绩效考核后会对开发工作进行量化,好了,领导一看,反正一个月就这么多时间,给我排排满。然后各个开发负责人就排排满。迭代之初大家兴高采烈的领了任务,估了任务时间,咔嚓。等到快要交付的时候,因为鸡鸭鱼的原因,狗没吃到屎,我去。

 

Leader很深情的说:没办法,大家加加班吧,领导说了要做完,客户有这个要求,弟兄们地球会因为我们的努力继续转的。然后与客户打交道的同事用上吊来威胁你:兄弟,不做完,我就死在这了,我能不能活就看你了。看着办吧!

怎么办?我不入地狱,谁入?于是乎噼里啪啦,回了句:哥能行。

好了,若干时间后,BUG大爷出现了。。。。。。。。。。。。。。

 

呵呵。开个玩笑,计划与变化,是个很难协调的话题。但是我一直认为一个计划一定是可执行的,如果一个计划只是一种形式,那肯定会有很多问题。变化也是相对于计划才有的,对吧?那好就把计划与变化划分清楚,把什么是计划什么是变化弄清楚。

迭代的目的就是把计划做到可执行,把一个短周期内安排的事情做完,给客户提交一个可信的制品。如果你的计划总是有这种那种原因被打断,一个迭代周期总是不让别人爽,那么你自己也不用想爽。这就得说说Scrum的需求评估,通常在Scrum会议上任务是由成员估时并认领的,那么,这个估时准不准就会成为重要的因素。不准,是多了少了?不管是多是少都是不准。怎么样才能准?如果到这时还不明白,那就继续拥抱变化吧!

呵呵,其实很简单,需求描述准确,开发人员理解准确,估时还会相差很大吗?如果很大那就是人品的问题了。

对了,还有测试,测试一定要懂的。

 

 

总结一下:软件开发是个系统工程,他涉及的人是方方面面,人涉及的多就会有交流问题,交流大家都知道很容易产生偏差,只有想办法把偏差减少才能减少变化。前面聊的个体交互与客户协作都是强调了内容的一致性,这才是敏捷开发带给我们的。

不管是和团队成员交互,还是与客户交互,要形成一致的语言,只有语言一致了才能理解相互在说什么,干什么。


 

posted @ 2011-09-03 12:15  5207  阅读(1716)  评论(0编辑  收藏  举报