Ihr Broker

  • DAX 0,70
  • EUR/USD 0,50
  • GOLD 0,30

Nur Spreads

Keine Kommission

Jetzt registrieren

CFDs sind komplexe Instrumente und umfassen aufgrund der Hebelfinanzierung ein hohes Risiko, schnell Geld zu verlieren.

ConSol Software GmbH

M?nchen - Komplexe Integrationsvorhaben in der Softwareentwicklung sind oft zeitaufwendig.

26.05.2021 - 19:07:32

Sieben Bausteine f?r ein erfolgreiches Change Management in Software-Integrationsprojekten. IT-Dienstleister Consol nennt sieben Best Practices, mit denen Unternehmen Change-Management-Prozesse in Software-Integrationsprojekten beschleunigen k?nnen. Die Lead Time for Changes ist der wichtigste Messindikator f?r ein erfolgreiches Change Management in der Softwareentwicklung.

M?nchen - Komplexe Integrationsvorhaben in der Softwareentwicklung sind oft zeitaufwendig. IT-Dienstleister Consol nennt sieben Best Practices, mit denen Unternehmen Change-Management-Prozesse in Software-Integrationsprojekten beschleunigen k?nnen.

Die Lead Time for Changes ist der wichtigste Messindikator f?r ein erfolgreiches Change Management in der Softwareentwicklung. Diese Lead Time beschreibt dabei die Zeitdauer, die erforderlich ist, um eine Source-Code-?nderung ab einem neuen Commit erfolgreich im Produktivbetrieb nutzen zu k?nnen.

Basierend auf den Erfahrungswerten aus zahlreichen Software-Integrationsprojekten hat Consol sieben Best Practices aufgestellt, die ein erfolgreiches Change Management ma?geblich f?rdern.

1. Uneingeschr?nkte Zugriffsm?glichkeit auf die Infrastruktur

Verz?gerungen bei der Lead Time for Changes sind oft auf infrastrukturelle Gr?nde zur?ckzuf?hren: So ist zum Beispiel ein Team f?r den Applikationsbetrieb in der Produktiv-Umgebung verantwortlich, w?hrend ein anderes Team f?r das Betriebssystem und Netzwerkthemen wie Firewall-Einstellungen zust?ndig ist. Geteilte Verantwortlichkeiten finden sich zudem h?ufig bei Testumgebungen oder der CI- und CD-Plattform, sodass bei Problemen oder geplanten ?nderungen immer auf Beistellungen anderer Teams zur?ckgegriffen - und gewartet - werden muss.

Best Practice: Die Testumgebungen m?ssen unkompliziert f?r alle Teammitglieder nutzbar sein. Dabei sollten Mitarbeiter mit Betriebsverantwortung einen m?glichst vollen Root-Zugriff auf die Test- und Produktivumgebung haben: von der Hardware ?ber das Betriebssystem und Drittanbieter-Software bis zur Applikation selbst.

2. Cloud-native Architektur

Gro?e Server-Applikationen ben?tigen viel Zeit f?r die Kompilierung, Paketierung und Installation. Automatisierte Regressionstests dauern oftmals stundenlang und werden in vielen Projekten deshalb nur nachts ausgef?hrt.

Will ein Unternehmen aber Software-Updates h?ufig - mehrmals am Tag und schnell, etwa innerhalb von 15 Minuten - in Produktion bringen, muss die Architektur dies auch unterst?tzen. Einerseits muss dabei das Risiko von Seiteneffekten so gering wie m?glich sein, andererseits m?ssen auch der Build-, Test-, Deployment-, Startup- und gegebenenfalls der Fall-back-Prozess schnell ablaufen. Und Nutzer der Applikation sollten nach M?glichkeit keine Unterbrechungseffekte wie eine Downtime bemerken.

Best Practice: Eine Microservice-Architektur mit kleinteiligen und voneinander unabh?ngigen Cloud-nativen Applikationen erlaubt eine fundamentale Beschleunigung. So kann der technische Anteil an der Lead Time for Changes von mehreren Stunden auf wenige Minuten verk?rzt werden, und zwar durch einen Umstieg von Komplettinstallationen auf inkrementelle Mini-Updates.

3. Funktionierende DevOps-Organisation

Das Sprichwort "Viele K?che verderben den Brei" trifft auch auf das Change Management zu. Hinsichtlich der Lead Time for Changes gilt vor allem auch: Sie verlangsamen die Prozesse.

Best Practice: DevOps-Teams, in denen alle Kompetenzen vom Software Engineering ?ber die Qualit?tssicherung und das Installations- und Konfigurationsmanagement bis hin zum Applikationsbetrieb geb?ndelt sind, k?nnen autark und ohne Warten auf Beistellungen alle ?nderungen und Optimierungen selbst durchf?hren. Durch den permanenten Wissensaustausch sind Interessen- oder Kapazit?tskonflikte vermeidbar.

4. Agiles Mindset

Wenn nicht jedes Team-Mitglied nahezu jede T?tigkeit aus?ben kann, sind auch Verz?gerungen der Lead Time for Changes nicht ausgeschlossen.

