开发者有什么意义？Scott Ambler:敏捷建模
目是为建模和文档构建描述
组原则和实战
最好是用于敏捷项目中
但如果它们不是那么敏捷也没有问题我们已经看到
它主要用途在于XP(极限编程)方面目是使现代文档构建过程更加明晰；或是和RUP(Rational统过程)结合降低些官僚作风并使它尽可能精简它只是通过你正在做
些事情不必死啃不必要文件为你描述有效研究思路方法从敏捷角度看它提出些直接策略帮助你避开希望你做过多文案工作官僚主义者并就如何管理工作提供些建议敏捷社区
些更加极端交流激发些人去做
事情我不是在嘲笑敏捷爱好者只是他们做事方式可能是你认为
员对于建模持什么观点？我认为
许多员出于些原因对建模嗤的以鼻首先
他们没有受到过良好培训我想学校根本就没有建模课程就我所知从来就没有过但他们现在在这方面表面确实不如人意许多时候
开发者接受第份工作第次做建模时他们几乎总是会面临以下两种不良状况的他们要么加入个项目团队(Team)这个团队(Team)首先为你提供所有建模条件然后你会慢慢忽略它于是他们发现在建模文档方面浪费了许多精力然后他们会说:“嗨我做了所有这些建模工作但它对产品没有任何影响这真是浪费！”因此他们开始讨厌建模或者
更糟糕是他们会做他们工作他们成功部署项目进入生产然后有人会指出:“嗯现在我们需要用接下来两个月时间构建所有文档我们应当让人们觉得我们遵循了工作流程”这完全是浪费精力只是有人为了给工作找到合理理由和交付价值根本无关许多开发者厌恶这种事情另
个常见问题是他们努力将建模和构建文档区分开来如果我在个白纸板上画草图那么这是个模型但却不是份非常整洁文档从某种意义上说错在供应商
我们想出售CASE工具我们试图让开发者确信建模必须用这些复杂工具来完成不
并不全是如此——我们只是观察到这样事实:许多建模在白纸板上完成许多建模在纸上完成那样很好如果你需要取得更加复杂效果就需要使用更加复杂工具例如
我拥有熟练建模窍门技巧因此在建模时我使用RSA(Rational软件Software构建器Rational Software Architect)或RSM(Rational软件Software建模器Rational Software Modeller)这类工具比用手“涂鸦”更加有效然后生成我代码和数据库材料如果能够生成代码
却要去编写它那样做就很愚蠢了我认为在这方面工具可以生成优良代码问题在于使用工具需要掌握大量窍门技巧——如果你不具备那种窍门技巧也没有花时间来掌握它或是和某个掌握这种窍门技巧人合作那么工作起来就相当艰难许多开发者发现如果可以选择他们愿意做更多建模工作但他们并没有获得学习机会我们肯定需要区分模型和文档
它们是完全区别概念；虽然些模型会进化成文档但许多模型不会那样也很好建模和构建文档的间
联系有多强？传统上
它们关系非常强这也是我们为什么全都如此关注原因但实际上它们的间联系不是那么强90%建模工作在白纸板上完成我们最近项调查显示建模是团队(Team)中第 4有效工作书面建模不是那么流行有关用户叙述(User Stories)和CRC卡等所有故事是我喜欢看到绝大多数建模工作都是在这种
次性模型上完成但你可以提出非常强有力证据介绍说明在开始编写代码前进行测试实际上也是建模你在开始编写代码前介绍说明使用方法就我没有画UML图并不表示我没有建模许多模型不会进化为文档
些模型会但在个敏捷团队(Team)你常常会随处看到白纸板人们在上面画模型或别什么随着时间推移你会看到它们进化当你开始考虑编写文档时你会发现那些仍然留在纸板上、你放进工具、你夸耀并进行修饰模型才是有用模型你认为教育部门需要采取哪些措施来解决这个问题？
我认为大学应该解决几个问题:首先
他们没有必要资金他们资金总是不够事实就是这样而且由于某种原因他们往往避开团队(Team)工作建模是个团体行为你需要许多人参和进来你们需要协同工作如果你在分配任务
你让人们绘制草图那样很好但他们可能只是粗略编写出代码他们还把教学内容划分成区别课程有Java课程、数据库课程、算术理论课程那么学习重点只是在数字编程或别什么内容上面他们从没有传授完整生命周期另
个问题是他们并不安排项目他们搞题海战术或者给你个任务让你去完成但他们不会说:“接下来两个时间我们研究这个系统”因此两年里他们传授区别内容你得不到任何实际经验我不是说做到这些很容易
但是他们应该着手解决这些问题几年前我在多伦多大学工作我们做了件艰难工作:在团队(Team)工作课程中我们告诉学生他们会全程开发个系统然后在中途我们撤走他们所有材料用前些年材料进行替代并且告诉他们:“好了现在你们要维护个遗留系统现在你们该如何办呢？”他们十分震惊
我们听到全都是说我们如何坏牢骚和抱怨但这就是现实在现实世界中你必须去维护其他人编写代码后来我遇到他们他们告诉我说这是他们学到唯确实有用课程那是真实发生事情你需要模拟那种情况这确实很难做到我想知道
为什么个为期 3年计算机课程不学习开源项目为什么他们任务不是让这 3个人完成他们想要项目；他们必须提供证据表明他们具备某人确实感兴趣素质——他们设计、执行、测试并交付该项目那就是整个工作那很容易做到也更加有用随着我们进入
个更加全球化开发模式你认为敏捷开发过程有多重要？由于某些原因
它显得非常重要首先人们在应用敏捷开发所以对离岸工作人来说为什么不能以敏捷方式完成离岸团队(Team)工作呢？没有什么可以阻止他们为什么不能以敏捷方式完成本土团队(Team)工作呢？同样没有什么可以阻止他们那么问题变为你如何在这些团队(Team)的间进行沟通
你必须擅长于此你该如何组织团队(Team)使他们即使在地球另面工作也能保持高效率呢？要做到这点并非易事但你可以保持明智赋予每个位置尽可能多
责任如果我得到个离岸处理子系统那么它就是离岸工作全部如果本土团队(Team)确定需求和构造再把它们交给离岸团队(Team)你项目就会缺乏活力如果你在本土完成所有关键研究你是在努力最小化风险但实际上你已经增加了风险如果我把
份构造文档或份详细需求文档交给离岸团队(Team)告诉他们说:“完成这项任务”那么如果你是离岸团队(Team)主管你会如何做你会让下属来完成这件工作他们已经为你安排好切——实际上任何高级职员都不想做那样工作在那种情况下你只是只“编程猴子”你需要承担尽可能多
责任——我看到许多成功团队(Team)把它们成员送到印度工作你让名项目经理(project manager)在那边协调工作但那样就足够了长期来看那样做风险和成本都低许多这实际上是种非常有趣工作方式但你必须非常信任你工作人员你对轻视敏捷建模
认为其不必要开发者有什么告诫？首先
如果你正在做敏捷“软件Software开发”你实际上就是在进行敏捷建模只是没有意识到这点而已于是我开始问这样
问题:“你在白纸板上工作吗？”答案是肯定这令人鼓舞如果你去参观个运作中XP团队(Team)那里总是有上面画着图表白纸板或者上面有索引卡软木板那些都是敏捷建模所以他们在做这种建模工作
但不承认这是建模XP中规划游戏——那也是种建模行为不是吗？如果你在做个月周期开发你用前半天或天时间规划出下个月工作那么许多工作其实都属于建模你把大家都集中到个房间你们开始讨论填写卡片然后找到白纸板在上面画、绘制草图并进行辩论等等这就是建模因此他们在做建模工作只是没有这么叫而已最终他们责备管理层
责备其它高级开发者而且他们不理解、无法介绍说明他们到底在做什么他们受到高级管理层轻视管理层心想:“哦
他们没有做任何建模工作你们这些卑鄙下属”他们是这样认为在 7 8十年代他们见过代码修复者做过这种事情；现在许多这种激进主义分子似乎也准备继承代码修复者传统行为因此他们被视为失败——他们并不相同但听起来好像样对于敏捷社区所有有关沟通
讨论我们有时确实努力去传达我们工作这是非常重要事情如果你正在进行调整如果你必须处理某种复杂问题、如果你在准备离岸搬迁那么你就在准备建模你将要构建文档即使你不会建模你仍然要构建文档要交付个系统文档资料必不可少这再正确不过了你需要用户文档、支持文档、系统文档就是这样我请你做到明智敏捷建模就在于此定要明智如果
个开发者轻视敏捷建模我不得不质疑他工作表现我无法想象没有敏捷建模他仍然能够做好工作许多开发者并不担心白纸板工作理念
但宁愿把它限制成组规则……是
但事实上团队(Team)没有做某种建模工作吗？我意思是说仅仅它在白纸板上、或在RSA或Visio或你使用任何工具上——那不是对过度建设承诺这并不意味着它会数月数月地建立所有这些无用
框架而不交付商业价值这些不对过度建设进行控制人们有什么毛病吗？因此你可能会选择利用建模益处而不受到过度建设或过分文档化影响这是个合理选择许多团队(Team)这样做他们只是不知道如何描述它代码生成
产品般比手工编写项目质量要差你赞成这个观点吗？这全都取决于工具
例如我会挑战任何手工进行数据库开发或编写其它人使用任何种先进数据建模工具他们都能生成流DLL和触发器如果你手工编写DLL你有毛病吗？如果你手工编写个触发器你到底出了什么问题？这完全是浪费时间真很愚蠢这很有趣编写数据库书籍时我不得不重新学习DLL知识编写DLL已经是多年以前事了我只要安装个CASE工具给按钮功能建模生成代码我为什么还要去编写它呢？在Java方面
为什么我要编写类存根、或构造器、或是OR映射代码等此类代码呢？我无法想象再去编写那种代码当然有些工具可以生成不那么完美代码你必须找到合适工具除机械触发器等工具外
人们直准备将员排除在整个过程的外20多年来
我直听到这种说法它过去是废话现在同样是废话你不能那样做
你需要高度窍门技巧你需要优秀工具如果我已经掌握那些窍门技巧我还是可以更快进行编码你真正想做
是对可视化建模有意义事物进行可视化建模为对代码有意义材料进行编码找到实现上述两种情形工具并在合适时间做合适事情那样做并不容易
但很有现实意义你绝不可能拥有个100%建模地点只有少数团队(Team)可以做到那点那非常棒你总是发现它非常小、非常狭窄、他们是个万人公司里唯团队(Team)现实中这样
团队(Team)非常罕见；当然这有可能但为什么要那么麻烦呢？你提到过我们需要建模窍门技巧和代码生成窍门技巧
除了在那种环境中学习以外你去什么学习那些窍门技巧向拥有那些窍门技巧人学习吗？那相当困难
你是说你可以学习课程我想你可以在课程中学会编程但你无法学会合理编程你应该在实战中学习你必须做那样工作因此当你学习这种内容时你会得到些培训那会给你提供些启示但你需要些指导你需要实际动手经验——这都需要时间来学习如果你认为每个人都会有长达30或40年
职业生涯那么在这方面投入些努力会有许多好处是掌握这些窍门技巧可能要几年时间但从职业生涯和学习时间百分比来看你值得这样做你必须积累动手经验
你必须和哪些了解如何建模前辈起工作建模没有什么特殊的处除非有人从头到尾地教你否则很难学会建模如果
切都要靠经验那么如果公司需要在建模工作中启用新人他们需要寻求哪些素质呢？许多原因
我寻找个人素质:现有经验固然不错但他们愿意学习吗？他们愿意和其他人共同协作吗？他们愿意做重复性工作并以软件Software为中心吗？我们讨论了许多建模问题但事实上你目是开发软件Software这可不是建模我想这个领域有许多专业建模师
建模是他们努力方向几十年来他们直接受这样教育:“首先完成建模你是商业分析师把你工作成果交给其他人他们再从那里开始”不
我不需要那样人才我需要职员能够做点分析、设计、编码、测试然后从头再来我不需要那些只会建模、或者只会编码或测试人才我想那是我们如今在社区中看到
主要差异拥有多方面技能人才我们直称他们为“专才”其他人叫他们“工艺师”或“复兴开发者” Gartner group使用了个新词:“多面手”(Versitalist)——即多才多艺专家或专门研究某个问题人才这是个呦口词他们定没有给它注音我不知道他们如何想但这个想法不错最后整理总结
最后要向开发者说
句——公平对待建模我想
对那些有点轻视建模和构建文档开发者来说——世界上没有绝对建模没有错构建文档也没有错达到目标就已足够对
员来说如果你们掌握些建模窍门技巧你们生产效率肯定会有显著提高对专业建模师而言人们直告诉他们要提前详细建模如果他们少做些建模工作及时建模他们生产效率也会得到提高如果你选择研究
有个重要证据在生命周期的初就制定详细需求介绍说明实际上并不是好做法证据表明在项目早期就进行周密设计实际对项目结果不会产生影响如果你提前进行大量详细设计和根本不进行设计成功可能性是相同；这两种做法都是极端行为这不是
个非黑即白世界我不是说根本不进行设计也没有说做大量设计敏捷建模是指为手头工作做足够设计提供足够需求找到个平衡点这就是搞混
地方——两个极端人都必须找到平衡提前建模没有合理理由那不是建模最佳时机你不可能开始就全盘考虑所有问题我们知道这
点我们多次看到这样做项目遭到失败如果你拥有今天提前建模窍门技巧那么在 6个月你确实需要所有信息时你当然还是拥有这些窍门技巧那你为什么不能等等呢？没有什么理由预先做好切你收集信息等待
时间越长那些信息就越有可能是你需要信息——你可以提出更加聪明问题如果我今天为某个工作建立模型对于这个模型我了解信息最少如果我在 6个月以后建模那么我就可以收集 6个月领域知识——我可以提出更合适问题我股东已经对交付软件Software研究了 6个月他们能够提供更好反馈因此
采用敏捷建模思路方法比传统建模思路方法效率更高这就是筑桥理论软件Software开发就像是修筑座桥梁告诉我上述观点
是那些没有筑过桥人虽然这很有趣但那些既有筑桥经验又有软件Software开发经验人会告诉你筑桥比我们想象要复杂得多
最新评论