建筑师需要务实的软件开发流程

自2006年以来，我一直是一名不间断的软件架构师。根据我的经验，我意识到在没有软件开发流程或过于简化的组织中，很难扮演架构师的角色。 如果开发的组织不够合理，项目经理就不会在时间表中找到实施架构建议的空间。 他们可能有时间和资源，但是由于他们对团队的生产力没有确切的了解，因此他们害怕接受新的非功能性需求或更改现有需求。 我注意到，在混乱的环境中，人们变得过于务实，不愿面对变化。

架构师期望组织采用更可预测和透明的软件过程。 这样，可以可视化建议的影响并在何时实施建议时进行协商。 他们对流程的期望最小，因为它具有经典的PDCA（计划，执行，检查和执行）循环的启发，因为它具有带反馈的循环，这是持续改进的基础。

下图描述了可以视为实用的软件过程。

迭代在时间上是重叠的，以便优化资源的使用并保证来自先前迭代的反馈。 每次迭代都在固定的时间段内执行。 这段时间取决于具体情况，并且随着组织的成熟度的提高而下降。 迭代由4个阶段（计划，执行，检查和执行）和根据计划可能发生的5个事件组成。 他们是：

• T1 ：表示迭代的开始，从计划开始。 计划的范围仅涵盖当前迭代的周期。 它不应与一般项目计划相混淆，后者是在初始迭代之一中生成的，用于计划所有其他迭代。 团队的所有成员都参与计划。
• T2 ：开始执行计划的迭代。 团队的所有成员必须在迭代范围内做点事情。 在当前迭代中，不应为将来的迭代计划任何事情。 人们可以产生各种输出，例如文档，代码，报告，会议记录等。
• T3 ：应检查所产生的一切。 应该检查文档，应该测试代码，应该测试用户界面以及与其他系统的集成，等等。所有发现的问题都必须注册以在适当的时候解决。
• T4 ：解决在检查阶段发现的所有问题，并发布所有计划的可交付成果。 每个人都应该提供一些东西。 如果时间不足以解决某些已发现的问题，则必须将它们包含在具有最高优先级的下一次迭代的计划中。 在此阶段应生成统计信息，以便将计划与执行进行比较。 利用先前迭代的经验，下一次迭代的计划也将从这一点开始。
• T5 ：释放所有内容后，当前迭代完成。 下一次迭代的T2立即开始，因为大多数资源已经可用。

T1到T5在固定的时间段内重复几次，直到项目结束。 该建议与过程无关，因此无论我们声称拥有哪种软件过程或我们可以想到的任何其他现代过程，都可以实施。

除此过程外，还有一些良好做法：

1. 考虑所有描述系统如何实现用例的业务需求的内容。 它也可以是功能性和非功能性需求，用户案例，场景等； 但是只能使用一种人工制品来描述业务需求。
2. 以使文本可以重复使用的方式编写用例：a）帮助商人可视化其需求的工作方式； b）指导测试人员进行探索性测试； c）帮助支持团队准备用户手册。
3. 在用例中避免使用技术术语。 如果确实需要，可以在其他人工制品中记录技术细节，例如用例实现。
4. 如果需要，仅使用UML模型创建用例实现。 将用例实现表示为文档意味着大量开销。 可以在UML元素的注释区域中添加任何必要的文本信息。
5. 根据实现用例的努力来确定用例的大小。 例如：我们可以确定用例的最大大小为1周。 如果估算值高于该估算值，则必须将用例分为两部分。 如果估算值远低于此估算值，则必须将用例与另一个紧密相关的用例合并。 通过简单地计算用例的数量，我们立即知道执行项目所需的工作量和资源。 此固定数字是将计划与执行进行比较的参数。 通过在每次迭代之后执行此比较，我们逐渐知道我们的估计变得越来越精确。
6. 使用Wiki记录用例和其他必需的文档，例如测试用例，发行说明等。为每个用例创建一个Wiki页面，并使用标记来指示仍有待发布的内容。 Wiki的优点是：a）用例在所有利益相关者被收集时立即可用； b）利益相关者可以通过跟踪页面中的更新来跟踪用例的演变； c）可能知道每个为用例做出贡献的人，以及他们所做的确切工作； d）可以在用例中添加注释，从而保留围绕它的所有讨论。
7. 如果组织具有业务流程，这也是架构师也喜欢的另一件事，则在业务流程的活动中放置引用，以指出实现它们的用例。 参考是指向在Wiki上发布用例的页面的链接。
8. 使用问题跟踪系统（例如Jira）跟踪用例。 每个用例必须具有一个相应的Jira票证，并且用例的计划，执行，检查和交付的每个细节都必须在该票证中进行注册。 将Jira票证与用例链接在一起的好处是：a）Jira票证表示计划的执行，可以将其数字与计划进行比较，生成管理者可以依赖的统计数据； b）我们确切地知道为用例做出贡献的每个人，他们做了什么以及持续了多长时间； c）这是汲取教训的重要来源。
9. 测试，测试，测试！ 它必须是一种强迫性行为。 没有通过广泛的测试会话，没有任何结果。
10. 不断培训团队，并向他们提供所用技术的所有参考书目。 我们在团队内部拥有的技术知识越多，我们解决问题和提高生产率的能力就越高。

以这种方式工作，一切都变得可量化，可预测，可比较且可追溯。

从上述实践中，我们可以提取从业务到最低IT级别的可追溯性流程，如下图所示。

泳道和活动等业务流程元素可能会激发参与者和用例。 用例和参与者记录在Wiki页面上。 每个用例和参与者在Wiki上都有一个页面，该页面具有唯一的URL，可用于引用电子邮件，文档，Jira票证等上的元素。 将为每个用例创建一个Jira票证，其中包含指向用例Wiki页面的链接。 该Wiki页面还可以具有指向票证的链接，因为它也具有唯一的URL。 可以通过版本控制系统（SVN）将Jira票证自动链接到源代码，并声明性地链接到系统的功能和用户界面。 由于可以在Wiki页面中创建模型，因此我们还将这些Wiki页面与用户界面链接起来，以将模型与最终用户界面进行比较。 我们终于有了与安全角色相关联的参与者。

我承认，架构师没有资格在组织中定义和实施软件开发过程（他们实际上更相信Programming Motherfucker编程哲学 ：D），但是他们始终愿意为建立一个合适的体系做出贡献。 由于他们拥有监视服务器，版本，测试，性能等的工具，因此他们还希望项目经理拥有能够估计工作量，预测事件，预测问题并因此产生更好的计划和结果的工具。

警告：无论我们在软件过程中投入了哪些内容，都无法量化或衡量，这将成为昂贵的开销。

参考： 建筑师需要 Hildeberto博客博客中我们JCG合作伙伴 Hildeberto Mendonca 的实用软件开发流程 。

翻译自: https://www.javacodegeeks.com/2012/07/architects-need-pragmatic-software.html