随笔分类 - 杂论笔记
摘要：第九章 现实中的软件工程理想状况下，软件工程=过程+方法+工具。然而工程成功的真正关键，并不在于你把你的团队“组织”得多好。即使在团队中他们都表现得有条不紊，你一样会面临失败。愚公如果停下来，思考的问题可能是碎石的方法，而项目经理从细节中跳出来，思考的问题就应当是完成工程的方法。评价这个方法的好坏的...
阅读全文
摘要：第六章 谁是解结的人在一个模式化的公司里，体制上最大的敌人其实是模式本身。在通常情况下，一个团队的特质是管理者在团队生活和行为过程中逐渐形成的。成功的经验往往最不可信，因为一方面，成功者沉醉于成功的喜悦，并急于与人分享快乐与荣誉，而不关注这些成功的前提与背景。另一方面，听取这些经验的人则因为那些“既...
阅读全文
摘要：第四章 流于形式的沟通C语言是程序员与计算机交流的语言，而不是他与客户交流的语言，程序员面对的是计算机，但计算机不是客户。因此，开发人员最好不要直接面对客户。项目经理由这样一种优势： 他可以不用了解C语言，也可以用一种非C的语言来与客户交流。要深入项目需求阶段的项目经理或者调研人员，被要求深谙项目所...
阅读全文
摘要：第一章 编程的精义愚公移山项目，原始需求的产生：“惩山北之塞，出入之迂”项目沟通基本方式：“聚室而谋曰”项目目标： “毕力平险，指通豫南，达于汉阴”可行方案：“扣石垦壤，箕畚运于渤海之尾”项目中有三名技术人员和一名工程管理人员： “（愚公）率子孙荷担者三夫”外加一名力量较弱但满腹激情的外协： “邻人...
阅读全文
摘要：支撑决策的数据：计划——根据已知的数据，设定合理的目标，预测未来可能发生的情况，制定可行的计划。检查——我们借助度量数据，识别现实与预期的差异、面临的问题、改进的空间。指标：一个指标体系通常包含：指标的维度，每个维度里可选的具体指标，指标的优先级评估，指标的数据采集、分析和使用方法。模型本身其实并不...
阅读全文
摘要：我们不是为了度量而度量，我们要知道度量体系是在什么时候，为谁产生价值，因此我们首先需要回答3个问题：1. 一个开发组织从来都不可能是独立存在的，其所服务的企业业务目标是什么？对应到对开发组织的期望是什么？2. 在开发过程中，谁是度量信息的使用者？他们使用度量信息的目的是为了作什么决策？3. 在梳理清楚上面两个问题之后，最后要回答的才是如何设计一个契合的指标体系来满足这些数据消费的需求？因此，度量体系是引导团队达成业务目标的一整套策略，包含了业务目标、决策场景和指标体系3个阶段。我们可以把软件产品的开发分成几个大的阶段：业务策略、项目定义、项目执行、维护支持。从业务部门期望的及开发组织相关的业务
阅读全文
摘要：风险源于不确定性，然而软件之所以为“软”，就是由其生命周期中所面对的变化和不确定所决定的，从另一个角度讲，不确定性又是与创新如影随形。精益软件开发的度量体系度量本身不是目的，是手段。在很多情况下，数据的生产者不是数据的使用者；数据的生产者没什么动力去分辨信息的价值，也不关心信息准确与否；数据的生产者关心的是数据是否会对自己带来惩罚或是收益，而不是数据跟软件开发的关系；在很多管理者的认识当中，度量的主要目的，是确保事情在掌控之中，为的是获得可靠性和安全感；相对于“更高效的开发软件”这样模糊的目标而言，很多一线人员对度量指标的使用其实更加一个简单、清晰、朴实——一旦开发除了问题，一个自我保护的理由
阅读全文
摘要：极限编程(eXtreme Programming,XP):希望将软件开发过程中的一些好的方法发挥到极致，注重的核心在于沟通、简明、反馈和勇气，用一句话来概括XP的4个核心价值观就是：通过充分的交流和沟通，使产品的设计尽可能简单明了，同时通过客户经常性的反馈，生产出符合客户要求的软件产品，并且有勇气迎接需求的改变。XP的12个主要实践方法对极限编程具有指导性意义：客户计划的制定、小版本发布、隐喻、结对编程、测试驱动开发、重构、稳定的进度、代码共享、编码规范、简单的设计、持续集成、现场客户。RUP(Rational Unify Process, Rational统一过程)：试图总结现代软件开发过程
阅读全文
摘要：模式六十一 没人在意的交付物 没有人愿意为团队开发的一些项目产物掏腰包。每一项产物都需要对应有愿意付钱的资助人。在这种场景中，付钱意味着不仅仅有权利要求开发某产物，而且也有能力把必要的开发资源拨派给团队。没人在意的交付物并没有清晰一致、经过验证的需求，换句话说，没有资助人。考虑一下每一个没人在意的交付物的价值。如果你发现没有人愿意为之付钱，而且项目也不需要它，那么就不要去开发，否则，找到一个资助人。模式六十二 隐藏的美 项目的某些产品不是满足于尚可甚至优雅的标准…而是追求至善至美。所有的设计都存在美学元素，问题是，这种美学元素对你是敌是友？任何设计都不可能通过堆叠附加特性或者外在装饰得到改..
阅读全文
摘要：模式四十一 同事预审 组织让将来与应聘人共事的员工也参与到招聘过程中来。当团队在招聘过程中能拥有话语权的时候，就出现了多赢的局面。从经理的角度上讲，同事预审在雇佣团队组长的问题上同样有效。模式四十二 浮潜与水肺潜水 不同形式的分析活动贯穿项目的整个生命周期：自下而上，自上而下以及先中间后两边。成功的项目团队在项目的整个过程中会把浮潜和水肺潜水两种方式结合起来使用，在特定的时刻明智的选择合适的方法，从而有效的利用时间。 浮潜是一项很好的技术，项目团队可以用它来弄清楚需要研究多少领域，以理解问题和达成目标，而深度潜水的发现常常会改变浮潜阶段所作出的假设。本模式的迹象之一是团队在做广度考察（浮...
阅读全文
摘要：模式二十一 苏式风格 交付的产品包含了客户要求的功能，但却不受客户待见，很快就被搁置一边了。我们需要发掘产品的非功能性需求，成功的团队会把系统性捕获非功能性需求当作流程中的特殊路径对待。避免构建苏式风格的产品，首先，保证你的项目计划中明确包含了非功能性需求。除了持续关注之外，对于能够获取用户好感的非功能性需求，要尽量使用早期项目原型以得到有价值的反馈。模式二十二 自然权力 权力往往会追逐能力，聚集在能力周围。违背自然权力的流动规律，听上去像是在滥用职权。模式二十三 万籁俱寂的办公室 办公室太安静了，凸显出团队已经失去了活力源泉。模式二十四 白线 目标的达成取决于系统内部行为和外部直接活...
阅读全文
摘要：模式一 玩的就是心跳 他们相信最好的工作方式不是先谋而后动，而是竭力追赶时间，该组织经常会断然行动，而非三思而后行，这样导致的结果就是大部分工作都处在不断变化、无法固定的状态，因此该状态容易导致失败，但并非总是失败。模式二 快，赶上 他们对于时间的紧迫性有着内在的直觉，对个人和集体的能力非常有信心并相信迭代的价值。当项目团队决定谁在何时该做什么事情时，呈现出明显的紧迫感，并迫不及待地想立即采取所有必要的行动。模式三 死鱼 项目团队中没有一个人相信项目最终能成功，通常看来，如果其它目标不做修改，截止日期是无法达到的，不可思议的是，没有人指出失败的阴影正如一只散发着恶臭的大死鱼一样把项目变得...
阅读全文