|
|
Treffen, Sitzungen, Meetings: immer wieder gerne durchgeführte Veranstaltungen, bei denen Mitarbeiter zusammenkommen und sich über einen gewissen Zeitraum über bestimmte Aspekte ihrer Arbeit austauschen. Und warum sind die jetzt so interessant? Na, weil es allem Anschein nach eine sehr verbreitete Unsitte, ist Meetings mit zu vielen Teilnehmern, uninteressanten Themen, langatmig in die Länge zu ziehen. Und das ist in niemandes Interesse! Deshalb gibt es hier nun
10 Tipps für eine effektive Meetingführung:
- An einem Meeting nehmen ausschließlich Teilnehmer teil, die direkt und unmittelbar in das Theman involviert sind.
* Wer auch sonst?
- Es gibt ein ausführliches Protokoll, anhand sich sonstige Interessenten informieren können.
* Dann gibt es auch kein Argument mehr gegen kleine und überschaubare Teilnehmerzahlen.
- Der Tagesordnungspunkt “Sonstiges” steht an erster Stelle und wird, nachdem er abgehakt ist, nicht mehr aufgenommen.
* “Sonstiges” wird immer für ausschweifendes Palaver missbraucht. Zu Beginn eines Meetings fehlt den meisten noch das Palaverpulver …
- Meetings als “Stehung” veranstalten: Keine Stühle, kein Kaffee, nur Stehtische
* Man ahnt ja garnicht, wie schnell ein Meeting wieder vorbei sein kann …
- In Runden, in denen alle was zu ihrer Arbeit sagen sollen, Konzept festlegen: z.B. was habe ich gestern gemacht, was gedenke ich heute zu tun, welche Probleme sehe ich?
* kommen Sie auf den Punkt und zwingen Sie Ihre Mitarbeiter und Kollegen dazu
- Keine Problemlösungsdiskussionen in Meetings. Problemlösungen werden in Kleinstgruppen mit kompetenten Teilnehmern ausgelagert.
* Das ist effektiver und zielführender.
- Themen werden vorher kommuniziert, Ergänzungen während der Sitzung werden nicht akzeptiert, sondern in Kleinstgruppe ausgelagert.
* Nie wieder ein “Ähh, ich hätte da noch was …!”
- Powerpoint wird strikt limitiert: Jeder Vortrag unter 10 Minuten braucht kein Powerpoint. Ansonsten 5 min / Folien, keine Death-By-Bulletpoint Folien (Grafiken, Übersichten sind ok), kein Ablesen. Verstöße dagegen führen zu Abbruch des Vortrags von Meetingleitung und Bitte um Überarbeitung.
* Dringend zu vermeiden: Death-By-Powerpoint
- Meetings beginnen und enden pünktlich: Wer zu spät kommt, bleibt draußen. Längerdauernde Gespräche werden ausgelagert.
* Ja, auch erwachsene Menschen brauche ein bißchen Erziehung und Führung. Klingt komisch, ist aber so!
- Es gibt Regeln, wie Meetings ablaufen sollen, die von der Meetingsleitung durchgesetzt werden.
* Vielleicht mal ein paar Gedanken machen, was man eigentlich wirklich in son einem Meeting will. Also, vorher.
Was machen Sie, um effektive Meetings sicherzustellen? Ist das alles Unsinn, was ich schreibe?
Ein kurzer Hinweis an alle Leser dieses Blogs: aus aktuellem Anlass werde ich dieses Blog nur noch für technische bzw. berufliche Inhalte nutzen. Fragen, Anregungen und Anmerkungen dazu beantworte ich gerne, allerdings nur per Mail und nicht in den Kommentaren: post at bernhardwilmer Punkt de
Wenn Sie demnächst mal wieder vor der Aufgabe stehen, eine Testdokumentation für einen Softwaretest zu erstellen, und den Hinweis erhalten, sich doch an der ANSI 829 zu orientieren, dann antworten Sie einfach mit einem klaren und entschiedenen Jein! Und warum das so ist und wie man es vielleicht einfacher, besser machen kann, das will ich versuchen mal ein wenig zu beleuchten.
Ja, möchte ich weiterlesen …
Letztens war ich wieder bei einem Kunden eingeladen, Mitarbeiter im Bereich Softwaretest und -qualitätssicherung zu schulen. Über drei Tage sollte der große Rundrumschlag gemacht werden: alle Themen ansprechen, so dass ein guter Überblick gewährleistet ist und die Kollegen befähigt werden, selber weiter zu lernen.
Im Schulungsraum saß dann eine sehr überschaubare Anzahl Teilnehmer und ich stellte die erste Frage: “Warum nehmen denn nicht mehr daran teil, ist doch schließlich quasi schon bezahlt!?” Sinngemäße Antwort: “Nee, die wollen nicht, die kennen das schon alles, sagen sie ….” - Aha, soso! Na, dann!
Und was will uns das sagen? Nun, man erkennt daran, die Einstellung der Menschen zu Test, insbesondere derjenigen, die nichts mit dem Test zu tun haben wollen. Sie unterliegen nämlich den
10 Irrtümer des Softwaretest
Ja, möchte ich weiterlesen …
Es wird immer bunter: Aus berufenem Munde Blog las ich eben, dass es für einen deutschen Beamten garnicht so einfach ist, einfach eine STOP Liste mit Kinderpornoseiten zu verwalten. Denn in dem Moment, in dem der Beamte Kenntnis von Kinderpornos im Internet erhält (und das muss er ja, sonst könnte er die Liste ja garnicht führen), so ist er gesetzlich verpflichtet dem nachzugehen! Ja, möchte ich weiterlesen …
In einer Schulung, an der ich gerade arbeite, geht es u.a. auch darum, wie man (Test-) Werkzeuge richtig in ein Unternehmen, Projekt, Arbeitsgruppe einführt. In meiner Literatur habe ich nichts Zusammenhängendes dazu gefunden und auch das wunderbare Internet hat nichts wirklich Ergiebiges erbracht. So habe ich mich mal hingesetzt und selber nachgedacht (mit Hilfe einiger Fragmente, die dann doch noch zu finden waren). Das Ergebnis werde ich hier mal (zumindest übersichtshalber) beschreiben:
Ja, möchte ich weiterlesen …
Nun also ein weiterer kleiner Text über die Grundlagen der Softwarequalitätssicherung - mal von der Praxisseite aus beleuchtet.
“Ja, wir müssen testen!” ist die schon fast triviale Erkenntnis vieler Softwarehersteller. Und dann? Fange ich mit naivem “Geklicke” an? Oder lerne ich erstmal monatelang etwas über Methoden, Prozesse und Techniken?
Ganz anders: als aller erstes steht die Analyse der eigenen Vorgehensweise, denn ein Test ist immer nur so gut, wie der Reifegrad des Softwareentwicklungsmodelles, das dahinter liegt. Und als weiter wichtiger Punkt ist “persönliche Verantwortung” zu nennen. Was ich damit meine, kommt gleich. Aber eins nach dem anderen.
Wenn bisher Softwareentwicklung “auf Zuruf” betrieben wurde, können von dem Test keine Wunder erwartet werden. Dann ist vielleicht gerade mal ein wenig exploratives Testen möglich, mit sehr dünnem Erkenntnisgewinn.
Ein Prozess, in dem Softwarequalitätssicherung sinnvoll angwendet werden soll, muss ein paar Voraussetzungen erfüllen.
Es gibt einen definierten Softwareentwicklungsprozess - Minimum: Softwareentwicklung findet in Phasen statt
Zu jeder Phase gehört: es wird festgelegt, was entwickelt werden soll, es wird entwickelt und am Ende wird das Ergebnis mit einem “Stempel” versehen. Z.B. einer Version, einer Bezeichnung oder sonst einem eindeutigem Erkennungsmerkmal. Und das ganze in einer vorher festgelegten Zeit. Das ist Minimum!
Das können sie leisten? Prima, dann können wir mit Softwaretesten anfangen.
Wenn sie bereits einen definierten Softwareentwicklungsprozess leben und auch schon irgendwie testen, dann kann es vielleicht sinnvoll sein mal genauer hinzuschauen, wie weit sie mit ihrem Prozess sind und welche Entwicklungsmöglichkeiten sie dann bzgl. des Tests haben. Dazu gibt es eine feine und erschreckend und logische Vorgehensweise namens TPI (Test Process Improvement). Mit Hilfe dieses Modells wird ihr aktueller Testprozess anhand von 20 Kriterien analysiert und mit Hilfe des Ergebnisses eindeutige Anregungen für die Verbesserung des Tests gegeben. (TPI ist eine Entwicklung von sogeti. Unterstützung bekommen sie auch von meinem Arbeitgeber). Bei Gelegenheit mache ich mal einen Artikel zum Thema TPI …
persönliche Verantwortung
In der Praxis begegnet mir immer wieder die Situation, dass QS und Test in einer Firma, Abteilung, Projekt nicht ernst genommen wird. Softwaretest hat keine Lobby. “Ja, muss man ja auch noch machen! Hach, hätte man doch glatt vergessen … tststs!” Das Ergebnis einer solchen Einstellung ist eine unzureichende Qualitätssicherung. Formell wird dann ein vielleicht sogar unternehmensweit vorgeschriebener Testprozess erfüllt, tatsächlich ist das meiste davon Fake.
Meiner Erfahrung nach muss sich in solch einer Situation eine Person persönlich verantwortlich für den Test fühlen und mit seiner ganzen Persönlichkeit in die Bresche springen. Man braucht den Typen, der sich freiwillig die Pappnase aufsetzt und in jeder Besprechung immer und immer den Test-Narren macht. Und dabei hilft es nicht einfach jemanden auszugucken (per Flaschendrehen oder Pinchenziehen), denn der macht den Job nur halbherzig. Am besten scheint mir dann eigentlich ein externer Profi, der es sich leisten kann, losgelöst von den internen Abteilungsbefindlichkeiten zu handeln.
Natürlich ist sowas nicht akzeptabel: aber, hey, irgenwie muss man ja weiterkommen!
Hier mal ein paar Softskills, die solch ein Mensch haben sollte:
- Teamfähigkeit, diplomatisches Geschick
- Kommunikationsfähigkeiten, -geschick
- Kreativität beim Hinterfragen der Gegebenheiten
- Pingeligkeit in der eigenen Arbeit, Durchführung, Dokumentation usw.
- Fähigkeit, sich schnell in fremde Sachverhalte einarbeiten zu können
- Disziplin und strukturierte Arbeitsweise
- Leidensfähigkeit
Also, quasi ein Supermann .
Und jetzt bin ich auf die Kommentare gespannt …
Wer Softwareentwicklung betreibt (aber auch andere) benötigt eine Software, mit deren Hilfe man Fehler erfassen und verwalten kann, einen so genannten Bugtracker. Derer gibt es viele für teures Geld zu kaufen, aber natürlich gibt es auch immer hervorragende Lösungen im Open Source Bereich, z.B. Bugzilla.
Das hat sich auch die Firma Atlassian aus Australien gedacht, diese Software in Java adaptiert und wesentlich verbessert, erweitert und professionalisiert und Jira genannt. Jira ist mittlerweile in der Version 3.1.3 erschienen und hat sich zu einem Issue Tracking System gemausert, also eine Software, mit der man Vorgänge und Angelegenheiten (issue ist aber auch recht schwierig zu übersetzen …) verwalten kann. Und so allgemein wie sich das anhört, ist es auch. Jira passt sich den individuellen Gegebenheiten des Einsatzzweckes an. Man kann es als Helpdesk Software genauso betreiben, wie als Bugtracker oder zur Vorschlagswesenveraltung oder Prozesssteuerung und und und. Das alles geht durch ein ausgeklügeltes Plugin Modell und extreme Flexibilität bei der Einstellung des Workflows.
Diese Software gibt es noch zwei Tage lang für 5$ für eine 5 User Lizenz. Und hier ist der Link.
Was ein Wiki ist sollte mittlerweile auch jedermann wissen. Auch hier findet man hervorragende Open Source Lösungen, wie z.b. das Mediawiki, das als Grundlage für die Wikipedia dient.
Atlassian hat auch diese Software professionalisiert (Plugin-Konzept, User Mangement uvm.), so dass sich das Ergebnis mit dem Namen Confluence als ein Knowledge Management Werkzeug darstellt. Immer wenn es gilt, Wissen aus den köpfen der Mitarbeiter in verwaltbare Form zu bekommen ist Confluence das Mittel der Wahl.
Jep, auch Confluence gibt es für 5$. Anwendung? Nun, die gesamte Atlassian Seite beruht auf Confluence.
Allerdings sollte man sich schnell entscheiden, die ganze Aktion geht nur noch bis zum 24. April!
Wer mehr als 5 User benötigt und überhaupt Unterstützung und Beratung rund um die Atlassian Software kann sich natürlich auch an meinen Arbeitgeber wenden …
Jeder halbwegs begabte Softwareentwickler weiß, dass er mit ein bißchen Kreativität, Nachdenken und Engagement durchaus hochwertige Software erstellen kann. Vielleicht hat dieser Entweckler einen Freund, der mitarbeitet, und schon hat man eine kleine Software erstellt, ein bißchen Aufmerksamkeit (im Internet) erzeugt und ein paar Euro verdient.
Was passiert aber, wenn eine Software nicht mehr einfach auf Zuruf entwickelt werden kann? Weil man komplexe Kundenbeziehungen berücksichtigen muss, Spezial-Know-How braucht oder das Projekt eine Größe von mehreren Mannjahren erreicht? Na, klar das geht nur in einem Team, viel Aufwand, Ressourcen, Zeit und Geld. Ja, klar, das kostet Geld. Insbesondere kosten Mitarbeiter Geld. Ein halbwegs funktionierender IBM kompatibler PC kostet heute nicht mehr als 2000 €, die passende Software dazu noch mal 5000 €. Der Arbeitspaltz (Stuhl, Tisch, Büro, Infrastruktur) ist auch nicht so tragisch. Alles in allem hat man Einmalkosten von nicht mehr als 10.000 €. Das ist in etwa das, was ein qualifizierter Mitarbeiter in zwei bis drei Monaten kostet. Und im nächsten Monat kostet er, und im nächsten, und im übernächsten auch.
Deshalb ist immens wichtig Lohnkosten so niedrig wie möglich zu halten, was zu den unschönen Entwicklungen führt, die wir alle in den letzten Jahren (und vermutlich auch in Zukunft) in der Wirtschaft beobachten. Nun, gut, man kommt nicht darum herum.
Nun schauen wir doch mal, was in den einzelnen Phasen einer Softwareentwicklung passiert, wenn ein Fehler entdeckt wird.
Codeerstellung / Coding
Der Entwickler findet, während er den Code schreibt, einen Fehler. In aller Regel kann er das Problem sofort lösen. Schlimmstenfalls muss er kurz Rücksprache mit der Projektleitung und / oder Kollegen halten.
Das Ändern der Codezeilen dürfte, natürlich je nach Art des Problems, in der Größenordnung von wenigen Minuten liegen.
Integration der Teilsysteme
Die Module und Teile einzelner Entwickler und / oder Teams werden zum Gesamtsystem zusammengestellt. Die Fehler, die in dieser Phase i.d.R. auftauchen beziehen sich auf das Zusammenspiel einzelner Teile (Schnittstellen, Kommunikation, Protokolle usw.)
Was passiert also, wenn ein Problem erkannt wird und eine Komponenten nicht zu den anderen passt: Die Komponenten muss geändert werden, vermutlich recht aufwendig. Das System kann (immer noch nicht) im Zusammenhang arbeiten. Wahrscheinlich müssen Diskussionen über Dokumente geführt werden (ist eigentlich alles richtig beschrieben?) und einige Änderungen vorgenommen werden.
Der Zeitaufwand ist schwer zu schätzen, aber ich tu’ es trotzdem: Klärung der Unstimmigkeiten, Überprüfung der Doku usw. ca. 0,5 Tage, Überarbeitung ca 0,5 Tage. Die Behebung des Problems liegt bei ca einem Tag.
Weil bisher kein nennenswerter Testprozess eingeführt ist und das System soweit ja arbeitet, kann man das Ganze ja mal beim Kunden installieren. Nur mal so im
Testbetrieb (beim Kunden).
Und es kommt, wie es kommen muss: der Kunde findet das seine Geschäftsvorgänge in der Software, zumindest an einer Stelle, nicht richtig abgebildet werden. Natürlich gibt es Gespräche, Abstimmungsbedarf (im besten Fall) oder gerne auch mal Schuldzuweisungen, Drohungen, Zahlungszurückhaltung. Den Schlamassel zu klären dürfte einige ‘Tage dauern.
Ich muss, glaub’ ich, nicht weiter schreiben. Was passiert wohl, wenn ein echtes Problem im Livebetrieb beim Kunden auftaucht. Regressvorderungen, Produktionsausfall, blablabla. Viel Spass, das wieder in den Griff zu bekommen!
Und was soll mir das jetzt sagen?
Tja, ein paar Dinge muss man sich mal vor Augen halten:
1) Ziel ist es nicht, eine fehlerfrei Software abzuliefern (das geht eh nicht. Wer mag kann die Gründe in der einschlägigen Literatur nachlesen), sondern zu wissen, wo man steht.
2) Wie man oben gesehen hat,muss mit sinnvollen QS - Maßnahmen aus wirtschaftlichen Gründen so früh wie möglich begonnen werden.
3) Von einem Problem beim Kunden überrascht zu werden grenzt an eine Katastrophe. Wichtig ist vorher zu klären wie hoch die Wahrscheinlichkeit ist, dass das eintritt und sich entsprechend betriebswirtschaftlich darauf vorzubereiten.
Also: sinnvolle QS - Maßnahmen, so früh wie möglich angesetzt, sparen Geld, vermeiden Chaos und Unstimmigkeiten und führen zu erweiterten, wichtigen Wissen über das eigene Produkt.
Natürlich habe ich nicht alles hier aufgeführt, was man an dieser Stelle schreiben könnte. Aber ich denke, der Kern ist klar geworden und bietet schon mal ein paar gute Argumente.
Noch Fragen?
|
|
