扫码阅读
手机扫码阅读

聊聊极限编程与测试启发

56 2024-01-31

这是鼎叔的第六十五篇原创文章。行业大牛和刚毕业的小白,都可以进来聊聊。

继续聊聊著名的敏捷研发框架:极限编程。

极限编程(Extreme Programming,XP)是由Kent Beck在1996年提出的一种软工工程方法学。XP作为最富有成效的方法学之一,相对于传统工程方法,更强调可适应性而不是可预测性。软件需求的不断变化是难以避免的,主动适应变化才是更加现实,更加具有竞争力的态度。

对极限编程理论的理解

XP是一种软件开发风格,专注于编程技术,清晰沟通还有团队协作的实践。XP是始终让客户驱动系统的内容,由团队驱动开发的过程,其工作范式是保持清醒,适应变化

XP致力于解决敏捷软件开发中的所有风险,包括延迟、取消、系统恶化,高缺陷率,业务误解,需求变更,人员流动等。

XP要求你抛弃旧的低效技术和习惯,按照你对团队共同目标做出的贡献来评价自己。

极限编程的价值观和核心实践

XP的基础价值观是加强交流、从简单做起、寻求反馈和勇于实事求是。它采用近似螺旋式的轻量级开发方法,把复杂开发过程分解为一个个相对比较简单的小周期,帮助客户清楚地了解开发进度和待解决的问题,并及时调整。

XP要求遵循的13条核心实践是:团队协作(Whole Team)、规划游戏(the Planning Game)、结对编程(Pair Programming)、测试驱动开发(Testing-Driven Development),重构(Refactoring)、简单设计(Simple Design)、代码集体所有权(Collective Code Ownership)、持续集成(Continuous Integration)、客户测试(Customer Test)、小型发布(Small Release)、40小时工作制(40-hour Week)、编码规范(Code Standard)和系统隐喻(System Metaphor)。如图2-2所示。

XP推崇开放式的工作环境,把客户卷入开发队伍之中,强调频繁测试不断整合的价值,希望尽早交付简单产品给用户以获得反馈。XP方法比较适合小团队的开发实践。

价值观是普适的,实践是基于场景的,那连接两者的桥梁则是原则

XP的原则

一 人性化,在开发中应满足一些人性的需求。软件是由人来开发的,非人性化的管理过程会付出高昂的代价,比如导致人员更替的成本,失去创新的机会。优秀的开发者需要基本的安全感,成就感,归属感,亲切感和成长。

XP中的限制工作时间就是为了给非工作场合的人性化需求挪出时间,从而提高工作时间内的个人贡献。总是牺牲个人需求来满足团队需求也是不可取的,伟大的团队在建立互相信任的关系时,让每个成员可以更加自我。

二 经济学。经济学上影响开发的两个方面是金钱的时间价值(今天的一块钱比明天的一块钱更加值钱),团队和系统的可选择价值(能适应未来变化的系统更有价值),必须有人为所以这些买单,不在没有把握的地方投资。

XP实践应让所有成员和客户都获益,才算是成功的,比如代码重构,优化命名和自动化测试。

改进工作,而不是等待完美。“最好”是“足够好”的敌人,软件开发的卓越是通过改进达到的。

多样性。想法越多,机会越多。关键的困难问题能用几种不同的方法解决。

反省。不要试图掩盖错误,反省后紧跟行动。

。通过参与软件开发的所有活动来交付有价值软件的稳定流,这个流是连续的,通过频繁部署较小的增量来实现。

机遇。有意识地学会把问题变成机遇。

失败。当你不知道怎么做的时候,冒一点风险失败可能是通向成功的最短道路。

质量。项目不会因为接受低质量而加快速度,要求高质量通常导致更快的交付,并且让工程师感到自豪。

责任。责任不能被指派,只能被心甘情愿的接受,同时还要接受相应的实践,责任和权力需要同时承担。

读者可以参阅Kent Beck和Cynthia Andres的《解析极限编程——拥抱变化》

下面我们从测试角度谈谈有哪些主要的启发。

测试启发

一、将业务代表或用户代表卷入到各类测试活动中,越早越好。

充分利用有代表性的客户,帮助我们明确需求的质量要求及优先级,参与早期版本验收测试(尤其是MVP版本,即最小可行产品的版本),尽快反馈能代表用户声音的质量问题。

通过积极的交流,让客户代表非常清楚开发的进度、风险、待解决的质量问题以及背后的困难;同时开发团队也能及时响应商业变化,避免投资浪费。

二、共享代码所有权。

有些团队是比较抵触测试人员获得代码权限,甚至以安全为理由拒绝权限申请。我倾向于支持专职测试人员获得和开发同等的代码权限,至少是阅读和本地编译权限,便于测试人员进行代码理解,精准测试,尝试定位问题等技能。测试人员有机会和开发在同等的信息源上进行技术对话,甚至直接针对代码质量进行规范检查。

