|
需求变化难题实话设计模式太极敏捷CMM/CMMI 与敏捷逻辑程序员图书银弹核心软件工艺
过去十多年来，我一直听到人们抱怨一个问题：需求变化大。的确，需求变化大是个老、大、难问题。如何解决这个信息化/系统集成/软件工程的头号难题，值得我们认真深入地进行研讨。当今的软件工程已经超成熟了。解决需求变化大、变化多的难题，其实已经有很多成熟的技术和管理手段可以综合运用。从开发商的需求技术技能角度，应该尽可能地提高需求分析的精度和深度，比客户看得更多、更远。 20 年前诞生于复杂电信软件开发领域的 Use Case（用例）方法是解决需求变化大难题的一项重要技术。简单地说，用例就是利用自然语言用写计算机程序（包括前态、后态、基本流、异常等）的方式来写软件需求，它的最大一个优点就是能够用结构化的文本模板系统、规范地帮助我们挖掘出许多采用其它方法很难发现的隐蔽、复杂需求（扩展流、扩展条件等），从而可以有效地规避需求风险。推广和传播基于用例的统一需求分析和管理技术也是我过去十年来做的一件主要工作。欢迎参加讨论：如何彻底解决需求变化大的问题？ 设计模式的重要性毋庸多言，每一位有经验的程序员都应该熟练掌握设计模式的原理和应用。学习和掌握设计模式，可以说既简单，又困难。如果学习方法对头，掌握了科学的思维方法（其中最重要的应该是抽象思维和逻辑思维）和学习方法，那么学会熟练地运用设计模式就很简单；如果学习方法不对头，那么就会越学越复杂，老也看不懂，不会用，不敢用。 如果你因为读了大名鼎鼎的《设计模式》这本书，就觉得 Design Patterns 很难、很深奥，这完全是一种误解。实话实说，著名的四博士 15 年前的那本《设计模式》并不适合作为初学者的入门读物。学习设计模式应该可以有一种更简单、更轻松、更快捷的方式。所以，除了向大师致敬以外，这也是我想写《大道至简：实话设计模式》这本免费公开网络书的一个原因。更多... 敏捷变革（agile transformation）是当前正在进行中的世界软件工程史上又一次重大的 paradigm shift。另一次著名的 paradigm shift 发生在上世纪末的八九十年代，也就是大家比较熟悉的由传统结构化编程向新型结构化编程（OO）技术的转变。很幸运这两次大变革都被我们赶上了。敏捷思想认为软件开发更多时候是一种非线性的、不确定的、随机性过程。 之所以提出太极敏捷，主要是出于十五年来我对什么是软件工程、软件研发深刻本质获得的一种理解：软件工程是一门处处讲究权衡的科学和艺术。此外，在国内的市场和文化环境下简单生硬地照搬、照抄西式敏捷方法，能有多大成功率也令人怀疑。推广基于辩证法和矛盾论的中式太极敏捷思想方法，可以弥补西式敏捷的不足，有助于我们抵御幼稚、天真的敏捷，偏狭、片面、偏激和极端的敏捷。很多人以为敏捷就是 XP、Scrum，就是测试驱动开发（TDD）、持续集成（CI）和结对编程（PP）等非常具体的做法，这其实是一种相当普遍的误解，敏捷是比 Scrum、XP 更大、更宽泛的概念（什么是敏捷）。敏捷是先进软件研发企业、团队和个人所达到的一种高级状态，敏捷开发和管理是一套建立在科学理论之上的更为先进、成熟的理念、思想、哲学、价值观和原则，当然敏捷更是一种先进文化。更多... CMM/CMMI 与敏捷的 PK 和比较，近些年来一直是国内外软件工程界的一个热点话题。以 CMM/CMMI 体系为核心的传统软件工程与近十年来兴起的敏捷软件工程形成了两大阵营。因为拥护一方，就把另一方贬得一无是处，显然不是一种科学的态度。围绕着两者的优劣和异同，它们之间到底有什么差别，国内的专业圈子内还存在着许多误解和误区，这里是张恂对此的分析。 Barry Boehm 院士和 Richard Turner 教授于 2003 年合著的 Balancing Agility and Discipline: A Guide for the Perplexed 可以说是这些年来这方面引用率最高的一本权威之作，也是张恂推荐国内软件企业、研发机构中技术管理者及相关人士，尤其从事、负责和关心软件过程改进的人士，必读的一本名著。 “程序员”这个称号其实只是一个笼统的称呼。程序员有专业和业余之分，就像棋手有专业棋手、业余棋手之分。合格的软件工程师一定是一名专业的程序员。那么，软件工程师，专业程序员，与业余程序员有何区别？根据我多年的观察，两者之间最根本的区别在于：是否具备或在多大程度上掌握了科学的逻辑分析推理能力。一名合格的软件工程师会主动地、自觉地根据科学原理，采用科学方法，科学地、系统地、经济地、人本地来开发软件（张恂的软件工程定义），并根据正确的逻辑分析和推理过程，最终得出客观有效的结论。 通过学习和研究，张恂还发现，世界上几乎所有的 软件科学家、软件工程师和软件大师们 似乎都基本上遵循着同一个基础的逻辑系统，因而他们也都具有大体上相似和一致的科学逻辑思维。更多... 作为一名软件人，我们可能一生都需要不断地学习，而千年未改，图书依然是今天二十一世纪的程序员和软件工程师们获取知识的最主要来源。于是，想到给对自己的职业生涯乃至人生影响最大的几本图书、名著，搞一个 排行榜。不知能不能凑足 10 本，抑或超出，先列出来再说。评选标准为张氏银弹理论： 售价不过是一本几十块 dollars（中文版、影印版不过是几十块 RMBs）的软件经典图书，在 10 年内带给它的读者们的回报岂止是 10 倍（一个数量级）？我看，至少是万倍，几十万倍，几百万倍 ... 而它们对于我们读者软件开发思想的形成和影响，不但可以受用终生，而且更是无法单纯用金钱、数量指标来衡量的！故：软件经典名著，即事实上的银弹，不仅是银弹，更是金弹！更多... 回顾过去十五年来，世界范围内的软件开发工艺有哪几个重大变革和潮流？我的总结是：迭代敏捷（Agile & Iterative）、对象（Object）技术 与 用例（Use Case）技术。迭代过程取代瀑布过程成为主流，构成敏捷的基础；多层次、多方位的面向对象（新型结构化）技术取代传统结构化技术，极大推动了软件系统和产品在规模、效率、质量和复杂性等许多方面实现了空前的发展；用例（协议、场景）等相关先进需求分析管理技术的成熟运用，显著缓解了传统的需求难题。因此，张恂把这三样综合技术（软件工程工艺）作为考察一个当代软件开发组织是否成熟、是否具备现代生产力的重要标志。如果您高价请来的评估师没有把这三样告知您，实在可惜 更多... |
|
|
通知
* 敏捷 OO 私教 2010.3-2010.6 学员招募中 * itpub 敏捷开发圈 软件过程论坛 项目管理论坛 我的空间 * UML 大中国论坛 UML 工具投票 需求方法调查 项目过程调查 * 大道至简：实话设计模式 * 若在 IE 8 中显示不正常，请用兼容性视图浏览。 需求
统一用例方法 Use Case Feature User Story 模版 软件架构设计
项目管理
|
Agile 与太极：到底啥是敏捷？ 14418(敏捷 2010-2-6)敏捷过程改进最好先从了解什么是敏捷开始。 解读敏捷原则 为什么要太极敏捷？ 中式太极敏捷：UDD over TDD 39241(敏捷 2010-2-6)敏捷过程改进最好从 IID 开始。很多人还蒙在鼓里，不知道瀑布式软件开发存在着很大的风险，早就该淘汰了。最近更新： UML 太极建模口诀 概要-如何敏捷 太极敏捷与西式敏捷的区别 敏捷的误解、误区和谬论 1142(敏捷 2010-2-4)敏捷方法不会完全脱离重量级RUP思想？ 敏捷不适合产品研发？敏捷会榨干开发人员？敏捷忽视文档？... 敏捷的现状 1386(敏捷 2010-1-28)国内外敏捷应用现状情况调查。 哪些企业敏捷了？ 著名的 VersionOne 2008 报告：敏捷的好处、最流行的敏捷方法、敏捷做法、敏捷工具。 2009 年度最佳案例 132(案例 2010-1-20)对 itpub 上几个典型案例的分析，涉及到瀑布过程、业务建模、需求、业务与 IT 关系等。 UML 图书 548(读书 2010-1-18)UML 名著推荐 UML 工具 1242(建模 2010-1-17)UML 工具的新时代已经来临。Rose 已老，IBM 仍是老大，EA、VP、MD 三剑客的实力也不容小觑。 MDSD 问答 750(建模 2010-1-12)我对德国模型驱动开发专家 Andreas Graf 的采访。一共 5 个问题。 Project Smart 评论 151(项目管理 2009-12-5)很棒的项目管理知识库 敏捷 OO 私人教练服务 8199(服务 2009-10-27)张恂做您的私人顾问和教练，面向个人定制的软件研发技能提升（成为敏捷 OO 开发者或管理者，架构师或项目经理） 敏捷 FAQ 3021(敏捷 2009-5-25)更新：为什么时间盒迭代提倡删减需求任务？为什么迭代开发能提高生产率？什么是太极敏捷？ CMMI 与 Agile 的融合 738(敏捷 2009-4-1)一篇非常重要的 SEI 报告，CMMI 拥抱敏捷。软件过程改进人员必读。 |