敏捷软件开发ASD-01-01方法论.pptVIP

Agile Software Development 一场协作者的游戏 Agenda 1 不可知和只可意会 Can you ever know what you are experiencing, and can you ever communicate it ? 1.1 解析体验(Parsing Experience)的问题 人类对世界的认识通常分解为若干部分，使用含糊的文字分别描述 定式思维：以城市为中心的思想就是定式思维 这样的解析模式存在若干问题： Conflicting Parsing Patterns Thinking Inexact Thoughts 解析模式冲突 人类体验的解析存在许多不同的模式，每种模式都会产生完全不同的经验感觉 使用解析结果重构后的体验通常会与实际存在细小而不易察觉的差异 佛说：不要执著 对一个方面的执着会忽视其他的方面 按照不准确的想法思考 We dont notice what is in front of us, we dont have adequate names for what we do notice When we go to communicate, we dont know exactly what it is we mean to communicate. The only thing that might be worse is if we couldnt actually communicate our message. 对软件开发的启示 需求编写者的思维定式会产生观察错误 对过程的痴迷通常忽略了人的重要性 用户和设计者都不能足够地识别、解析和命名他们的体验 边做边设计(design by doing)? 1.2 交流的不可能性 Shannon的信息论原理中讨论了“受限通道”问题： 通信词汇是预先已知的 (the communication vocabulary is known in advance ) 体现在三个方面 Internal Restructuring Touching into Shared Experience 内部重建 所接收的信息是内部重建的一种度量 反映了接收者在信息接收后，对世界的预测模型的一种变化 每个人在接受信息时，都会根据预测模型进行思考 触及共同的体验 成功的交流依赖于双方具有共同的体验 交流必须建立接触点(touch point) 体验是个人的阅历，接触点随着体验而增长 随着认知的发展，体验级别逐渐提高 管理不完整的交流 交流永远都不可能完美和完整 信息接收方必须在某些点上跨越一道隔阂，而且必须独自跨越 双发的差异越大，可以跨越的隔阂越小 你只能后退，解释基本概念，以便减小差异 后退没有终点 我们在规格说明和设计中尽我们所能地解释意图 但是我们不能奢求可以完整说明需求和设计 我们只能假设读者具有一定级别的体验 任何对完整交流的企图都是枉然，科学的态度应该是管理交流中的不完整性 2 一场关于创造和交流的游戏 2.1 Software and Games 软件开发的组成结构 理解问题空间 在可行的技术空间内想象解决问题的某些机制 以可执行语言的形式表达智力构造 软件与其他 我们仍然处于一种期望团队产生的设计优于他人的阶段，而且技术的快速变化难以产生工程手册 工程的另一种含义是“思考并权衡” 使用工程观点刻画软件开发对项目运行不会产生很多的指导 但是，使用模型构造观点则可能在项目运行中产生不恰当的决定 建立模型不是软件开发的目的 交流的效果比交流的形式更重要 2.2 软件开发是协作游戏 软件开发是一场关于创造和交流的游戏 软件开发的第一目标是交付可用的工作软件，作为游戏遗产的第二目标是为下一场游戏建立基础 讨论的相关问题包括 Programmers as Communications Specialists Gaming Faster Diminishing Returns Sufficiency for the Primary Goal Sufficiency in the Residue A Game within a Game 领导-协作模型 取决于领导和写作，而不是命令和控制 不幸的是，大多数项目不是被领导的，而是被管理的 协作是控制工作态而不是工作流 协作和信任、尊重和参与者人际价值相关 责任用于防止出错、误解和无意的不诚实 程序员应该是交流专家 程序员给人的映象是不善交流的人，他们一般坐在昏暗的房间里对着屏幕独自冥思苦想 这反映了游戏的创造性特征 程序员的兴趣似乎在编程技术方面，而不关心与发起者、用户和业务专家的交流 这样的状况可能部分归咎于大学的教学课程 大学应该加强这些方面的教育 更快