二十三 解决流于形式的敏捷实践

面对慢慢流于形式的敏捷实践,该怎么办? 在某些情况下,敏捷实践不能够坚持而流于形式。作为项目管理者,需要做的不是强行用行政手段强推实践,也不是放任自流,而应该做的分析这个实践所期待发挥的价值,采取正确的策略应对。 以当前团队中对于验收条件的态度变化为例。 在实践验收条件几个月之后,从各方的反馈来看,似乎验收条件不被重视: 对于开发人员来说,因为有详细的设计文档,大部分详细信息都在设计文档中体现,他们倾向于看文档一步一步完成,而不是通过验收条件找具体设计; 对于测试人员来说,也因为有详细的设计文档,所有测试用例都在设计文档的帮助下完成,最终的测试脚本就是所有测试用例,而不是按照验收条件的顺序; 对于分析人员来说,因为开发和测试人员对于验收条件的漠然,对于书写验收条件的工作开始变得倦怠, »

二十二 敏捷项目的三层保护

为什么需要保护? 谁来保护? 如何保护? 敏捷项目因为透明而往往趋向于脆弱——一个鼓励提前暴露风险和缺陷的精益环境,它把交付团队的一切都展露无疑,风险或者坏味道在第一时间就可以被暴露。风险或缺陷的提前暴露,在某种情况下会引起客户的不安,如果没有适当的引导和疏解,这样的不安会变成很多“反敏捷”的动作,例如:填写每日工作日志审核,或者按照合同强压开发上。结果是,我们推崇的敏捷特性——越早发现缺陷,浪费越少——最后走向了敏捷的反面。 通常的做法,其实也是最简单的做法就是有选择性地暴露,对于某些影响小的,可控的风险或缺陷,只将它在团队内部暴露, »

二十一 敏捷后

没有路线图,实践终有一天会被忘记。 为什么我会觉得疲惫不堪且阻力重重,为什么似西西弗斯(Sisyphus)的巨石终日不得安息,为什么若置黑洞中旋转挣扎?敏捷实践不受保护,甚至被榨干每一点可能的改进,所有人都在焦虑等待敏捷能够带来的可以体会的好处时,敏捷本身到底应该何去何从? 我们的敏捷实践是一个关于50多个善良可爱的底层开发者精益化自己这个小组织的故事。在这个组织里,业务组(负责业务逻辑的开发)便是核心的价值流,我们所有工作都围绕在保障业务组顺利进行开发的前提下,任何阻碍业务组开发活动的活动都应该被避免,其他小组任何超过业务组工作节奏的工作都应该被避免。 为了减少等待,我们把之前独立的辅助小组和业务组进行整合,充分鼓励他们努力学习对方的知识,让之前必须两个小组完成的事情现在可以一个小组完成;为了减少浪费,我们随时关注那些进度过快的辅助小组,要他们慢一些, »

二十 杀死敏捷

客户、销售、友商三人一起谋杀敏捷 你可以这样思考,敏捷最成功的实例一定是具有以下三个元素:客户对精益生产的认同,销售在交付压力方面对团队无微不至的保护,友商的通力协作和配合。那么敏捷最失败的实例一定具有以下三个元素:客户足够强大搞死团队、客户和销售合作搞死团队、客户、销售和友商通力合作搞死团队。 客户谋杀敏捷的工具很简单,交付压力。那些用合同关系于开发团队绑定的客户,在乎团队开发进度情况,却不在乎如何帮助团队解决,通常做的永远是要求更多的进度报告文档,用更大的压力推动开发暗示完成。最后的结果是,原本敏捷擅长的“及时发现项目风险”的特点,变成“及时让客户更紧张” »

十九 我们忘记CoC了吗?

请问,我们忘记什么是CoC了吗? 还记得敏捷宣言里Customer collaboration over Contract negotiation吗?我无法理解的是,到底是用敏捷让客户与开发商之间达到CoC,还是在CoC之后才能适用敏捷?敏捷宣言到底是敏捷所达到的结果还是制约敏捷实施的准入条件? 如果CoC是敏捷希望达到的目标,那么合约关系对敏捷实践的推行有着强大的阻力。合约关系是目标驱动—合约范围里交付一定量的产品(代码),合作的另一方纯粹是供应商。 就像作为经营超市的业主,我所关心的是我的东西能不能在指定的时间,足量地被提供而已,而我不会去管供应商的生产、物流、配送、质量管理流程。而当供应商的任何一个环节出现问题的时候,都不会趋向于将消息告诉超市的业主, »

十八 敏捷死于交付压力

