In den Schulen unterrichten sie Latein. Warum kein VBA?

Zugegeben, die Überschrift wirkt auf den ersten Blick provokant. Handelt es sich bei Latein doch um eine Sprache, die als Basis aller romanischen Sprachen mindestens die Einstiegshürde zum Erlernen dieser deutlich erleichtert. Heutige Redewendungen und auch viele Wortbedeutungen lassen sich aus der Kenntnis der Sprache Cäsars genauso ableiten, wie die Tatsache, dass die Rolle des “Kaisers” eben auf den Namen desselben Herrschers zurückzuführen ist. Achja… und für das Jura-Studium sowie das Studium der Medizin benötigt man es auch.

Und VBA? Eine tote Sprache? Genau wie Latein?

Mag sein. Nichts desto trotz haben nicht einmal Office Apps, Visual Studio Tools for Office oder selbst OLE Automation dazu geführt, dass VBA vollends in Vergessenheit geraten ist. Warum auch? Leichtgewichtiger geht es kaum: Der Visual Basic Editor (VBE) ist in die Office Produkte integriert, der Zugang ist extrem leicht, es werden keine zusätzlichen Lizenzen benötigt und sämtliche Belange von Word, Excel und Access lassen sich damit programmieren. Zudem benötigt es keine komplexen Installationssysteme und technisch gesehen auch keine Rollout-Gremien, um zeitnah Problemlösungen innerhalb einer Fachabteilung an den Start zu bekommen (was die IT Abteilung davon hält sei einmal dahingestellt).

Trotzdem. Ein ungutes Gefühl bleibt.

  • Es gibt keine integrierte Quellcodeverwaltung.
  • Unter modernen Gesichtspunkten sind viele Verhaltensweisen zunächst nicht nachvollziehbar.
  • Es gibt zwar Klassen und Interfaces (tatsächlich!), aber keine echte Polymorphie oder Funktionsüberladung.
  • Die Arbeit mehrerer Entwickler an einem Projekt gestaltet sich als sehr aufwändig.
  • Aufgrund der nur eingeschränkten Verwaltungsmöglichkeiten sind komplexe Projekte langfristig nur schlecht wartbar.
  • Die Fehlerbehandlung ist auf den ersten Blick wenig intuitiv.
  • etc.

Stellen wir uns aber der harten Realität: In großen sowie kleinen Unternehmen wird VBA innerhalb von speziell Excel und Access noch immer flächendeckend von den Fachabteilungen eingesetzt. Das Phänomen lässt sich nicht einmal auf bestimmte Branchen einschränken. Und so schnell wird sich das auch nicht ändern.

Daher liegt es in unserer Verantwortung, dafür zu sorgen, dass die Entwicklung (und damit auch unsere Dienstleistung) auch in diesem Kontext einem hohen Anspruch an Qualität gerecht wird. Quellcodeverwaltung, Nachvollziehbarkeit, Testing, Requirements-Engineering & Co sind dabei nur einige Stichworte. Und der Einsatz von VBA ist kein Grund, die modernen Prozesse zur Softwareentwicklung links liegen zu lassen.

Im Gegenteil.

Als Einstieg für die Interessierten hier ein paar Querverweise, die zeigen, dass da auch mehr geht:

In Projekten, in denen auch bei uns dann und wann mal VBA genutzt wird, verwenden wir übrigens selbstverständlich den Team Foundation Server für die Requirements, das Work Item Tracking und auch die Quellcodeverwaltung.

Neugierig? Sprechen Sie uns an!

Stakeholder an die Macht – Projektbeteiligte erhalten kostenlosen Zugriff auf Visual Studio Online

Brian Harry berichtete nach der Early Adopter Phase Anfang Juli bereits davon, dass viele Projektzuordnungen von Mitarbeitern wieder aufgehoben wurden. Der Zusammenhang mit dem Ende der Einführungszeit war offensichtlich: Zuvor war der Zugriff kostenfrei, nun konnten “nur noch” bis zu fünf Nutzer gratis Visual Studio Online nutzen.

Da Microsoft allerdings erhöhten Reibungsverlusten in den Entwicklungsprojekten zuvorkommen möchte, hat Brian angekündigt, mit der Stakeholder Rolle eine neue Lizenz einzuführen, die es einer praktisch unlimitierten Anzahl Projektbeteiligter ermöglichen soll, weiterhin kostenfrei auf den gehosteten Team Foundation Server zuzugreifen und in allen für ihre Arbeit relevanten Belangen zu nutzen.

Assigning a stakeholder license

 

