Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Software entwickeln statt Feuer löschen

Ähnliche Präsentationen


Präsentation zum Thema: "Software entwickeln statt Feuer löschen"—  Präsentation transkript:

1 Software entwickeln statt Feuer löschen
Noser Engineering AG Software entwickeln statt Feuer löschen 25. August 2008, Wallisellen Application Lifecycle Management Day Markus Hämmerli Noser Engineering AG Manuel Domeisen Noser Engineering AG Folien Master

2 Inhalt Teil 1 Ausgangslage in der SW-Entwicklung
Wir haben das Referat in zwei Teile aufgeteilt Im ersten Teil werde ich versuchen die kritischen Punkte und die Problemstellungen aufzuzeigen Um dann die fünf wichtigsten Schlüsse welche wir aus den letzten 10 Jahren aus der Praxis gewonnen haben zu erklären Im zweiten Teil wird dann Manuel Domeisen aufzeigen wie diese best Practises konkret in der Praxis umgesetzt werden können. Teil 1 Ausgangslage in der SW-Entwicklung Theorie aus langjähriger Praxis Die 5 wichtigsten Punkte Teil 2 Vorgehen in der Praxis Ausschnitte von konkreten Umsetzungen der 5 Punkte

3 Application Lifecycle Management ?
Noser Enginnering AG Application Lifecycle Management ? Vor einiger Zeit sah ich meinen Sohn ganz konzentriert hinter dem PC sitzen. Ich ging hin und fragte was er da mache. Er: „ich lösche ganz viele Feuer“, „kennst du das Spiel Papa?“ Und ich dachte an einige Projekte und sagte: „na ja - ich glaube ich kenne das Spiel“ Start Folien Master

4 Projekt- / Entwicklung
Noser Enginnering AG Das Spiel mit dem Feuer Die Herausforderung für den Projektverantwortliche besteht darin in der Koordination von all diesen vielen Tasks / Aufgaben, bevor es zu brennen beginnt. Koordination: Der unterschiedlichen Tasks und Herausforderungen Detailvielfalt Unsicherheiten managen: Die unterschiedlichen Erwartungen Die unklaren Anforderungen Die noch offene Lösung Die laufenden Änderungen Die verschiedenen Risiken Die schwer abschätzbaren Aufwände Fixe Punkte: Termine Budget GL Verkauf Vertrieb Reports Kunden Releases Lösungen Terminplan Kunden Termindruck Qualität Kunden Projekt- / Entwicklung Kostendruck Änderungen Produkt-management Änderungen Erweiterungen Anforderungen Trends Features Markt Technologien Bugs Tech. Risiken Tester Vorgehen Tasks Architekt Entwickler Folien Master

5 Was macht das Management heute schwierig?
Noser Engineering AG Was macht das Management heute schwierig? Die Aufgabenstellungen sind oft komplex und abstrakt < und somit nicht ganz einfach erfassbar> Sind heutzutage komplexer weil System immer mehr vernetzt sind, Software gilt als etwas schnell änderbares: Änderungen sind die Regel: Randbedingungen, Bedürfnisse ändern Vorhaben sind zieloffener! Kunden sind heute mutiger was die Lösung angeht, Kunden gehen bewusst offen und evolutionär an die Aufgabenstellungen heran, man will sich nicht auf eine erste Lösung fixieren. Ist sehr gut, aber erfordert vom entsprechend ein agiles Management vom Lieferanten Unklare Anforderungen : Der Kunde weiss drei Wochen nach Auslieferung was er will Grösserer Zeitdruck, mehr Dynamik, höherer Unbekanntheitsgrad Budget nicht ganz so offen ist wie die Ideen  -> pragmatische Lösungen Mangement aller Kunden mit den verschiedenen Versionen Komplexe Aufgabenstellungen Änderungen sind die Regel, Randbedingungen, Bedürfnisse ändern Zeiten und Aufwände einzuschätzen ist sehr schwierig Vorhaben sind zieloffener! Projekte Unklare Anforderungen aber Fixpreis Grösserer Zeitdruck Budget und Termine nicht ganz so offen wie die Ideen  Produkte Höherer Unbekanntheitsgrad Etliche Konfigurationen Langwährende Entwicklungen Viele Versionen Unterschiedliche Kunden Folien Master

