Vielen Dank!

Hier ein paar Eindrück der ersten und letzten Minute vom 16.02.2010 in Köln:

Einstimmung in der Cafeteria

“Biologen werden mich böse angucken, wenn ich den Bug mit Käfer übersetze”

Die Sprecher Sven Hubert (li.) und Matthias Zieger (re.) vor interessiertem Publikum

Vielen Dank auch an die Personen im “Hintergrund” die für Organisation und Fragen zur Verfügung standen:

Anja Korn (Microsoft), Nadine Fuchsmann (Microsoft), Daniel Rißmann (AIT AG), Dr. Roland Schmitsdorf (Microsoft), Holger Brück (Microsoft)

Die Folien des Vortrags werden den Teilnehmern umgehend zur Verfügung gestellt.

Sie konnten nicht teilnehmen? Macht nichts. Das nächste Event kommt bestimmt. Mehr Informationen…

A significant amount of project effort, especially at customers doing mainly product development, goes into migrating and optimizing build processes. Build processes exhibit 3 important aspects, which due to their criticality and benefits legitimate project costs:

1. Build processes are implicitly business critical – only a working build process results in deliverable products.
2. Heterogeneous build processes imply high – mostly hidden maintenance efforts without directly visible benefits. Small changes in “the scripts” are long lasting and expensive tasks which can be done by high qualified resources only.
3. Build processes often require manual steps, which can be automated with modern platform. Which saves costs!

This article introduces the new free AIT Build Suite 2010. With which complex build processes can be configured easily using centralized builds with Microsoft Visual Studio Team Foundation Server 2010.

Release Management

An important part of the Build Suite is release management. The standard process associates code changes (Changesets) and tasks (Work Items) using the build status. All changes that happened on a specific branch since the last successful build will be associated with the current one (see figure 1).

Figure 1 – Build association of Changesets and Work Items

But that’s not sufficient. Figure 1 shows the changed behavior using the AIT Build Suite 2010. It additionally instruments the build quality (see figure 2) to generate change lists. With this functionality, all changes back to a released product version can be tracked easily.

Figure 2 – Build summary

Versioning

During the creation of product versions it is important to integrate versioning information into the product itself. With the first call of a customer caused by questions or issues, versioning information about the product must be easily accessible for end-users. .NET framework provides options to keep the version number and other details inside an assembly and to show those inside an about box.

AIT Build Suite provides an easy way to integrate this task into the build process and includes an example of how to show these information in your application (see figure 3).

Figure 3 – Assembly information are shown in an about dialog (sample: WordToTFS)

Upgrade

With Team Foundation Server 2008 build processes have been executed using a central MSBuild script deployed with Team Explorer or Team Build components. With the new version 2010 Workflow Foundation is used instead. Still, at the core of compilation, MSBuild is used (new version 4.0). Existing build scripts cannot be integrated out-of-the-box with 2010. The Microsoft UpgradeTemplate ought to provide an easy to integrate experience. But even for basic customized scripts it is not sufficient. Despite the core compile targets, none of the customizable extension targets like AfterGet or BeforeCompile are instrumented. That’s why, AIT delivers a generic Template with Build Suite 2010 which provides MSBuild extension points. This accelerates the migration of build to TFS 2010 dramatically.

Code Documentation

Customers of AIT use our Sandcastle integration for Team Build 2008. Sandcastle projects can be used to automatically generate code documentation. This can be integrated into the central build as well. The new AIT Build Suite 2010 provides parameterized activities for Sandcastle as well.

Summary

With AIT Build Suite 2010 you can bring your build processes towards company-wide processes which respect the specific needs of teams. Download your copy of our Build Suite 2010 for free from our Tools & Downloads Area. After a short registration, you have access to all the tools of AIT TeamSystemPro Team – such as WordToTFS – a Work Item integration with Microsoft Office Word 2007.

