简化你的敏捷工作流程，提高你的工作效率。

生产力应用确实可以让你的工作流程变得更加轻松。在本文中，我将分享一些我用来简化工作流程、提高整体生产力的开源应用。本文中所有的生产力应用都是免费的 Linux 生产力应用。

Tomboy/Gnote

Tomboy 是一款可以在 Linux、Windows 和 macOS 上使用的简单记事本应用。它是 GNU LGPLv2 下许可的开源软件。

Tomboy 使用起来非常简单。你写下一张纸条，选择是否将它贴在桌面上，完成后就可以删除它。

它（以及它的克隆版 Gnote）是一个很好的快速记笔记的小程序。很多时候，当我在做某件事情的时候，会有一些想法或思路想要回忆。Tomboy 可以让我快速创建一个笔记，在我忘记之前把我的想法记下来。然后我就可以把这些想法转移到一个更长久的地方。

Joplin

Joplin 是一个开源的记事和待办事项应用。它是跨平台的，可以在 Linux、Windows、macOS、iOS 和 Android 上使用，并且采用 MIT 许可开源。

它可以使用 Dropbox、OneDrive、Nextcloud 等云同步服务进行同步。它很容易安装，可能就在你的 Linux 仓库里。当你在桌面上安装它时，它一个应用中实际包含了两个：你会得到一个标准的图形用户界面 （GUI），或者打开一个终端，在那里使用 Joplin。

桌面版有一个非常漂亮的界面。笔记被组织在笔记本中，这基本上使它们成为你的手册页。而且因为笔记是 Markdown 格式的，所以它们会被渲染，你可以实时编辑它们。我喜欢使用 Markdown，因为它让我写笔记的速度很快。你也可以导出或导入 Joplin 笔记。

Evolution

Evolution 是一款开源的个人信息管理应用，它与 Outlook 非常相似，但我认为更适合我使用。它具有电子邮件、工作、笔记、链接、日历和地址簿功能。它是 LGPL 和其他许可证下的开源软件。

我在运行 Fedora 的台式电脑上使用它。它的效率很高，绝对能帮助我度过繁忙的一天。它让我能够使用 Linux 开展业务；我还能要求什么呢？

要在 Fedora 中使用它，打开一个终端并输入以下命令：

sudo dnf remove evolution
sudo dnf update
sudo dnf install evolution
sudo dnf install evolution-ews

我的常用工具

这些工具是我的主力军，我已经依赖了一段时间。使用它们超越了它们的基本功能，使我更有效率、更有效果、更有生产力。作为一名技术产品经理和敏捷专家，我很自豪，我仍然使用 Linux 和其他开源软件，即使我工作的公司不这样做。

本文原载于 Course Hero，经授权转载。

via: https://opensource.com/article/21/1/open-source-productivity-apps

作者：Taz Brown 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

持续集成和持续交付是由测试驱动的。以下是如何做到的。

“如果一切似乎都在控制之中，那只是你走的不够快而已。” —Mario Andretti

测试自动化是指在软件开发过程中尽可能早、尽可能快地持续关注检测缺陷、错误和 bug。这是通过使用那些追求质量为最高价值的工具完成的，它们旨在确保质量，而不仅仅是追求质量。

持续集成/持续交付（CI/CD）解决方案（也称为 DevOps 管道）最引人注目的功能之一是可以更频繁地进行测试，而又不会给开发人员或操作人员增加更多的手动工作。让我们谈谈为什么这很重要。

为什么要在 CI/CD 中实现自动化测试？

敏捷团队要更快的迭代，以更高的速度交付软件和客户满意度，而这些压力可能会危及质量。全球竞争制造了对缺陷的低容忍度，同时也增加了敏捷团队的压力，要求软件交付的迭代更快。减轻这种压力的行业解决方案是什么？是 DevOps。

DevOps 是一个大概念，有很多定义，但是对 DevOps 成功至关重要的一项技术是 CI/CD。通过软件开发流程设计一个连续的改进循环，可以为测试带来新的机会。

这对测试人员意味着什么？

对于测试人员，这通常意味着他们必须：

• 更早且更频繁地进行测试（使用自动化）
• 持续测试“真实世界”的工作流（自动和手动）

更具体地说，任何形式的测试，无论是由编写代码的开发人员运行还是由质量保证工程师团队设计，其作用都是利用 CI/CD 基础架构在快速推进的同时提高质量。

测试人员还需要做什么？

具体点说，测试人员负责：