敏捷项目多死于交付压力 敏捷并不是保证交付的银弹,敏捷也从来不是提高交付速度的工具,敏捷和其他所有项目一样,当交付压力过大时,很可能面临失败。因为敏捷的迭代化特征,使这个交付压力从第一个迭代就能体现,而如果这个交付压力不能够很好的解决,比起传统瀑布式项目来说,更容易造成失败。 传统的瀑布式模型对交付压力的反应最慢。在整个开发期中,交付压力的体现往往需要到后期才能显现——所有人都在工作,谁也不知道能不能完成,这也是为什么延期成为传统软件开发最经常碰到的事情。但是这样的交付压力并不在项目的大部分时间被开发人员体察,于是“做不完怎么办”的忧虑对团队影响比较小,交付压力往往并不是导致瀑布式模型软件开发失败的关键原因,真正的关键原因是在于需求失真,最后的成品不满足客户需要。 而敏捷项目的迭代开发,每个迭代团队能够交付的交付量较为固定, »

十七 浪费本质

对不起,请停下来,努力工作也可能是浪费 对浪费的理解不深刻 杜绝浪费就是“不做不产生价值的东西” 如何“不做不产生价值的东西” 到底什么是浪费,一般的理解里,浪费可以是我们看到公司购买最高档的打印机,但实际上很少人用;浪费可以是本来约定十点的会议到十点二十人才到齐;浪费可以是本来可以一个人解决的事情却需要繁杂的流程审核。 但我们却很少有一个统一认识,只有永远不会使用那台打印机的人才会认为那是浪费;只有最先到达会议室空等的会议组织者才会觉得迟到会是浪费;只有需要去解决问题的那个人才会觉得繁琐流程是浪费。也就是说,人们把对自己不产生价值的却不得不做的行为(等待或执行无必要流程)或者有经济关系的购置物(自己不同可自己可能不得已参与购买)。 在精益的环境里,浪费的本质不是针对每个人而言,而是放在整个组织产生价值的价值流上来考虑— »

十六 一体团队

大型团队敏捷实践得答应我3件事: 我们追求一体化团队 为何不能达成一体化团队 如何达成一体化团队 精益生产中单件流模式最终依靠U型生产线实现,将传统生产方式中产生的库存及等待所产生的浪费降至最低,依靠需求拉动,和有缺陷及停止的制度,保证每件从U型流水线上流出的产品都是符合质量标准并满足需求的。 映射到敏捷软件开发中,将分析人员,开发人员,测试人员集中在一个一体化团队,每个团队的技能足以满足一个需求从设计,开发到测试各个阶段顺利完成,达到符合质量标准并满足需求的软件。这就是一体化团队的概念,就像精益里无处不在的U型生产线,它们处处体现着精益的基因。 在大规模生产的世界里,每个车间都负责生产一种零件,因为各个车间生产效率不同,每个车间都不同程度存在着库存或者等待的情况。市场的快速变化,使得这些库存成为不得不返工的零件,或者不得已低价销售, »

十五 项目启动

让我们推动大铁球 老王是一个典型的H人-充满激情和执行力极强,他忧虑地跟我说:“这个项目就像一个大铁球,人人都知道很重,但是光滑的表面让所有人不知如何使劲”。我的回复是:“你需要一个敏捷里的项目启动”。 这样的项目都有一个类似的特征:一个被拍脑袋的,谁也不知道能不能完成的结束日期;一堆还未明确的需求;一群缺乏计划的开发人员;和一个必须看到团队至少应该干点什么的项目经理。以往的项目开始也许是当项目不得不开始的时候,大家停止争吵说:好吧,一起开始。可能事情不如我相信的那样悲观,但是在上线前几天没人知道团队到底能做到什么程度,应该是确定的。 于是,敏捷项目启动的关键在于确定项目范围,围绕在这个周围的是:故事拆分、 »

十四 敏捷不在于快

我们在乎的是不返工,而不是快速返工 开始前,请记住这几点: 敏捷在于快速反应,不在于速度 速度快不一定是好事,有时反而可能导致反应迟缓 快速反应的基础是合理库存和快速反馈 “敏捷”一词可能很容易被理解为一种高效工作方式,通过对价值关注、减少浪费、简化流程、团队建设、持续改进、和信息共享,使得工作效率得到大幅度提高。当提到“敏捷是拥抱变化的”时,部分人的理解是,一旦我们遇到变化的时候,可以因为工作率的提高而缩短应对变化所需要的时间—达到快速反应。 但是事实上, »

十三 敏捷转型的约定

