|
专家团队需求难题实话设计模式太极敏捷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 可以说是这些年来这方面引用率最高的一本权威之作，也是张恂推荐国内软件企业、研发机构中技术管理者及相关人士，尤其从事、负责和关心软件过程改进的人士，必读的一本名著。 “程序员”这个称号其实只是一个笼统的称呼。程序员有专业和业余之分，就像棋手有专业棋手、业余棋手之分。合格的软件工程师一定是一名专业的程序员。那么，软件工程师，专业程序员，与业余程序员有何区别？根据我多年的观察，两者之间最根本的区别在于：是否具备或在多大程度上掌握了科学的逻辑分析推理能力。一名合格的软件工程师会主动地、自觉地根据科学原理，采用科学方法，科学地、系统地、经济地、人本地来开发软件（张恂的软件工程定义），并根据正确的逻辑分析和推理过程，最终得出客观有效的结论。 通过学习和研究，张恂还发现，世界上几乎所有的 软件科学家、软件工程师和软件大师们 似乎都基本上遵循着同一个基础的逻辑系统，因而他们也都具有大体上相似和一致的科学逻辑思维。更多... 回顾过去十五年来，世界范围内的软件开发工艺有哪几个重大变革和潮流？我的总结是：迭代敏捷（Agile & Iterative）、对象（Object）技术 与 用例（Use Case）技术。迭代过程取代瀑布过程成为主流，构成敏捷的基础；多层次、多方位的面向对象（新型结构化）技术取代传统结构化技术，极大推动了软件系统和产品在规模、效率、质量和复杂性等许多方面实现了空前的发展；用例（协议、场景）等相关先进需求分析管理技术的成熟运用，显著缓解了传统的需求难题。因此，张恂把这三样综合技术（软件工程工艺）作为考察一个当代软件开发组织是否成熟、是否具备现代生产力的重要标志。如果您高价请来的评估师没有把这三样告知您，实在可惜 更多... |
|
|
通知常用
迭代敏捷过程和方法
什么是迭代？ IID 与 IIDD、HIRAIED 为什么要迭代？ 先迭代后敏捷 UML
软件架构设计Web架构模式.NetJEE
项目管理
PMI/PMBOK Scrum APM 软件项目管理知识体系 十大风险 |
中式太极敏捷：UDD over TDD 50502(敏捷 2010-7-13)太极敏捷主张先迭代、后敏捷，敏捷过程改进最好从 IID（迭代递增式开发）开始。最近更新： 软件项目经理最应该关心的 14 件事 软件开发项目是否真的需要一个需求分析阶段？ 为什么说软件工程是太极？ 国内软件项目的 10 大风险 UML 太极建模口诀、概要-如何敏捷、太极敏捷与西式敏捷的区别 软件工程项目管理专家团队 638(合作 2010-6-24)社区里潜伏了很多菁英，缺点是大家你一言我一语，没有形成合力，这是资源的极大浪费！大家组织起来，就可以一起做点事。欢迎加入我们的团队！6-24 新增成员 Wade 上海 金融保险 我的速写 137(悟道 2010-6-1)关于 Agile 敏捷开发与管理工具 211(工具 2010-4-27)收集各种 Agile 工具资源 Java 开发与管理工具 187(工具 2010-4-26)收集各种 Java 工具资源 敏捷的现状 2397(敏捷 2010-4-8)国内外敏捷应用现状情况调查。 哪些企业敏捷了？ UML 工具 1771(建模 2010-4-3)UML 工具的新时代已经来临。Rose 已老，IBM 仍是老大，EA、VP、MD 三剑客的实力也不容小觑。 公益免费 UML 培训 233(培训 2010-4-1)经过十多年的发展和普及，如今 UML 就像 HTML、Java 一样，已经成为了一种大众化的编程技术。初学者不要幻想在 2-3 天之内就学会 UML。其实网络培训是一种最佳的学习方式。由 UMLGreatChina（UML 大中国）主办 ;-) 丰田召回门给软件行业的启示 202(案例 2010-3-16)不要迷信任何理论和方法，提升人的素质和能力才更重要。 程序员必读的敏捷开发建议 192(敏捷 2010-3-16)架构师和项目经理也应该读一读。 敏捷 OO 私人教练服务 9197(服务 2010-3-7)张恂做您的私人顾问和教练，面向个人的软件研发和管理技能提升（成为 Agile 与 OO 的开发者|管理者|架构师|项目经理）。 2010 最佳案例 828(案例 2010-3-4)2010 最佳案例 |