软件开发 – 第26页小小书 XXshu

技术交流员：为什么我们很少在野外找到它们

技术交流者是一个难以捉摸的物种。他们依靠复杂且无法使用的技术为生，并捕食毫无意义的文字，但没有人真正了解这些生物的行为。您可能知道他们是技术作家，信息开发人员，知识工程师，莎士比亚，也是我个人最喜欢的：“写作的那个人”。训练有素的眼睛可能很难区分他们，但是如果您想找一个“那个写作的人”，您将找不到技术交流员。如果您正在寻找技术作家，您将找到一个“写作的人”。仅仅因为它有条纹，并不意味着它是斑马。当然，技术交流者需要出色的写作技巧，但这远不能定义角色。业界中所有公认的术语都太狭窄，无法定义真正使技术传播者成为现实的东西。写作是容易的部分！除了样式，一致性和语言能力外，任何人都可以编写解释某些内容的过程。为了组建Feedzai的Tech Comm团队，我们面临着写作方面的挑战，许多具有写作或语言学经验的应聘者会在没有格式或标点符号的情况下传递文字，这种文字通常太复杂且难以阅读。看看我在那里做什么？剧透警报：不聘用这些候选人。 10个关键特征有10个关键特征可以帮助我们区分技术交流者和撰写者。技术交流员：了解核心信息并考虑读者需要学习的内容，并专注于解释真正相关的内容。…

学徒制：久经考验的模式改变了技术的面貌

创建人：Elizabeth Scutchfield 科技行业以开拓创新，发现新机遇和突破界限而闻名。现在，具有远见的技术公司正在利用一个古老的培训方法：学徒制，这是一个新的机会。这种新的学徒模式旨在通过将在职培训与相关的基于技能的学习相结合，来满足科技行业的招聘需求。去年，这种模式在公共部门和私营部门都是头等大事。像LinkedIn，Intuit，Adobe和GE这样的公司正在使用技术学徒制来建立更具凝聚力的团队并提高员工忠诚度。 2017年6月15日发布的行政命令也证明了学徒制是白宫的优先事项。在本地层面上，我们看到了与Apprenti等组织合作为学徒及其加入的公司所取得的成果。为了庆祝国家学徒周，我们想分享其中一些故事。大卫·林（David Lim）和亚马逊（Amazon）陆军退伍军人和代码研究员毕业的大卫·林（David Lim）直接知道学徒制的好处。离开军队后，他在执法部门又花了9年的时间，想要一份不会涉及个人风险的新职业。软件开发符合要求。他来到Code Fellows来加快他的职业发展步伐，并进入高科技行业，寻找可以提供指导和专业技能建设的机会。…

回顾“软件开发的本质”

Ron Jeffries的这本书快速，轻松且有趣。因此，如果您希望在这个假期里（例如，在旅途中）获得一些有关软件开发的轻松阅读，请选择此处。现在问“为什么有趣？”这个问题与软件工程书籍不同，它不是一本关于软件构建过程的书籍。绝对不是编程。这与最佳实践无关。相反，这本书提倡建立软件的原则。尽管事后看来这个原则似乎很明显，但我们经常不能坚持下去。该原则始终以价值为导向。软件（按时交付）交付给用户的价值应指导软件的开发。除了仅仅阐明以价值为驱动力的重要性外，这本书还提供了令人信服的论点，说明如何通过利用现有的方法和实践来实现价值驱动，例如重构，用户案例，（A）TDD，Scrum，敏捷方法。尽管该书为开发团队规定了更多的自治权和权力，但它也描述了管理在诸如设置方面的作用。此外，这本书还介绍了逐个特征开发这一术语，这正是它的含义，并且在执行时似乎很明显。如果您对软件开发或开发感兴趣，我强烈推荐这本书。为了唤起您的食欲，以下是我的书copy中的一些要点：专注于尽早并经常交付价值。要记住的主要事情是，我们逐个功能地交付软件可获得最佳结果。按功能进行组织。…

