敏捷开发

本文转载自爱码小士。 一.《软件测试的艺术》 适合软件开发人员、IT项目经理等相关读者阅读，还可以作为高等院校计算机相关专业软件测试课程的教材或参考书。 从第1版付梓到现在已经30余年，是软件测试领域的经典著作。本书结构清晰、讲解生动活泼，简明扼要地展示了久经考验的软件测试方法和智慧。 如果对软件测试、接口测试、自动化测试、性能测试、LR脚本开发、面试经验交流。感兴趣可以加群：718897738，群内会有不定期的发放免费的资料链接，这些资料都是从各个技术网站搜集、整理出来的，如果你有好的学习资料可以私聊发我，我会注明出处之后分享给大家。 二.《软件测试》 适合软件测试人员及希望未来从事软件测试的其他专业人员阅读，也适合高等院校相关专业的学生及教师参考。 是一本软件测试的入门书，内容全面实用，讲述浅显易懂，既可作为高等院校软件测试课程的教材，也可作为软件测试爱好者的自学用书。对于那些希望增强软件测试方面知识的程序员、软件项目经理和软件开发团队的其他人员，《计算机科学丛书：软件测试（原书第2版）》也具有很好的参考价值。 三、《Google软件测试之道》 软件测试泰斗传道解惑，Google软件测试精髓完美呈现；淘宝测试技术专家翻译，测试界知名专家鼎力推荐。 从内部视角告诉你这个世界上知名的互联网公司是如何应对21世纪软件测试的独特挑战的。《Google软件测试之道

项目 内容 课程班级博客链接 班级链接 这个作业要求链接 要求链接 团队名称 微风吹过的街道 团队成员分工描述 王颖奇：编码及修复问题 李婷华：测试编码及任务分配 汪慧和：测试编码及组织团队成员 杨野：编码与成果整理 团队的课程学习目标 项目冲刺 这个作业在哪些方面帮助团队实现学习目标 敏捷开发 团队博客链接 博客链接 团队项目Github仓库地址链接 仓库链接 任务1：团队软件项目编码准备，要求如下： 软件开发环境配置说明 tool version show jdk (Java Development Kit) 1.8.0_21 ADB（Android Debug Bridge） 1.0.41 SDK platforms 30 Android Studio 3.5.2 团队商议制定团队项目编码规范 项目编码规范说明文档，上传到团队项目Github仓库 任务2：以实验八作业成果为基础，团队协作编写软件代码，创建程序开发软件关联数据库，进行必要的代码测试 博文导航 【Alpha】Scrum meeting 1 【Alpha】Scrum meeting 2 【Alpha】Scrum meeting 3 【Alpha】Scrum meeting 4 【Alpha】Scrum meeting 5 【Alpha】Scrum meeting 6 【Alpha】Scrum meeting 7

目录 前言 任务分配 Bug 贡献时间 燃尽图 站立会议照片 困难 前言 第2次会议由PM王志成召开 时间：6月27日14:30-15:40 地点：西苑餐厅 内容：1.制定计划，分配任务；   2.讨论解决服务器搭建问题；   3.讨论关于软著的相关内容；   4.汇总测试中遇到的问题。 任务分配 姓名 今天任务 明天任务 王志成 录制视频演示软件测试过程，搭建服务器 压力测试 滕江南 测试用例，绘制燃尽图 压力测试 孔维滢 测试功能 压力测试 常惠琢 测试用例 压力测试 Github链接： https://github.com/nzyc202007/loan Github上传演示视频截图： Bug 以上是在【Alpha】Scrum Meeting 7中出现的问题，经过重新导入数据库，清空数据后，修复成功。 大家可通过链接注册登录，进行验证！ 用户登录链接： http://121.199.68.210:8080/zxdk/ 管理员登录链接： http://121.199.68.210:8080/zxdk/admin/index.jsp 管理员登录： 学校账号：admin 密码：admin 银行账号：yinhang 密码：yinhang 贡献时间 姓名 贡献时间 王志成 4.5h 滕江南 5h 孔维滢 4.3h 常惠琢 4.5h 燃尽图 站立会议照片 困难 1.数据测试还未达到要求

经历了几个从商业角度来看或成功或失败的项目，都会发现代码、设计都会慢慢地、在不经意间腐化。而且有一个项目开始的时候，架构是经过精心设计的，也有较为严格的代码规范，并且通过静态代码检查来尽量保证代码的质量，连code review都有一个可供参考的checklist。但半年一年之后，还是会发现，很多代码都已经臃肿走样，到处都是复制粘贴，动辄好几千行代码的模块，能 work、但不 right的代码。 getting it work is easy getting it right is hard 不禁想问问代码和设计是如何一步步腐化的？ 本文地址： https://www.cnblogs.com/xybaby/p/13173047.html 代码如何开始腐烂 其实大家都听说过 clean code，但不一定真正意识到其重要性，且知道并不等同于做到，而时间更是一把杀猪刀，让程序员秃了，让代码烂了。 一个新项目开始的时候，大家都是满怀壮志，期待灵活可复用的架构，期待成功的产品。与此同时，敏捷开发告诉我们不要过度设计，当然，本身也是很难预料到以后需求变化的方向，于是应该等到第一次变化的时候才去考虑如何重构以应对这一类型的变化。但问题很可能就会出现在这里。 也就是说，也许哪一天，当我们需要加一个新功能的时候，会发现原来的设计和代码不是很方便增加这个新功能。当然，我们不应该过多苛责之前的设计

