Tag: Agile (Seite 4 von 4)

Highlights aus dem MobileTech 2013 Workshop – Mobile Javascript WebApps professionell entwickeln

Die Beschäftigung mit den verschiedenen Ansätzen der Softwareentwicklung für mobile Endgeräte lenkte mein Augenmerk auf aktuelle Konzepte in der Javascript-Entwicklung. Dass sich bewährte Prinzipien und Praktiken aus der herkömmlichen Webentwicklung auch auf Mobile-Web Projekte übertragen lassen, ist nachvollziehbar. Beispielsweise können dort ebenso CleanCode Richtlinien berücksichtigt und JavaScript Module Test getriebenen entwickelt werden. Dennoch gibt es spezifische Herausforderungen, die bei der Entwicklung von mobilen Applikationen ergeben.

Auf der MobileTech 2013 in München wurden im Workshop „Mobile Javascript WebApps professionell entwickeln“ derartige Herausforderungen adressiert und Lösungsansätze vorgestellt, welche anhand von Programmieraufgaben verinnerlicht werden konnten.

Im Folgenden möchte ich meine persönlichen Highlights aus diesem Workshop vorstellen.

Passt AGILE zu Ihrem Unternehmen?

Kommt Ihnen folgendes bekannt vor? Fasziniert von den Versprechen agiler Methoden – wie z.B. Steigerung der Effizienz/Qualität/Mitarbeiterzufriedenheit, kürzere Produktzyklen, besseres Risikomanagement – beschließt ein Unternehmen, Scrum oder Ähnliches, flächendeckend einzuführen. Nach anfänglicher Begeisterung aller Beteiligten und ersten Erfolgen schleicht sich dennoch die alte Arbeitsweise langsam wieder ein. Trotz Daily Stand-ups und Taskboards fällt das Unternehmen also in alte Muster zurück – beispielsweise werden User Stories immer detaillierter, bis sie letztendlich traditionellen Anforderungsdokumenten wie Pflichtenheften gleichen.

Bericht Mobile Tech 2013

Vom 11. Bis 14. März 2013 fand in München die Mobile Tech Conference 2013 statt. Das breite Themenspektrum und die interessante Mischung aus Workshops, Hands-On-Vorträgen zur Konzeption und Entwicklung mobiler Lösungen bis hin zu Themen wie User Experience oder Erfolgsfaktoren im Mobile Business hatten für jeden Geschmack etwas zu bieten.

Montag war Workshop-Tag – ich entschied mich für das Thema Responsive Design („Responsive ist noch lange nicht mobil“) von Annika Brinkmann. Responsive Websites basieren auf einem einzigen Template und passen über sog. „media queries“ den sichtbaren Inhalt abhängig von den Eigenschaften des Endgeräts entsprechend an. Es muss also immer nur eine Version einer Seite gepflegt werden, die zudem für alle Plattformen immer über dieselbe URL zugänglich ist.

Behavior Driven Development

n Projekten kommt es immer wieder vor, daß Kunden und Business Analysten bei der Präsentation der Ergebnisse einer Softwareentwicklung ihre Anforderungen nicht umgesetzt sehen. Gründe dafür können z.B. unspezifische Anforderungen, fehlende Beispielfälle und Mißverständnisse bei der Interpretation der Anforderungen sein. Softwareentwickler leiten aus der sprachlichen Spezifikation Testfälle in Programmcode ab, die von technikfernen Projektbeteiligten nur schwer verstanden und geprüft werden können. Wie kann es ermöglicht werden, diese automatischen Tests lesbarer zu gestalten, so daß sie durch Business Analysten und Kunden geschrieben und abgenommen werden können? Bei der Suche nach Lösungen bin ich auf “Behavior Driven Development” gestoßen.

Kanban Reloaded

In meinem letzten Blogeintrag habe ich die agile Methode „Kanban“ bereits vorgestellt. Ich konnte zeigen, was Kanban ist und wie wir Kanban in einem Wartungsteam eingeführt haben. Der Blog endete mit einem Ausblick auf den vor uns liegenden Weg und die Umsetzung der noch offenen Punkte.
An dieser Stelle möchte ich nun anknüpfen und den Erfahrungsbericht fortsetzen.

Automatisierte Tests über Weboberflächen

