我是如何意外地成为质量检查测试人员的

我已经决定开始写一些令我感兴趣的东西,而我不想仅仅局限于主题。 但是我认为重要的是要从我的职业生涯开始,并撰写有关使我进入技术领域的内容,因此,我将首先简要介绍如何进入软件质量保证体系。 我刚刚获得了学士学位,并且正在努力寻找工作(就像其他许多人一样)。 这个职位空缺,可以在一家初创公司担任测试分析师,尽管我没有任何经验,但这是我开始从事IT工作的机会。 自从第一次经历以来,我意识到的最常见的事情之一就是在大多数公司中如何看待质量保证角色。 开发人员与测试人员之间存在(仍然是)这种隐式隔离,并确保产品符合客户的需求。 同样,有一个常识,只有在您不知道/不喜欢编码时才去进行质量检查。 通常这是一个复杂的工作关系,需要专业人员的经验和成熟度。 我必须承认,很长一段时间以来,我一直只考虑从事质量检查,直到我能在业务或需求方面找到更好的职位为止,尽管我擅长,专注和注重细节,从而多次防止出现严重缺陷部署。 然后我们得到了敏捷/混乱的爆炸,突然之间每个人都应该可以跨职能使用。 团队成员之间不应有区别,每个人都是开发人员,因此改变了软件开发的长期文化。 我真的很喜欢由此带来的变化和挑战。 因此,我决定真正地将质量保证提升到一个新的水平,并成为一个可以想到不可思议的功能场景,可以帮助我的同事理解它们,可以测试它们以及承担许多其他职责的开发人员。 这是一个持续的过程,我打算在下一篇文章中进行介绍,如果您敢的话,请遵循。 谢谢!

传递不可能的[工作标题]

版本— 0.1 —亚里斯多德 第2章 什么是敏捷? 社交媒体的一件奇怪的事情是,有时谈论工作和与朋友谈论变得混在一起。 结果,我的一个对软件开发一无所知的朋友开始看到我对敏捷或SAFE或某人表现得不好而感到恼火。 有时他们向我提到他们不知道我在说什么。 其中一些朋友实际上已经开始阅读这本书。 正如一个人所说的那样:“我从头到尾都读了一遍。”我想知道是否有可能让这些人继续阅读本书的下一章。 本章解释了为什么参与项目(尤其是软件开发项目)的任何人都应该对“一些”和“全部”的这些观察结果感兴趣。 为了解释这一点,我们需要讨论敏捷宣言,以及它如何鼓励一种“某种”方法来思考软件开发,然后我们需要讨论最成功的敏捷方法:Scrum。 但是为了解释什么是敏捷宣言,我们需要解释什么是敏捷。 并且为了解释什么是敏捷? 好吧,要真正解释什么是敏捷,我们需要解释什么不是敏捷,以及我们如何习惯敏捷。 幸运的是,为使事情更好地运行而进行的所有备份都与本书的中心思想完全相关:当您使用“全部”时,事情会出错,应该使用“一些”,而当您使用“一些”而不是全部。 什么是瀑布? 直到21世纪末,人们普遍认为,管理软件开发的最佳方法是将其视为复杂的物理结构的工程,例如引擎或悬索桥。…

“敏捷不适合我们”……认真吗?

2010年3月3日,联邦调查局终止了其最大,最雄心勃勃的现代化项目,该项目原本可以防止另外9/11发生,但后来演变为有史以来最大的软件崩溃之一。 十多年来,FBI一直在尝试更新其计算机系统,并且看起来好像它们会失败。 再次。 现在是他的孩子。 在过去的几个月中,我对大型企业的员工进行了简短的采访,以了解他们在项目中使用敏捷的经验。 与那些经历较差的人一起,我深入讨论了更多内容。 他们在抱怨中分享了两个共同之处:“我们太公司化了,无法进行敏捷工作”或“我们拥有关键业务应用程序,敏捷对我们来说是有风险的”。 我知道他们都不是失败的原因,但他们的项目确实失败了,他们回到瀑布上,我不得不找出原因。 您的公司是世界上最具企业形象的企业吗? 首先,我必须说服这些人,他们声称自己是公司或业务关键项目并不是真正的原因。 让我们首先考虑公司结构。 美国银行,摩根大通和高盛只是企业界使用敏捷开发软件项目的一些例子。 他们写了一本关于公司的书,即使他们在数据中心担任电缆工作,他们的员工也穿着西装。 如果他们更喜欢敏捷并在敏捷中获得成功,那么成为具有复杂公司结构的大型企业就不会成为失败的原因。 您认为您的移动应用程序比FBI或国防部项目更重要吗? 让我们讨论关键业务应用程序。 您不能对业务关键型应用程序使用敏捷实践吗? 绝对可以。…