当你只有一把锤子，那么你看所有的一切都是钉子。 史蒂芬.柯唯 在《高效能人士的七个习惯》里举过一个例子，他拿出下面一张卡片。 如果你是一位男士，你可能看到下面的图片是一个漂亮的大美女，卷发，带着黑色的项链，露出长长的脖子一直向下，穿着一件时髦漂亮的羽毛上衣。 但是我告诉你他是一个伤心的老太太，一点都不好看，你是不是觉得不可思议？ 那么请仔细看下面的图，如果你刚开始认为是个老太太，那么请找出美女的视角，如果你刚开始认为是美女，就请找出伤心的老太太的视角。 如果你没有找出来，我告诉你一个技巧，首先如果你看到的是美女的耳朵，就换成是老太太的眼睛，如果你看到是美女的下巴，就换成是老太太的大鼻子，美女的项链换成老太太的嘴巴，美女的白白的脖子请换成老太太的下巴。（如果你还没看出来, 请使劲多看几遍 ) 当然，我这里并不是要和你完捉迷藏，而是要说我们经常用自己的第一印象或者自己熟悉的方式来理解一个事情，用我们已熟悉的方法往所有的新问题上用。而没有深入的想有没有更好的方法。 如果我们有一把锤子，然后去找钉子，那么就是发挥特长，但是我们很多人的问题就是只有一把锤子，那么觉得这个世界全都是钉子。 当一个家长，把孩子打一顿，就完成了作业，这个就是他的锤子，很可能以后孩子所有的问题都变成了钉子。 当一个老师，用一个方法教成功一个学生的时候，这就是他的锤子，就可能一直用这个方法对所有的学生

作者：你听___ lv-4 出处：https://juejin.im/post/6844903760444014600#heading-0 1. what—什么是CR codereview（CR）一直以来在软件行业被视为提升代码质量的一种有效的方式，也被视为一种工程师文化的代表。关于什么是CR，在goole出具体的定义如下： 代码评审是指在 软件开发过程中 ，对源代码的系统性。通常的目的是查找 系统缺陷 ，保证软件总体质量和提高开发者自身水平。Code Review是 轻量级代码 评审，相对于正式代码评审，轻量级代码评审所需要的各种成本要明显低的多， 如果流程正确，它可以起到更加积极的效果 。正因如此，轻量级代码评审经常性得被引入到软件开发过程中。 从上面的解释中可以基本上可以看出CR的几个核心关键点： CR应该是 处在研发流程中 ，并不是项目结束之后，也就是说CR应该是存在于研发流程之中的事情，只有在过程中进行才能确保最终的交付结果，而不是最后的亡羊补牢和自怨自艾； CR的目的是 提前发现系统缺陷 ，进而提前解决，事实上，CR的目的不仅仅是发现问题，而是开发者在一起进行沟通和协同的过程，主要的目的还是为系统质量负责的一种手段，但收益却会远远超过此点； CR是 轻量级代码 的check和沟通，所以说要想完成一次质量很好的CR，前提条件是足够轻量，这个轻量体现在两个方面

作者介绍 姜岩， 哈尔滨银行数据中心总经理。自1993年至今，始终在银行业从事应用系统开发、运维管理、架构管理以及新业务科技实现的设计等相关工作，历经银行系统从单机到联网、从独立到集中、从网点渠道为主到线上渠道为主的发展过程，以及多次核心系统更新换代的亲身参与，对金融科技与业务的配套发展有着深刻的思考。 一、数字金融业务与技术发展的回顾 金融业务与服务，利用信息化技术持续改进与发展，已有近30年的历程，这一发展过程的各个阶段，既改善了金融服务，促进实体经济发展的收益性结果，也有因各类未知问题造成的事件与影响等经验教训，因此，金融业务发展与信息技术的改进优化，是一个互相促进、迭代发展的过程。 根据信息化技术在金融业务发展过程中所起到的作用，以及金融业务服务的阶段性特征，大体可分为以下三个阶段，各阶段之间，既有继承衔接的关系，也有并行发展的关系： 1、会计电算化阶段 金融行业在二十多年以前，开始以计算机技术，逐步替代传统金融业务中的标准人工处理流程，主要包括会计核算、清结算等业务流程，金融业务的服务，仍然是以物理网点为主，但随着计算机网络技术的发展，逐步开始提供跨网点、跨地域、跨银行的便捷金融服务，通过将金融业务人工流程计算机化，逐步提升了业务处理效率，降低了人为操作风险，这一时期技术对于业务发展的关键作用与自身问题如下： 1）在会计核算流程逐渐复杂化的前提下