• 测试新的和现有的软件应用
• 根据系统要求评估软件来验证和确认功能
• 利用自动化测试工具来开发和维护可重复使用的自动化测试
• 与 scrum 团队的所有成员合作，了解正在开发的功能以及实施的技术设计，以设计和开发准确、高质量的自动化测试
• 分析记录在案的用户需求，并针对中等到高度复杂的软件或 IT 系统制定或协助设计测试计划
• 开发自动化测试，并与功能团队一起审查和评估测试方案
• 与技术团队合作，确定在开发环境中自动化测试的正确方法
• 与团队合作，通过自动化测试来了解和解决软件问题，并回应有关修改或增强的建议
• 参与需求梳理、估算和其他敏捷 scrum 仪式
• 协助制定标准和流程，以支持测试活动和材料（例如脚本、配置、程序、工具、计划和结果）

测试是一项艰巨的工作，但这是有效构建软件的重要组成部分。

哪些持续测试很重要？

你可以使用多种测试。不同的类型并不是学科之间的牢固界限。相反，它们是表示如何测试的不同方式。比较测试类型不太重要，更重要的是对每一种测试类型都要有覆盖率。

• 功能测试： 确保软件具有其要求的功能
• 单元测试： 独立测试软件的较小单元/组件以检查其功能
• 负载测试： 测试软件在重负载或使用期间的性能
• 压力测试： 确定软件承受压力（最大负载）时的断点
• 集成测试： 测试组合或集成的一组组件的输出
• 回归测试： 当修改任意组件（无论多么小），测试整个应用的功能

总结

任何包含持续测试的软件开发过程都将朝着建立关键反馈环路的方向发展，以实现快速和构建有效的软件。最重要的是，该实践将质量内置到 CI/CD 管道中，并意味着了解在软件开发生命周期中提高速度同时减少风险和浪费之间的联系。

via: https://opensource.com/article/20/7/automation-testing-cicd

作者：Taz Brown 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

开源社区欢迎来自不同背景和技能的贡献者。

我是一名 IT 专业人士，拥有超过 15 年经验，担任过不同职位 —— 包括系统管理员、高级 Linux 管理员、DevOps 工程师、自动化顾问和高级 敏捷专家 scrum master 。我开始是在 Ubuntu 上学习 Linux，但是后来作为系统管理员转到 CentOS，然后我又转到 Fedora 作为个人使用。但是我对技术的喜爱要远比我使用第一个 Linux 发行版要早的多，而且是来自于一部电影。

我最喜欢的电影是《 黑客 Hackers 》。最精彩的一幕发生在电影的开头。电影一开始，一群特工冲进一所房子抓捕臭名昭著的黑客 Zero Cool。我们马上发现 Zero Cool 其实是 11 岁的 Dade Murphy，他在一天之内成功瘫痪了 1507 台计算机系统。他被指控犯罪，他的家人被处以重罚。而且，在他 18 岁之前，他都被禁止使用电脑或按键式电话。

劳伦斯·梅森 Laurence Mason 扮演的 Paul Cook，又名 Nikon 勋爵，是我最喜欢角色。其中一个主要原因是，我从没有看过一个黑客电影里面的人物长的像我，所以我被他的形象深深吸引了。他很神秘。这让我耳目一新，并且感到自豪，我对 IT 充满了热情，我也是一个和他很像的极客。

成为一个 Linux 贡献者

15 年前，我开始使用 Linux。当我成为一个 Linux 管理员的时候，Linux 就成了我的激情所在。我一直尝试找到某种方式能够为开源作出贡献，当时我还不知道该从哪开始。因为这个社区实在是太大了，我不知道自己能否真正成为一个有影响力的人，但当我发现一些人认可我的兴趣，还对我进行指导，我开始彻底打开心扉，问各种问题，并且从社区中学习。自从那以后，Fedora 社区一直是我做贡献的最主要社区。

我现在对于向开源做贡献还是有点稚嫩。当我意识到我可以用代码以外的方式来贡献时，我对开源的想法发生了改变。我更喜欢通过文档做一些贡献，因为我本质上不是一个软件开发人员，而且社区里面最迫切的需求正是文档。请记住：用户的技能和开发人员的技能同样重要。

我的硬件是什么？

硬件也很重要，而且现在几乎所有东西都可以运行 Linux。现在，我家里的配置包括：

• 联想 Thinksever TS140，64 GB 内存，4 x 1 TB SSD 和一个存储数据的 1 TB 机械硬盘
• 使用 RAID 5 配置的 164 TB Synology NAS
• 输入输出使用罗技 MX Master 和 MX Master 2S
• 一个定制的并且符合人体工学的 Kinesis Advantage 2 键盘
• 两个 38 寸 LG 超宽曲面显示器和一个 34 寸 LG 超宽显示器
• 一台配备 i7 六核十二线程 CPU 和 16.1 英寸 IPS 显示器的 System76 笔记本