为什么敏捷对您不起作用。

敏捷是一个松散的概念,被公司称为“尝试并做这件事”,而无需花费时间学习和采用适用于其业务的独特方法。 发生这种情况时,如果不考虑敏捷的复杂性,以及他们的公司应如何采用对他们有用的敏捷方法,就会导致问题,团队的表现方式与原来一样,导致他们选择改变方法。 当一家公司的高层对敏捷进行研究时,发现诸如“ 98%的参与者声称其组织已从敏捷项目中取得成功”这样的统计数据,而敏捷方法可以将交付时间平均缩短37%,并且将团队生产力提高16% ,他们将迅速寻求将这些工作流程实施到他们的业务中。 可以说,敏捷是对您的开发团队影响最小的决定。 一个好的开发团队可能会努力获取他们将在前期工作的任何票证或产品中的尽可能多的细节,甚至可能将那些较大的票证分解为更小巧,更易于管理的工作。 从这种方法学转变为在混乱或看板之外工作的转变非常小,并且将是一种思维方式的改变,而不是其他任何事情。 不预先创建大型瀑布式项目,而是在每个地方都有宽松的开发计划而不是甘特图,这可能会受到开发人员的热烈欢迎。 更频繁地发布,风险更低,这将是对一支已经习惯于“每月加班之夜”的团队的热烈欢迎。 在业务本身内部,更改无法坚持下去。 公司可能会决定转向敏捷,因为它不会影响客户,因为项目仍会按时或按预算交付。 只是当客户开始要求大笔费用时,基本原理突然消失了,企业主呼吁开发团队寻找另一份完整报价,以解释要确定范围的项目中每个工作日的情况。 公司将不愿为项目预算采用更为敏捷的预算方式,这很可能会导致原本计划的事情无法交付,但这是因为他们从未问自己这是否是一件好事。 六分之一的IT项目超支了200%的成本和70%的时间,而当企业要求大瀑布任务的预算提前时,这些统计数据可能隐藏在“意外情况”中。 当给出基于时间的估计时,要求开发人员和管理人员都“再次加倍”不是什么内在的秘密,标签更改的估计将突出显示为多天以说明“测试”-当他们真正考虑范围时蠕变,需求变更,技术和系统尚未完全说明。 您的敏捷项目也应该正确地反映这一点,并且应该考虑或更好地考虑相同水平的意外事件, 然后重新投入到企业手中…

我用辛苦的方式学到的关于Scrum的5件事

我在2007年获得了Scrum Master认证,从那时起,我在许多团队中一直使用Scrum。 可以公平地说,这是一次教育之旅,在本文中,我想提及我在此过程中发现的一些事情。 1. Scrum对于小型团队确实是最有效的 我已经尝试过将Scrum与许多不同规模的团队一起使用。 有时他们甚至超过了规定的9人上限。 在这些情况下,它通常根本无法很好地工作。 当团队规模太大时,团队进行自我组织以最有效的方式完成工作变得非常困难。 也很难感到每个人都在一起,共同负责一个如此庞大的团队中的工作。 当然,有16个人可以在各个故事之间进行分配,并完成工作,但是这样做,他们会错失Scrum的许多优点,而且Scrum风险感觉就像是头顶开销。 例如,可以公平地说,大多数人比起只需要10%的Sprint计划会议或日常Scrum来更好地利用自己的时间。 我会说理想的团队规模可能是4-5。 这是一个足够大的团队,可以从成为团队的好处中受益,例如让具有不同技能和想法的人一起工作。 同样,如此规模的团队每个冲刺应该能够完成合理的工作量,而不会在例如某人度假或生病时停下来。 2.冲刺回顾确实是Scrum中最重要的会议 根据2015年的Scrum状态调查,每5个团队中就有近1个团队在每次冲刺结束时都没有进行回顾,我确实可以理解为什么。 回顾不佳可能会浪费时间,无聊甚至具有破坏性!…