Dieser Blog Artikel geht auf die Inhalte der Zertifizierungsprüfung für das Testen von Software mit Visual Studio und dem Microsoft Test Manager ein und liefert einen Leitfaden zur Vorbereitung auf die Prüfung 70-497.

Create and Configure Test Plans

• Create test plan properties: Select Test Configurations, Test Case Title, Area, Iteration, State, Automation Status, Assigned To, Assign Build To Test Plan, Determine Changes Between Builds
• Configure test settings: Create test settings, Data and Diagnostics, Roles
• Define configurations: Creating configuration variables, Default configurations, Creating a new configuration, Setting configuration state, Delete a test configuration
• Create Test Suites: Organizing Test Cases Using Test Suites (Query-based, Requirement-based and Static Test Suites), Hierarchy of Test Suites, Copy Test Suites, Managing Test Suites and Test Cases, TCM
• Configure Test Suites: Assign a Tester, Change the order of test cases, Select default configuration

Manage Test Cases

• Create Test Cases: Creating Manual Test Cases, Creating Automated Tests, Test Case History, Links and Attachements, Tested Work Items and Test Case States
• Create Test Steps: Adding parameters to a Manual Test Case, Adding parameters to Shared Steps, Run Multiple Iterations of Test with parameters, Add attachement to test step
• Define parameters: Add, Rename and Delete parameters
• Manage Shared Steps: Create Shared Steps, Copy Shared Steps, Share Common Test Case Steps Using Shared Steps, Create an Action Recording for Shared Steps

Manage Test Execution

• Run Tests: Run tests with options, Create action recordings, Shared steps action recording, Capture a screenshot while running a test, Add a comment while running a test
• Perform Exploratory Testing: Perform Exploratory Testing, Explore Work Item, Create bug, Create test case
• Manage bugs: Dashboards (Agile), Reports (Agile), Dashboards (CMMI), Reports (CMMI), Reports (Scrum), Verify bugs
• Use Lab Center: Create Lab Environments, Creating an SCVMM Environment Using Stored Virtual Machines and Templates, Running Tests in Lab Environments
• Analyze Recommended Tests: Assign Build, Test Impact, Related Work Items
• Perform analysis: Analyze Manual Test Runs, Reporting on Test Progress, View Test Plan Status
• Manage Work Items: Link existing test cases to a requirement

Inhalte der Zertifizierung Software Testing with Visual Studio 2012 (70-497) is a post from: AIT Blog

Oberstes Gebot bei der Bearbeitung von Process Templates ist die Verwendung der Versionskontrolle. Bevor man eine Anpassung macht, sollte man den Source Code eines Process Templates zunächst in seiner noch unveränderten Form in einem TFS Repository einchecken. Dies ermöglicht die Vorteile einer versionssicheren Dateiablage zu nutzen, um später Änderungen besser nachvollziehen oder Stände miteinander vergleichen zu können. Wenn man häufig Anpassungen der Art macht, dann ergibt sich in der Versionskontrolle in regelrechtes Sammelsurium an Process Templates (siehe Abbildung 1).

Abbildung 1: Sammelsurium an Process Templates

Damit hat man einen sehr wichtigen Grundstein für die Weiterentwicklung gelegt, auf dem man stabil und verlässlich weiter an seinem Template arbeiten kann. Dies ist jedoch nur der erste Schritt. Direkt als nächstes ist es wichtig, ein haltbares Versionierungsschema zu implementieren.

Nachdem ein neues Team Project auf Basis eines bestimmten Process Templates im Team Foundation Server erstellt wurde, kann man nämlich nicht mehr so einfach herausfinden, welches Process Template beim Anlegen des Team Projects verwendet wurde. Mit der Version 2012 des Team Foundation Servers hat Microsoft hier nachgebessert. Die Datei Classification.xml des Process Templates ist in der Lage eigene Properties aufzunehmen.

Genau dieses Feature (übrigens auch schon in TFS 2010 verfügbar) hat Microsoft nun erstmals selbst genutzt, um ein Property namens “Process Template” einzufügen (siehe dazu Abbildung 2). In dem Screenshot ist die Datei Classification.xml des von Microsoft ausgelieferten Process Templates Microsoft Visual Studio Scrum 2.2 zu sehen. Die in Zeile 25 beginnende Sektion properties gab es bereits vor dem Team Foundation Server 2012. Nun hat Microsoft diese jedoch selbst genutzt, um Versionsinformationen zu hinterlegen. Diese werden beim Erstellen eines neuen Team Projects mit in der TFS Datenbank gespeichert und sind somit später abrufbar (später mehr dazu).

