敏捷开发团队的10个最佳提示

Hollander针对解决方案架构师如何在敏捷团队中取得成功，提出了最重要的十件事情：

“正好足够”的预先设计——除了非常简单的专案，一定时间的预先设计（例如，1到2周）是绝对必要的，其时间长短会取决于应用的型别——网路应用程式、智慧客户端（smart client）、移动或批处理，基本的功能需求是什么，是长期的解决方案抑或是折衷的、暂时的方案，都要弄清楚。预先设计的目的是要决定：使用什么技术——例如，ASP.NET或MVC，应用程式是什么型别——2层、3层抑或是面向服务的应用，如何访问资料库——储存过程、实体框架、LINQ、依赖注入（DI）。一篇简短的文件就可以包含所有这些资讯以供大家参考。
从垂直分片开始——是指从一小块功能开始（例如登入页面），尽可能地在垂直方向把它切分为很多层，从而把前一阶段所决定的所有技术结合在一起。这将验证设计决策的正确性，而且所有的技术可以一起工作，并且将向开发者展示在开发新程式码时可以遵循的模式。如果发现最初的设计决策不当，此时是一个合适的修改时间。
在每次迭代中的Just-in-time设计——在每个4周迭代的中段，专案经理、产品经理和架构师应该聚在一起讨论在下一个迭代中要完成的需求，确保他们每一位都同意这些需求，重要性更高的事情放在了前面处理，而且每个人对一切事情都非常清楚。这些讨论在当前迭代中会以不太明显的方式延续一个星期。接下来的一周，也即当前迭代的最后一周，架构师复审下一次迭代的需求，作出必要的设计决策，以便团队可以在下一个星期基于这些决策开展工作。如果需求与以往相当不同，那么，架构师会开发一些原型，编写一些程式码来证明概念，绘制一些图表，然后把所有这些东西集编为5页的档案以供参考。这不是为了制定出有利于开发人员的详细设计方案，而是要确保新的需求满足全域性的要求。
信任你的团队...但要跟他们在一起——这关乎架构师与开发人员的关系。架构师需要确保他没有逾越自己的角色，没有独占所有“做决定”的乐趣，使得开发人员的工作变得无聊。与此同时，架构师需要给团队提供指导，解决那些可能会导致开发人员停顿的困难问题。架构师每天都应该与每位开发人员接触，获悉他们在做什么，并且在他们遇上程式设计问题的时候给予帮助。特别是当开发人员不喜欢寻求帮助，试图花上整整一个礼拜的时间来自行解决问题的时候，这种帮助尤为需要。这种关系也适用于PjM和测试/构建/释出团队。
编写程式码！——架构师应该知道程式码的质量如何，这样才会对他做出的决定所产生的影响有更好的理解。他也可以整明白何时重构是必须的。编写程式码的架构师在开发团队中有更好的声誉。也就是说，Hollander并不认同（设计和开发）职责的泾渭分明。他还认为，架构师仍然是架构师，他不一定要像普通的开发人员一样擅长于编写程式码。
参与一切——架构师参与所有与专案有关的会议：设计、开发、程式码评审、需求规划等，这是有好处的，因为他能够以更广阔、更清晰的视角看待正在发生的事情，而且他能够通过告知产品经理其决定的潜在后果，从而帮助他/她避免在早期阶段做出错误的决定。
推动质量文化——一个成功的团队，一个人人都想成为其中一分子的团队，是建立在质量文化之上的：没有人偷工减料；没有人提交拙劣程式码；如果设计中有一个重大的缺陷，它绝不会不知不觉地混过关；所有人都是诚实和开放的，寻求整个团队达到最佳的结果。Hollander承认，建立这样一个团队很难，但并非不可能。首先，架构师应该在一开始就建立一些规则，这些规则不会因为开发人员不喜欢就随著时间而改变。比如决定编写单元测试，再比如在每次提交以前都要进行程式码评审，包括由架构师提交的程式码。如果评审人员（可以是团队中的任意一位）不认可程式码，程式码就不能提交。
知道何时需要改变——架构师应该非常灵活，随时准备好在设计需要改变的时候去改变设计。早期的解决方案也许不再适合，抑或是新的需求需要不同的方法。
遮蔽来自外部的随机请求——虽然这通常是专案经理/Scrum master的职责，但架构师可以保护团队不受外部请求的影响，这些影响往往会分散团队的精力和浪费真正工作的时间。举个例子：业务团队可能想要以某种特定的方式完成某些特定的事情，而他们的请求并不全然合理，也并不是必须实现。
撰写文件...但只有当有人需要阅读它们的时候——Hollander并不提倡记录一切，也不提倡根本不撰写任何文件。他认为有必要取得一个平衡——只编写一定数目真正有帮助的、有人会去阅读的文件。文件在记录详细设计的决定（比如资料模型）方面是很好的载体。迭代的设计决定，虽然它们由整个团队在迭代开始之初讨论得出，但我们仍然建议将它们记录在5页的文件之中，以备开发人员日后不记得架构师言论的时候进行查阅。而当最开始的开发人员和架构师离开专案、加入其他专案之后，新加入专案工作的人也能借助于这些文件理解某些决定的来龙去脉。

　　综上所述，Hollander指出，架构师应该确保他从理论上和实践上都是团队的一分子。架构师不应该编写所有的程式码，而只是其中一小部分，他不去测试或部署这些程式码，但他要确保整个流程的顺利进行。

Scrum References

Scrum Events

敏捷开发团队的10个最佳提示

Scrum References

免費創建在線翻頁電子書

TOGAF 9.2 有哪些新功能？2022 update

Lewin 變化模型綜合指南

六頂思考帽教程

PDCA 綜合指南

online diagramming

it

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結