高效软件开发

本文纲要【引言】【技术教练团队】【持续集成】【哪些实践更加优先】【复杂的自动化测试】L0自动化测试L1自动化测试L2自动化测试L3自动化测试【组织级工程实践氛围建设】【小结】【引言】工程实践，也有称为技术实践，其推进在敏捷转型当中具有重要位置，有推算认为效能提升里面的至少一半来自于工程实践。由于不能严格的区分提升来自于哪里，以上推算难以证实，但也可以体会到工程实践的重要性。当一位教练辅导10...

本文摘要为了更快更好的满足业务增长需要，这个跨国银行在全球各分支进行敏捷转型和推广，将敏捷实践应用到大型金融系统开发和维护。本文首先来介绍关于Agile center和敏捷教练的实践背景情况1.案例简述IT系统是银行运营的重要支撑，极端重要，极端慎重 包括变更审批评审文档格式等等在内的重型流程成为快速响应的障碍经过比较选择和试行，进行全球的敏捷转型2.达到的目标更快响应客户，缩短了

在早期的Scrum培训中，燃尽图的典型画法如下： 1，在Sprintd的第一天，识别所有任务的工作量，常常使用理想工时作为单位，缩写是IMD，全文是ideal man day，这样得到燃尽图的第1个点 2，以后每天跟踪各个任务未完成的工作量，早期的工具不多，常用Excel来跟踪，并利用Excel来绘制燃尽图。跟踪部分形状如下： 利用Excel绘制得到的燃尽图如下： 为方便讨论，将此画

2012年12月的某日，@scmroad配置管理之路 发出了条微博 “求教，agile 和 lean， 请问这两个词在敏捷中都是是啥含义？有什么特殊的意思”, 后面@张克强-敏捷307，请我来回答。@张克强-敏捷307:回复@scmroad配置管理之路:lean的翻译是精益。agile的翻译就是敏捷。有观点认为，精益软件开发是敏捷软件开发的其中一种。也有观点认为，精益软件开发与敏捷软件开发是并列的

随着敏捷软件开发宣言的签署和发布，多个敏捷方法框架在全球得到传播和使用。因为各个敏捷方法框架由不同的专家组维护，所以各个方法有不同的表述方式，有不同的着眼点和侧重点。本文将为你介绍敏捷开发方法框架的共同特征，理解与传统软件工程的联系和不同。短迭代的生命周期模型生命周期是事物发展的客观规律，软件同样存在生命周期。早期的软件生命周期往往是说“软件从计划、需求开始，经历分析设计、实现、部署、维护，直到最后

小帆 17:20谁来科普下TDD的好处和坏处是啥？我们市场VP听说了TDD以后情有独钟，但是大致看了一些好像很难推广？菌菌 17:21好处是大大的，坏处是成本很高罗耀秋 17:22你自己开发写代码 你愿意这样干不小帆 17:23@JuneC 好处具体是啥？福瑞德孟 17:24对于一锤子买卖的项目来说，如果没有自动化的工具，那成本一定是大于收益的；对于产品来说，一定是小投入，大收益菌菌 17:28据说

本指南的组成结构为了便于博客阅读，拆分成如下3部分： 1. 苍狼敏捷团队模型 2. 团队建设 3. 干系人管理干系人管理基础干系人管理是为了帮助团队在计划阶段识别组织内外部的干系人，在团队全生命周期当中计划并跟踪干系人的参与活动，以保障团队的成功。干系人又称为相关利益者。下文交待了干系人的基础说明，列举了潜在的干系人，给出了干系人管理策略和典型的干系人参与的活动。说明了如何识别干系人及其

组建项目团队团队领导者根据项目情况、技能需要和组织人力资源布置来组建项目团队。进入条件团队领导者得到指派。输入项目情况和目标； 组织项目管理政策。活动1.团队领导者在与关键干系人沟通后选择团队模型，根据项目情况，从常见的团队模型中选择恰当的团队模型； 2.确定团队边界，帮助识别项目干系人（参见第6章），考虑与干系人的接口，更多相关内容见下文干系人相关内容； 3.确定团队成员，得到上级以及