测试人员可以推动团队使用单一代码库,对临时分支生命周期进行度量,推动尽快关闭。

三、可持续的工作投入。

即不要长时间加班(工作时间超过40小时/周)。据我观察,一些加班严重的团队效率并不高,加班必要性不强,而每天真正高效的工作时间远远低于8小时,很多时间都被浪费或者拖延掉了。管理者也常陷入只看工时不看效率的低水平管理模式。

可持续的稳定工作时间,才能形成稳定的迭代会议节奏,和准确的工作量估算。团队处于比较松弛的迭代状态是持久健康的,这远比高承诺低交付要好。

在国家明令打击996的今天,企业管理者只能寄希望于法定工作时间内的稳定效率。

因此,如果出现大量加班现象,管理者和客户可以一起确定加班的原因,及时采取缓解措施,进行项目进度和资源的调整。

四、开放的工作空间。

最好15秒内能识别团队的信息工作空间。所有人在一个开放的空间办公(可以有一些小隔间做私人沟通用途),墙上有大白板贴有各种重要的提醒卡片,列出团队共同的目标和愿景,随时可以在白板上进行涂写讨论,甚至可以一起在休息间吃茶点交流。

成员需要团队感,而不是碎片人的感觉。

五、测试驱动开发TDD。

详细解读文章参考本公众号上一篇:聊聊测试驱动开发

XP将单元测试结合到它独特的螺旋式增量型开发过程中,鼓励开发人员先写验收测试通过的代码,再不断补充和重构代码内容,降低冗余代码,并努力保证测试代码的通过。这些测试代码就形成保障质量内建的安全网,同时确保了开发设计从简单开始演进,尽可能避免冗余设计。

对于测试人员,学习TDD的代码可以更好的理解开发人员的设计过程,以及单元测试的完成质量,同时可以把相关测试代码高频率地用于回归测试。多用单元测试替代目前的系统测试,在降低冗余的同时,还能提升根源分析的能力。

对于架构师,应习惯利用测试代替规格说明和解释,并对系统治而分之。

六、结对编程对质量有什么好处。

结对编程是XP实践中争议最大的一点,实施效果参差不齐。由于个人隐私空间被打破,第一次尝试结对编程的开发者通常不太适应,需要管理者加以推动。而且长时间结对很难保障,每天的结对时间通常建议控制在4小时以内。

从个人产出效率来说,结对编程并没有明显的优势,开始时甚至是下降的(因为同时要占用两个开发人员),随着配合越来越默契,结对编程的效率会提升。

但是从设计质量和代码质量角度来评估,结对编程效益明显,因为一个人员在主导编码时,另一个人会对他的设计思路、代码规范、测试质量做评估,及时指出了大部分的初级问题。同理,我们也鼓励测试人员和开发人员一起实践结对编程。

七、泰勒科学管理主义和TPS(丰田产品生产方法)

泰勒主义,把质量从工程中分离出来使得质量部门更像惩罚而不是建设性的。而TPS是把质量融入到工程每个角色和每个环节,强调控制在制品的最大数量,中间零件承载了上游是否稳定工作的信息。

为什么项目中本应该亲密合作的两个角色团队会产生对立?

我认为是,部分团队采用了敏捷原则中对自己有利的部分,而忽视了敏捷的其他重要价值观,沟通,one team,角色互补

部分团队没有学习敏捷,而是泰勒主义的中间人,没有定期停下来审视和集体改进,建设上下游的尊重融合。

八、迭代计划和估算

用户故事的计划就像购买货物,价格就是估值,预算就是时间,尽量晚做出基于最佳信息的决定,降低质量并不会减少工作量。

大团队要缩小,就要学会把大问题转化为小问题,从而可维护,可追溯。为了提高团队的瓶颈吞吐率,尝试把约束转移到团队以外(这需要主管的认可),把推模式变为拉模式。

软件设计质量则依赖核心人员的本能,思考,经验。

合同。和客户签订可协商范围的合同,甚至尝试按次付费(有利于与客户的快速反馈),关注初次产生收益的周期,尽快对外呈现出产品优点。客户只为系统现在或将来功能制品付费,其他都是浪费。

有价值的项目文档应在开发完成后尽快完成,不能为了文档增加基本的开发周期。

最佳的面试方法:先让候选人和团队工作一天吧。

原文链接: http://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484261&idx=1&sn=b323a0f77344dc863b7a98974e1a6393&chksm=c24fb607f5383f113bcd5d0b0065b262031d87f9b67ebd862a2a42ca4c4486d2297333981609#rd

《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。

81 篇文章
浏览 5364
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线