In unseren Projekten, vor allem bei Kunden mit Schwerpunkt auf Produktentwicklungen ist ein wesentlicher Teil der Arbeit die Migration und Optimierung von Buildprozessen. Buildprozesse besitzen 3 wesentlich Eigenschaften, die aufgrund des Nutzens die anfallenden Kosten rechtfertigen:

1. Buildprozesse sind implizit geschäftskritische Prozesse – nur ein                   funktionierender Build resultiert in einem auslieferbaren Produkt.
2. Stark heterogene Buildprozesse erforden einen hohen – meist versteckten Wartungsaufwand ohne direkten Nutzen. Kleine Änderungen an “den Skripten” dauern lange und involvieren zu viele qualifizierte Ressourcen.
3. Buildprozesse erfordern häufig manuelle Schritte, die sich aber mit modernen Tools automatisieren lassen. Das spart Kosten!

Dieser Beitrag stellt die neue, kostenlose Build Suite 2010 der AIT vor. Damit lassen sich komplexe Buildprozesse auf Basis des Microsoft Visual Studio Team Foundation Server 2010 einfach und parametrisierbar umsetzen.

Release Management

Ein wesentlicher Bestandteil der Build Suite ist das Release Management. Im Standardbuildprozess erfolgt die Assoziierung von Codeänderungen (Changesets) und Arbeitsaufgaben (Work Items) anhand des Buildstatus. So werden zu einem Build alle Änderungen zugewiesen, die seit dem letzten erfolgreich kompilierten Build in den Branch eingeflossen sind (siehe Abbildung 1).

Abbildung 1 – Buildassoziation von Changesets und Work Items

Das reicht aber nicht aus. Abbildung 1 zeigt das veränderte Verhalten unter Einsatz der AIT Build Suite 2010. Dabei lässt sich zusätzlich die Buildqualität (siehe Abbildung 2) nutzen, um die Änderungsverfolgung zu gewährleisten. So lassen sich also Änderungen zwischen der aktuellen und zuletzt ausgelieferten Version tracken.

Abbildung 2 – Buildbericht

Versionierung

Bei der Erstellung einer Produktversion ist es wichtig auch die Versionsnummer entsprechend im Produkt nachvollziehbar zu integieren. Spätestens bei einem Anruf des Kunden aufgrund von Fragen oder gar Problemen zum und mit dem Produkt muss die Versionsinformation schnell greifbar sein. Dazu bietet zum einen die .NET-Plattform über die Assembly-Information Möglichkeiten, zum anderen ist es günstig, die Version auch in einem für den Benutzer zugänglichen About-Dialog anzuzeigen.

Mit der AIT Build Suite ist auch dies möglich. So lässt sich mit wenigen Handgriffen die Buildversion in den Assemblies hinterlegen.

Abbildung 3 – Die in den Assembly-Informationen hinterlegten Versionsinformationen werden im About-Dialog dargestellt (Beispiel: WordToTFS)

Upgrade

Im Team Foundation Servers 2008 wurden die Buildprozesse noch zentral über MSBuild abgearbeitet. Mit der neuen Version 2010 findet ein Paradigmenwechsel hin zur Workflow Foundation statt. Im Kern wird für die Kompilierung aber weiterhin MSBuild (in der neuen Version 4.0) verwendet. Die bestehenden Buildskripte des TFS 2008 lassen sich nicht Out-of-the-box mit 2010 verwenden. Ein von Microsoft mitgeliefertes UpgradeTemplate soll die einfache Integration ermöglichen. Bei genauerem Hinsehen reicht dies aber nicht aus. Lediglich der zentrale Kompilierungsvorgang wird ausgeführt, alle angepassten Targets, die vor und nach der Kompilierung wesentliche Aufgaben erfüllen werden nicht mehr instrumentiert. Abhilfe schafft auch hier die AIT Build Suite 2010. Das mitgelieferte Template enthält die von 2008 gewohnten Erweiterungspunkte wie z.B. AfterGet, BeforeCompile usw.. Dies ermöglicht einen reibungsloseren Übergang auf TFS 2010 im Buildbereich.