“攻城狮”之痛 痛一：最“可爱”的产品经理，这些人一天到晚提需求，而且毫无愧意改来改去。 每一个需求背后都是一大串的代码，每一次需求的变更，意味着相对应的每一个环节都要变更，而这些，都是“攻城狮”一个一个代码敲上去的。所谓杀掉一个“攻城狮”，不用枪、刀、剑、斧，多提需求以及需求变更就够，大概就是这样子的吧。 产品经理们，摸过你们长在左心房的良心吗？而且，说好的下午茶、大餐呢？ 痛二：最“要命”的老板，这些人老是有这周想到下周就要的系统。 996已经司空见惯，跟谁学更是提倡“996变为007”，鼓励员工尽量住在公司，所谓“不畏加班不念下班”，虽然不确定真假，但这个应该是每一个老板的内心想法。项目工作量需要30人/天，老板要求10人/天，这就是现实！ 老板们，你有考虑过我们“攻城狮”所剩无几的头发兄弟的感受吗？你有想过我们“攻城狮”也想有时间去大学城找女朋友吗？ 痛三：最费头发的事儿——修Bug，这些“兄弟”最讨人烦，但无奈它天天光顾。 在公司/机构里，老师绝对是最受宠的那类人，天天都有人围着。 我们这些“攻城狮”则天天围着Bug，当真是一个Bug一时爽，一打Bug头发光。如果是自己写的代码倒还好，最坑的是公司/机构里有N多不知道哪儿来的“系统”，甚至还没有说明文档。 痛四：最憋屈的事儿——修复“罢工”系统，这些家伙不来则已，一来惊天动地。 每年招生高峰期，大大小小的活动肯定是少不了

项目 内容 课程班级博客链接 https://edu.cnblogs.com/campus/xbsf/nwnu2020SE 这个作业要求链接 https://www.cnblogs.com/nwnu-daizh/p/13089324.html 团队名称 3+1>4 团队成员分工描述 王嫄：PM 牛莉梅：文档撰写 祁甜：系统开发 王爽：测试 团队的课程学习目标 1、软件编码Alpha阶段博客编写 2、项目编码测试 3、培养合作意识，提升软件开发效率 这个作业在哪些方面帮助团队实现学习目标 1、了解了Alpha阶段的具体内容； 2、对项目进行了编码实现 团队博客链接 https://www.cnblogs.com/team12138/ 团队项目Github仓库地址链接 https://github.com/book-team/team-book 一、团队软件项目编码准备 1.软件开发环境配置说明   "西师爱阅"微信小程序使用"微信开发者工具"进行编码，使用Mysql创建数据库。微信开发者工具是微信官方提供的针对微信小程序的开发工具，集中了开发，调试，预览，上传等功能，所以我们选择该软件来编码。这里，我们下载的是Windows稳定版，各个版本之间是兼容的。如需安装，去官网下载适合自己电脑的版本安装即可，具体安装配置可参照 这篇博客 ，微信开发者工具配置好的截图如下： 2

摘要： 企业在做敏捷转型中，需求无法按时交付的困扰你是否也遇到过呢？ 背景 在之前组织的一次敏捷线下活动中，有家企业问道：“我们公司刚做敏捷转型不久，遇到一个比较头疼的问题——团队每天都很忙，从转型到现在已经两个多月了，基本没有一个迭代能做完全部任务，问题出在哪？”该问题一提出后，引发了激烈讨论： “我们公司也是，总有那么几个人完不成手头任务，每次拖后腿让客户不满意”； “最近我们项目用了个新框架，很多人他没用过啊，不知道从哪下手，项目评审的时候一片惨淡”。 其实上述几种情况归根到底都属于需求无法按时交付，类似这样的困扰你是否也遇到过呢？ 问题分析 在交流中，笔者了解到每家公司的情况： 背景中第一家企业在第一个迭代认领了15个故事，团队很容易就完成了；老板觉得以团队的能力可以做到每个迭代完成30个故事，于是后续每个迭代都希望团队认领30个故事，团队认领30个任务后，累死累活只能完成20左右的故事； 第二家企业研发团队8人，每个迭代总有两个成员工作完不成：团队每天早会正常开，但是总感觉那两个成员整个迭代都在做那一两个故事，做的功能也没啥进展，有时候还做不完； 第三家企业使用了一个新框架，近两个迭代团队按以往的速率进行任务认领，结果由于团队对框架不熟，每个迭代只完成了冲刺待办列表中一半的故事。 笔者结合交流结果及以往经验，对需求延期交付的原因进行了如下分析：