《敏捷思维方法学》由会员分享，可在线阅读，更多相关《敏捷思维方法学（34页珍藏版）》请在金锄头文库上搜索。
1、低碳雇佣军团低碳雇佣军团 以您尊贵的品牌或名义以您尊贵的品牌或名义 帮您精确锁定节能率 狙击低碳收益帮您精确锁定节能率 狙击低碳收益 城市照明减碳项目一体化外包机构 支援呼叫 13823741008 一 从方法论看架构设计一 从方法论看架构设计 方法论对软件开发而言意味着什么 我们如何看待软件开发中的方法 论 方法论能够成为软件开发的救命稻草吗 在读过此文后 这些疑惑就会得到 解答 在第一篇文章中 我们来了解标题中的一些词的含义 方法学是什么 敏捷是什么 为什么讨论架构 方法论方法论 方法论的英文为 Methodology 词典中的解释为 A series of related methods
2、 or techniques 我们可以把它定义为软件开发 针对软件开发 的一整 套方法 过程 规则 实践 技术 关于方法论的出现的问题 我很赞同 Alistair Cockburn 的一句话 方法论源于恐惧 出于对项目的超期 成本失控等等因 素的恐惧 项目经理们从以前的经验出发 制定出了一些控制 监测项目的方法 技巧 这就是方法论产生的原因 在 Agile Software Development 一书中 作者提到了方法论的十三个 要素 基本能够函盖方法论的各个方面 角色 Roles 个性 Personality 技能 Skills 团队 Teams 技术 Techniques 活动 Acti
3、vities 过程 Process PDF 文件使用 pdfFactory Pro 试用版本创建 低碳雇佣军团低碳雇佣军团 以您尊贵的品牌或名义以您尊贵的品牌或名义 帮您精确锁定节能率 狙击低碳收益帮您精确锁定节能率 狙击低碳收益 城市照明减碳项目一体化外包机构 支援呼叫 13823741008 工件 Work products 里程碑 Milestones 标准 Standards 质量 Quality 工具 Tools 团队价值 Team Values 它们之间的关系可以用一幅图来表示 图 1 方法论的十三个要素 很多的方法论 都涉及了上面列举的十三要素中的部分要素 因此 我 们可以把方法
4、论看作是一个抽象的 无穷的超集 而现实中的方法论都是指超集 的一个有限的子集而已 它们之间的关系就好像有理数和 1 到 100 之间的整数的 关系一样 不论是 XP 还是 UI 设计经验之类 都属于方法论的一个子集 只是 这两个子集之间有大小的差别而已 我们还应该看到 讨论一个完备的方法论是 没有意义的 因此这种方法论铁定不存在 就好像你视图穷举出所有的有理数一 样荒唐 因此 我们关于一个通用的方法论的说法也是无意义的 好的方法论 PDF 文件使用 pdfFactory Pro 试用版本创建 低碳雇佣军团低碳雇佣军团 以您尊贵的品牌或名义以您尊贵的品牌或名义 帮您精确锁定节能率 狙击低碳收益帮
5、您精确锁定节能率 狙击低碳收益 城市照明减碳项目一体化外包机构 支援呼叫 13823741008 比如说 XP 水晶系列 它们都有一个适合的范围 因为它们了解一点 自己并 不是一个无所不能的方法论 在现实中 我们其实不断的在接触方法论 比如说 为了控制项目的进 度 项目经理要求所有的开发人员每周递交一份详细的进度报告 这就是一种方 法 一种技巧 如果把开发过程中的这些技巧系统的组织起来 就能够成为一种 方法论 你可能会说 那一种方法论的产生也太容易了吧 不 这样产生的方法 论并没有太大的实用价值 没有实用价值的方法论根本就没有存在的必要 因此 一个成功的方法论是要能够为多个的项目所接受 并且能
6、够成功实现软件的交付 的方法论 我和我的同事在实践中做了一些试验 希望能够把一些好的方法论应用 于开发团队 试验的结果很无奈 方法论实施的效果并不理想 一开始我们认为 是方法本身的原因 到后来 我们发现事情并不是这么简单 在试验的过程中 开发人员一致认同方法论的优势所在 但是在实施过程中 鲜有坚持的下来的 在 Agile Software Development 中 我发现作者遇到了和我们一样的问题 Alistair Cockburn 在和大量的项目团队的访谈之后 写成了 Agile Software Development 一书 在访谈之前 他笃定自己将会发现高度精确的过 程控制是成功的关键
7、所在 结果他发现事实并非如此 他把他的发现归结为 7 条定律 而我在实际中的发现也包含在这七条定律中 总结起来就只有两点 沟 通和反馈 只要能够保证良好的沟通和即时的反馈 那么开发团队即使并没有采用 先进的方法论 一样可以成功 相反 那些 高质量 的团队却往往由于缺乏这两 个因素而导致失败 我们这里指的失败是用户拒绝使用最终的软件 最有效 而成本也最低的沟通方法就是面对面 face to face 的沟通 而随着项目团队 的变大 或是另外一些影响因素的加入 比如地理位置的隔绝 面对面的沟通 越来越难实现 这导致沟通的的成本逐渐加大 质量也慢慢下降 但这并不是说 非面对面的沟通不可 重要的是我们
8、需要知道不同的沟通方式的成本和质量并不 相同 XP 方法尤为强调面对面的沟通 通过现场客户 站立会议 结对编程等 方式来保证沟通的有效 在我的经验中 一个开发团队其实是需要多种沟通方式 的结合的 完全的面对面的沟通对某些团队来说是很难实现的 那么问题的关键 就在于你如何应用沟通的方式来达到你希望的效果 在前不久结束的欧莱雅创业 计划大赛上 有一支团队特别引人注目 他们彼此间素未谋面 仅仅凭借 Internet 和电话完成了高效的合作 他们虽然没有使用面对面的沟通方式 但 是仍然达成了既定的目标 软件开发也是一样的 面对面的沟通是非常有必要的 但其它的沟通方式也是需要的 再看反馈 不论是控制进度
9、 还是保证客户的满意度 这些活动都需要 管理成本 软件开发中的管理成本的一个通性就是伴随有中间产出物 PDF 文件使用 pdfFactory Pro 试用版本创建 低碳雇佣军团低碳雇佣军团 以您尊贵的品牌或名义以您尊贵的品牌或名义 帮您精确锁定节能率 狙击低碳收益帮您精确锁定节能率 狙击低碳收益 城市照明减碳项目一体化外包机构 支援呼叫 13823741008 intermediate delivery 比如说我们的需求规约 分析文档 设计文档 测试计划 这些都属于中间产出物 中间产出物的增加将会带来效率下降的问题 因为开发人员的时间都花在了完成中间产出物的工作上 花在给软件新功能上的 时间就
10、减少了 而中间产出物的主要目的是两个 一个是为了保证软件如客户所 愿 例如需求规约 另一个是为了作为团队中的其他成员工作的输入 例如开发 计划 测试计划等 因此 我们也可以针对这两点来商讨对策 一种是采用迭代 的思想 提高软件发布的频率 以保证客户的需求被确实的满足 另一种就是缩 小团队的沟通范围 保证成员能够从其他人那里得到新的思路 而不是撰写规范 的内部文档 内部文档指那些仅为内部开发人员之间的沟通所需要的文档 因此 一个软件项目的成功和你采用的开发方法论并没有直接的关系 重量重量 我们根据把拥有大量 artifact RUP 官方翻译为工件 意思是软件开发 过程中的中间产物 如需求规约
11、设计模型等 和复杂控制的软件开发方法称为 重型 Heavy Weight 方法 相对的 我们称 artifact 较少的方法为轻型 Light Weight 方法 在传统的观念中 我们认为重型方法要比轻型安全许多 因为我 们之所以想出重型方法 就是由于在中大型的项目中 项目经理往往远离代码 他无法有效的了解目前的工程的进度 质量 成本等因素 为了克服未知的恐惧 感 项目经理制定了大量的中间管理方法 希望能够控制整个项目 最典型的莫 过于要求开发人员频繁的递交各种表示项目目前状态的报告 在 Planning XP 一书中有一段讨论轻重型方法论的精辟论述 它把重型 方法论归结为一种防御性的姿态 d
12、efensive posture 而把轻型方法论归结 为一种渴望成功 Plan to win 的心态 如果你是采用了防御性姿态 那么你 的工作就集中在防止和跟踪错误上 大量的工作流程的制定 是为了保证项目不 犯错误 而不是项目成功 而这种方法也不可谓不好 但前提是如果整个团队能 够满足前面所提到的两个条件的话 项目也肯定会成功 但是重型方法论的一个 弊端就在于 大家都在防止错误 都在惧怕错误 因此人和人之间的关系是很微 妙的 要达到充分的沟通也是很难的 最终 连对人的评价也变成是以避免错误 的多寡作为考评的依据 而不是成就 我们在做试验的时候 一位项目经理开玩 笑说 方法论源自项目经理的恐惧
13、这没错 但最糟糕的是整个团队只有项目 经理一个人恐惧 如果能够做到人人的恐惧 那大家也就没有什么好恐惧的了 这句话提醒了我们 如果一个团队的精神就是力求成功 那么这支团队的心态 就和其它的团队不同了 尤其是对待错误的心态上 根本就没有必要花费大量的 精力来预防错误 错误犯了就犯了 即时改正就可以了 这其实就是渴望成功的 心态 方法论的艺术方法论的艺术 PDF 文件使用 pdfFactory Pro 试用版本创建 低碳雇佣军团低碳雇佣军团 以您尊贵的品牌或名义以您尊贵的品牌或名义 帮您精确锁定节能率 狙击低碳收益帮您精确锁定节能率 狙击低碳收益 城市照明减碳项目一体化外包机构 支援呼叫 1382
14、3741008 管理 被称为科学和艺术的融合体 而管理的艺术性部分很大程度的体 现为人的管理上 我说 方法学 一样是科学和艺术的融合体 这是有依据的 其实方法论和管理学是近亲关系 管理学中有一门分支是项目管理 而在软件组 织中 项目管理是非常重要的 方法学就是一种针对软件开发的一种特定的项目 管理 或是项目管理的一个子集 重型方法最大的一个问题就在于他不清楚或忽略了艺术这个层次 忽视 了人的因素 把人做为一个计量单位 一种资源 一种线性元素 而人的要素在 软件开发中是非常重要的 软件开发实际上是一种知识 智力的转移过程 最终 形成的产品是一种知识产品 它的成本取决于开发者的知识价值 因此 人是
15、最 重要的因素 而人这个要素是很难衡量的 每个人都有不同的个性 想法 经验 经历 这么多复杂的因素加在一起 就导致了人的不可预见性 因此 我们强调 管人的艺术 最简单的例子是 在重型方法中 我们的基本假设是对人的不信任 项 目经理要控制项目 但不信任就会产生很多的问题 比如士气不高 计划赶不上 变化 创新能力低下 跳槽率升高等等 人都是希望被尊重的 技术人员更看重 这一点 而很多公司也口口声声说自己多么多么以人为本 可是采用的却是以不 信任人为前提的开发方法 言行不一 我们说敏捷方法的出发点是相互信任 做 到这一点是很难的 但是一旦做到了 那这个团队就是非常具有竞争力的 因此 这就产生了一个问
16、题 在没有做到完全的相互信任之前 我们到底相不相信他人 呢 这就是我提到的艺术性的问题 什么时候你要相信人 什么时候你不相信人 这些都是需要权衡的问题 也都是表现你艺术性的问题 敏捷敏捷 敏捷代表着有效和灵活 我们称那些轻型的 有效的方法为敏捷方法 在重型方法中 我们在一些不必要 重复的中间环节上浪费了太多的精力 而敏 捷则避免了这种浪费 我们的文章将会重点的讨论敏捷 Agile 方法论的思想 敏捷这个名字的前身就是轻型 目前已经有了一个敏捷联盟 他们制定了敏捷宣 言 Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 而我对敏捷的理解包括了几个方面 PDF 文件使用 pdfFactory Pro 试用版本创建 低碳雇佣军团低碳雇佣军团 以您尊贵的品牌