每个测试人员应该阅读的十大书籍

在最近清理我的书架时，我清除了Cem Kaner，Hung Q Nguyen和Jack Falk编写的旧版《测试计算机软件》。早在2003年，我的第一位计算机科学老师就把这本书送给了我，这是一个出色的项目的礼物。这带回了一些回忆，让我开始思考，即使在这个现代博客和youtube时代，有多少书会影响我们的生活。在媒体的某个地方，有适用于所有内容的课程，适用于所有内容的教程和博客。但是，与真正的传奇专家从精心编写的书籍中可以获得的核心信息下载相比，没有什么比这更重要的了。但是，什么是最好的书呢？ Cem Kaner撰写的软件测试基础：-这是我关于测试的第一本书，对此我有些偏见。因此，它是第一位的。本书是一本基础扎实的书，我会推荐给每位新手测试人员。这将帮助您了解简单但必要的测试支柱，例如测试用例和测试用例管理。但是，我最喜欢的部分是关于软件测试必要性的章节。必读！！敏捷评估和规划，作者：Mike…

增量标准：团队升级的工具

您多久听到一次这样的消息，“当冲刺开始时，我们的用户故事从未被完全烤熟。如果可以，那就太好了，或者，“我们从不花时间进行真正的连续测试。” 不断提高的卓越标准是团队将绝妙的目标变成离散的，可行的目标的一种方法，这些目标可以使他们的理想实践变为现实。在本文的其余部分，我们将为团队描述一种简单的协作方式，以共同定义其理想的团队实践，并计划使这些实践成为现实。它针对有兴趣为团队促进此过程的人员。读者会知道如何使用此过程来帮助您的团队共同定义成为金牌或什至更好的含义！ —标准团队，以及如何使用此过程来了解团队在其工作环境中的价值观。我在我领导的团队和其他团队中作为宾客主持人都使用过它，并且两者都发现它是宝贵的，值得的时间投入。示例均来自技术团队，但原理和过程适用于各个学科。卓越的提高标准是嵌套的，命名的目的和过程目标集。重要的是，它们是：命名：每个集合都有一个清楚地标识质量级别的名称。稍后，我们将使用古铜，银，金，铂和钻石的标准名称。嵌套：要达到银级标准，团队必须达到铜级标准中的所有目标，以此类推。可行的：每个标准中的每个目标都完全在团队的影响力范围内。…

如何克服冒名顶替综合症

在公司里开始新的职位时，您曾经有过那种紧张的感觉吗？当您环顾与之合作的团队时，会产生信心危机，并且想知道您是如何开始使团队变得疲惫不堪的？别担心，这是我们许多人在某一时刻或另一时刻都面临的感觉。这被称为冒名顶替综合症，《国际行为科学杂志》发表的一篇文章说，有70％的人在生活中的某个时刻已经或将要经历这种感觉。实际上，发现冒名顶替综合症在性别方面并没有歧视，并且会影响男人和女人。这意味着，您或团队中的某人很可能现在正为此而挣扎，面临诸如“我刚刚很幸运”或“我是欺诈”之类的消极想法。可悲的是，冒名顶替综合症不仅仅是仅限于工作场所，并且可以扩展到个人关系和社交聚会。不过不要担心。有可能摆脱任何冒名顶替的感觉，并完全认可您带来的价值。以下是克服冒名顶替综合症的几种方法：查明是什么使您有这种感觉：花些时间反思和认同，在那些高压力的时刻，触发那些不足的感觉将使您有机会向前冲，直截了当地解决问题。在这里，我们可以合理化我们所坚持的任何不切实际的期望。寻找指导者：一旦您解决了问题，找到一个在您觉得自己的弱点成功的指导者将帮助您获得进一步的发展动力。与该同事或朋友建立融洽的关系带来了开放的交流，这使您有机会讨论您的压力和缺点，并制定改善策略。在寻找和模仿我的导师并与之合作之后，我个人看到了职业生涯的进步。记住要克服的挑战要达到这一点：很可能您面临着众多的障碍和考验，要想走到这一步要走很长的路要走，但是要站在这里。坚持不懈地赢得胜利的是你。拥有并庆祝自己的成就-意识到内心的批评者开始出现的那一刻，您将面临过去成功克服和克服的新挑战。…