Abbildung 2: Classification.xml des Scrum 2.2 Templates

An dieser Stelle kann man nun ansetzen und auf die gleiche Weise weitere Eigenschaften bekanntmachen. Zwei zusätzliche Informationen, die sich als nützlich erwiesen haben, sind die Versionsnummer, unter der das Template initial verwendet wurde sowie ein Verweis auf das Process Template, welches als Basis für die eigene Weiterentwicklung gedient hat. Die konkrete Vergabe der Versionsnummer kann natürlich frei gewählt werden. In dem hier gezeigten Beispiel ist das AIT-Versionsnummernschema zum Einsatz gekommen. Ein möglicher Aufbau der Datei Classification.xml nach diesem Schema ist in Abbildung 3 dargestellt.

Abbildung 3: Classification.xml eines angepassten Process Templates

Wie bereits angekündigt, ist es ein Leichtes, diese Informationen wieder aus einem existierenden Team Project auszulesen. Dafür gibt es verschiedene Möglichkeiten. Man kann sich z.B. ein kleines Tool schreiben, welches über die TFS API diese Informationen zur Verfügung stellt. Eine Alternative ohne die TFS API ist der Zugriff auf die TFS Datenbank mit einem einfachen Select-Statement.

SELECT [tbl_projects].[project_id]
  , [tbl_projects].[project_name]
  , [tbl_project_properties].[name]
  , [tbl_project_properties].[value] 
FROM [tbl_projects]
INNER JOIN [tbl_project_properties]
 ON [tbl_projects].[project_id] = [tbl_project_properties].project_id
WHERE [tbl_projects].[project_name] like 'AIT.Scrum%'

Diese Abfrage kann einfach wiederverwendet werden. Man muss lediglich den Namen des Team Projects in der Where-Clause austauschen. Abbildung 4 zeigt das Ergebnis der Abfrage.

Abbildung 4: Ergebnis der SQL-Abfrage

Nachdem der Quellcode des Process Templates nun unter vollständiger Kontrolle der Quellcodeverwaltung ist und das Process Template auch noch ein paar Versionsinformationen erhalten hat, kann man den nächsten Schritt in der Weiterentwicklung erschließen: Branch-Struktur der Process Templates.

Die Tatsache, dass der Source Code durch die vorher beschriebenen Schritte sowieso im Source Control des TFS verfügbar ist, kann nun noch durch Verwendung von Branches ausgenutzt werden. Das Elternelement eines Branch-Baums ist dabei stets das vom Hersteller ausgelieferte Process Template. In dem Beispiel des Scrum Templates von Microsoft ist Microsoft Visual Studio Scrum 2.2 also das Wurzelelement eines Branch-Baums (siehe Abbildung 5).

Abbildung 5: Branch-Hierarchie

In dem in der Abbildung dargestellten Beispiel gibt es im Unternehmen zwei verschiedene Business Units, die für die Entwicklung verschiedener Produktlinien verantwortlich sind. Dabei verwenden sie unterschiedliche Prozesse, was den Einsatz verschiedener Process Templates im TFS nach sich zieht. Die Entwicklung der beiden Produktlinien B.I und B.II ist bzgl. der Zustände der einzelnen Work Items jedoch gleich. Sie unterscheiden sich nur auf Feldebene der einzelnen Work Item Typen. Deshalb ist es sinnvoll, für diese Process Templates noch einmal einen gemeinsamen Knoten in der Branch-Hierarchie abzubilden, hier: Business Unit B.

In der Praxis hat sich gezeigt, dass es nur schwer möglich ist, Anpassungen, die innerhalb eines Process Templates entstanden sind, z.B. bei Product Line B.II, durch Reverse Integration auf andere Zweige zu verteilen. Jedoch dokumentiert die Branch-Struktur hervorragend die Entstehung sowie die Beziehungen der einzelnen Anpassungen. Außerdem kann man Änderungen allgemeiner Art relativ gut durch Forward Integration verteilen.