我很喜欢 Fedora 处理外置设备的方式，比如说我的鼠标和键盘。一切都完美融合。即插即用工作正常，性能从来不受影响。

软件是什么？

使用开源软件对我的工作非常重要。我依赖于：

• Fedora 30 作为我日常使用的 Linux 发行版
• Wekan 作为我的项目的开源 看板 kanban
• Atom 作为我的文本编辑器
• Terminator 作为我日常使用的终端，因为它的网格布局以及丰富的键盘快捷键
• Neofetch 用来显示每次登录到终端时的系统信息

最后同样重要的是，我把 Powerline、Powerlevel9k 和 Vim-Powerline 搞到我的终端上来跟别人装酷。

Linux 让我们走到一起

美国是个大熔炉，我也是这么看待 Linux 和像 Fedora 项目这样的特定社区的。在每个 Linux 社区中，对于不同的贡献都有很大的空间。也有很多方式可以参与进来，而且对于新的想法，也总是有发挥的空间。通过分享我过去 15 年在开源方面的经验，我希望帮助更多在科技领域的少数族裔体会到来自开源社区对多样性和包容性的认同感。

编者注：这篇文章改编自“Taz Brown：你怎么搞 Fedora？”，并得到许可重新发布

via: https://opensource.com/article/20/7/linux-user-contributor

作者：Taz Brown 选题：lujun9972 译者：Yufei-Yan 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

两者之间的区别在于开发完毕之后发生的事情。

早期，软件开发并没有特定的管理流程。随后出现了 瀑布开发流程 Waterfall ，它提出软件开发活动可以用开发和构建应用所耗费的时间来定义。

那时候，由于在开发流程中没有审查环节和权衡考虑，常常需要花费很长的时间来开发、测试和部署软件。交付的软件也是带有缺陷和 Bug 的质量较差的软件，而且交付时间也不满足要求。那时候软件项目管理的重点是长期而拖沓的计划。

瀑布流程与 三重约束模型 triple constraint model 相关，三重约束模型也称为 项目管理三角形 project management triangle 。三角形的每一个边代表项目管理三要素的一个要素: 范围、时间和成本。正如 Angelo Baretta 写到，三重约束模型“认为成本是时间和范围的函数，这三个约束以一种确定的、可预测的方式相互作用。……如果我们想缩短时间表（时间），就必须增加成本。如果我们想增加范围，就必须增加成本或时间。”

从瀑布流程过渡到敏捷开发

瀑布流程来源于生产和工程领域，这些领域适合线性化的流程：正如房屋封顶之前需要先盖好支撑墙。相似地，软件开发问题被认为可以通过提前做好计划来解决。从头到尾，开发流程均由路线图清晰地定义，沿着路线图就可以得到最终交付的产品。

最终，瀑布模型被认为对软件开发是不利的而且违反人的直觉，因为通常直到开发流程的最后才能体现出项目的价值，这导致许多项目最终都以失败告终。而且，在项目结束前客户看不到任何可以工作的软件。

敏捷 Agile 采用了一种不同的方法，它抛弃了规划整个项目，承诺估计的时间点，简单的遵循计划。与瀑布流程相反，它假设和拥抱不确定性。它的理念是以响应变化代替讨论过去，它认为变更是客户需求的一部分。

敏捷价值观

敏捷由 敏捷宣言 Agile Manifesto 代言，敏捷宣言定义了 12 条原则（LCTT 译注：此处没有采用本文原本的简略句式，而是摘录了来自敏捷软件开发宣言官方的中文译本）：

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。
3. 经常交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 面对面沟通是传递信息的最佳的也是效率最高的方法。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷流程倡导可持续的开发，责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构，需求和设计出自自组织团队
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

敏捷的四个核心价值观是（LCTT 译注：此处译文同样来自敏捷软件开发宣言官方）：

• 个体和互动 高于流程和工具
• 工作的软件 高于详尽的文档
• 客户合作 高于合同谈判
• 响应变化 高于遵循计划

这与瀑布流程死板的计划风格相反。在敏捷流程中，客户是开发团队的一员，而不仅仅是在项目开始时参与项目需求的定义，在项目结束时验收最终的产品。客户帮忙团队完成验收标准，并在整个过程中保持投入。另外，敏捷需要整个组织的变化和持续的改进。开发团队和其他团队一起合作，包括项目管理团队和测试团队。做什么和计划什么时候做由指定的角色领导，并由整个团队同意。

敏捷软件开发

敏捷软件开发需要自适应的规划、演进式的开发和交付。许多软件开发方法、框架和实践遵从敏捷的理念，包括：