完成工作的启动技术：客户的预先客户。

Dark正在改变开发人员编写后端和操作基础结构的方式。有兴趣尝试吗？在这里注册，然后在“其他内容？”部分中告诉我更多有关您想要做什么的信息。每次注册都直接进入我的收件箱（您也可以给我发送电子邮件 ellen@darklang.com ）。很少有人写关于他们自己的创业公司的早期故事。这是有充分的理由的：您不顾一切地寻找客户，而不是写下自己在做什么¹。关于“早期创业公司”的内容集中在以下几个方面：您投入的时间（嘿，要求每周80个小时以上）。人们失败的地方（这是这些博客文章和此列表）。成功人士的特定技术。不利的一面是，这些想法通常听起来像是“快速修复”，而不是您早日真正要做的所有事情。尽快获取客户如果有快速解决方案，它会尽快吸引客户。…

第六期：十个绿色瓶子

你好，我本周想到瓶颈。瓶颈是软件交付过程中任何可能卡住的点。想象一下，一个由五个开发人员组成的团队每周都会产生五个新功能。每种功能在发布之前都必须经过产品所有者的批准，但是他们经常忙于开会，因此每周只能查看一次。那里我们有一个瓶颈-五到一个瓶颈。我的大部分工作都涉及解决瓶颈问题，并且有几种解决问题的方法。选项A-减速与其让开发人员每周生产五个功能，不如让他们只生产一个功能。这样，产品所有者就不会感到不知所措，积压的订单也将消失。从表面上看，这听起来很疯狂，因为这意味着开发人员的生产力明显下降了80％。但是，当然，如果某个功能没有发布，那么它可能根本就不会开发出来，那么它真的下降了80％吗？这个5对1的瓶颈是一个极端的例子，但是通常会减慢您的交付渠道以使其达到最慢的速度，实际上可以使您的交付速度大大提高。想象一下一家直通车餐厅。最终，拿到订单的家伙比最后交出一包汉堡的家伙没有什么意义，您只是阻塞了系统。选项B-保持瓶颈繁忙如果我们的产品所有者很少有，那么对于他们来说他们会发现自己有足够的空闲时间，但是对于我们的开发人员来说，还没有为他们准备的一切，那将是绝对的悲剧。…

为什么计划持续两个小时以上的任务是一个坏主意？

每个软件开发人员面临的最大问题是生产力。您上次尝试从头开始进行某些项目是什么时候，并且经过一段时间的尝试，您已经放弃了？我知道我已经做过很多次了。因此，我试图研究造成这种情况的主要原因。我得到的答案是我组织不够。看看何时您不事先计划事情，您就不会有任何动机或精力去做事情。因此，最重要的是提前计划，至少提前一周。但这并不是我在这里所说的新内容。我们拥有解决这些问题的敏捷方法。我们有看板和Scrum。 Trello和KanbanFlow是您可以用来实践这些技术的两个很棒的站点。但是我要走的更远。在Scrum中，有一个称为“史诗”的术语，这意味着任务如此模糊且漫长，以至于无法像现在这样在计划委员会中进行，但需要将其分解为较小的任务。我认为，只要开发人员认为该任务将花费超过2个小时的时间，该任务就是史诗级的，应将其拆分为较小的任务。为什么？让我们回到这篇文章的开头。生产率。当我们有如此任务以至于所有事情都解释得很清楚并且变化很小时，只需要一个小时就可以完成它，我们确切地知道该做什么，我们已经准备好了，我们的大脑也知道它需要执行的确切动作，它不会试图让我们拖延。…