机械网站建设多少钱,网站服务理念,wordpress和mvc,湘潭做网站 要到磐石网络7.7 移山开发方法——比TFS敏捷更精简 几个软件学院的学生来请教阿超#xff0c;同学们自豪地说#xff0c;我们要用全套TFS敏捷开发模式开发项目#xff01; 真的#xff1f;阿超不敢相信。 同学#xff1a; 对#xff01;我们要用全5个工作项类型 – 任务、缺陷、场景… 7.7 移山开发方法——比TFS敏捷更精简 几个软件学院的学生来请教阿超同学们自豪地说我们要用全套TFS敏捷开发模式开发项目 真的阿超不敢相信。 同学 对我们要用全5个工作项类型 – 任务、缺陷、场景、风险、服务质量需求、 阿超 你们有多少实战项目的经验哦都没有。这么说这是你们第一个真正的实用项目我建议你们先忘记这么多工作项类型把时间花在写代码上好了。 同学 可是老师要我们上敏捷开发模式呀? 阿超 当敏捷模式变成强迫那还能敏捷到哪儿去呢如果你们非用不可我建议你们只用其中两个工作项类型 任务缺陷 同学 超总我觉得其他的工作项类型也很好用耶比如场景风险——没有风险管理我们咋能上CMM等级呢 同学 还有“QoS——服务质量需求”难道你不重视程序的效能和可扩展性 阿超 看来你们读书都不错那些类型都很好但是不直接使用这些类型并不表示我们不重视特别是风险。因为在一个全新的团队中不加辨别地使用所有工作项类型也是一种风险。它增加了VSTS的系统复杂性从而增加用户(就是你和我)学习和使用的难度浪费时间。有可能使项目的进展受到影响至于“服务质量需求”我们很重视程序的效能和可扩展性但是不必拘泥于非要用某一特定的类型不可。 对于小规模的项目我的原则是“直奔主题精简过程”我们的主题是啥让用户买我们的产品只要用户满意我们的产品他们会关心我们内部开发模式用的是哪几个工作项类型么 我个人认为项目开发过程中有两件不同类型的事 (1)事先预计到的要做的事。这就是任务把要做的事情组合起来实现用户某一个特定的需求这就是场景也可以用任务来表达。 (2)事先没有预计到但是为了项目成功而不得不做的事。这就是缺陷。 软件开发的过程就是做完这些“计划要做的事”和“没计划但是不得不做的事”做好就行了。等你们做了三五个项目写了一万行以上的程序再来看场景、风险、服务质量需求也不迟。 同学您说得在理但是老师让我们用全套敏捷模式我们怎么办 阿超你们可以回去告诉老师说这是最新的“移山精简开发模式”填补了国内外空白很好用。 把同学们打发走了以后阿超转念一想为什么不呢“移山精简开发模式”说不定对小型团队来说是一个很好的模式。 举例说明例如我们要设计一个网上拍卖的网站商业用户(简称商户)可以开商店卖东西一般的用户可以浏览购物。 商户可以用我们的系统进行登录。这是场景也可以叫任务我们要以此为基础驱动开发和测试工作 我们计划要在网络用户界面实现商户登录管理这是任务。 我们计划要在中间逻辑层实现商户登录管理这是任务。 我们计划要在数据层实现商户登录管理这是任务。 我们计划要测试商户登录这是任务。 我们计划要系统能支持100个以上的商户同时访问这是任务同时也是“服务质量需求”。 在某些情况下商户登录失败这是缺陷。我们事先没有预计到会出这样的问题。 在标准配置情况下20个以上的商户同时登录时系统的响应时间很慢这是缺陷。我们事先没有预计到会出现这样的问题。 系统在上传某种图像文件时出错这是缺陷。 对于一个不太复杂的系统来说每次里程碑(迭代)中要实现的场景应该两个手掰指头能数得过来。而且场景是相对稳定的不会突然间有大的变化。对于一线的开发和测试人员来说每天打交道更多的是任务和缺陷。过多的类型会增加管理和交流的成本一个开发者每天很简单地浏览“我的任务”和“我的缺陷”这两个检索就能知道今天该做什么。同时开发和测试的交流也主要通过“缺陷”这一类型来完成。管理人员在跟踪进度、报告进度的时候也很简明。在这种情况下“场景”只是起到一个综合与归类的作用使管理人员和客户知道哪些功能能够使用了哪些还差得远。因此“场景”可以等同于“任务”。因为这是我们预计到要做的事情。 如果加上“服务质量需求”那么团队中每个人需要接触的工作项类型就有4种如果测试人员发现“服务质量需求”的某些部分不符合要求需要重新激活“服务质量需求”并创建一个新的“缺陷”并且通报所有相关人员对于一个小规模、人员相当集中的团队真的有这个必要么 对于一个新建的团队保持一个精简的过程和管理方法是很重要的。只要任务、缺陷这两个类型足以解决问题就不必考虑更多的工作项类型而是集中精力把项目开发好。 在软件工程发展的过程中各个专家在不同时期总结了软件工程的原则下面是1983 年Barry Boehm在总结了多个项目(各个项目总共耗时约175000人月主要是国防、航空、航天相关)之后提出的软件工程原则[i]请把它和MSF、Agile的原则相比看看有什么异同? 表7-2 Barry Boehm总结的软件工程原则 Principles 中文翻译和解释 1. Manage using a phased life-cycle plan. 使用分阶段的计划来管理流程强调需求分析和抵制随意地改变项目计划。 2. Perform continuous validation. 持续地检查认证争取在早期发现问题。 3. Maintain disciplined product control. 坚持规范的产品控制– 验证过的程序或文档只有通过规范的流程才能修改。 4. Use modern programming practices. 使用现代的编程方法和工具 5. Maintain clear accountability for results. 确保团队成员能分阶段分模块地产生可以测试可以复审的结果并对结果负责。 6. Use better and fewer people. 用少而精的人员减少交流成本提高效率。 7. Maintain a commitment to improve the process. 持续地收集数据和反馈争取通过多个迭代实现流程的改进和整体软件质量的提高。 小飞 能否有一个打折扣的MSF让一个团队一下子接受MSF的“9项基本原则”似乎并非易事那么我们可以打折扣地贯彻MSF吗如果可以应该如何实施呢 阿超 这些原则都是相互依赖、相互促进的。如果只实施了50%的原则也许只有10%的作用。但是不必为此烦恼只要开始改变经常总结就是好事。 小飞 越是充分授权和信任很多人在团队中越不自觉结果写的代码都是敷衍了事(大学里面的团队很多都是这样)需要用什么激励机制来促进吗还是说只能依靠团队成员的个人自觉 阿超 那我们要问一下这个项目的商业价值是什么如果这个项目没有任何商业价值我想你也不好意思照搬商业软件的做法。但是也许这个项目对个人而言很有价值(提高个人技术的价值)那些有心锻炼自己的同学能够自我驱动值得你去“授权”和“信任”。 小飞 我体会最深的是——“如果你问一个技术人员技术人员往往略带不屑地告诉你——把“工具 | 选项”打开在某个“高级选项”下改某个参数即可”这一段。移山公司的一些技术人员特别是开发人员甚至还带有一些轻蔑的眼神。参照这一新闻(北京禁止售货员用轻蔑审视的眼光扫视顾客)[ii]我大胆地提一个建议——“移山公司禁止开发人员用轻蔑审视的眼光扫视测试人员” 大牛 我同意而且要扩展到“禁止开发人员用轻蔑审视的眼光扫视非开发人员” 果冻 西方管理学大师戴明曾经说“Eliminate numerical goals, numerical quotasand management by objectives. Substitute (that with) leadership”意思就是说(在团队中)要消除以数字定义的目标、份额以及以类目标为基础的管理原则。我们要用领导能力取而代之。这和“数量化的管理”级别的要求有没有冲突 二柱软件工程讲的净是一些奇妙玄幻的概念拗口的专业名词加上纷繁复杂的流程其实做软件完全没那么难主要靠的还是程序员自身的修养和完成工作的素质。 你怎么看二柱的观点 [i] 论文信息Seven Basic Principles of Software Engineering, Barry W. Boehm, 链接http://dx.doi.org/10.1016/0164-1212(83)90003-1 [ii] http://news.sina.com.cn/c/2006-11-30/202110650498s.shtml