6 Produktivitäts- und Qualitätssteigerung
Neben diesen Anforderungen kommt nun zusätzlich hinzu, dass man zudem die Produktivität und Qualität steigern will. Das Team soll schneller und besser arbeiten, Verbesserungen in wenigen %. Einfachheit ist die Kunst, die Menge nicht gemachte Arbeit zu maximieren Industrialisierung des Software-Entwicklungsprozesses Qualitäts- und Produktivitätssteigerung Werkzeuge + Prozesse System unterstützt den Entwicklungsteam Qualität Automatisierung von bestimmten Prozeduren Klar definierten Aufgaben Zusammenarbeit Kommunikation Austausch / Verteilen von Informationen / Dokumente / Code Projektleitung Echtzeit Automatisierung (Aufnahme der Informationen) Definition der Produktivität Produktivitätssteigerung Bedürfnisse klar verstehen Genau das liefern was der Kunde braucht 80% / 20% früher / oft liefern Mehr Wert generieren Output Wert Direkte Kosten reduzieren: do the simplest thing that work Nur das liefern was der Kunde bereit ist zu zahlen Input Kosten, Arbeit Weniger Kosten, Arbeit Indirekte Kosten reduzieren: Automatisieren Systematischer und effizienter arbeiten (Werkzeuge, Methoden, Infrastruktur) Qualitätssteigerung

7 => Die 5 wichtigsten Punkte
… und wie kann dies erreicht werden ? => Die 5 wichtigsten Punkte

8 1. Das richtige Vorgehen …
Noser Engineering AG Jedes Projekt ist unterschiedlich Umfeld und Rahmenbedingungen Fachliche Komplexität Anforderungen Möglichkeiten Jeder Kunde ist verschieden Business, Abläufe, Leute, Erfahrungen, Umfeld Arbeitsweise, Sichtweise Jede Team ist anders Basierend auf dieser Ausgangslage der Verschiedenheit der Projekte überlegt man sich wie man ein Projekt erfolgreich abwickeln kann. Es ist offensichtlich: Es gibt kein Kochrezept für ein Entwicklungsprozess, schon gar nicht für Erfolg 1. Das richtige Vorgehen … Sage mir wie du ein Projekt startest und ich sage dir wie es endet Leicht umsetz- und flexibel anpassbarer Prozess Nutzen und Kunde stehen im Vordergrund Einfach, zweckmässig und effizient Folien Master

9 2. Team und Interaktionen
Noser Engineering AG 2. Team und Interaktionen Nichts ist erfolgreicher als ein effizientes eingespieltes Team Das Team und deren Zusammensetzung ist erfolgsentscheidend, Tools müssen dies unterstützen Jedes Team entwickelt und lebt eigene Prozesse, Zusammenarbeit und Kommunikation Eher kleinere Teams mit Spezialisten Offene Kultur und Eigenverantwortung Noch wichtiger als der Prozess ist das Team Ob ein Projekt erfolgreich ist oder nicht kommt schlussendlich auf das Team an Folien Master

10 3. Funktionierende Software
Noser Engineering AG Ok ich habe ein gutes Team zusammengestellt. Nur. Wie muss ich es organisieren, dass ich einen sinnvollen Output generieren kann? -> Wie ist dies in der Praxis machbar? Iterative Entwicklung ist die Schlüsselmethodik, wie OO in der Programmierung Jetzt können sie denken: Was erzählt der den da, das kennen wir seit 20 Jahren und machen wir schon lange. Fact ist, das ich sehr wenige Projekte sehen, bei welchen dies wirklich konsequent gemacht wird. Man geht zwar iterativ vor, man implementiert oft in Iterationen, aber viel zu wenig wird die Iteration dann auch getestet und was ich am wichtigsten finde beim Kunden auch eingeführt. Warum: weil testen mühsam und aufwändig ist, weil das Deployment beim Kunden nicht so einfach ist, weil der Kunde gerade keine Zeit hat, weil … Und gerade darum ist es so wichtig. Wie wollen sie sonst Feedback, und wie wollen sie es später bei noch viel grösseren Releases machen 3. Funktionierende Software Nichts ist überzeugender als funktionierende Software Iteration Inkrementelle Realisierungseinheit Alle Phasen werden durchlaufen Dauer etwa 1 Monat abhängig von Komplexität , Erstellungs- und Integrationsaufwand Deployment Planning Testing Analyse Implementation Design Folien Master

