Archiv der Kategorie ‘Softwareentwicklung‘

 
 

#365 Und noch ein Manifest!

Spätestens seit dem Erscheinen des Agilen Manifests (einer Art Leitbild für agile Software-Entwicklung) ist es zu einer gewissen Inflation an Manifesten gekommen. Und da haben wir auf nichts dringlicher gewartet als auf ein neues agiles Manifest von Kent Beck (ausgegraben von PJMB), der bereits zu den Vätern des ursprünglichen Manifests gehört. Etwas sarkastisch könnte man so ein Manifest als eine ideologische Verkürzung der Welt zu einem Patentrezept bezeichnen. Und so ein Anspruch geht mir zu weit, so gut und so richtig die einzelnen Aussagen für sich auch sein mögen.

#340 V-Modell XT Bund

Das Projektmagazin berichtet, dass die Bundesstelle für Informationstechnik (BIT) den neuen Standard V-Modell XT Bund veröffentlicht hat. Details und Download gibt es bei der BIT.

#327 Was Tester testen sollen

Und noch einmal Pawel Brodzinski, der sich mit einem Beitrag von Jennifer Bedell auf PMStudent zum Thema Testmanagement auseinander setzt: Testen kann auch ausufern, wenn der Scope des Projekts aus dem Auge verloren wird und weit über die ursprünglichen Projektauftrag hinaus getestet wird. Zurecht weist Pawel darafhin, dass die Erfüllung von Spezifikationen mitunter noch wenig über die tatsächliche Qualität des Ergebnisses aussagt. Auch wenn alle Anforderungen erfüllt sind, kann der Patient bereits tot sein. Der Test der Spec stelllt quasi den minimalen Testumfang dar,  aber um die Qualität sicherzustellen braucht es „mündige Tester“, die auch nach rechts und links schauen, aber mit Augenmaß, um nicht einfach den Projektauftrag beliebig zu erweitern und die Kosten aus dem Ruder laufen zu lassen.

#326 Agil? So what!

Pawel Brodzinski bringt es auf den Punkt: Bei aller Methoden-Diskussion – letztlich zählt nur das Ergebnis und dessen Qualität, da sollte es keine Rolle spielen ob das mit agilen oder klassischen Methoden erreicht wurde. Auch die beste Methode ist bei fehlendem Qualitätsbewußtsein unzulänglich. Pfusch bleibt Pfusch!

#316 VisualPM: Poster

In unserem Powerpoint-verseuchten Alltag vergessen wir allzuleicht, dass es auch noch andere Visualisierungsmöglichkeiten gibt, z.B. Poster. Hier ein paar Beispiele:

Die Beispiele sind alle sehr Methoden-lastig, aber Sie vielleicht schon mal daran gedacht Ihr Projekt in Poster-Form darzustellen: Auftrag & Inhalt, Stakeholder, Vorgehensweise, Beteiligte,…

#306 Debriefing im Testmanagement

Sebastian Preuss/ Seibert Media weist in einem lesenswerten Beitrag auf die Bedeutung des Debriefings im Testmanagement hin. Die Tester im User-Test sichern nicht nur die Qualität, wir sollten ihren Einfluss auf das Changemanagement auch nicht vergessen! Ihre Eindrücke und ihr Feedback landen früher oder später bei den Anwendern. Selbst wenn der Test schief lief, können sie bei den Anwendern für Verständnsi und Akzeptanz beitragen.

Mit dem Thema Testmanagement haben wir uns hier auch schon wiederholt auseinander gesetzt:

#195 Testmanagement in IT-Projekten
#187 Umgang mit Testfehlern
#156 Excel Toolset
#153 Your Unit Tests lies to you

#148 Testmanagement in IT-Projekten: Organisation und Ablauf
#145 „Effektives“ Testmanagement
#86 Gute Tester, schlechte Tester

#291 KANBAN

Neuerdings häufen sich untern den Anhängern von agilen Methoden Posts über Kanban. So widmen sich z.B. Pawel Brodzinski und Henrik Kniberg dem Thema.

Kanban kommt eigentlich aus der Produktionssteuerung und beruht im Wesentlichen auf dem Pull-Prinzip. Statt einer zentralen Steuerung (also übertragen einer zentralen Planvorgabe), wird dezentral ja nach aktuellem Bedarf (also situationspezifisch je Sprint) Material (also Input/Requirements/Zulieferungen) abgerufen.

Auch über Lean Management findet man gelegentlich ähnliche Übertragungen auf das Projektmanagement.

Die guten alten Management-Methoden finden also im Projektmanagement und der Softwareentwicklung ein erfolgreiches Recycling.

#254 Requirements

Craig Brown von Better Projects hat eine Taxonomie für Requirements von Don Firesmith ausgegraben. Zugegeben, solche Übersichten sind immer etwas abstrakt und theoretisch, haben aber durchaus ihre Berechtigung, z.B. um einen Anforderungskatalog auf Vollständigkeit und Qualität hin zu überprüfen.

Je besser der Anforderungskatalog, umso überschaubarer werden die erforderlichen Änderungen (jedenfalls im Normalfall).

Natürlich wird es immer Änderungen geben, denn die Welt dreht sich immer weiter und wir wissen heute (hoffentlich) auch mehr als gestern. Paul Ritchie von Crossderry Blog weist darauf hin, dass bei Change Requests häufig eine der wichtigsten Fragen nicht gestellt wird, nämlich welche anderen Anforderungen/Changes möglicherweise auf der Strecke bleiben wenn ein bestimmter Change Request verabschiedet und realisiert wird. Sozusagen die Opportunitätskosten eines CRs.

#250 VisualPM: Storyboards im Requirements Engineering

Craig Brown schlägt Storyboards als „requirement tool“ vor. Leider beschränken sich seine Ausführungen auf die Überschrift und ein Youtube-Video über Storyboards im Film. Storyboards sind natürlich auch wieder eine Visualisierungstechnik, insofern ist der Ansatz interessant. Die Frage liegt darin, wie Storyboards auch auf abstraktere, weniger visuelle Themen als Film oder beispielsweise die Präsentationserstellung angewendet werden können.

#230 Mal wieder SCRUM

Über SCRUM war hier schon öfters die Rede. Bei Henrik Kniberg finden sich aktuell zwei interessante Beiträge zu SCRUM (alle in Englisch). Zum Einen die Präsentation zu seiner SCRUM-Einführung auf der Agile 2009 in Chicago, zum Anderen seine SCRUM Checklist 2.0, „a simple tool to help you get started with Scrum, or assess your current implementation of Scrum“.



bernhardschloss.de