Netbeans und PHP Codesniffer

Bei meiner Arbeit bei Ekumo wurde ich mit dem PHP CodeSniffer konfrontiert, der als Precommithook ins SVN eingehängt war. Immer wenn man eine Datei committen wollte, die schon etwas älter war und vor Einbau des Precommithook ins SVN gewandert war, kam es zu Fehlermeldungen die zeitraubend bearbeitet werden mussten. Es wäre schön gewesen, man hätte diese Fehler bereits beim Bearbeiten gesehen und sofort behoben.
Jetzt habe ich ein Plugin für Netbeans gefunden, das PHPCodeSniffer und PHP Mess Detector in Netbeans einbindet.
Das Plugin gibt es bei SourceForge als Download.

Eine Anleitung zur Installation gibt es bei hasematzel.de

Nachdem man PHPCodeSniffer und PHPMessDetector über PEAR installiert hat und dieses Plugin in Netbeans installiert hat, bekommt man nach dem Speichern einer Datei die Ausgabe der beiden Scripte in Netbeans im ActionItems Fenster angezeigt.

So kann man vor dem Committen alle Warnungen beheben und hat keinen Ärger mit dem Precommithook.

 

Signaturen von Burndowncharts

Kane Mar hat einen netten Beitrag über die Signaturen von Burndowncharts geschrieben.

Ich finde seine Meinung zur geraden Sprint Burndown Linie Interessant. Er nennt es den Fakey-Fakey, ich hab erlebt das dieser Burndown als das Ideal angesehen wurde.

Ziel bei dem Projekt in dem ich mit Scrum zu tun hatte, war es, möglichst dieser Linie nahe zu kommen. Als ich in das Projekt einstieg verliefen die Brundowns aber immer zunächst recht Waagerecht, bevor sie dann zum Ende des Sprints fielen. Der Grund dafür war recht trivial. Die einzelnen zu lösenden Teilprojekte waren relativ groß und jeweils ein Entwickler benötigte einen großen Teil seiner Zeit, um sein Projekt zu lösen. Wir haben dann beschlossen, keine Tasks zu machen die im Planning Poker auf mehr als 8 Stunden geschätzt wurden. Wenn dem so war, wurde der Task weiter aufgegliedert.

Dieses hatte dann zur Folge, dass sich unsere Planning Meetings sich exponential verlängert haben. Für die Planung eines zwei Wochen Sprints benötigten wir zwischen 8 und 14 Stunden. Allerdings war das Team mit 10 Mann auch recht  groß.  Das Team wurde daraufhin geteilt und die Sprints auf 1 Woche verkürzt.

Am Ende meines Einsatzes als Entwickler in der Firma kamen wir dem Fakey-Fakey von Kane sehr gut nahe und hatten damit das Ideale Burndown erreicht. Dies zum einen dadurch, dass wir die Anwedung, an der wir Programmiert haben, recht genau kannten und weil wir den Lernaufwand einzelner Mitglieder des Teams durch gutes abschätzen abfangen konnten.

Der Fakey-Fakey ist also nicht unbedingt ein Betrug.

Scrumology.com

Ich folge jetzt dem Blog von Kane Mar, der als Trainer für Agile Softwareentwicklung arbeitet. Ich selber habe Agile Softwareentwicklung bei einem Projekteinsatz in Berlin kennen gelernt und  finde es einen sehr schönen Ansatz.

Warum verwendet man SCRUM?

Scrum

  • steigert die Produktivität des Teams
  • erhöht die Übersicht über das Projekt
  • hilft, Störungen vom Team fern zu halten

Ich werde demnächst sicher mehr darüber schreiben.

 

Yii Framework

Seit ein paar Wochen  arbeite ich mich jetzt in das Yii-Framework ein, um ein Kundenprojekt fertig zu stellen. Die Einarbeitung ging am Anfang ziemlich gut, das Erstellen der ersten Applikation war dank Gii kein Problem, da alles in der Anleitung sehr gut beschrieben ist. Jetzt geht es an die Programmierung der Geschäftslogik und ich bin gespannt, wie schnell ich da mit dem Framework vorankomme.

Ich werde hier dazu in Kürze mehr schreiben.

Neuer Internetauftritt

Willkommen auf meinem neuen Internet-Auftritt.

Ich werde hier über alles Rund um meine Arbeit schreiben. Gerade im Bereich der Web Entwicklung gibt es immer viele Neuigkeiten, daher habe ich meine Homepage jetzt auf WordPress umgestellt, um besser über aktuelle Themen berichten zu können.

Folgen Sie mir durch die Welt der Web Entwicklung und der Programmierung. Setzen sie einen Bookmark auf meinen Webauftritt.

Ihr
Michael Bohn

Ekumo

Diese Woche endet für mich mein Projekt bei Ekumo in Berlin. Ich war jetzt 4 Monate und zwei Wochen hier im Projekteinsatz und habe dabei viel gelernt. Zum einen haben wir hier nach der SCRUM Methodik gearbeitet, zum anderen sind wir sehr tief in PHP eingestiegen. Ich will hier ein Kurzes Fazit über meine Arbeit geben.

Als ich in das Team von Ekumo kam, hatte ich noch nie mit SCRUM gearbeitet. Da ich aber bereits während des Studiums als Gruppenleiter und Tutor Erfahrungen mit der Moderation von Arbeitsgruppen gesammelt hatte, kamen mir viele der Ansätze vom Scrum bekannt vor. Da ist zum einen das Visualisieren der Gruppenarbeit, zum anderen das Moderieren der Team-Meetings.

An der Uni hatten wir bei einigen Arbeitsgruppen zum Visualisieren der Arbeitsergebnisse das Metaplanning verwendet, und so das Arbeitsergebnis als Tapete an der Wand hängen. Beim Scrum wurden die Tasks, auf die wir uns commitet hatten mit Postits an die Wand in “to be done” gehängt, um dann über “in progress”  auf “done” geklebt zu werden. Dadurch war das Team und die Product Owner stets über den Fortschritt der Gruppe im Bilde. Die zweite Visualisierung beim SCRUM ist der Burn-Down-Chart, der gibt einen Überblick darüber, wie viel der zu erledigenden Arbeit tatsächlich erledigt wurde.

Beim Dayli Scrum galt die Regel: Fasse dich kurz. Erzähle, was du gestern gemacht hast, was du heute machen wirst und was dich gestern an der Arbeit gehindert hat. Da das Meeting nur 10 – 15 Minuten dauern soll, kann man jede dieser Fragen nur mit einem kurzen Statement beantworten.

Ausführliche Statements hingegen sollten bei den Sprint Planungs-meetings und der Sprint Retrospektive abgegeben werden. Das ist der Platz um sich im Detail zu äußern.

Meine Erfahrungen mit SCRUM sind durchaus positiv.