Code-Dokumentation

Unsere Kunden sind seit den AIT Build Tasks 2008 gewohnt, dass auch Ihre Sandcastle-Projekte für die automatische Erstellung von Code-Dokumentation mit in den zentralen Build eingebunden werden können. Auch hier haben wir nachgelegt und bieten diese Funktion auch in der AIT Build Suite 2010 an.

Fazit

Die AIT Build Suite 2010 bringt Sie elegant einen Schritt in Richtung unternehmensweit einheitlicher Buildprozesse, die dennoch die team-spezifischen Eigenheiten der Projekte respektiert. Laden Sie noch heute Ihre Version der Build Suite 2010 kostenlos von unserer Tools & Downloadsseite. Nach kurzer Anmeldung haben Sie zudem Zugriff auf weitere Tools des AIT TeamSystemPro Team – wie z.B. der Work-Item-Integration in Microsoft Office Word 2007.

Wenn dies in mehreren 100 Projekten geändert werden muss, ist das nicht mehr benutzerfreundlich. Abhilfe schaffen gemeinsame Property Sheets, die sogenannten .props-Dateien…

Property Sheets (siehe MSDN) dienen der zentralen Definition von Projekteigenschaften, die ich über den oben dargestellten Dialog im Visual Studio ändern kann.

Property Sheets lassen sich komfortabel über den Property Manager einrichten. Dieser findet sich im View-Menü unter Other Windows:

Im Beispiel gehen wir von folgender Win32-Solution aus:

Im Property Manager kann für ein Projekt eine neue props-Datei angelegt werden:

Wir benennen die Datei als “CommonProperties.props”. Im Anschluss ist für alle Projekte ein Knoten Common Properties verfügbar:

Durch Doppelklick öffnet sich der gewohnte Properties-Dialog, welcher nun jedoch die Eigenschaften für alle Projekte überschreibt.

Fazit

Mit den Property Sheets lassen sich Projekteinstellungen zentral verwalten. Zudem besteht die Möglichkeit diese z.B. im zentralen Build umzustellen, um andere Ordnerstrukturen zu unterstützen.

Der Inhalt erstreckt sich über die wesentlichen Aspekte bei der Anforderungsverwaltung und bezieht sich auf die spezifischen Funktionen des Team Foundation Servers in der neuesten Version 2010. Hier ein Auszug aus dem Inhaltsverzeichnis:

1. Introduction: RM Rangers Guide to the Complete Guide –> Start Here
2. Requirements Management Planning
3. Requirements Traceability
4. Analysis and Breakdown
5. Requirements Elicitation
6. Requirements Specification
7. Requirements Validation
8. Requirements Change Management and Approval
9. Requirements Management checklist sheet

Weitere Konzepte zum Anforderungs-Management wie z.B. das Testen werden wir zudem in unserer Testing-Roadshow besprechen. Melden Sie sich an und reden Sie mit! Fragen Sie uns nach dem Promocode und sparen Sie sich die Anmeldegebühren!

Im Rahmen von Visual Studio 2010 bringt Microsoft im März 2010 unter dem Namen umfangreiche neue Werkzeuge speziell für die Qualitätssicherung und für nicht-technische Tester auf den Markt, die erstmals eine reibungsfreie Zusammenarbeit zwischen Testern und Entwicklern ermöglichen, und beispielsweise das häufige Problem nicht nachvollziehbarer Fehler beseitigen (die so genannten „No Repro Bugs“). Das komfortable Einrichten, Verwalten und Auswerten von virtuellen Testumgebungen wird durch leistungsfähige Systemmanagement-Werkzeuge mit Visual Studio 2010 einfacher und komfortabler als je zuvor.