Hierbei ist es wie in der Softwareentwicklung entscheidend, dass die Branch-Hierarchie sorgfältig definiert wurde. In dem Beispiel aus Abbildung 5 ist es durchaus denkbar, zwischen dem Wurzelknoten und den beiden Business Units noch einen gemeinsamen Zwischenknoten einzufügen, um Änderungen, die für alle Templates zutreffen, an einer Stelle implementieren zu können. Ein Beispiel dafür kann ein Feld sein, welches in einem bestimmten Work Item Type (z.B. Task) in allen Templates vorhanden sein soll.

Wenn man diese Forward Integration zum Verteilen von Neuerungen weiter durchdenkt, kommt man noch zu einem weiteren Knackpunkt: die Formatierung des XML-Codes. Wenn man Process Template Anpassungen im großen Stil macht, kann es sinnvoll sein, sich auf bestimmte Richtlinien zur XML-Formatierung zu einigen, um Vergleichs- und Merge-Operationen zu vereinfachen oder überhaupt erst sinnvoll zu ermöglichen.

Deutlich wird dies durch folgendes Beispiel: Einem Work Item Type (z.B. Product Backlog Item des Scrum Templates) soll ein neues Feld hinzugefügt werden. Dafür sind mindestens zwei Stellen zu bearbeiten. Zunächst muss das neue Feld innerhalb des XML-Tags Fields bekannt gemacht werden. Hier kommt die erste Herausforderung, denn an welcher Stelle innerhalb der genannten XML-Sektion die Felddefinition eingefügt wird, ist aus Sicht des TFS irrelevant. Jedoch ist es für einen Vergleich zweier Dateien unabdingbar, dass man sich auf eine einheitliche Vorgehensweise geeinigt hat. Dies könnte z.B. so aussehen, dass neue Felder stets unten in dem Bereich Fields in alphabetischer Reihenfolge angefügt werden. Eine Alternative ist, die Felddefinitionen so zu sortieren, dass sie mit der Reihenfolge der Elemente an der Oberfläche übereinstimmen.

Die zweite Schwierigkeit in diesem Umfeld ist, dass die XML-Formatierung einheitlich ist. Darunter fallen Punkte wie “Tabulator oder Leerzeichen zum Einrücken” oder die Verwendung von Kommentaren. Auch hier wird die Weiterentwicklung durch eine Vereinheitlichung erleichert.

Wie den vorherigen Erläuterungen zu entnehmen ist, entpuppt sich die nachhaltige Pflege und Weiterentwicklung von Prozess Templates als etwas komplexer als man vielleicht auf den ersten Blick meint. Deshalb ist es umso wichtiger auch die Änderungswünsche der Nutzer kritisch zu hinterfragen und wie in anderen Projekten ein sorgfältiges Requirements Management zu leben. Eine Möglichkeit, die Process Tempaltes stabiler zu halten, ist die Verwendung der Tags, die seit dem Update 2 (TFS 2012.2) zur Verfügung stehen. Damit kann die Anzahl der Änderungen deutlich reduziert werden. Denn alle Anfragen nach weiteren Feldern, um zusätzliche Metainformationen zu speichern, um dann beispielsweise nach weiteren Kriterien auszuwerten, können nun von den Benutzern selbst gelöst werden.

Fazit

Process Template Customization ist sehr ähnlich zu einem Softwareentwicklungsprojekt. Es gilt zunächst, die Anforderungen gründlich zu sondieren. Darüber hinaus müssen gewisse Qualitätskriterien eingehalten werden. Anpassungen des Process Templates müssen auch getestet werden. Schließlich müssen Versionen oder Releases definiert werden, die geordnet veröffentlicht und installiert werden.

Wartung und Versionierung von Process Templates is a post from: AIT Blog

Arbeiten im Team

In den bisherigen Versionen vom Team Foundation Server wurden über Work Item Areas und Iterations nur funktionale und zeitliche Aspekte abgebildet. Mit der 2012er Version vom Team Foundation Server rücken die Organisationsstrukturen im Unternehmen mehr in den Fokus. Neben funktionalen Aspekten müssen nun auch organisatorische Aspekte abgebildet werden.

Hierzu sollte die Verwendung der Work Item Areas angepasst werden, um die Arbeit in Teams zu vereinfachen. Der Wurzelknoten für die Work Item Areas entspricht der Firma und bildet die höchste organisatorische Einheit. Unterhalb des Wurzelknotens werden Unterknoten für jede Organisationseinheit bzw. Produktgruppe ein Team angelegt. Unterhalb von jedem dieser Teams  können weitere Teams für Untereinheiten bzw. Teilprodukte eingefügt werden. Hierüber werden die organisatorischen Aspekte abgebildet. Unterhalb der Teams erfolgt eine weitere Untergliederung im Bezug auf die funktionalen Aspekte der Produkte. Hierzu werden weitere Unterknoten für jeden Funktionsbereich angelegt. Die Unterteilung bzgl. der fachspezifischen Aspekte sollte hierbei für alle Teams einer Gruppe idealerweise gleich sein.