11 Iterative Entwicklung … richtig eingesetzt!
Noser Engineering AG Iterative Entwicklung … richtig eingesetzt! Die Planung der Iterationen ist essentiell! Welche Anforderungen werden in welcher Iteration umgesetzt. Welche Risiken sollen angegangen werden? Bsp: Für einen Kunden haben wir eine sehr komplexe Managementlösung implementieren müsssen. Wir haben ein kleines Subset von Features für die erste Iteration definiert und dann umgesetzt und getestet – alles hat gut funktioniert. Dann kam die letzte Phase der Iteration die Inbetriebnahme auf dem Server beim Kunden. Nichts hat funktioniert. Warum, weil es verschiedene Probleme bei den Berechtigungen gab. Da man dies so früh erkannt hatte hatte wir sehr viel Zeit die Probleme beim Kundenserver zu lösen und parallel konnte man die nächste Iteration entwickeln . Das ist aktives Risikomanagement. Andernfalls haben sie die Inbetriebnahmen die dann Monate dauern. Frühes Feedback Oder der Kunde weiss drei Wochen nach Auslieferung was er will. Wenn dem so ist, dann liefern sie so schnell sie können! Holen Sie Feedback des Kunden, der Endanwender: Beispiel bei einem anderen Projekt : Der Kunde sagte, er wird die User-Interfaces und Verhalten nicht spezifizieren können, zuerst musste man verschiedenste Enduser-Feedback einholen, die dann in jeder Iteration weiter verfeinert wurde. Nichts gibt mehr Vertrauen als Resultate Vorteile: Frühes Feedback Risikominimierung Fortschrittsmessung Alle Prozesse der Erstellung u. Integration werden durchlaufen Bessere Kontrolle für den Auftraggeber Schnellerer Start, einzelne Iterationen kaufen Kundenvertrauen durch funktionierende Releases Iterationen Inkrementelle Releases I1 I 2 I n F 1  + Anpassung F 2 F n Funktionalität Folien Master

12 4. Kundenzusammenarbeit
Noser Enginnering AG Man kann ein noch so raffinierter Vertrag aushandeln, Schlussendlich kommt es nur darauf an, ob der Kunden zufrieden ist, wenn ja werden sie kaum über den Vertrag reden. Der Vertrag rückt in den Hintergrund, oftmals interessiert der Vertrag überhaupt nicht mehr, der Fokus liegt voll auf den gelieferten Releases, man diskutiert über Features, ob sie noch Sinn machen wie teuer die sind aber nie mehr ob die in der Offerte drin waren oder nicht. 4. Kundenzusammenarbeit Kundenzusammenarbeit ist wichtiger als Vertragsverhandlungen Der Kunde muss schlussendlich zufrieden sein Der Kunde muss am Schluss eine Lösung haben, die ihm einen Nutzen bringt Die Lösung sieht am Schluss oft anders aus als am Anfang gefordert (durch Änderungen in Anforderungen und Umfeld) Die Lösung muss gemeinsam erarbeitet werden Folien Master

13 Termine, Ressourcen und Funktionalität …
Noser Enginnering AG Termine, Ressourcen und Funktionalität … Auftragnehmer und Auftraggeber gehen eine strategische Partnerschaft ein, es wird weniger „ein Stück Software nach Spezifikation“ bestellt, sondern mehr der Nutzen, rsp. Das Ziel definiert welches man gemeinsam erreichen will. Im Gegensatz zur klassischen Vorgehensweise wo der Fokus auf dem Pflichtenheft ist, Wird beim agile Ansatz zuerst die Ziele und den Nutzen ermittelt und festgelegt tönt etwas abenteuerlich! man ist sich gewohnt Funktionalität zu vereinbaren oder gar vertraglich zu regeln Agil werden mehr die Ziele vereinbart Agile Vorgehensweise Ziele und Nutzen werden ermittelt und festgelegt Termine und Kosten werden definiert Funktionalität wird iterativ erarbeitet und kann während der Entwicklung angepasst werden Nach der definierten Anzahl Iterationen hat der Kunden eine lauffähige Software Strategische Partnerschaft Höhere Kundenzufriedenheit Resources Schedule Features Folien Master