Als Stakeholder können Nutzer nun gegenüber der früheren Work Item Only View folgendes:

  • Die Projekt Homepage betrachten
  • Auf die meisten arbeitsrelevanten Funktionen zugreifen
  • Das Backlog einsehen
  • Einträge hinzufügen und bearbeiten
  • WorkItem-Abfragen erstellen und ausführen
  • Benachrichtigungen abonnieren

Aus unserer Sicht ist Microsoft mit der Einführung der Stakeholder Lizenz in VSO ein ganz großer Wurf gelungen, deren Umsetzung extrem schnell nach der initialen Ankündigung realisiert werden konnte. Dass diese Funktion mit dem kommenden Update sogar in weniger als einem halben Jahr danach On Premise verfügbar sein wird zeigt die enormen Vorteile der neuen Rapid Release Strategie von Microsoft.

Mehr Informationen darüber, welche Funktionen und Möglichkeiten den Projektbeteiligten nun offen stehen, finden sich auf der eigens dazu eingerichteten Landing Page.

#epic. Oder: Ruck, wenn Scrum zu krass ist?

Bei Scrum handelt es sich eine Management Methode, die zumeist in der Softwareentwicklung eine große Hilfe dabei ist, umfangreiche Projekte steuerbar zu machen. Kernpunkte sind dabei u.a. die Leistungsbereitschaft der Teammitglieder und deren Selbstorganisation, die Aufteilung des Projektes in Timeboxes und regelmäßig stattfindende Meetings.

Das klingt zunächst einfach, bedingt aber eine absolute Disziplin, damit das Konzept aufgeht. Marcus Jacob hat dazu auf der letzten Developer Week einen Vortrag gehalten. Thema: Football, Poker, PM oder: Wir führen Scrum ein!*

Während es zuhauf Dokumentationen, Fachbücher, Artikel, Prozess-Templates u.ä. zu Scrum gibt, soll dieser Blogartikel allerdings etwas vorstellen, das kaum jemand kennt, von dem sich aber viel lernen lässt.

Microsoft Ruck

Rucks […] are similar to scrums in that several players are bound together while fighting over the ball. In the case of rucks, however, the ball is literally up for grabs, unlike in the relatively controlled environment of the scrum. Quelle: isport.com

Dieses Zitat von einer Sportseite drückt es bereits treffend aus. So wie Scrum eine Methode zur “kontrollierten” Softwareentwicklung ist und sich für die Namensgebung einer Sportmetapher bedient, entnimmt Microsoft eben jener Sportart – Rugby – einen weiteren Begriff (Ruck), der im Prinzip die gleiche Bedeutung hat, aber weniger Disziplin erfordert.

Bedeutet nun “weniger Disziplin” nun auch weniger Qualität? Oder sogar Fehler? Nein. Ganz im Gegenteil. In diesem Kontext löst dieses Vorgehensmodell typische Probleme, die verteilte Entwickler-Teams haben: Sie entwickeln nicht zur gleichen Zeit, es steht nicht immer jeder Mitarbeiter zur Verfügung, andere Projekte haben eine höhere Priorität… und im Zweifelsfall befinden sich die Entwickler nicht einmal in der gleichen Zeitzone. Die meisten Prinzipien von Scrum müssten in solchen Fällen über Bord geworfen werden.

Im Kontext der sog. ALM Rangers hat Microsoft daher eine eigene Methode entwickelt, die sich zwar an Scrum anlehnt, dabei aber wesentlich mehr Freiheiten ermöglicht und das ganze konsequenterweise Ruck genannt.

Bei den ALM Rangers handelt es sich um eine Gruppe von Enthusiasten, die kontinuierlich Tools, Dokumentationen, virtuelle Labs und dergleichen mehr außerhalb des regulären Entwicklungszyklusses des Team Foundation Servers bereitstellen. Da deren Hauptaufgabe allerdings häufig durch andere Themen bestimmt wird (mitunter zählen sogar Freelancer zu den ALM Rangers), benötigten sie eine Methode, die es ihnen erlaubt trotz der widrigen Umstände eine hohe Qualität abzuliefern.

image

Herausforderungen eines zeitzonen-übergreifenden Teams

Microsofts Lösung

Hier einige Schlüsselfaktoren, die entscheidend mit zu dem Erfolg bei Microsoft in verteilten Teams wie den ALM Rangers beitragen:

  • Sprint-Planungsmeetings finden virtuell und online statt (via Microsoft Lync und Email).
  • Neben Schätzungen, die das Team verantwortet (z.B. via Planning Poker) wird häufig auf die Schätzung desjenigen zurückgegriffen, der die Umsetzung verantwortet.
  • Das Team entscheidet, wann und wie oft “Standup-Meetings" stattfinden (i.d.R. wöchentlich), dabei schicken abwesende Teammitglieder Status-Updates per Email an den Lead / Ruckmaster.
  • Wer am Sprintreview nicht teilnehmen kann, stellt ein kurzes Demo-Video seiner Arbeit bereit.
  • Auch zur Retrospektive können Erkenntnisse per Email eingereicht werden; eine Zusammenfassung der Ergebnisse stellt der Lead in der Ruck Improvement Community allen Teammitgliedern zur Verfügung.