Am Beispiel der AIT Netfactory lässt sich dies wie folgt umsetzen: Unter dem Firmennamen als Wurzelknoten (AIT) befinden sich die Unterknoten für die Produkt Teams (Netfactory Team, Dependency Management Team etc.). In Abbildung 1 ist hier nur die Unterstruktur für das Netfactory Team dargestellt. Produktübergreifende Teams – wie zum Beispiel ein Plattform Team – sind auf der gleichen Ebene wie die Produkt Teams anzulegen. Das Netfactory Team unterteilt sich in zwei weitere Unterteams für das Front- und Backend (Netfactory Backend Team und Netfactory Frontend Team). Innerhalb der Teams werden für die funktionalen Bereiche Alarming, Database, Reporting, Application Framework und Trending nochmals Unterknoten angelegt.

Abbildung 1 – Produkt- und Team-spezifische Work Item Areas

Über die Work Item Iterations erfolgt klassischer Weise eine zeitliche Unterteilung und die Abbildung von Iterationen bzw. Sprints. Bei der Arbeit mit Teams und agilen Planungstools ändern sich hier zwei Aspekte: Die zeitliche Dimension eines Sprints wird mit dem TFS 2012 nun über ein Start- und Enddatum spezifiziert und zusätzlich zu den zeitbezogenen Iterationen wird eine Backlog Iteration angelegt, in der die noch nicht geplanten Anforderungen gehalten werde.

Am Beispiel der AIT Netfactory ergibt sich die folgende Work Item Iteration Struktur: Zusätzlich zum Backlog gibt es eine Release 1.0 und Release 2.0 Iteration. Für das Release 1.0 erfolgt eine weitere Unterteilung in Sprint 1, Sprint 2 und Sprint 3, mit definierten Zyklen, die in Form von Start- und Enddatum dargestellt werden (Siehe Abbildung 2).

Abbildung 2 – Work Item Iterationen

Im Anschluss werden nach dem Anlegen der Teams für jedes Team die nach ihm benannten Work Item Area Knoten inkl. aller Unterknoten zugewiesen, die für das Team gültigen Sprints inkl. des Team Backlogs definiert und die Mitglieder dem Team zugeteilt.

Für das Team Netfactory Team ist dies die Work Item Area Netfactory Team inkl. aller Unterknoten und die Iteration Release 1.0 als Backlog Iteration mit den Sprints 1 bis 3 für die agile Planung.

Agiles Arbeiten mit den Planungstools

Beim agilen Arbeiten werden die Vorteile einer nach organisatorischen, funktionalen und zeitlichen Kriterien definierten und über Teams abgebildeten Struktur deutlich: (Entwickler-)Teams wird über das Taskboard die fokussierte Sicht auf ihre Aufgaben ermöglicht (siehe Abbildung 3 und 4). Gleichzeitig haben Projektmanager die Möglichkeit die aktuellen und zukünftigen Sprints teamübergreifend für ein Produkt zu planen und im Daily Stand-up den Status aller (Entwickler-)Teams über das Taskboard  darzustellen (siehe Abbildung 5).

Abbildung 3 – Taskboard des Netfactory Frontend Teams

Abbildung 4 – Taskboard des Netfactory Backend Teams

Abbildung 5 – Übergreifende Sicht auf alle Tasks im Netfactory Team während des Daily Stand-up Meetings

Fazit

Mit einer auf die organisatorischen Bedürfnisse eines Unternehmens angepassten Work Item Area und Iteration Struktur können mit dem Team Foundation Server sowohl für das Management eine allgemeine Übersicht zur Planung und zum aktuellen Ist-Zustand als auch für die Entwicklungsteams fokussierte Sichten auf die zu erledigenden Aufgaben zur Verfügung gestellt werden.

Agiles Arbeiten im Team is a post from: AIT Blog

Die neue Version des AIT Dependency Managers umfasst die folgenden Features:

• Visual Studio 2012 Integration und TFS 2012 Build-Integration
• Visual Editor Unterstützung für alle Abhängigkeiten
• Definition von komprimierten Abhängigkeiten

