— 笔记整理自 北京理工大学 计算机学院

软件开发的方法论

• 方法论
  • 一系列需要照着做的方法
  • 一系列约束开发人员的规则
• 软件工程是非常实践、非常工程、非常灵活的一套方法
• 某些方法在某些情况下会比另一些方法好，反之亦然
• 最终目的是：学习方法 -> 实践方法 -> 忘掉方法

方法论源于恐惧

Alistair Cockburn:方法论源于恐惧

—— 出于对项目的超期、成本失控等等因素的恐惧，项目经理们从以前的经验出发，制定出了一些控制、监测项目的方法、技巧

比如老板或项目管理者恐惧被一些掌握了核心技术的人员掐住脖子，从而制定了一些监管方法与技巧

方法论

• 理想的方法论是一个抽象的、无穷的超集，而现实中的方法论都是指超集的一个有限的子集
• 不存在一个完备的、通用的方法论
• 成功的方法论:经历过多个项目的检验
• 方法论的分类
  • 按照规则的多少和约束的强弱，或者软件开发过程中的中间产物，如需求规约、设计模型等
  • 重型方法和轻型方法

1 ） 重型方法

• 特征:正规、严谨、开发人员具有较强的可替代性
• 侧重点:计划、过程、中间产物(状态 告)
• 不同人员偏爱程度不同
  • 管理者(偏爱)
  • 开发人员(讨厌)

2 ） 轻型方法

• 特征:迭代、重构、响应需求变化
• 交付物
  • 代码
  • 可运行的产品
  • 测试用例
• 管理成本低(管理人员少,管理成本少,会议少)而高效
• 开发人员较偏爱(必要，简洁的文档)

3 ） 方法论轻重的确定

• 没有两个项目会采用完全相同的方法论(世界上没有完全相同的两篇树叶)
• 软件工程是非常灵活的一套方法
• 可考虑因素: 项目规模和紧要性
• 提倡“刚刚够”(Barely Sufficient)
• 工作重点: 沟通、反馈、频繁交付(增量式交付)
• 管理目标: 有效和灵活

4 ） 轻重方法的融合

• 自动化技术和工具使得轻重方法之间的界限进一步模糊
• 自动化工具的同步特性支持轻型方法的迭代和重构
• 自动化工具的模型翻译和转换依赖于重型方法的详尽文档和模型
• 很多自动化工具可以将设计的UML类图和它们之间的关系转化为代码，反过来从代码中可时时转化为模型
• 大型软件项目往往结合轻型方法和重型方法

5 ） 瀑布模型被取代了么/strong>

• 所有的软件开发方法论和开发模型都毫无例外的由基本开发活动构成
• 不同的方法论相互结合而非取代
• 瀑布过时了! 不存在了! (绝对不是!)
• 从不同的方法论中借鉴适合自己团队的的方法和工具

站立会议 – 计划纸牌 – 结对编程 – TDD – 用户故事 – 自家发明的新方法