搞敏捷,你我要有个约定,请不要忽悠我。 我可以理解为了让敏捷推广的难度降低,我们把敏捷实践暂时从编码开始。但请一定明确,在需求的迭代中若没有需求分析的阶段,之后做的所有敏捷实践都是未得本质的活动,我们的最终目标是要从需求分析开始进行敏捷实践,因为需求分析才是敏捷的开始。 敏捷最大的优势,也是可直接体察的价值—通过持续集成和自动化测试,最大限度地得到一个趋向于无缺陷的软件,但往往被忽略的是,这个倾向于无缺陷软件的前提是它必然是一个被期待的软件。如果不,那么所有我们为质量做出的努力都是在用一件绝对正确的事情验证一件绝对错误的事情。 现实并不能让人满意,注重价值的敏捷,在很多情况被简单误解为一种信息验证器,而不是价值。各种看板、Story拆分、任务划分、验收条件等等这些应该成为价值验证的有力工具, »

十二 反馈的风险

很矛盾,鼓励反馈也能产生风险 之前谈到反馈,其实反馈也是项目风险来源之一,和技术风险一起需要项目管理人员及时发现和管理。假设我们已经通过合理的迭代计划(上篇日记记述)找到了鼓励有效反馈和发现记述风险的平衡,而技术风险可以由计划常规的技术风险规避工作量以及Tech Lead配置,对于反馈产生的风险我们如何控制? 用最简单的话说,软件开发最核心三个不同层次的要求是:做可用的软件,做对的可用软件,做对的好用的可用软件。然后考虑任何软件开发必然是一种商业投资,对于每个层次客户都在计算投入产出比: 质量控制:有多少缺陷,有多少性能问题,有多少架构问题; 需求验收:有多少不是需求所要求的,有多少不满足需求; 可用性测试: »

十一 设计迭代计划

用户故事(User Story)没有真正业务价值!” (熊节对本文亦有特殊贡献) 理论告诉我们:应该从高业务价值Story开始进行迭代,这样我们就有更多的时间对高业务价值的Story发现问题并修复。这句话的后半段是告诉我们为什么要这么做,而后半段成立的前提是,我们假设先做一定可以先发现问题。 根据这个理论我们按照Risk-Value的方式把 Story分散在这个二维区间里面,把最靠近于High Risk和High Value的区域作为优先选择放入第一迭代。但是问题是,我们也许可以很容易分辨一个Story的技术风险,但当每个Story独立存在的时候,衡量它的Story价值是否还能够反应真正的业务价值? 有价值(Valuable)作为故事重要的一个标准之一是我们一再强调的概念——每个用户故事都是有价值的。但是大部分情况,我们的拆分都是将一个流程化的业务场景, »

拾 故事拆分和交付范围

简单来说,敏捷就是一个先拆再合的过程。 拆分是一种双刃剑,它让一个抽象的事物从混沌不清到细节分明,使得开发和验收更加高效,但与此同时,对于每一个被拆分出来的元素,客户都有潜在的可能抱怨要求更多。这也就是为什么一些不成熟的敏捷开发项目总是存在客户期待控制不好的问题——因为迭代开发的缘故,客户有机会在开发过程中看到他的主意慢慢成形,敏捷的宣传中对拥抱需求变化的推崇使得客户倾向于变化;而细致的拆分使得一个需求成倍地增加了可变性系数——因为我把需求看得更清楚,那么我就更容易去改变它。 敏捷开发绝不是传统软件开发的对立面,相对于传统软件开发中开发过程对需求提出人不透明来说,开发过程绝对透明的敏捷实践,追求得绝对不是无限制的反馈和拥抱变化,而是在需求范围里接受真正负责任的反馈,而对于需要在需求范围以外实现的改进,应该考虑工作量对团队的影响。之前提到的例子正式在于,开发团队没有与客户达成对某个需求的范围达成一致,导致本应该在需求以外完成的改进被强行当做对这个需求免费的改进,而之前工作量评估基于的需求范围远远小于这个产生误差的范围。 »

玖 邪恶的UX

可能拥有一个外部资源的UX顾问对团队来说是个看起来很美好的事 不管你称UX为什么,UID或者UCD,它的初衷都是极为理想的——用“最好的”用户体验最大化“正确的”软件的使用价值。明显,“最好的”用户体验首先基于“正确的”软件,即一个被需要使用(体验)的软件才会被评判是不是拥有“最好的”体验。而我所观察到的UX的普遍问题就在于,在没有足够深度的分析这个软件是不是一个“需要的(Required)”之前就开始考虑它如何变得”可用的(Usable) »

捌 引导客户

我看,搞客户整体上比找女喷油难一点 首先,最基本的,同理心。 确实,客户不总是对的,但将心比心地为客户考虑永远是对的。我们经常会对客户提出看似不合理的需求烦恼,但实际上我们烦恼的不应该是这件事情本身,而是我们为什么我们不能让客户接受我们所想的方案,当然第一件事情是问自己:我们有我们的方案吗?如果没有,问题变成:我们知道客户到底为什么提出一个我们所谓不合理的需求吗?于是,在我们没有这些答案前,所有我们的抱怨,都是不职业,缺乏考虑,而且极易成为一种情绪破坏现有的客户关系。 我们要做的事情就是将心比心(我知道很土,但真对),用同理心来思考客户为什么要这样, »