Die neue Version finden Sie auf unserer Homepage und auf der Visual Studio Gallery: Jetzt herunterladen.

Sollten Sie Anregungen, Änderungswünsche oder Bedarf für eigene Anpassungen haben, nehmen Sie bitte mit uns Kontakt auf: info@aitgmbh.de

Neue Version: Dependency Manager v2.0 für TFS 2012 is a post from: AIT Blog

Auf der Seite des Team Foundation Servers stehen damit auch endlich die Tags zur Verfügung, mit deren Hilfe man auf einfache Art zusätzliche Informationen an Work Items speichern kann, ohne deren Definition verändern zu müssen. Die Nutzer von Team Foundation Service, der Cloud-Variante des TFS, kennen dies bereits. Neben den Verbesserungen im Planungsbereich sind auch einige Fortschritte in verschiedenen Teilen der Entwicklung selbst zu sehen, z.B. die Unit Test Unterstützung im Windows Phone Umfeld ohne den Einsatz von 3rd Party Tools.

Die ausführliche Liste der Änderungen ist auf der offiziellen Microsoft Webseite Description of Visual Studio 2012 Update 2 zu finden. Eine etwas illustriertere Übersicht neuer Features hat Brian Harry in seinem Blog bereits am 30. Januar bei der Ankündigung des Updates veröffentlicht. Die Downloads stehen unter nachfolgenden Adressen zur Verfügung:

• Visual Studio 2012 Update 2
• Visual Studio Team Foundation Server 2012 with Update 2

Visual Studio und TFS 2012 Update 2 verfügbar is a post from: AIT Blog

"Seit Scott Guthrie das Ruder übernommen hat, erfahren nicht nur die Entwicklerwerkzeuge für Windows Azure kontinuierlich Verbesserungen. Auch neue Features der Plattform selbst scheinen in letzter Zeit in immer kürzeren Abständen angekündigt zu werden. Die Windows Azure Mobile Services als eine der jüngsten Neuerungen erleichtern die Entwicklung von Cloud-basierten Backends beispielsweise für Windows 8 Apps."

Der Artikel gibt eine praktische Einführung in die Azure Mobile Services und zeigt an Hand eines Beispiels die Möglichkeiten und Chancen auf

http://www.dotnetpro.de/articles/onlinearticle4434.aspx

Viel Spaß beim Lesen!

Artikel: dotnetpro 04/2013 – Nicht nur mobil is a post from: AIT Blog

Implementing TFS: Lessons Learned at Siemens Healthcare

Video: Thomas Dasch (Siemens Healthcare) und Thomas Rümmler (AIT) auf dem ALM Summit 3

ALM Summit Videos online is a post from: AIT Blog

Cloud Computing hat die Anforderungen an die Architektur von Anwendungen verändert. Themen wie Rechenleistung, Datenbankspeicher oder Netzwerkkapazität konnten bei der Entwicklung von verteilten Intranet Anwendungen bisher vernachlässigt werden. Durch die im Cloud-Computing gängigen Abrechnungsmodelle rücken diese Aspekte plötzlich in den Fokus. Wer bei den Ressourcen aus dem Vollen schöpft, wird leicht mit einer unangenehmen Rechnung überrascht.

Besonders schwierig ist die Kalkulation der Kosten für den Datentransfer. Während man die Anzahl der virtuellen Maschinen Instanzen und den verbrauchten Datenbank Speicher noch leicht überblicken kann, ist das Datenvolumen stark vom Verhalten der Nutzer sowie den Client Anwendungen abhängig.

Kosten im Bereich Cloud Computing stehen synonym für Ressourcen. Eine Anwendung die verschwenderisch mit Ressourcen umgeht erzeugt hohe Kosten. Zu beachten ist weiterhin das nicht alle Ressourcen im Cloud Computing unendlich sind. Dies trifft z. B. auf den Datentransfer zu. Insbesondere im mobilen Umfeld ist die zur Verfügung stehende Bandbreite oft beschränkt und die Latenzzeiten sehr hoch. Damit ist im Umkehrschluss eine Anwendung die sparsam mit Ressourcen umgeht nicht nur kostengünstiger, sondern auch schneller.

Grund genug um sich einmal intensiver mit dem Thema Datentransfer zu beschäftigen.

Viel Spaß beim Lesen!

http://www.dotnetpro.de/articles/onlinearticle4432.aspx

