近来做了点东西有一点儿心德想要分享一下，也许在写的过程中有些描述的欠缺，但是也算是一点心德了，希望大家指正。
是否在项目中采用UML实际上一直是一种矛盾的事情，你说它有用吗，它真有用，你说它没有用吧，它真是一个废物。此话怎讲哪？UML对于需要求变更量不大的项目，那可是法宝一件，有种倚天即出，谁与争峰的感觉.但是如果项目中频频变更需求那么好吧乖乖，UML就是废物一个，成为项目组中人见人怕的怪物。
所以说我建议大家采用敏捷的方法开发，配合UML中常用的图例进行组员沟通与理解就不失为一种比较好的方法了，采用纯粹的敏捷开发一点儿文档也没有的话，我个人感觉前期开发人员会乐死，后期维护人员会哭死，特别是对于现今中国软件开发公司人员流动过快的现象，这种事真的是太多太多了。
做一个简单的比喻吧：
采用传统式流程式开发的兄弟们：好像是一群建筑设计院出来创业的老学究，事事讲究，什么都是理论一套一套的，一到实际盖房子的时候全部完蛋，为什么哪？主要是因为这帮学究们天天只会待在房子里研究，但是一盖房子全部都傻，没有实战过，对现场开发是一个白痴。但是奇了怪了就是这样的一帮人就能拿到大项目的单子，为什么哪？揪其根源主要在于人都是好面子的，一听你找了一个包工头子干这个项目，打死政府也不敢给你项目，所以一般都是白痴做一包，我们做二包，如果感觉不爽，你可以再找三包了。。。。
采用敏捷开发的兄弟们：这帮人一般都比较猛，一个人可以干三四个人的活，有时甚至是五六个人的活，团队短小精捍，战斗力超强，（可惜再强也拿不到大项目，更别提什么政府项目，大企业外包了），所以你们发现采用敏捷开发的团队多半是XXX工作室，？？？网站，YYY框架的，因为他们是真正做东西的人，不需要那些华而不实的东西。
看来看去这二种开发方法都是有缺陷的，最后想来想去用了一招土法造炮，姑且叫它“敏捷UML”。让我们以前的敏捷组织采用UML来做为日常沟通的工作，慢慢的让UML融入到以前的敏捷开发模式中，呵呵效果不错。方法如下：
第一 项目分块，将项目中所需要的功能进行划分，并将功能按实现难易程度再分成三个等级，并按开发小组人员能力进行任务派发，在派发时只要求开发人员先实现最基本功能，基本到只是一个实现的小例子，呵呵这也就是以前经常用的原型开发模式
第二 每天坚持开早晚例会，时间要控制在30分钟之内，记得就是没有问题也得开，这里面有一个基本含义就是提高团队的沟通能力
第三 每天下班坚持团队成员一起打一次CS游戏（还是提高团队合作能力，加强“战斗力”）
第四 不要求团队成员一开始就写一大堆的文档，写了也没有用，因为需求总是变来变去，写了就是糊弄自已了，但是在每次的例会上要求团队成员在讨论流程，框架设计，类库实现时采用手画的方法进行描述，一来是强化队员思维，二来就是让那些天马行空的人能有点约束，剩得搞完了设计就只有他一个人能看懂。
第五 采用交叉review的方法来提高代码质量，在完成功能模块后，要求采用不懂的人交叉review.
第六 多多申请几块白板，也许用得上
第七 对完成5次迭代以上的代码包含数据库，要求组员进行基本的UML逆向工程，主要是想通过宏观上再次确认项目.
第八 对于项目组中能力比较弱的组员，坚决不能放弃，不能拿着好人用个不停，对于弱的组员要采用师傅带徒弟的方法，这种方法真是百试不爽哪，好用的很。
第九 要避免“灯下黑”，尽力让自已站在一个大宏观的角度进入项目，不能事事亲为，这样会让项目组对你产生依赖性，就是一句话-“要像三营长练顺溜一样，练自已的兵”。
拖拖拉拉，乱说了一大通，希望大家指正。。呵呵。。。
来源：https://www.cnblogs.com/chu888chu888/archive/2009/07/06/1517548.html