建筑师如何培养技术卓越的研讨会成果

建筑师如何培养技术卓越的研讨会成果"/>

建筑师如何培养技术卓越的研讨会成果

讲习班背景

本周早些时候，我在敏捷联盟在波兰格但斯克举行的第一次敏捷欧洲会议上举办了一个研讨会。 如摘要所述：

在敏捷世界中，建筑师和体系结构通常被认为是肮脏的话，但是架构师的角色和体系结构思想是实现技术卓越性（提高软件敏捷性）的重要推动力。

在本研讨会中，我们将探讨团队实现技术卓越的不同方式，并探索架构师用来成功影响技术卓越的不同工具和方法。

研讨会期间，与会人员探讨了：

• 技术卓越的一些例子是什么？
• 如何定义技术卓越？
• 探索了架构师在敏捷环境中的角色
• 了解在敏捷环境中工作的架构师的广泛职责
• 专注于帮助/阻碍技术卓越的架构师的特定行为和职责

以下是2016年敏捷欧洲会议期间研讨会参与者的集体经验的结果。

技术卓越实例

• 团队共享，讨论和遵循的一组编码约定和标准
• 引入更多正式的代码审查工作奇迹，代码审查支持的代码质量，用户测试和编码标准，对等代码审查流程
• 使用UML进行软件建模
• 第一次我们在内存搜索索引中使用它来解决性能严重的RDBMS问题
• 如果使用scrum，则可以看到并应用良好的技术定义（DoD）
• 面向内部和外部使用者的共享API
• 引入“无估算”方法，并提供足够好的软件/功能，以使其继续使用
• 具有Docker的微服务架构
• 团队精神
• 倾听别人的声音（不是！我的想法是最好的）
• 通过卓越的客户支持（最独家）保持项目/软件的生命周期并在产品中使用
• 团队中的态度是“艺术不容忍”
• 思维宽广！
• 开发工程到需求
• 明确报告问题（例如丰田）
• 使用最新的库和升级功能
• 正确的工作工具
• 经常可用的“事物”（例如，日常构建可能功能不完善，但原则上可行）
• 举例说明
• 设置新软件的技术环境后，新的团队成员Swift介绍了该项目（干净，直接的设置）
• 团队通过回顾和其他方式对此进行有意识地追求技术卓越
• 在设备上执行的设备驱动程序
• 持续学习（发现新技术），方法论
• 自动部署，DevOps工具使用带有TDD方法的CI，CD，UT，我参与的项目中的CD于2011年首次实现，多层CI网格，用于所有服务的CI环境，持续集成和交付（每天使用的工具来支持他们），持续集成，出色的CI
• 测量质量（静态分析，测试覆盖率），集成到IDE中的静态代码分析
• 快速失败方法，反馈循环
• 着色器统计信息（统计方法，提高编译器效率）
• 少锁多线程调度算法
• 多线程属性推导的启发式算法
• 无需修改所有内容，代码库的模块化即可轻松扩展产品
• 学习如何使用复杂的东西（深入）
• 重用超过重新发明/重新设计
• 能够预测给定解决方案的工作方式/后果
• 事半功倍（效率）
• 一站式的简单设计，很容易理解该技术的真正作用，产品的结构适合于白板＆＃55357;＆＃56898;
• 系统的架构与团队/组织结构相匹配
• 自我组织
• 理想的分离测试，自动化性能测试，使用硒的自动前端功能测试，十年前首次进行的单元测试，构造新的性能测试用例需要几分钟的时间，而重构单元测试已经通过了（多数-希望全部！）
• 对新技术/方法的不断好奇
• 熟悉软件模式（何时使用以及何时不使用）
• 从错误中学习

技术卓越的定义

• （技术）卓越是一种比昨天更好的态度
• 卓越技术是激励团队继续前进的圣杯
• 技术卓越是不断改进产品设计和开发团队的过程。 示例：自动化，知识共享，文化。 别名：梦
• 卓越技术能力是一种有意识地运用工具和实践来以可持续的方式并在限制（例如时间和金钱）内解决并持续改善复杂问题的能力。 示例：连续交付

建筑师的活动