柒 最大的风险

敏捷最大的敌人是客户 比起组建高素质和自管理的团队更难的事情是遇到负责任和价值驱动的客户。业界对敏捷最大的担忧是如何才能够组织起一支不需要任务驱动且充满活力的职业团队,特别是在大型开发团队中。然而往往被忽略的是,在这条价值产品线的最开端,我们是否能够保证,提供需求的客户团队是价值驱动且负责任的。 有一个非常坏的语境—敏捷就是拥抱变化。这样经常被销售人员兜售的卖点往往被客户曲解,敏捷从适应市场快速变化追求快速反馈的一种较为科学的方法论,成为一种放纵客户需求变化的托辞—我不需要想太清楚,因为你们告诉我敏捷拥抱变化。结果变成,当我们需要合理的快速反馈时,我们得不到真正的反馈,那个我们唯一希望拥抱变化的理由—既通过快速反馈改进我们的软件—成为一种可有可无的东西。 问题的关键在于拥抱变化被严重曲解,这样的曲解使得我们的客户变得越来越不负责任。这种曲解被转化成最有杀伤力的销售语言:如果你们总是拿不定主意,你们的需求总是摇摆不定, »

陆 匠人精神

敏捷,是一种匠人阶层的唤醒” 我曾经拜访过印度某个Freemason(共济会)分所,这个世界上最大地下组织来源于传说中制造巴比伦神殿的三个石匠。教谕认为石匠是人类中掌握自然奥秘的一群人,常人只是“神有缺陷的复制品”,而只有靠匠工的不懈努力才能修补人类缺陷使其更接近于神。这也是为什么共济会的标志便是圆规和方矩,方圆规矩的隐喻在六芒星下变得直白。 也许西欧文明开化来自于匠工阶层精英化,不论是对技能技巧的极致追求,或是家族荣耀的逐代传承,这样的阶层似乎在可以营造一种近乎偏执的质量文化。之后,匠人阶层的经验和行规在大生产时代演变成各种制造业雏形,最终演化成一种现代的规模化的制造业体系。从匠人阶级到现代制造业体系,必然是某种技能精益,经验积累,和规则验证极致后模式化规模化的演变。而究其根本,其核心充满着精益中两大核心:“以人为本” »

伍 能力建设

丰田精益生产信奉的两大支柱是"以人为本"和"持续改进"而从字面来看第一个是所有的基石。印象深刻的是当我第一谈起这一点时候,我隐约感受到这个强大执行力组织中的管理者心中的迟疑。不止一次地被问道在一个庞大的,人员结构参差不齐的组织中如何实践对参与者要求极高的敏捷实践:“若非丰田那种百年拥有有强大技工文化背景的企业不能真正实现精益生产。” 这便是我们绝大部分客户对于敏捷实践最为疑虑之处: 弱化流程的敏捷方法如何在平庸素质团队执行? 疑虑的产生合乎情理:敏捷崇尚的自管理团队对人的优秀程度要求极高,自管理的团队可望而不可及。当我承认如此现状时,解决方法无外乎两个:其一提高人员优秀程度;其次则降低敏捷实践的要求。 抛开降低敏捷实践的标准不谈,因为咨询师调整标准的权宜之计只可能有策略地采用,当提升团队某方面的能力到达极致仍不可达到。 于是策略在于如何全尽所能提升团队内部执行敏捷的能力,视为敏捷咨询首要目标。 接下来的问题是,团队需要什么样的能力? »

肆 作恶的Portal

我不由自主地开始深恶痛绝Portal这种概念,IBM的伟大在于设计出比微软交互性还要差的Business Moduler软件以及革命性地抛出了个Portal的玩意。我并不知道Portal的始作俑者,能猜测的是,在15年前,当IBM的客户发现软件能够实现的功能越来越多,他们很自然地抛出了一个“怎么能让我在这么多功能里面找到我所需要的业务功能?”,而IBM的咨询师给出了一个Portal的答案-好吧,我们把你所有要用的这些看起来很美好的业务功能都放在一起,我们的WebSphere就是为你们这种高复杂度业务而生,我们把它叫做Portal,当然为了使它们工作得更好,当然我同时推荐我们的服务器哈,另外我们附送200个劳力帮助你们,让我们共建智慧的地球。 或许在这之后10年得某个时间,前端JavaScript已经到了无所不能阶段,某人(这个可能不是IBM的同志)又革命性的在Portal前面加了个山寨无比的i。你明白我的意思伐?是的,也许那个客户又在挠头越来越多的功能放在一起还是很难寻找。 »