团队章程概述以前多数软件建设是按项目进行的，有明确的起始和收尾，随着互联网经济的兴起，互联网类软件建设不再是有明确的收尾，不再按照传统项目制进行，更加追求从开发到运维的高效运作，因而组织各种团队，而不是组织项目来处理。 因而项目章程也就不再适用到团队，也就转向了团队章程。 团队章程与项目章程存在很大的相关性，可以理解为从项目转到了团队。 团队章程是提供指导原则、规则并管理团队成员行为的方针政策。

有些敏捷传播者把敏捷看成是划时代的发明，敏捷里面所用到的实践大都归功于敏捷。 而有些敏捷反对者或者质疑者认为敏捷大量的抄袭了原来就有的方法实践，其实没有什么新东西。本文试图来分析下 敏捷到底带来了哪些新东西。 许多东西并不是截然分明的，为了便于表达，定义如下原创程度表示法： - 5 - 绝对原创 - 4 - 不是原创，但大幅度更新 - 3 - 不是原创，但有中幅度更新 - 2

敏捷 规划会议 看板

方法二：利用SVN自身的revision number。最高效的方法是在关键commit时说明打基线，或者说明关键要点，比如评审后修改再复核通过，比如评审通过。方法二更加正式的做法是利用专门的表格记录关键点的Revision Number