Die Qualitätsroadshow dauert einen halben Tag und richtet sich an Verantwortliche aus der Qualitätssicherung, Softwaretester, Projektleiter und Entwickler. In drei Vortragsblöcken gefolgt von einer offenen Diskussionsrunde stellen Ihnen die Softwareentwicklungsprofis von Microsoft und AIT auf dieser Roadshow einen optimalen Ansatz zur Verbesserung der Produktqualität mittels eines durchgängigen Testprozess vor. Während der interaktiven Veranstaltung bleibt außerdem viel Zeit für Ihre Fragen und angeregte Diskussionen mit den Teilnehmern und Referenten.

• Die Teilnehmerzahlen sind begrenzt.
  Melden Sie sich daher gleich hier an. Als AIT-Kunde kontaktieren Sie bitte Ihren AIT TeamSystemPro Ansprechpartner für weitere Informationen. 

Die Folien stehen zum Download bereit:

Nehmen wir ein Minimalbeispiel mit einer User Story und 2 Sub-Tasks:

Eine zunächst unmerkliche Änderung wurde beim Mapping von Work-Item-Feldern auf Project-Felder vorgenommen. In den Standardeinstellungen der MSF-Prozessvorlagen werden aggregierte Zeiten (Completed Work, Remaining Work und Estimate) in sogenannten Summary-Tasks nicht in den TFS zurückgeschrieben.

Das je nach Verwendungszweck und Team Project allerdings umgestellt werden. Hier das entsprechende Mapping-Xml:

Das AIT TeamSystemPro Team ist mit Rudolf Günther, Neno Loje (kürzlich zum Ranger Champion gewählt), Sven Hubert, Thorsten Dralle und Boris Wehrle in zahlreichen Projekten zu  Requirements Management, Branching Guidance, Virtualization Guidance, Integration Platform, Architecture Guidance vertreten.

Die Erkenntnisse lassen wir zudem in unsere Workshops und Projekte einfließen, so dass Sie von uns immer zu den aktuellsten Themen und Features beraten werden können. Profitieren Sie insbesondere in unseren Seminaren und Trainings, wie z.B. dem TeamSystemCamp kurz vor Weihnachten.

Although the scrum template for Team Foundation Server is a good way to organise your work, a lot of teams often miss a way to visualize the sprint backlog.

A sprint backlog should be easy to change and administer. A team-member, scrum-master or project stakeholder should be able to check the status of the sprint easily. A flat list of items may not be an ideal solution for this demand.

There are some tools available to visualize backlog, among one of them is the Scrumdashboard which is presented in this post.

The Scrumdashboard solves a lot of problems which a team faces to administer a scrum-project. The tasks can be assigned by simply dragging them to the correct column (e.g. dragging a task from “Not Done” to “In Progress” automatically changes the state of the task to “In Progress” and assignes it to the yourself.)

In the upper part of the screen, the “basic controls” are shown. You can choose your project and sprint. The choices which are available to you depend on the same rights as all the Team Foundation Server projects.

After choosing a sprint and pressing “load”, you automatically see the sprint-burndown, the sprint-goal and the sprint backlog in the low-part of the screen.

All the sprint backlog items are shown by product backlog item. You immediately can see in which state all the sprint backlog items are. (in this case, most items are in the state “ready for test”, and some are “done”.)

This tool is really valuable because it gives you a good overview of a project in 5 seconds. All the important information is compressed in one screen.

This tool is also great to give to customers and project stakeholders. The team-explorer will prove to be too “technical”. A project stakeholder only wants to check whether everything is going fine. This screen provides a correct non-biased overview in 5 seconds. Once a project stakeholder understands how to read a sprint-burndown (which is not rocket-science anyway), he will be able to check-out how a team is doing by himself. He will feel “in control” of a project.

This dashboard could prevent surprises during sprint reviews and get constant project-by-in from project stakeholders.

You can download Scrumdashboard for free from Codeplex.

About the Author

Ive Verstappen ist Geschäftsführer und Software Consultant bei der belgischen Firma BIT IT Consultancy.Schwerpunktthemen:  Agile Entwicklungsprozesse (Scrum) Projektmanagement Prozessberatung