14 5. Auf Änderungen reagieren
Noser Enginnering AG 5. Auf Änderungen reagieren Wenn agil und iterativ gearbeitet wird haben sie die Nutzen für den Kunden zu erhöhen. Gerade bei sehr innovativen und / oder interaktiven Projektenist dies sehr wichtig. Aber Achtung die Änderungen müssen sauber erfasst und professionell verwaltet werden, Das bedeutet aber auch höhere Anforderungn an das Projektmanagement! Und wie man solche Dinge in den Griff bekommt werden wir im zweiten Teil der Präsentation zeigen. Auf Änderungen reagieren ist wichtiger als einem Plan zu folgen Anforderungen können in der Analyse nicht abschliessend definiert werden Vor allem nicht bei innovativen, neuen und sehr interaktiven Projekten Weitere Erkenntnisse während dem Projektverlauf Nicht erwähnte oder bekannte Randbedingungen Änderungen als Chance nutzen! Änderungen müssen verwaltet werden = > Höhere Anforderungen an das Projektmanagement! Folien Master

15 Anpassungen / Erweiterungen
Noser Enginnering AG Nach einführenedem Gespräch und Kunden Meeting wird abgeklärt in welchen Bereichen der Kunde Unterstützung braucht. Von der einfachen Installation und Inbetriebnahme durch Noser über die Kundenspezifischen Anpassungen bis hin zu einer Ausführlichen Beratung und anschliessendem Coaching. Wobei das Coaching auf unterschiedlichen Ebenen angesiedelt ist (Auf Entwickler Ebene, Auf Prozess Ebene und Je nach Kunde / Firma eignet sich das einte oder andere Modell oder gar alles zusammen. Was ist nötig um Arbeiten zu können. Jetzt wird es konkret... Beratung Coaching Installation / Inbetriebnahme Anpassungen / Erweiterungen Folien Master

16 1. Das richtige Vorgehen ? Analyse auf allen Ebenen
Noser Enginnering AG Am Anfang einer Beratung steht man ohne Wissen über den Kunden vor dem Kunden. Der Effizienteste Weg sich ein Bild zu verschaffen ist bei uns eine 12 Punkte checkliste zu verwenden mittels welcher wir durch die Unterschiedlichen Punkte gehen und diese jeweils mit dem Kunden besprechen: - Am Anfang um auf hoher Ebene die Visionen des Unternehmen auszumachen, die aktuellen Probleme (meistens kommen wir erst zum Einsatz wenn irgendwo bereits der Schuh drückt…), die Ziele des Unternehmens helfen uns eine Übersicht zu verschaffen Dann gehen wir einen Schritt weiter rein und schauen uns gezielt die definierten aber meistens die gelebten Prozesse an ( Wie werden tasks delegiert? Wie wird auf Änderungswünsche reagiert? Wer hat welche Rolle und vor allem ist diese Kommuniziert?) Die definition eines Prozeses ist grundsätzlich mal noch nichts eine Leere Hülle, die Prozesse werden dann mittels Tools unterstützt, Was für Tools sind im Einsatz, was ist der Output, haben Sie hilfscharakter oder sind Sie für den Prozess relevant?, Was für Daten sind enthalten, redundant? Zentral? Tools und Prozesse sind gut nur stellt sich die Frage wer diese wie und wann nutzt, durch dezentrale Tools (Task Management, Bug Reporting, Change Management, Release management, Controlling, Zeiterfassung) sind die MA oft daran an mehreren Stellen Ihre Daten einzutragen  Die Devise sollte hier lauten : mit minimalem Aufwand Alle Daten zu sammeln die Benötigt werden am besten Zentral : einfach gesagt weil wer weiss schon genau welche Daten er wirklich braucht? Beispiel… 1. Das richtige Vorgehen ? Analyse auf allen Ebenen Geschäftsebene: Visionen, Ziele, Chancen Prozessebene: Analyse der Prozesse und Umsetzung Technische Ebene: Wie werden Prozesse technisch unterstützt Anwendungsebene: Wie werden die Prozesse gelebt 12 Punkte Check mit Kunden durchgehen Alle wichtigen Aspekte der Softwareentwicklung werden untersucht Ungenutztes Potential aufdecken Risiken lokalisieren Vorgehen zur Steigerung der Produktivität und Qualität Folien Master

17 2. Team und Interaktionen ?
Noser Enginnering AG Anfangs wird TFS out of the Box installiert, das ist gut aber nicht genug Idee zentrale Datenhaltung die Rolle soll optimalst unterstützt werden – Jeder soll mit seinen Tools arbeiten Die Fragen sind dann: Was für Daten bringt jeder ein und was Für Daten brauch jeder Mitarbeiter um seine Rolle ausführen zu können (VS, MS Project, Reports) Abgeleitet vom Prozess kann die Konfiguration des TFS gemacht werden nicht genug: Leute müssen geschult und in den Prozess mit eingegliedert werden -- > feedbacks der einzelnen sind Wichtig! Nur wenn Prozess gelebt wird nutzt er was  Leben einhauchen Mittels einem Gezielten Coaching abgstimmt auf Rollen können hier die besten Resultate erzielt werden Jedes Unternehmen lebt Prozesse mehr oder weniger bewusst: Der Mensch als routinier wird sich seine Arbeitsweise zurechtlegen Wenn sie nicht vorgegeben ist. Gerade das einführen von neuen Prozessen kann und darf nicht damit enden sie zu dokumentieren, ich lehne mich vielleicht hinaus, aber ich würde sogar so weit gehen und sagen Die Dokumentation ist nur 2 rangig wichtiger ist das sie kommuniziert, akzeptiert und gelebt werden (3 K : Kommandieren, Kontrollieren, Korrigiere). Beispiele von Massnahmen: - Konkret treffen wir bei Kunden ganz unterschiedliche Bedürfnisse an sei es den Projektleiter bei der Planung seiner Tasks, seiner Mitarbeiter, seines Projekts zu coachen: - In welcher Granularität definiere ich Tasks, Was brauche ich um den Fortschritt messen zu können, mit der Zentralen Erfassung im TFS und die möglichen Auswertungen über Excel, MS Project und reporting wurden die Kennzahlen abgebildet die im vorhinein definert worden sind. Es braucht nicht unmengen von daten sondern ein paar ausgesuchte kennzahlen, diese auszumachen wird durch gezieltes coaching erreicht. - TFS ist ein mächtiges Tool das die zusammenarbeit von mehreren Rollen erlaubt (Stakeholder, Architekt, PL, Dev, test) da ist es wichtig dass die einzelnen Rollen dahingehend unterstützt werden die Technologie effizient einzusetzten. Das Coaching beispielsweise der entwickler ist eine in jedem Projekt wieder auftauchender Task ( Wie wird die versions verwaltung genutzt, was sind die Konzepte hinter TFS, wie rufe ich meine Tasks ab und ordne sie meiner Arbeit zu, die 2. Team und Interaktionen ? Entwickler Designer Datenbank entwickler Architekt Tester Business Analyst IT / Projekt Manager Folien Master

18 Anpassungen / Integrationen
Noser Enginnering AG Anpassungen / Integrationen Dabei gilt es nicht einfach nur TFS zu installieren (ausser man gründet gerade ein Firma) Prozesse sind vorhanden bestehende Tools müssen evaluiert werden / Einbindung ? Prozesse out of the box Nutzbar – Anpassung der Firmen Prozesse und oft nicht Ideal darum meistens Bedürfniss Daten zu sammeln. Kenndaten sind sehr unterschiedlich. Diese werden im Gespräch ausgemacht und verfügbar gemacht. Oft am Anfang will man sehr viel allerdings hat sich gezeit das wenig Gute Daten besser sind. Die Fragen sind immer diesselben, was für Tools werden eingesetzt? Wieso? Was ist ser Output? Kann dieser qualifiziert werden? Bsp: der Kunde setzte ein eigenes Task management ein. Selber entwickelt ideal auf seine Bedürfnisse angepasst (Aussage des Kunden) beim nachhacken stellt sich dann schnell heraus: es fehlen dinge wenn man es innerhalb des gesammten Prozess betrachtet stellt sich heraus das Daten mehrfach einegeben werden müssen Tfs ist im Einsatz nun stellt sich die Frage was wird integriert oder abgebildet? Auf was kommt es an / was sind die wichtigen Fragen Welche Drittparty-Tools sind vorhanden ? Wie sind diese im Prozess integriert ? Einbindung -> Schnittstellen ? oder Abbilden -> mit TFS ? Sollen die Tools integriert werden ? Sollen Daten übernommen werden ? Folien Master

19 Prozessdefinition für ein Maintenance Portal
Noser Enginnering AG Prozessdefinition für ein Maintenance Portal Beispiel einer Umsetzung: verteiltes Team China / Schweiz Wie werden tasks kooridiniert : am Anfang entstht im Gespräch die definition des Prozesses (im Hinterkopf die möglichkeiten des TFS) Definition der Verantwortlichkeiten, der Schnittstellen Umsetzung und Bei einem Kunden ging es darum einen Prozess zu definieren mittels welchem Probleme bsw. Änderungswünsche zentral verwaltet, geschätzt, priorisiert und kontrolliert werden können. Die Rollen in einem Prozess müssen genau definiert werden können und auch zugewiesen können: Bsp.: Problem tritt in China auf, dieses wird dem System Verantwortlichen gemeldet, dieser Trägt das in ein Eigens dafür zur Verfügung gestelltes Portal ein, der Aufwand zur erledigung wird dann abgeschätzt, Die Abschätzung wird dann durch den System verantwortlichen priorisiert und je nach dem ferigegeben, nach freigabe wird daran gearbeitet nach abschluss wird der Task zur verfifizierung an den System verantwortlichen zurückgespielt, bei erfolgreicher Lösung des Problems wird der Fall abgeschlossen. Das Controlling ist damit auch gerade enthalten. Verschiedene Sichten auf die gesammelten Daten erlauben es unterschiedliche Aussagen zu treffen (gesammt kosten, häüfigkeit von fehlern) Fazit: Genau definierte Rollen, Schnittstellen , zentrale Datenhaltung  TFS stellt diese Funktionen zur Verfügung mit geringem Aufwand erzielen Sie Pragmatische Ansätze ohne overhead Wichtig ist es den Prozess mit dem Kunden klar zu definieren Klare Verantwortlichkeiten Koordinator beim Kunden Systemverantwortlicher Schweiz Systemverantwortlicher China Koordinator beim Support-Dienstleister Folien Master

20 3. Funktionierende Software ?
Noser Enginnering AG Wir haben gehört Funktionierender Software erreicht man durch iteratives vorgehen: Eine Problematik stellt sich beispielsweise beim Releasmanagement: Ein paar Fragen: Wissen Sie was beim Kunden draussen für ein release läuft ? Können Sie dieses einfach so aus der Schublade ziehen ? Oder Gibt es doch noch ein bisschen recherche Arbeit um das Release nachbauen zu können? Beispielsweise bei einem Kunden wurde das ganze Releasemanagement transparent gestaltet so, dass: Zum Zeitpunkt t wird entschieden ein release zu erstellen. Dann wird ein Branch erstellt um dieses zu testen und zu stabilisieren (andere Entwickler arbeiten am Produkt weiter) Der tester findet fehler, diese werden automatisch dem betreffenden Release zugordnet und die Entwickler können diese beheben. Als Projektleiter interessiert mich -- > wie viele Bugs?? Mit Entwickler muss ich nun diskuttieren wie die Problemlösung zurückgespielt wird… Wenn das releas beim kunden ist was habe ich für möglichkeiten dies herauszufinden? Bei DLL‘s werden beim Build automatisch die Metadaten geändert! Rechte Maustaste Bei Applikationen habe ich dann das auch automatisch im Info drin!  Meistens kleine Änderungen erzielen spürbar Q steigerung Eine erste Frage ist immer wissen Sie was beim Kunden draussen ist? Wenn ja können Sie diesen Release genau nachbilden? Oder sind doch noch irgendwo Konfigfiles? Oder hat sich das DB schema geändert? Hmm, und schon sieht man ganz alles ist meistens nicht einfach so rekonstruierbar. Wichtig ist hier dass Sie sich bewusst sind dessen was jeweils noch zusätzlich benötigt wird um einen Kunden release 100 % zu definieren. Auch hier: man braucht nicht eine eierlegende wollmilchsau zu bauen sondern man muss sich bewusst sein was man benötigt, die Release Strategie muss in diesem Fall klar sein. Bei einem Kunden ging es darum Das ganze releasemanagement durchgängig abzudecken. Ich entwickle, zum Zeitpunkt t entschliesse ich als PL (oder das management) zu einem Release (hier könnte man jetzt lange auch noch über software configuration management reden) ganz einfach: wie markiere ich mein Build um zu wissen welches release das ist? Wie passe ich meine Versionen in den Metadaten eines Assembly automatisch an? Wie kann ich auf meinem Gui über info die version anzeigen lassen? Das alles zu automatisieren ist keine Hexerei und mitels TFS Build sind solche automatisierungen möglich. Sie können getrost zurücklehnen und den Kunden das release aushändigen 3. Funktionierende Software ? Versions- und Konfigurationsmanagement Release 0.1 Release 0.2 Release 0.3 Kundenspezifische Versionierungsstrategie V 0.1 V 0.2 V 0.3 V 1.0 V 1.1 V 1.2 V 2.0 V 2.1 V 2.2 Release 1.0 Release 1.1 Release 1.2 Release 2.0 Release 2.1 Release 2.2 Folien Master

21 4. Kundenzusammenarbeit ?
Noser Enginnering AG Der Austausch von Inforamtionen mit dem Kunden muss definiert sein: Wer darf was sehen? (Angebote, Spezifikationen…) Über welche Medien soll kommuniziert werden (Telefon, Meetings, … ) Wie sollen Informationen festgehalten werden? Was für Daten Sollen ausgetauscht werden ? TFS wird immer mit WSS geliefert wobei Sharepoint eine solide Basis bietet Basis  out of the box bietet Sharepoint viel, aber nicht genug! Auch hier: Die Plattform muss in den Prozess integriert sein dann lebt sie!! 4. Kundenzusammenarbeit ? Wie ist die Zusammenarbeit koordiniert? Welche Informationen sollen ausgetauscht werden? Dokumente Kontakte Ideen Termine Aufgaben Sharepoint integration im TFS  solide Grundlage Folien Master

22 Lösung für ein Maintenance Portal
Noser Enginnering AG Lösung für ein Maintenance Portal Vorteile Kategorisierte auflistung und Verwalttung von Change-Requests Bugs einmal eingegeben und verwaltet Von jedem Standort aufruf und editierbar Erfassung / Dokumentation Abschätzung Priorisierung Freigabe Entwicklung / Stunden Verifizierung abschliessen Neben dem noch die weiteren Kanäle werden gesammelt und somit ist der ganze Info austausch gemangt. Change / Bug Management Controlling Zentrale Ablage Globaler Zugriff Verantwortliche Folien Master

23 Projekt- / Entwicklung
Noser Enginnering AG 5. Auf Änderungen reagieren ? Der Arme Entwickler: Verkauf Knopf grösser  Verkauft sich besser? Kunde hat Kontakt mit dem Entwickler gut aufgehoben will eine kleine „änderung“ (weiss ich jetzt welches release dieser hat?) Tester meldet einen Bug  Ehre Dev. Muss aus Ehrgeiz korrigieren PL sieht velocity die er jetzt endlich mit dem TFS im Griff hat sich verringern… Wo liegt das Problem? Entwickler ist der Ansprechpartner? Lösung liegt in der Zentralen Ablage der Anfragen, und somit die Koordination die qualifizierung und vor allem das Planen erlauben!! Woher kommen Änderungswünsche? Wohin gehen diese? Wer qualifiziert dies? Wer setzt diese mit welcher Priorität um? GL Kunden Tester Verkauf Vertrieb Tasks Projekt- / Entwicklung Änderungen Änderungen Tasks Produkt-management Entwickler Anforderungen Folien Master

24 Bugreporting Integration
Noser Enginnering AG Bugreporting Integration Bestehendes Tool Frage ? Integration ? Schnittstellen? Abbildung? Möglich ? Datenübernahme notwendig? Struktur ? Entscheid : Ja abbildung  neuer Workitem typ eigener Workflow, Struktur übernommen Daten & Struktur TFS Work Item Bugtracking Tool (Freeware) Auf Kunden angepasste Struktur Folien Master

25 Zum Schluss … Effizienz
Noser Engineering AG Zum Schluss … Effizienz Schneller reagieren als die Konkurrenz und frühere Erfahrungen am Markt Einfachere Lösungen nach 80/20 Regel, weniger Überdesign Grössere Chance für wirtschaftlichen Erfolg Fokus liegt auf Produktivität Transparenz Bessere Kontrolle über Entwicklungsverlauf Durch die Zentrale Datenhaltung Vernetzung von Daten möglich Wissen wer was macht, was wann durch wen geändert worden ist Zuverlässig Bewährte Technologien Folien Master

26 Besten Dank für Ihre Aufmerksamkeit!
Noser Engineering AG Besten Dank für Ihre Aufmerksamkeit! Noser Engineering AG ... ... realisiert seit über 24 Jahren vielseitige Software-Projekte für anspruchsvolle Kunden. Nutzen Sie unser Know-how für Ihr Projekt zum gemeinsamen Erfolg! Markus Hämmerli Manuel Domeisen Folien Master


Herunterladen ppt "Software entwickeln statt Feuer löschen"

Ähnliche Präsentationen


Google-Anzeigen