用户故事地图，提供了2维的角度来分析用户故事，直观，更加有利于优先级的表达。 在理解用户故事地图时，需要注意其作者的用词跟一般的用户故事不一致，因此要注意跟普通的用户故事用词之间的对应关系。 推荐一般理解如下： 一幅用户故事地图展现1个史诗Epic User Acitivites(Backbone)行，可以理解为对史诗Epic的一级功能分解 User Tasks(

万事开头难！  对于启动敏捷而言，启动前安排一个准备阶段将对顺利的开展第一个迭代很有帮助。整理了下文试图来说明如何准备启动敏捷。  迭代0是指在启动敏捷开发前的准备工作阶段，迭代0一般的时间长度不超过所选择的迭代周期。 对于看板类做法，如果没有明确的迭代周期，那么建议不超过2周，为方便，将看板类的准备工作阶段仍然称为迭代0。 （附带推荐-对于看板类做法，仍然推荐安排迭代用于回顾和定期展望等等活动

用户故事自最早1998年诞生以来，由于其突出的优点，到现在得到了广泛的应用。一般而言，用户故事里面的用户是人类用户，用户故事在表达人类用户与系统的交互方面已经证明了其有效性。  那么当处理系统之间交互时，我们能不能参照用户故事来说明系统交互的需求？ 让系统来讲讲故事？ 这样的故事不妨称之为系统故事。 微博上有朋友形象的说这是瓦力和伊娃之间的故事。

鸡蛋估算法原理鸡蛋估算法，或者称鸡蛋计数法，在包括软件开发的智慧工作领域，是指对所处理对象进行简单分解后计量个数，直接作为规模。比如在敏捷软件开发中，对于迭代工作的范围大小，直接以用户故事个数为规模，不再细分故事点数，不再识别子任务，也不再估算理想工时数量。之所以用鸡蛋估算法（也称鸡蛋计数法）来命名这个方法，是因为鸡蛋的大小范围在同一个数量级上，容忍在这个范围变化，不再做更精细的估算。其实T...

关于Definition of Done 完成的定义DoD在以往的说法中，常见用 退出标准 , 完成条件，成功标准，等等典型的是迭代的DoD，这也是最初DoD应用的地方。 常见在Scrum中，需要预先定义DoD。常见的迭代DoD条款1，所有完成的用户故事得到PO的验证2，所有代码得到静态分析，纠正最高级别的不符合项，静态分析的规则参见…3，所有新增代码得到人工评审4，所有完成的用户故...

看板上面的列，一般的就表明了卡片所属的状态。看板列的名称列的名称用简单的文字清晰的表明所处的状态。最简单的列名称组合是“Todo”，“Doing”，“Done”，这是来自于经典的scrum board。本文所说看板按广义定义，以上scrum board也看成是看板的一种形式。 在软件开发看板中，最经典的列名称组合有： 待办，分析，编码，测试，待上线，上线。 为了更加清晰表明状态完...

职能筒仓在软件开发当中，尤其是敏捷开发当中，貌似带着负面的光环，最新的特性团队建设试图打破职能筒仓。而在看板列设置的时候，按角色划分的看板列在形状和内容上都太像职能筒仓了，难道看板这样的列设置走了回头路？看板的起源要回答这个问题，先来看看看板的起源。 看板管理方法是在同一道工序或者前后工序之间进行物流或信息流的传递。JIT是一种拉动式的管理方式，它需要从最后一道工序通过信息流向上一道...

业务敏捷，从最早提出到现在也许超过8年时间了。 但正真得到有效的实施恐怕还不多。这么多年来，围绕着敏捷和业务敏捷已经有诸多讨论。本文作为本号的第一篇，试图来谈谈业务敏捷的特征。 1，贯穿业务创意和机会捕捉到需求识别到开发上线再到业务运营，形成大反馈闭环。 2，业务人员和IT人员协同参与，达成共同目标。 3，从创意到上线运营所需时间得到度量，并能够缩短。 4，线上运营的业务数据得到监控，从...

[原文发表在https://hespr.blogspot.jp/2009/03/blog-post.html 写在2009年3月 最近发现被人盗版了多处, 重新发布在CSDN]最近读了《我和敏捷团队的五个约定》（from InfoQ），很是赞同，不少来自于传统方法，似乎并没有体现敏捷团队的特点。 在敏捷开发的测试方面有没有不一样于传统开发测试的并且是有效的实践？ 从敏捷团队的组建上来说，敏捷团

标题问题的提出是因为在敏捷教练小伙伴微信群里面的一段对话，摘录如下。 张克强 10:35 Scrum碰到高频交付，其最小集合要求也得改。 徐毅 10:36 @张克强-独立教练-上海 什么是scrum，它不能应对高频交付吗 张克强 10:37 到每迭代一次交付的频度就超越了Scrum创始时应对的情景。 张克强 10:38 90年代的高频是相对当时的瀑布说的。 张克强 10:38 现

早期用户故事写在卡片上，只需一个句子。随着越来越多的系统和产品采用敏捷开发，对于有些复杂长生命周期的系统和产品而言，用户故事的内容值得积累，以便后续追查和修改。另外一个情形是为了确保用户故事真的完成，需要在前期就明确其验收条件（也翻译为接收条件），因此曾几何时开始，用户故事的写法成了 用户故事经典句式+验收条件。

最近常常碰到的一个问题是 如何看待和处理迭代中的backlog的变化？Scrum对Sprint backlog范围在Sprint中坚持不变，这与瀑布里面冻结需求的做法较为接近。这样的迭代待办事项的冻结，对外不能快速响应外部的变化；对内让团队吃自己的狗食，并且容易引起product owner与scrum master和团队对于迭代工作范围的矛盾，进而给scrum mastsr提出了非常高的软技能要求

曾几何时开始，用户故事的写法成了 用户故事经典句式+验收条件。 在https://blog.versionone.com/agile-acceptance-criteria/ 上提供了如下一个故事的样例。As an executive, I want to be able to filter the dashboard by department so that I can isolate dat

4年多前，在微博上说起了苍狼敏捷，3年前把这个初步的版本发在了百度空间，没想到百度空间竟然关闭了，好不容易从百度云备份当中取出。最近讨论狼文化，拿出来晒晒，供批判参考。 后续打算更新下，以反映最新的实践和认识。 另外说明，方法都是被选用的，有适应范围和局限性。苍狼敏捷方法遵循敏捷软件开发宣言。崇尚沟通，简单，反馈，勇气，尊重，进取，挑战七大价值观。 苍狼敏捷崇尚8小时内完成工作，认为超时工作

本词汇表是旨在说明敏捷与DevOps中各种术语。 由于敏捷与DevOps存在紧密的联系，在讲述DevOps时需要引用到大量的来自敏捷的词汇，因此本文试图做些整理 词汇名称 对应英文 说明 重构 Refactor 指保持某个对象的外在行为不变，优化其内部结构。代码重构是重构的一种。 代码重构 Code refactor 保持程序代码的外在行为不变，优化代码。在面向对

1，专门的机构或专人来推进组织级敏捷，可能的机构名称有：敏捷中心、卓越中心、过程改进部、SEPG、质量部、运营改善部、PMO、Delivery Excellence；可能的专人有：过程总监、质量总监、项目管理总监、Chief Agile Coach。 2，敏捷开发涉及到各项方方面面，就算是采用书本上的某些实践，比如用户故事，各个团队各个组织都有些定制化或改造过的做法，比如新加tech story，

本文用于收集整理软件开发词汇

Dennis van der Stelt在Yahoo的scrumdevelopment组（http://groups.yahoo.com/group/scrumdevelopment/）发起了题为“Commitment to Definition of Done”的讨论。背景是D

用什么词来描述某个组织采用敏捷呢？ 敏捷采用？敏捷导入？敏捷转型？敏捷引入？敏捷改进？ 从这些词当中可以发现不同级别的组织采用敏捷是不一样的，大体可以分为项目级、部门级和公司级，不同组织级别的敏捷导入or转型or改进得到的高层支持不一样，可以采取的手段不一样。       #

权力运用的七重境界第一重：吩咐，作为经理人做出决定。第二重：推销，说服有关的人相信决定。第三重：咨询，在决定前听取团队的意见。第四重：加入，与团队一起决定。第五重：建议，影响团队的决定。第六重：确认，在团队做出决定后，要求获得反馈。第七重：代表，没有影

在软件工程术语中，“原始需求”并不是个常见的说法。这个“原始需求”的提法是本博主自己提出来的。它的起源与CMM有关，CMM中，有“客户需求”的说法。当时没有直接采用“客户需求”而采用“原始需求”的主要原因是当时开发产品不直接面对客户，直接面对的是工程实施部门，需求来自

写完上文 《CMM/CMMI的20年和敏捷十年》，想起了我在AgileChina Google Group曾有过一段对话。起因是有网友这样说道：1、那些用敏捷去套CMMi、瀑布模型的家伙都是大忽悠，两者根本的假设就不一样，无法融合。这种观点之所以有市场不过是让原有

近来在InfoQ上陆续翻译了纪念回顾敏捷十年的文章，在CMM/CMMI/Agile都有兴趣的我不由得想到从1991年CMM1.0发布之时算起，今年正好也是CMM/CMMI的20年。对比看下两者的历史，也许会有些意思。SEI1986年在美国国防部资助下开始研究能力成熟度模型

关键词： 过程改进 改进建议 改进机会摘要：改进建议（也有叫改进机会）推进往往是过程改进的源动力，本文讲述了以下四个方面的有效实践，分别是收集改进建议，分类、分级别处理改进建议，改进建议的状态管理和改进建议的统计分析。通过这些有效实践，可以管理改进建议的完整生命周期，可以

在今年与多个软件开发单位的交流中，补文档的问题多次提到，试图通过本文谈谈文档的价值，如何写刚刚好的文档。软件开发所需要的文档在传统的瀑布型生命周期下典型的有：开发计划，需求规格说明书，设计书（有分成基本设计书、详细设计书；也有分成High Level Design、Low L

场景1合同谈判：经过了长达3个月的前期交流讨论，终于谈清楚了所有的技术附件和商务条款，又过了2周总算等齐了双方高层领导，终于签订了合同，客户要求越快上线越好。场景2产品立项：产品研发立项调研了4个多月了，立项调研报告已经修改了3次了，仍然没有决定是否正式立项，等待着高层领导的

每日集成和持续集成现在成为软件开发的最推荐实践，通过整理不同的做法来比较比较看，也许会有意思的:) 第1重，手工打开n个工程，复制m个文件，按照脑袋里的次序一个一个编译，花费了不少时间，总算编译完成了。换个工程师来编译就出了好多错，问了很多问题，最后历经千难万险总

Alistair Cockburn 在90年代初受IBM之约进行正规方法的研究。 Cockburn除了归纳整理他自己的实践经验以外，他还积极地造访其他项目，和项目组成员进行广泛的讨论， 考察这些项目是怎样运作的。Alistair Cockburn提出了 水晶（Crystal〕 方