敏捷之痒
普天之下莫非王土，貌似是真理。。。额。。淡定淡定，土也有肥与不肥之分。。哈哈。
灰常有趣，现在公司开发模式采用了敏捷开发之scurm方法，最初也是神密与憧憬还夹带着疑问，嗯，是的，不了解则无法理解。于是就scurm进行中。。也许是太了解了就容易生厌，就好像夫妻有个什么七年之痒似的，我还没7年就有点痒了。最初的神密没了，疑问变成了反问，当然憧景还是有滴。
每当看到敏捷开发的文章都来一段《敏捷宣言》，立马站直抬头看天空，高喊：
个体与交互 重于设 计过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
然而念多了就会觉得喊口号容易，干事情真难。于是乎就从反过来的角度思考宣言，才发现这宣言也是狗屁不是啊。说的好听点是废话。哦，我是不是得罪大多数敏捷开发者了？？我才狗屁不是。。。对对，你们是狗屁，我不是。。哈哈
我们之所以会认可敏捷开发，一定程度上是因为之前的开发过程太纠结，无序的计划，无尽
的任务和无尽的交流加上无尽的BUG。所以想寻求一种开发方法来解决，敏捷开发是一种很好的方法，他解决了什么呢？
- 使用迭代来解决开发周期与目标的混乱
- 使用合理的交流方式来促进问题的分析与解决
- 有了好的迭代就如同有了可执行的计划，所以交付制品也更加快速，安全
- 提高了对个体的要求，一方面个体除了会完成任务外，还要会交流，交互，更重要是明白你不是一个人在战斗（哈哈）
- 领导放心了，因为他能看到任务在一个接一个的咔嚓掉。
除上面这些之外呢？也许有吧，哦，你会说：
完备文档被好的制品替代了？
和客户有交流了？
拥抱变化了？
老兄，这些问题你觉得哪一个开发方法不重视？如果不重视也不是开发方法的问题，而是具体执行人员的问题，这些问题即使使用了敏捷，你解决了吗？？反问自己吧。
说了些打击自己和他人的话，也要找找解决的方法。最近因为工作上的原因，所以就看了一些关于敏捷的资料，也切身的思考了实际开发中对敏捷的应用。也发现很多人都在分析敏捷开发在实际应用中存在的问题，也有提出了解决方法的人。我不是高手，但别人不能阻止我像高手那样叼根烟。。。所以我也叼根烟。咳咳。。
Scurm的可谓是覆盖面够广呀，真是做到了个体的交互，“客户”的协作，响应变化。但是咱们拿出来分析一下：
个体的交互？
就是你和我交互了，我把可以说的随便说一下，不想说的不说，交互的结果就是你知道了又怎么样呢？
敏捷思想是希望能把需求也好、问题也好，拿出来沟通，但要让开发人员把这些东西拿出来说还是要靠方法滴。Scrum约定了很多会，最值得提的还是站会吧，这个是每天都要做的事情，做的好提高效率，做的不好就是浪费时间。借用网上一个家伙提到的例子：
站立会议=审问？
我们自己想想，是不是这个样子？所以我们这些当兵的就只好把可以说的随便说说了，有问题？没有，咱们没问题。领导我保证完成任务。好吧，领导放心了。
我觉得吧，不能这样，既然是站立会议就是要快，要有效。把大家一起聚集起来是讨论问题的，领导也好、Master也好不要去问些无趣的问题，如果想要问问题就必须把每个开发任务都弄清楚，知道任务的关键点。
比如你问：HI，兄弟这个任务要搞定千万级数据缓存问题耶？你现在用的什么方法呢？
被问的人说：我不知道耶，正在想。
那好了，这个问题效果来了，不需要再解释了吧？
个体的交互，目的是交流沟通，把一些潜在问题消灭掉，而不是领导问进度，要充分相信自己共事的人，把问题分析清楚，不要把任务逼成潜在问题。
一个团队不要把阶层划的太过份，很多问题不一定是老手才能解决，有时新手也能有更加出色的点子，解决方法更加独特有效，要充分发挥团队的作用。
做为Leader更是要把外界的压力减到最低，让团队成员在执行任务时可以专心，不能因为自己压力大，就让成员也跟着无序，心急。否则要Leader干什么？同样的，团队成员也要负起自己的责任，把事情做好，有问题就要尽快交流。这样Leader才能知晓，调配资源。最终目的就是把开会变成沟通，而不是碰头，头都碰烂了，最后发现啥也没干。
“客户”的协作，交互可用的制品？
之所以敏捷开发会强调客户的作用，就是希望能让客户把问题充分描述，以保证开发的产品符合要求。在很多时候客户的需求不一定是合理的，如果不告诉客户，结果就是客户和开发都成了SB，不要以为收到了客户的钱就是成功。最后客户SB的发现自己付的钱没用时，会让你吐的更多，这时你更SB。
敏捷开发就是希望把问题解决在需求阶段，让一个个迭代来与客户交流，让客户了解制品，对产品产生概念，从而反馈到最真实的需求模型。好了，我们真的这么做了吗？？？
很多时候，我们开发人员又如何能知道客户真实的需求呢？需求背景描述？跟着现场人员讨论？与客户讨论？都是方法，那最终体现是什么呢？怎么算能认账？
敏捷不等于没文档，制品也不能代替文档，与客户交流就更加是了，说了一大堆，没有个记录，你敢说你交流的充分了？绝大多数时候，不写文档都是因为懒，然后敏捷说不需要完备的文档，这下好了，直接就可以欢天喜地了，不用写文档咯。。自己问问自己是不是这样？文档真的不是DOC,PPT，文档有很多形式，与客户交流时可以用用例模型，界面原型工具，有时文档就是一段话，甚至是一句话。比如：客户希望把登录按钮默认为按回车。
文档的目的是为了记录、传播、更加充分的讨论，你一个人懂了不代表所有人懂了。把自己的工作做踏实点，把建模过程做起来。从源头上提高交流的效率效果，文档有很多，我比较推荐的方法是：建模。
UML建模是软件开发领域的一种描述语言，他的好处是统一、规范、描述性强。从客户开始就可以有需求建模，界面原型建模等。这个工作客户如果没有能力就让需求分析人员做，让客户明白后再转到开发。这种事情不存在增加工作量，和客户交流总归是要有文档的，只不过是换种形式而已。
开发则更重要了，一个需求如何开发，一拍脑袋就这么干吧，拍脑袋的过程是在干什么呢？不就是在把需求分析成一个个的程序模型吗？为什么不记录下来呢？把分析的过程转成一种可描述的语言，这不是更好？除了你自己之外，还可以上其他人阅读。而且用模型工具也能一定程度上提高分析效果。同样的，UML建模之后再与市场人员进行交流时就更加充分了，UML不仅仅是只有开发人员懂。市场、测试甚至很多客户都具备这样的能力。而且图形化的描述，客户也更能理解接受。
响应变化？
计划赶不上变化，这大多数情况下就是事实。敏捷开发是想通过迭代及沟通来解决变化给项目的影响。然而更多的时候变化就是会影响到计划，而且让人很不爽又不得不干，理由很多，如：什么客户就要这么干，那个时候必须要，云云。。。其实这个事情真的很急，但是急有什么用？
所以我对响应变化的理解是：把计划做到容忍变化才是解决之道。通常公司有了绩效考核后会对开发工作进行量化，好了，领导一看，反正一个月就这么多时间，给我排排满。然后各个开发负责人就排排满。迭代之初大家兴高采烈的领了任务，估了任务时间，咔嚓。等到快要交付的时候，因为鸡鸭鱼的原因，狗没吃到屎，我去。
Leader很深情的说：没办法，大家加加班吧，领导说了要做完，客户有这个要求，弟兄们地球会因为我们的努力继续转的。然后与客户打交道的同事用上吊来威胁你：兄弟，不做完，我就死在这了，我能不能活就看你了。看着办吧！
怎么办？我不入地狱，谁入？于是乎噼里啪啦，回了句：哥能行。
好了，若干时间后，BUG大爷出现了。。。。。。。。。。。。。。
呵呵。开个玩笑，计划与变化，是个很难协调的话题。但是我一直认为一个计划一定是可执行的，如果一个计划只是一种形式，那肯定会有很多问题。变化也是相对于计划才有的，对吧？那好就把计划与变化划分清楚，把什么是计划什么是变化弄清楚。
迭代的目的就是把计划做到可执行，把一个短周期内安排的事情做完，给客户提交一个可信的制品。如果你的计划总是有这种那种原因被打断，一个迭代周期总是不让别人爽，那么你自己也不用想爽。这就得说说Scrum的需求评估，通常在Scrum会议上任务是由成员估时并认领的，那么，这个估时准不准就会成为重要的因素。不准，是多了少了？不管是多是少都是不准。怎么样才能准？如果到这时还不明白，那就继续拥抱变化吧！
呵呵，其实很简单，需求描述准确，开发人员理解准确，估时还会相差很大吗？如果很大那就是人品的问题了。
对了，还有测试，测试一定要懂的。
总结一下：软件开发是个系统工程，他涉及的人是方方面面，人涉及的多就会有交流问题，交流大家都知道很容易产生偏差，只有想办法把偏差减少才能减少变化。前面聊的个体交互与客户协作都是强调了内容的一致性，这才是敏捷开发带给我们的。
不管是和团队成员交互，还是与客户交互，要形成一致的语言，只有语言一致了才能理解相互在说什么，干什么。