Darüber hinaus ist der Worfklow gegenüber Scrum leicht verändert und es gibt auch weitere Workitem Typen (wie z.B. sog. Epics, die über einem Feature stehen und ein Thema auf übergeordneter Ebene betrachten).

Da das Thema in Summe allerdings zu umfangreich ist, um es in Gänze in einem Blogartikel zu betrachten, sei an dieser Stelle auf das Material verwiesen, das Microsoft kostenlos zum Download zur Verfügung stellt.

Über die Landing Page “Supporting Guidance and Whitepapers” gibt es weiterführende Informationen und Materialien, die einem helfen in Bild, Ton und Text den Ruck Prozess und die virtuellen Personas zu verstehen und bekommt ergänzend dazu Whitepaper, Sample Solutions, Hands on Labs und dergleichen mehr, um sich auch praktisch mit dem Thema auseinandersetzen zu können.

Fazit

Wer sich mit seinem Team den Herausforderungen moderner Softwareentwicklung stellen will und feststellen muss, dass Methoden wie Scrum im spezifischen Fall nicht funktionieren können, der findet im Ruck Prozess eventuell die Lösung. Es lohnt sich aber in jedem Fall, einen Blick in das Material zu werfen, da auch unabhängig davon einige wirklich interessante Konzepte vermittelt werden (wie z.B. das der Personas). Da es sich dabei um Anwendungsfälle aus der gelebten Praxis handelt, fällt die Adaption umso leichter.

*Im Übrigen ist niemandem aufgefallen, dass das Wort Scrum seine Herkunft im Rugby hat und nicht im Football. :)

Pokern auf der DWX14 – Scrum lässt grüßen!

Haben wir das nicht alle schon erlebt? Man sitzt in einer Besprechung mit einem Projektleiter, bekommt grob skizziert was die neue Anwendung können soll und hat dann gefühlte 10 Sekunden Zeit, um eine Aufwandsschätzung abzugeben. Aussagen wie “Das können wir so nicht schätzen, da fehlen noch viel zu viele Informationen!” führen dann gerne zu Reaktionen wie “Ok, dann sagen wir einfach mal 50 Tage!”. Und als wäre das nicht schon verheerend genug, nein, die Aufwandsschätzung wird vom Kunden dann als Festpreis verstanden, ganz unabhängig davon, wie viele zusätzliche Wünsche noch einfließen werden…

Am Ende hat das Projekt dann im besten Fall 100 Tage gedauert, die Timeline wurde 3 mal verschoben und der Absatz an Haarfärbungsmitteln hat wieder ein Stück weit zugenommen, um die neu gewachsenen grauen Haare zu kaschieren. Naja und vielerorts findet man dann eine der unzähligen Varianten folgenden Bildes an den Wänden hängen:

Projektmanagement

 

Aber muss das wirklich so sein? Kann man da nicht etwas dran verbessern? Natürlich! Genau an dieser Stelle setzen agile Entwicklungsmethoden ein, um den Gesamtprozess zu definieren. Natürlich können Aufwände belastbarer geschätzt und Deadlines gehalten werden. Das geht sogar mit viel Spaß an der Sache und einem kontinuierlichem Projektfortschritt, der allen Beteiligten zeigt, wie die Anwendung Stück für Stück wächst. Und genau über dieses “wie” wird die TOP TECHNOLOGIES auf der #dwx14 berichten! In der Session “Football, Poker, PM oder: Wir führen Scrum ein!” werden wir anhand von Scrum zeigen, wie man ein Projekt durchführen und dabei sogar ohne schiefe Blicke zu ernten Pokern kann!

Über die Autoren

Christian Jacob ist Leiter des Geschäftsbereiches Softwarearchitektur und -entwicklung und zieht als Trainer im Kontext der .NET Entwicklung sowie ALM-Themen Projekte auf links.

Marcus Jacob fokussiert sich auf die Entwicklung von Office-Addins sowie Windows Phone Apps und gilt bei uns als der Bezwinger von Windows Installer Xml.

Martin Kratsch engagiert sich für das Thema Projektmanagement mit dem Team Foundation Server und bringt mit seinen Java- und iOS-Kenntnissen Farbe in unser ansonsten von .NET geprägtes Team.

Aktuelle Kommentare

Comment RSS