看板"/>
海沟看板
介绍
在组成软件项目团队的一部分后，该团队于2013年在BBC Worldwide开展了一个重要项目，我觉得发布一些关于我看板的经验以及如何帮助向客户交付高质量软件的说明将非常有用。 。
这是我准备的一些注释，目的是在BBC之外的后续项目中向工程界发表看板励志演讲。
海沟看板
看板是用于管理软件开发过程的技术。 它并没有告诉我们如何开发软件，而是提供了可以帮助我们执行（作为软件开发团队）我们认为是为客户开发可接受的优质软件的正确公式的技术。
例如，我们可能确定适当的软件工程过程需要以下各项：
- 充分理解并达成共识的要求将成为继续发展的基础。
- 开发同情不断发展的，易于理解的体系结构，该体系结构已发布，供整个团队使用。
- 我们练习JIT开发/工程-仅在需要时才做。
- 从单元测试到UAT，都建立并维护了一系列连贯，精心计划和精心设计的测试。
- 通过计划和协调可以积极地管理部署和发布管理。
- 可以对功能开发优先级进行调整，以便我们的敏捷团队可以快速响应关键利益相关者的要求。
- 至少对所有团队资产进行同行评审-代码，文档，用户手册和测试。
- 特征设计带有轻巧的描述和图片–重点和白板照片。 有时，可以证明正式的UML图是合理的，即用于状态或序列表示。
- 开发过程必须随着团队，产品和组织的期望而发展。
看板委员会
对于我参与的看板项目，我们的项目委员会通常包括五个关键领域：
- a）团队池（一组名称），
- b）一组代表我们的软件工程过程的相关列，
- c）一些流，
- d）在各个阶段的一组功能任务，以及
- e）重要事件日历。
a）团队池 ：团队池是名称/头像的集合，每个头像/头像是一个人的姓名和姓名，可用于执行任务–每个团队成员通常都有两个头像。 您一次可以执行至少一项任务，通常我们有能力并行执行另一项任务。
这些化身有助于我们了解团队合作的方式。 例如，如果尝试将化身分配给两个以上的任务，或者在完成任务之前频繁地在多个任务之间切换–董事会很可能会告诉我们一些我们需要理解和处理的内容。 也许我们团队中的资源不足，也许我们的知识集中在一个人身上（专有知识）。 无论如何，我们都需要记录下来，如果继续发生，请采取纠正措施来解决。
b）关联列组：这些列代表我们软件开发过程中的阶段或主要里程碑。 看板没有在下面列出这些列，但是建议了我们团队前进的一个很好的起点–该过程将随着团队的发展而发展。
例如，以下列用于我参与的BBC Worldwide项目：
清单 –具有广泛描述的功能集，以便可以理解（仅在此阶段进行三点估算）。 现在不需要进一步的详细信息–请记住，JIT。
识别 –我们已同意花一些时间在上面的功能。 我们需要了解功能部件是否受日期驱动，价值主张是什么，如何了解目标是否实现（一旦部署，我们就需要衡量成功），确定重要的依存关系（其他工作/职能等）。 指定哪个发行版本/日期等。
分析和设计 –在此阶段，我们将定义和完善验收标准–将这些标准写在卡片上。 现在，我们需要收集足够的需求，以便客户能够得到他们想要的（并希望能得到要求），并且我们了解如何构建它。 在准备质量检查时，我们将讨论并记录BDD方案。 分析和设计将经过同行评审，并由经过同意的最少数量的团队成员组成，这些成员具有与正在开发的功能有关的业务，技术和架构知识。 如有必要，该功能将分解为较小的单元/任务，每个单元/任务将持续（大约）0.5至5天。 线框（来自白板）将由客户绘制，描述和同意/批准。 该功能将根据体系结构进行审查。 将商定通用测试方法，同时考虑技术债务，即缺少现有代码包的测试。 同意功能部件的文档，设置，配置，用户手册条目等。同意承诺构建功能部件。
开发和质量保证 –必须编写每个新的类，服务，技术功能，并在需要时通过测试和可执行文档。 计划将创建并触发自动测试。 在将任务添加到“ develop”（Git分支）并将所有测试变为绿色之前，任务不会离开此列。
准备部署 –团队同意他们很高兴该功能可以发布到下一个版本，并向客户进行了演示。
看板的关键方面之一是进行中的工作（WIP）限制。 看板告诉我们最好不要承担太多，并且我们应该始终考虑完成事情而不是开始新的事情。 对于看板新手来说，这通常是一个很大的挑战，因为这意味着您不必去承担一项新任务，而必须去与已经在从事一项任务的人员结对。 我们都知道应该鼓励配对，这是实现配对的一种途径。 配对工作可能是编码，测试，文档，质量检查，基础架构等。每列都定义了WIP限制，根据团队规模，列和我们的工作经验，它们可能具有不同的值。 我们可以提高WIP限制，但要注意诸如阻塞之类的后果。 不用增加WIP限制，而要完成工作。
将一列分解为两部分通常很方便，一部分显示正在进行的任务，另一部分显示已完成但尚未准备好移入下一列的任务。
c）一些流：如果将一组相关任务组合在一起，有时会更容易跟踪和阅读演示板。 如果在分析和设计过程中将某个功能细分为例如8个子任务，则可以将这些子任务中的每个子任务分组为一个流，因此我们可以很容易地看到它们之间的相关性。
d）功能任务：看板委员会的重点是代表功能开发的任务。 目的是通过系统（从右侧）拉动任务，而不是从左侧将任务推入。
每个任务卡均包含进度历史记录。 卡的背面附有扩展名，设计图，JIRA号，依存关系，沿电路板移动的日期并不少见。
为了进一步帮助识别，使用颜色编码卡非常有用，这样可以轻松识别功能工作，文档，基础结构和错误。
保持看板工作板的最新状态非常重要，因此这通常是每天早晨进行的–站起来。 谁在运行站立式程序，谁就会仔细阅读董事会上的任务，并要求从事该任务的任何人进行更新。
e）项目日历：整个团队需要知道某人是否生病，正在休假或即将释放。
我们可以考虑存在两类错误，一类与当前正在采用的功能直接相关，另一类与历史功能开发有关。 与当前功能开发相关的错误应由从事其中的功能人员/团队来修复，直到并包括用户验收测试阶段（即后期部署）。
产品功能开发和历史错误修复之间的主要区别似乎是日常工作任务及其持续时间的稳定性–频繁更改优先级（一天内），并且通常开发/测试生命周期很短。 理想情况下，我们希望功能会在几天或几周内部分或全部进行开发。 上下文切换非常昂贵，因此我们希望工程师继续专注于他们正在使用的功能，而不是经常在功能和历史性错误之间切换。
因此，有两个项目板（或一个板上有两个流），一个代表核心功能开发，一个代表错误，可能就很合适。 在这两个方面不同的，需要分开的方面是工作单元，而不是团队成员。 因此，这是一种明智的方法，可根据工作量和优先级，使团队成员能够从事核心功能开发和历史错误。
现有技术债务
我们需要制定一种机制，以促进，鼓励和跟踪必要的重构，以使其得到良好的社会化，宣传和协调。 我们可以在主板上以流的形式对其进行跟踪，还是可以使用不同的看板来对其进行跟踪？
估算值
对于库存任务，将使用三点估计。 最好的情况，最坏的情况和预期的情况。 我们将使用它来帮助驱动哪些功能首先要针对给定版本需要开发的任意功能集。 在分析和设计阶段分解任务时，可以进一步完善此估计。 此信息将有助于输入代表功能依赖项和发布日期的发布跟踪板。
建筑
在任何功能或发行版的任何阶段，都应该有可能查看用于对齐功能开发的体系结构图。 有趣的方面是当前架构，理想的下一步架构和最终状态架构。 当然，随着产品及其环境的成熟，所有这三个因素都将随着时间的推移而变化。
与其他所有工作一样，将提出架构推测并将其作为总体审查过程的一部分提交给团队。 这些工作都没有被隐藏，它们都将作为任务显示在看板上。
演示版
应该从列退出标准中清楚地看出来，但是为客户或其代表运行演示是向发行版添加功能的前提。
GitFlow
软件在什么阶段进入“开发”， 发布和支持阶段 。 看板板必须与我们的发布流程保持一致，反之亦然。
经过一系列探索和探索性问题，团队开始尝试了解为建立软件产品的工程满意度而需要采取的措施。
团队认为什么是足够的产品工程？
团队共同确定了以下标准，这些标准对于制造质量足够的产品至关重要，因此我们很乐意将其提供给客户。
这些分组在某种程度上是人为的，但是让我们对我们共同积累了重要工程标准的区域的类型和范围有所了解。
看板委员会
实际的看板板将成为要素开发状态的主要副本。 我们需要在始终可访问的区域中构建和放置一个板，因为一些团队成员已经观察到将其放置在会议室中不是一个好主意。
将为最高级别的功能名称创建JIRA票证，但会在过程结束时（即当它们到达最后一列（即UAT）时）创建。 通常，我们不会为使JIRA与物理板保持最新而感到困惑–通信是关键，并且不能用问题跟踪系统代替，所以我们不要尝试。
在前面的示例中，我们现在将定义将要使用的列，并为每个列分配退出条件。
董事会管理
尽管作为一个软件开发团队，我们将共同负责该过程，但需要与使用该董事会的团队一起积极管理看板董事会。 有时，我们需要仲裁，鼓励，指导和决策才能运作。 如果没有敏捷教练，我们需要确定某人来担任教练或经理的角色。
致谢
我要非常感谢Sabina Kamber Salamanca和Kevin Ryan的所有知识共享和指导，这使我发现了一种更好的软件工程方法-鼓舞人心。
翻译自: .html
更多推荐
海沟看板
发布评论