Fast jeder kennt das Problem. Man implementiert neue Funktionalität, führt eventuell noch paar Code-Optimierungen durch und lässt anschließend Unit-Tests laufen. Obwohl alle Tests erfolgreich sind, ist man trotzdem nicht immer sicher, ob eigene Änderungen keine Seiteneffekte verursacht haben, die erst beim manuellen Testen der Applikation über die Oberfläche ersichtlich werden. Ganz schlimm wird es, wenn diese Fehler ganz übersehen werden. Meistens ist es nicht der Fall. Doch wer sicher sein will, sollte sich über Testautomatisierung der Benutzeroberflächen (GUI-Testing) Gedanken machen.

Kanban in der Wartung

Das Jahr neigt sich dem Ende zu. Die Weihnachtsfesttage haben begonnen und viele freuen sich auf besinnliche Stunden mit der Familie. Insbesondere für Entwicklungsteams eine Zeit, in der die Möglichkeit besteht, zur Ruhe zu kommen und die vielen Aufgaben zu vergessen. Der tägliche Terminstress, kommt im nächsten Jahr bestimmt wieder.
Doch das muss nicht sein und ich möchte diesen Blog nutzen, einen Entwicklungsansatz vorzustellen, der überlasteten Teams die Ruhe und damit auch eine erhöhte Teamleistungsfähigkeit zurückbringen kann.

Legacy Code unter Kontrolle – Folge 3, JMockit für Fortgeschrittene

m ersten Blog-Eintrag dieser kleinen Serie habe ich erzählt, warum JMockit eine so wichtige Rolle spielt, wenn es darum geht, eine Legacy-Anwendung zu testen. Im nächsten Eintrag habe ich das wichtigste API von JMockit, das Expectations-API vorgestellt. Als Abschluss zeige ich an zwei konkreten Beispielen aus der Praxis, wie JMockit einem auch in schwierigen Fällen einen Unit-Test möglich macht.

Hier nochmal der Überblick über die ganze Serie:
•    Folge 1: Vorstellung von JMockit
•    Folge 2: Die Grundkonzepte von JMockit. Ein erster Test, der ohne JMockit nur schwer zu erstellen wäre.
•    Folge 3: Zwei schwierige Fälle aus der Praxis: Ein Schaltjahresproblem und ein Singleton-Factory-Lindwurm.

Legacy Code unter Kontrolle – Folge 2, Die Grundkonzepte von JMockit

In meinem letzten Blog-Eintrag habe ich erläutert, warum JMockit bei meinem aktuellen Kunden eine so wichtige Rolle spielt, wenn es darum geht, eine Legacy-Anwendung testbar zu machen und so änderbar zu halten.
In der Folge 2 will ich heute darstellen, wie man konkret Unit-Tests mit JMockit schreibt und welche Konzepte dabei eine Rolle spielen. Es entsteht ein Test für eine Stück Legacy Code, das ohne JMockit nur sehr schwer zu testen wäre.

Hier nochmal der Überblick über die ganze Serie:

  • Folge 1: Vorstellung von JMockit
  • Folge 2: Die Grundkonzepte von JMockit. Ein erster Test, der ohne JMockit nur sehr schwer zu erstellen wäre.
  • Folge 3: Zwei schwierige Fälle aus der Praxis: Ein Remote-Service-Call und eine Schaltjahresregelung.

Legacy Code unter Kontrolle Folge 1 Vorstellung von JMockit

Bei meinem aktuellen Kunden setzen wir das Tool „JMockit“ so erfolgreich ein, dass es inzwischen einen wichtigen Platz in meiner „virtuellen Werkzeugkiste“ bekommen hat. Auch wenn sich die Entwickler in meinem Team größte Mühe gegeben haben, ordentlichen Code mit einem sauberen Design zu erstellen, so schlagen wir uns nun dennoch durch inzwischen weit über 1 Million Zeilen Java-Code, aus denen uns die Fehlentscheidungen der letzten 10 Jahre „entgegenmüffeln“. Wir kämpfen mit Legacy Code. Hier helfen uns Unit-Tests. Und JMockit spielt bei der Erstellung dieser Tests eine entscheidende Rolle.

 

Da JMockit noch recht neu und unbekannt ist, möchte ich es Ihnen hier in einer lockeren Folge von Blog-Einträgen näherbringen:

  • Folge 1: Vorstellung?
  • Folge 2: Die Grundkonzepte von JMockit. Ein erster Test, der ohne JMockit nur sehr schwer zu erstellen wäre.
  • Folge 3: Zwei schwierige Fälle aus der Praxis: Ein Remote-Service-Call und eine Schaltjahresregelung.