Artikel: dotnetpro 04/2013 – Die Menge macht’s is a post from: AIT Blog

Für wen diese Lösung geeignet ist…

Wem die gezeigten eigenen Lösungen mit TFS nicht ausreichen, der muss auf Drittanbieter wechseln. Damit entstehen zum einen Lizenzkosten, da es sich nicht um kostenfreie Lösungen handelt. Zum anderen arbeiten diese Tools mit eigenen Datenbanken die zusätzliche zu den TFS-Datenbanken Informationen zu Zeiten und Aufwänden erfassen.

Die gezeigten Lösungen ermöglichen im Gegensatz zu den reinen TFS-Lösungen aus Teil 1 und 2 folgende Funktionen:

1. Zentraler Pool – Zentrale Ressourcen- und Urlaubsplanung
2. Approval Workflow – Freigabe von Zeiten durch Projektleiter
3. (tw.) Integration – Einbindung von Nicht-TFS-Nutzern und Zeiterfassung für Aufgaben, die nicht im TFS erfasst werden

Die hier gezeigten Tools sind mögliche Optionen – es sind nicht unsere Empfehlungen, die folgende Nachteile unserer Meinung nach überwiegen:

1. Komplexität der Installation und Verwendung
2. Abhängigkeit zu weiterem Hersteller
3. Unabsehbare Folgen beim nächsten Versionswechsel von Team Foundation Server

TX-Chrono – Team Expand

Die Zeiterfassungslösung TX-Chrono von Team Expand ist speziell auf den TFS zugeschnitten und existiert seit 2010. Es ist eine rein webbasierte Ergänzung von TFS und deckt nur die Zeiterfassung und zentrale Urlaubsverwaltung ab. Eine Integration zu anderen Systemen (z.B. zur unternehmensweiten Zeiterfassung) ist nicht vorgesehen. Weitere Informationen erhalten Sie auf der Herstellerseite.

TeamPulse – Telerik

Telerik hat mit TeamPulse ein eigenen Projektplanungswerkzeug am Markt etabliert, welches auch eine Schnittstelle zu TFS hat. Es kann aber auch eigenständig verwendet werden. Eine Komponente von TeamPulse ist das Timesheet, welches zur Zeiterfassung dient. Die Lösung ist umfangreicher als das TX-Chrono, da in TeamPulse auch andere Funktionen angeboten werden.

Project Server – Microsoft Office

Die umfangreichste Lösung ist der Einsatz von Project Server, welches mit TFS verbunden werden kann. Der Ansatz verlangt allerdings der Administration und den Nutzern viel ab und kommt sicher nur für größere Teams oder Teams mit gefestigten Prozessen in Frage. Sprechen Sie uns an, wenn Sie mehr zur Project Server Kopplung erfahren wollen: Sven.Hubert@aitgmbh.de

Fazit

Wir können wie bereits beschrieben keine der hier gezeigten Lösungen uneingeschränkt empfehlen. Eine eigene Lösung ist für unsere Projekte bisher die erste Wahl. Sie müssen entscheiden, welche Lösung die bessere für Ihren Anwendungsfall ist bzw. am besten in Ihre Systemumgebung passt. Gerne unterstützen wir Sie dabei!

Wir sind jedoch allgemein gesprochen der Meinung, dass in jedem Fall eine separate Zeiterfassung notwendig ist, da nicht alle Mitarbeiter im Unternehmen einen Zugang zu TFS haben. Daher gleichen wir diese beiden Systeme durch manuelles Controlling ab. Der TFS dient vornehmlich zur Fortschrittsüberwachung…

Zeiterfassung mit Team Foundation Server Teil 3/3 – Mit Drittanbieterwerkzeugen is a post from: AIT Blog

Entwicklungsrichtlinien werden sehr häufig als Ballast empfunden. Sie fristen als dicker, eingestaubter Stapel Papier ihr Dasein im Regal und werden immer dann herausgezogen, wenn ein neuer Kollege in der Tür steht. Gelebte, von allen Beteiligten akzeptierte Vereinbarungen können die Arbeit ihm Team durchaus erleichtern. Wie müsste ein solcher Regelsatz aussehen? Reduziert auf das Wesentliche – auf maximal ein Blatt Papier!

Viel Spaß beim Lesen!

http://www.dotnetpro.de/articles/onlinearticle4409.aspx

Artikel:dotnetpro 03/2013–Spickzettel für Entwickler is a post from: AIT Blog