• 解释决定
• 能够在多种可能性（后果和局限性意识）中选择正确的解决方案
• 能够证明做出的技术决定的合理性
• 思考（花时间思考产品，结构，使用的技术等）
• 帮助解决相互依赖性，帮助识别/最小化外部噪音（即具有负面影响的技术依赖性更改），以及与从事同一项目的其他团队的整合协调
• 开始和主持有关设计，决策的长期后果等的讨论
• 需求定义，确保在分析/设计过程中省略“所有内容”
• 对决策提出质疑，以鼓励开发人员考虑更广泛的情况，提出问题（尤其是不明显的问题），对正在完成的工作提出困难的问题
• 听别人
• 鼓励人们提出想法，鼓励想法分享
• 设置积压以实现卓越的技术
• 挑战旧决定
• 业务决策支持（IT，第三方）
• 确保我们咬的不超过咀嚼量-递增/迭代
• 确保团队可以看到，理解和访问体系结构，保持技术凝聚力，帮助团队考虑全局和相互依赖性，帮助团队定义系统并绘制图表
• 有关所使用技术/协议的详细知识
• 前瞻性思维
• 提出解决复杂问题的方案
• 图表/演示
• 广泛查看情况/项目，查看其他团队正在构建什么以供重复使用或与之交互
• “主要”测试方案定义
• 组件结构和相互作用的定义
• 维护技术远见（与利益相关者对话）
• 专注于项目目标
• API规范
• 验证当前设计与计划使用
• 当事情变得复杂时，立即向功能团队提供临时咨询
• 教学团队，与团队共享技术知识（和专业知识）
• 教练团队。 指导开发团队，从团队那里获得买断以进行改变
• 识别团队中的技术技能差距
• 积极思考
• 间隙识别
• 降低风险
• 开箱即用的想法
• 研究解决方案，帮助团队确定试验领域，探索新领域
• 创建概念证明（POC）
• 学习新事物，研究并尝试新工具，思想，技术等
• 尝试更改系统之前，先要对系统有深入的了解
• 审查团队的系统设计，执行代码审查和编码标准支持，审查代码

支持技术卓越的行为

活性

• 给团队快速及时的反馈
• 耐心地解释所有微小的细节，回答简单的问题
• 随时需要
• 在开发人员需要您时成为安全网
• 设置交流以共享知识
• 解释设计背后的原因
• 提高优秀开发人员的知名度
• 进行配对编程，与团队合作
• 解释技术卓越的商业价值
• 鼓励团队思考并努力实现技术卓越
• 不断壮大的人才，指导开发人员提高技术技能，培训团队，积极教育–组织编码dojos等
• 设置积压以实现技术卓越
• 提高团队合作精神和动力
• 每天凌晨3点醒来，每天与团队联系（对于分布式团队）
• 与团队讨论发现的问题
• 与团队坐下来讲授并记录架构培训，以备将来使用
• 密切关注市场上的新事物并将其带入团队
• 在技​​术，工具，概念等方面保持最新。
• 在追求技术卓越方面树立榜样
• 鼓励实验
• 支持团队与其他团队合作
• 帮助团队识别盲点

被动

• 在项目之间更改上下文的能力
• 让团队做出决定
• 退后一步，为整个团队的技术进步腾出空间
• 不从积极劝阻专栏做事
• 团队做决定

阻碍技术卓越的行为

活性

• 专政，必须按照我的方式去做，要控制（每个小细节）
• 责备和羞辱
• 做出任意决定，尤其是不解释其背后的原因
• 拒绝过于复杂的C ++代码
• 使用歧义，复杂，不确定的英语词汇
• 关闭团队的新想法
• 令人沮丧的想法“我不会不介意您复杂的C ++ SPT初始化”
• 为演示创建丑陋的原型，并迫使团队随后进行清理
• 将BDUF（前期大设计）强加给开发团队
• 创建了不可行的设计（即无法在当前限制下实施）
• 坚持惯用的“旧方法”，以摆脱惯性/无知地执行旧的已知技术等

被动

• 进行过多的活动以致无法进行–不专注于任何活动（也没有时间鼓励技术卓越）
• 邀请但从未参加过会议
• “我不见建筑师”
• 具有较差的开发技能的软件架构师
• 不与团队合作
• 在文档中保留过时的信息
• 仅在提示时参与设计
• “我不知道如何，所以我不会定义它”

故事

• 开发人员支持软件（获取电子邮件反馈）
• 反故事：“让我们*不要*坐在一起” –离开的人向他们展示了如何做
• “让我们一起坐下”（解决内存泄漏问题）
• 小组问题（安全问题）

如果您喜欢这篇文章，您将对“ 与Tech Leads交流 ”感兴趣，该书分享了来自全球超过35个Tech Leads的真实生活经验。 现在可在Leanpub上使用 。

翻译自: .html