Best Practice: Mit agilen Konzepten werden die Zusammenarbeit innerhalb von Teams und die Kompetenzen der Mitarbeiter gest?rkt. Zu den wichtigen Methoden aus der agilen Welt z?hlen etwa ein Taskboard, Refactorings, Heartbeat-Retrospektiven, Pair Programming oder Peer Reviews.

5. Null-Fehler-Toleranz

Vorhandene Fehler oder auch schon der Verdacht, dass potenzielle Fehler vorhanden sind, bremsen die Bereitschaft, Software h?ufig und schnell zu aktualisieren - gem?? dem Motto "Never change a running system". Umgekehrt f?rdert aber eine dauerhaft nachgewiesene Fehlerfreiheit und Zuverl?ssigkeit das Vertrauen bei Software-Aktualisierungen, und zwar das Vertrauen aller Beteiligten vom Anwender ?ber den Softwareentwickler bis hin zum Projekt-Sponsor.

Best Practice: Jedes Unternehmen sollte der Null-Fehler-Toleranz eine hohe Priorit?t einr?umen. Alle vorhandenen Fehler m?ssen beseitigt werden und die korrekte Funktionsweise ist durch automatisierte Tests mit maximaler Abdeckung abzusichern. Durch Code-Generierung, -Reviews und -Refactorings kann redundanter, fehlerhafter oder ?berfl?ssiger Code vermieden werden. Die fehlerfreie Umsetzung von ?nderungen wird so deutlich beschleunigt.

6. Automatisierung von Interaktionen innerhalb des Lead-Time-Intervalls

In der gesamten Prozesskette der Lead Time for Changes sind vor allem die menschlichen Interaktionen die gr??ten Zeitfresser: Es beginnt vielfach schon beim Zusammenf?hren von Source-Code-?nderungen. Zudem sind manuelle Schritte h?ufig bei der Installation und Testausf?hrung oder bei Konfigurations-?nderungen anzutreffen. Manuelle T?tigkeiten verursachen nicht nur zeitliche Verz?gerungen, sondern beinhalten auch die Gefahr menschlicher Fehler, die unn?tige Reparaturaufw?nde nach sich ziehen k?nnen.

Best Practice: Durch Nutzung einer Trunk-basierten Entwicklungsmethode liegen zum Zeit-punkt der Release-Entscheidung alle ?nderungen schon fix und fertig vor. Sie m?ssen damit nicht noch manuell zum Beispiel in einen Release-Branch ?bertragen und gepr?ft werden. Eine CI-/CD-Pipeline kann zudem alle Schritte wie die Release-Paketierung, Testinstallationen oder die Produktiv-Inbetriebnahme vollautomatisiert ausf?hren. Jede menschliche Interaktion, die automatisiert wird, vermeidet unn?tige Wartezeiten innerhalb der Lead Time for Changes und entlastet zudem das gesamte Team.

7. Schlanke Change-Management-Prozesse

In manchen F?llen sind menschliche Interaktionen unverzichtbar und auch nicht automatisierbar, etwa bei der fachlichen ?berpr?fung und Qualit?tssicherung einer umgesetzten ?nderung. Allerdings gibt es auch hier M?glichkeiten, manuelle Schritte durch Automatisierung zu unterst?tzen und zu beschleunigen.

Best Practice: Alle Change-Management-Prozesse werden dahingehend verschlankt, dass manuelle Schritte nach M?glichkeit nur noch f?r kontrollierende oder explorative T?tigkeiten erforderlich sind. Testergebnisse k?nnen beispielsweise automatisiert so aufbereitet werden, dass alle ?nderungen seit dem letzten Testlauf hervorgehoben und schnell ?berpr?fbar sind.

Automatisierung reduziert Lead Time for Changes enorm

"Unter den richtigen Voraussetzungen k?nnen in Software-Integrationsprojekten individuelle Kundenanforderungen innerhalb einer Stunde umgesetzt und ?nderungen produktiv in Betrieb genommen werden", erkl?rt Christian Wied, Teamleiter Software Engineering bei Consol. "Durch automatisierte Test- und Installationsroutinen etwa kann die Lead Time for Changes vielfach auf 15 Minuten reduziert werden. Unter zus?tzlicher Ber?cksichtigung von menschlichen Interaktionen wie Abstimmungs-, Review- oder Quality-Assurance-Prozessen ist damit eine Lead Time for Changes von unter 60 Minuten realisierbar."

Pressekontakt:

ConSol Consulting & Solutions Software GmbH Isabel Baum St.-Cajetan-Stra?e 43 D-81669 M?nchen Fon: +49-89-45841-101 E-Mail: mailto:Isabel.Baum@consol.de Web: https://www.consol.de und https://cm.consol.de

PR-COM GmbH Nicole Oehl Sendlinger-Tor-Platz 6 D-80336 M?nchen Fon: +49-89-59997-758 E-Mail: mailto:nicole.oehl@pr-com.de Web: http://www.pr-com.de

Weiteres Material: http://presseportal.de/pm/21298/4925261 ConSol Software GmbH

@ presseportal.de