敏捷之痒

2011-09-03T04:15:00Z

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

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

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

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

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

客户协作重于合同谈判

响应变化重于遵循计划

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

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

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

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

除上面这些之外呢？也许有吧，哦，你会说：

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

和客户有交流了？

拥抱变化了？

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

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

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会议上任务是由成员估时并认领的，那么，这个估时准不准就会成为重要的因素。不准，是多了少了？不管是多是少都是不准。怎么样才能准？如果到这时还不明白，那就继续拥抱变化吧！

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

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

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

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

本文链接

LinqToSql开发实践之认识LinqToSql

2009-11-13T08:37:00Z

一、Linq是什么Linq何许神也？MSDN中有这么一段话：语言集成查询 (LINQ) 是 Visual Studio 2008 和 .NET Framework 3.5 版中一项突破性的创新，它在对象领域和数据领域之间架起了一座桥梁。突破性的创新，这个称号确实让人一惊，呵呵。LINQ是Language Integrated Query的英文缩写，从这串英文可以看出LINQ是语言，是一种集成的查询语言。目前微软提供的库中已经支持了：Linq To Objects、Linq To Xml、 Linq To DataSets、Linq To Sql以及新近推出的Linq To Entites。Linq通过定义一套查询操作符结合.NET Freamwork实现了强大的查询功能，为此微软也为Linq新增了相应的命名空间以使开发者能够非常简单的应用LINQ的强大功能。

一个google浏览器很意思的东东

2008-09-22T15:46:00Z

在google浏览器刚出来时用了一下，感觉还行，因为用习惯了ff3所以就一直没用它。今天回家后想在自己电脑上也装一个用用，装好后进入设置时发现一个有意思的地方。注意图中的红色区域：

老文新发——快乐的IT时代

2008-07-20T02:51:00Z

记得有一次与同事聊天说道其家里的产业，我叫他去接受并发展下，没想同事却回道：“我爸那份黄昏产业有什么做头！”，我哑然！~~~ 这让我想起了一个久未提及的词汇：“朝阳行业”，IT业可以说是一个实足的“朝阳行业”啦！有泡沫来泡沫去的网络业，也有天天围着制造业转的ERP，还有让陈天桥几年暴富的游戏产业，还有。。。太多啦，现在开个小公司都得用WORD、EXCEL，购物都可以刷卡了！有意思！人们休息时不再老是你家他家的窜门了，改在家里上网了，网上事情多呀，看电影、聊天、新闻。。。。。。。。。。。信息时代，军队都在搞信息化了。

[原创]软件产品策划的思考

2008-07-18T13:13:00Z

看来企业的产品体系的建立关系到的是整个公司的运作，我们可以发现目前一些业务增长稳定的企业都是很好的解决了体系运转问题。创业型企业更多的是要考虑到未来的发展，在产品初期加以足够的规划，为将来的高增长铺路。具有一定规模的企业更多的是平衡企业资源，形成长效机制以合理投入新产品线的投入。

C#访问非托管DLL

2007-08-11T02:28:00Z

来至:http://bbs.mini188.com/showtopic-161.aspx前段时间写了一个读卡器程序，使用到了一个DLL。在.NET 中调用DLL还是相当简单的。我也是转别人的代码，自己的不写。下面就是代码：C#中要使用动态链接库中的导出函数，只能在程序中根据DllAtribute显示调用，无法在运行阶段动态加载，但是我们可以利用WIN32 API的LoadLibrary和FreeL...

随着DzNT的开源，我将投入到.NET的开发当中

2007-05-27T12:35:00Z

一直找不到个理由让自己静下心来学习.NET技术。公司有个项目现在在用.NET写，自己参于了部分，但是程序的架构是选用的WinForm。感觉与我目前使用的delphi相并不是很大，仅仅是语言上的区别，目前SOA吵的火热，所以希望自己能参于到WEB开发，由于对JAVA存有不爽感，所以目前只能用心投入到。NET中。。。。。。夏季的来临，让技术点燃我多年失去的激情之火吧。