Difference between revisions of "Coaching en"
Jump to navigation
Jump to search
(Created page with "{{Backlink|target=Leistungen}}{{language|master page=Coaching|language=en}}{{SimpleArticle|title=Coaching|text= If you would like to train your team intensively in Softwareeng...") |
|||
Line 1: | Line 1: | ||
{{Backlink|target=Leistungen}}{{language|master page=Coaching|language=en}}{{SimpleArticle|title=Coaching|text= | {{Backlink|target=Leistungen}}{{language|master page=Coaching|language=en}}{{SimpleArticle|title=Coaching|text= | ||
If you would like to train your team intensively in Softwareengineering and the focus is on problems to be solved in your current project, than coaching is the adequate approach. | If you would like to train your team intensively in Softwareengineering and the focus is on problems to be solved in your current project, than coaching is the adequate approach. | ||
+ | |||
+ | Martin Fowler wrote in his article "Who needs an architect?": | ||
+ | ''Improving the development team’s ability gives an architect much greater leverage than being | ||
+ | the sole decision maker and thus running the risk of being an architectural bottleneck.'' | ||
+ | |||
+ | Investing in the skills of your developers and architects has a very good cost/benefit ratio. | ||
<br> | <br> | ||
== Topics == | == Topics == |
Latest revision as of 10:03, 14 October 2019
This page in other languages: de
Coaching
If you would like to train your team intensively in Softwareengineering and the focus is on problems to be solved in your current project, than coaching is the adequate approach.
Martin Fowler wrote in his article "Who needs an architect?": Improving the development team’s ability gives an architect much greater leverage than being the sole decision maker and thus running the risk of being an architectural bottleneck.
Investing in the skills of your developers and architects has a very good cost/benefit ratio.
Topics
- Continuous Integration
- Microservices
- Test Driven Development
- Software Architecture
- Domain Driven Design
- Y-Prinzip
- Model Driven Development