[et_pb_section fb_built=”1″ _builder_version=”3.0.47″][et_pb_row _builder_version=”3.0.48″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″ _builder_version=”3.0.47″][et_pb_text _builder_version=”3.19.9″]<\/p>\n
Softwareentwicklung in agilen Teams stellt hohe Anforderungen an jedes einzelne Teammitglied. W\u00e4hrend den fachlichen Qualit\u00e4ten f\u00fcr gew\u00f6hnlich die h\u00f6chste Aufmerksamkeit gewidmet wird, fallen die \u201eweichen\u201c Faktoren naturgem\u00e4\u00df mit sch\u00f6ner Regelm\u00e4\u00dfigkeit unter den Tisch. Das ist gleich aus mehreren Gr\u00fcnden paradox: Scrum dient nicht in erster Linie der Verwaltung von Tasks und deren termingerechter Umsetzung, sondern der Organisation des Teams, das mit der Umsetzung betraut ist. Das bringt zwangsl\u00e4ufig den Faktor \u201eMensch\u201c ins Spiel. Im \u201eDaily Scrum\u201c bleiben oft nicht mehr als zehn Minuten, um die Befindlichkeit der Kollegen, schwelende Konflikte und Unstimmigkeiten im Team zu erfassen. Wer hier nicht eine geh\u00f6rige Portion Empathie mitbringt, kann schnell mit Problemen konfrontiert werden.
Nicht minder schwierig kann die Situation werden, wenn im Zuge von Continuous Delivery die Grenzen zwischen Entwicklung und Betrieb verwischen oder im Sinne von DevOps komplett aufgehoben werden. Kollegen, die bisher in strikt getrennten \u201eSilos\u201c ihren Dienst am Projekt leisteten, m\u00fcssen nun pl\u00f6tzlich und unerwartet Seite an Seite agieren. Eine vergleichbare Szenerie kann entstehen, wenn Entwickler aus ihrem Einzelk\u00e4mpferdasein in die Paar-Programmierung gelotst werden. In beiden F\u00e4llen ist Konfliktpotenzial vorprogrammiert und will erkannt und moderiert werden.
Pers\u00f6nliche Probleme einzelner, offene oder schwelende Konflikte im Team, Missverst\u00e4ndnisse durch mangelnde Kommunikation: Das Erkennen und Beseitigen dieser und vergleichbarer Zust\u00e4nde ist f\u00fcr den Projekterfolg ebenso entscheidend wie die fachliche Qualit\u00e4t. Was ein blo\u00df funktionierendes von einem erfolgreichen agilen Team unterscheidet, sind deshalb oft genug die stillen Erfolgsfaktoren, die Soft Skills. Das beginnt bei der sorgf\u00e4ltigen Zusammenstellung des Teams. Aber es l\u00e4sst sich auch in laufenden Projekten weiter steuern und verbessern.
Mitarbeiter \u2013 ob Entwickler oder CEO \u2013 kann man in ihren grundlegenden menschlichen Eigenschaften nicht ver\u00e4ndern, aber darum geht es auch nicht. Trainierte Soft Skills sch\u00e4rfen das Bewusstsein f\u00fcr kommunikative Situationen, verbessern das Gespr\u00e4chsverhalten und erh\u00f6hen die Sensibilit\u00e4t f\u00fcr Zwischenmenschliches. Allein das kann das Teamplay schon entscheidend verbessern.
Das beiden Trainings Soft Skills f\u00fcr Softwarearchitekten und Agile Softwarearchitektur nach iSAQB-Standard genie\u00dfen an der ITech Academy einen hohen Stellenwert. Zahlreiche Unternehmen aus unterschiedlichsten Branchen lassen jeden neuen IT-Mitarbeiter in einem offenen Training an der Academy schulen oder holen sich einen Trainer f\u00fcr eine Inhouse-Schulung ins Haus.<\/p>\n
F\u00fcr weitere Informationen:<\/span><\/p>\n iSAQB Soft Skills f\u00fcr Softwarearchitekten<\/a> [\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section]<\/p>\n","protected":false},"excerpt":{"rendered":" Softwareentwicklung in agilen Teams stellt hohe Anforderungen an jedes einzelne Teammitglied. W\u00e4hrend den fachlichen Qualit\u00e4ten f\u00fcr gew\u00f6hnlich die h\u00f6chste Aufmerksamkeit gewidmet wird, fallen die \u201eweichen\u201c Faktoren naturgem\u00e4\u00df mit sch\u00f6ner Regelm\u00e4\u00dfigkeit unter den Tisch. Das ist gleich aus mehreren Gr\u00fcnden paradox: Scrum dient nicht in erster Linie der Verwaltung von Tasks und deren termingerechter Umsetzung, sondern […]<\/p>\n","protected":false},"author":1,"featured_media":14526,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"on","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[551,834,549],"tags":[],"class_list":["post-7354","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-kommunikativ","category-medthodik-und-vorgehensweise","category-methodisch"],"_links":{"self":[{"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/posts\/7354","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/comments?post=7354"}],"version-history":[{"count":5,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/posts\/7354\/revisions"}],"predecessor-version":[{"id":53863,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/posts\/7354\/revisions\/53863"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/media\/14526"}],"wp:attachment":[{"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/media?parent=7354"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/categories?post=7354"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/tags?post=7354"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
iSAQB Agile Softwarearchitektur<\/a>
Inhouse-Trainings<\/a><\/p>\n