• Scrum
• 看板 Kanban （可视化工作流）
• 极限编程 Xtreme Programming （XP）
• 精益方法 Lean
• DevOps
• 特性驱动开发 Feature-Driven Development （FDD）
• 测试驱动开发 Test-Driven Development （TDD）
• 水晶方法 Crystal
• 动态系统开发方法 Dynamic Systems Development Method （DSDM）
• 自适应软件开发 Adaptive Software Development （ASD）

所有这些已经被单独用于或一起用于开发和部署软件。最常用的是 Scrum、看板（或 Scrumban）和 DevOps。

Scrum 是一个框架，采用该框架的团队通常由一个 Scrum 教练、产品经理和开发人员组成，该团队以跨职能、自主的工作方式运作，能够加快软件交付速度从而给客户带来巨大的商业价值。其关注点是较小增量的快速迭代。

看板 是一个敏捷框架，有时也叫工作流管理系统，它能帮助团队可视化他们的工作从而最大化效率（因而变得敏捷）。看板通常由数字或物理展示板来呈现。团队的工作在展示板上随着进度而移动，例如从未启动到进行中，一直到测试中、已完成。看板使得每个团队成员可以随时查看到所有工作的状态。

DevOps 价值观

DevOps 是一种文化，是一种思维状态，是一种软件开发的方式或者基础设施的方式，也是一种构建和部署软件和应用的方式。它假设开发和运维之间没有隔阂，他们一起合作，没有矛盾。

DevOps 基于其它两个领域的实践: 精益和敏捷。DevOps 不是一个公司内的岗位或角色；它是一个组织或团队对持续交付、持续部署和持续集成的坚持不懈的追求。Gene Kim（Phoenix 项目和 Unicorn 项目的作者）认为，有三种方式定义 DevOps 的理念：

• 第一种: 流程原则
• 第二种: 反馈原则
• 第三种: 持续学习原则

DevOps 软件开发

DevOps 不会凭空产生；它是一种灵活的实践，它的本质是一种关于软件开发和 IT 或基础设施实施的共享文化和思维方式。

当你想到自动化、云、微服务时，你会想到 DevOps。在一次访谈中，《加速构建和扩张高性能技术组织》的作者 Nicol Forsgren、Jez Humble 和 Gene Kim 这样解释到：

• 软件交付能力很重要，它极大地影响到组织的成果，例如利润、市场份额、质量、客户满意度以及组织战略目标的达成。
• 优秀的团队能达到很高的交付量、稳定性和质量；他们并没有为了获得这些属性而进行取舍。
• 你可以通过实施精益、敏捷和 DevOps 中的实践来提升能力。
• 实施这些实践和能力也会影响你的组织文化，并且会进一步对你的软件交付能力和组织能力产生有益的提升。
• 懂得怎样改进能力需要做很多工作。

DevOps 和敏捷的对比

DevOps 和敏捷有相似性，但是它们不完全相同，一些人认为 DevOps 比敏捷更好。为了避免造成混淆，深入地了解它们是很重要的。

相似之处

• 毫无疑问，两者都是软件开发技术。
• 敏捷已经存在了 20 多年，DevOps 是最近才出现的。
• 两者都追求软件的快速开发，它们的理念都基于怎样在不伤害客户或运维利益的情况下快速开发出软件。

不同之处

• 两者的差异在于软件开发完成后发生的事情。

  • 在 DevOps 和敏捷中，都有软件开发、测试和部署的阶段。然而，敏捷流程在这三个阶段之后会终止。相反，DevOps 包括后续持续的运维。因此，DevOps 会持续的监控软件运行情况和进行持续的开发。
• 敏捷中，不同的人负责软件的开发、测试和部署。而 DevOps 工程角色负责所有活动，开发即运维，运维即开发。
• DevOps 更关注于削减成本，而敏捷则是精益和减少浪费的代名词，侧重于像敏捷项目会计和最小可行产品的概念。
• 敏捷专注于并体现了经验主义（适应、透明和检查），而不是预测性措施。

总结

敏捷和 DevOps 是截然不同的，尽管它们的相似之处使人们认为它们是相同的。这对敏捷和 DevOps 都是一种伤害。

根据我作为一名敏捷专家的经验，我发现对于组织和团队从高层次上了解敏捷和 DevOps 是什么，以及它们如何帮助团队更高效地工作，更快地交付高质量产品从而提高客户满意度非常有价值。

敏捷和 DevOps 绝不是对抗性的（或至少没有这个意图）。在敏捷革命中，它们更像是盟友而不是敌人。敏捷和 DevOps 可以相互协作一致对外，因此可以在相同的场合共存。

via: https://opensource.com/article/20/2/devops-vs-agile

作者：Taz Brown 选题：lujun9972 译者：messon007 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出