Erfahrungsaustausch

Gestern hab' ich mich mit einem Bekannten unterhalten, der Web-Projekte leitet, eigentlich aber aus der Ecke der Software Entwickler kommt. Die Probleme, Erkenntnisse und Eskalationen in Bezug auf Zeit und Budget in seinen Projekten lassen mich nur Schmunzeln ... "go agile" denke ich und versuche ihn davon zu überzeugen.

Ich:

Wie sehen denn die Rahmenbedingungen bei den Projekte aus?

Er:

Zeit, Budget und Ressourcen werden vorgeben. Die technische Lösung hat damit bereits Nebenbedingungen, die sich bei der Realisierung zeigen.

Ich:

Du hast also keinen Einfluss auf die Resourcenverteilung in deinen Projekten. Wie hoch ist denn die Fluktuation während des Projekts?

Er:

Ja, das ist immer problematisch. Die Ressourcenzuteilung ist nicht garantiert. Es werden oft Leute abgezogen, für die man nicht immer einen adäquaten Ersatz bekommt. Sobald jemand als freie Ressourcen ausgemacht wird, bekommt man wieder ein neues Teammitglied.

Ich:

Wie erfolgreich sind den diese Projekte?

Er:

Sehr erfolgreich. Wir haben nur selten Budget oder Zeitüberschreitungen bis zum Projektabschluss.

Ok, seltsam. Noch ein paar Fragen und ich war am "Kern". Er eröffnet mir, dass bei vielen Projekten dann nach dem Abschluss erst die grosse Überraschung kommt. Der Kunde hat dann oft noch Change Requests, die allerdings eher Bugs sind und möchte nachträglich die Spezifikation ändern. Da man den Kunden halten möchte, arbeitet man auch nach Projektabschluss noch am Projekt, ohne Aufwandsverrechnung und oft nur mit halbem Team. Was am Ende dann rauskommt, möchte keiner mehr Warten, meint er ...

Nochmal: "go agile"
Ich würde mal unterstellen, dass man das bei agilem Vorgehen besser hinbekommt!

WebTest vs Selenium: WebTest gewinnt 13 zu 5

Am 29.10.07 wurde auf TheServerSide.com ein Artikel gepostet, der sich mit Tools zum automatisierten Testen von WebApplikationen auseinander setzt - es wurde WebTest (Canoo) mit Selenium (OpenQA) verglichen.

Insbesondere das aufzeichnen von Tests ist offensichtlich ein Bedürfnis, z.B. mit dem WebTest Recorder von Canoo. Ausserdem wird Element von PragmaticQA angesprochen, was auf Ruby & Watir basiert.

Andere sprechen davon, JUnit performanter zu machen, indem man auf Grid Computing setzt.

Ich setzte auf Selenium, wobei die Testbarkeit von AJAX Anwendung sich als schwierig erweist. Der Selenium IDE Recorder ist hier etwas schwach ...

CruiseControl im Mac Menü

Mit CCMenu kann man bei einem Mac die CruiceControl Server Task/Results in der Mac Menüleiste darstellen.

Erik Doernenburg von ThoughtWorks schreibt mit seinem Team auf Sourceforge über CCMenu.

CCMenu wurden auf der CITCON (Continuous Integration and Testing Conference) 2007 in Brüssel erstmals vorgestellt.

Noch 2 Tage, dann gibts Leopard und dann .....

... gibts bald ein Mac!

Ubuntu upgraded

Gutsy Gibbon 7.10, die neueste Version von Ubuntu ist installiert.

Der Update Manger hat mir heute morgen direkt angeboten, meine Version 7.04 Feisty Fawn abzugraden - ein, zwei Klicks - root Password eingeben und ca. 2.5h warten, dann ist Gutsy Gibbon installiert! Ubuntu läuft bei mir auf einem Notebook von Dell - D620 Latitude.

Eine Update Guide in englisch gibts hier, das deutsche Ubuntu Forum gibt sicher auch Auskunft bei Problemen - aber es gibt ja keine Probleme, nur anspruchsvolle Aufgaben ,-)

Go and get it!

Nach dem Restart und dem Login gab's dann noch ne böse Überraschung, die mich dann einen Tag beschäftigt hat - "failed to initialize HAL", ein Bug, der bekannt ist .....

Working in Project Zero

Da Project Zero offensichtlich agile entwickelt wird, habe ich mal nachgefragt:

Man geht iterativ vor, pro Iteration wird ein Milestone entwickelt. Einen Milestone gibt es alle 6 Wochen, das entspricht einer Interation. Aktuell arbeitet man gerade am Milestone 2 (M2). Backlog, ProductOwner, Teammembers und Kommunikation wird Bugzilla eingesetzt.

Am kommenden Mittwoch, 24.10.07 wird ein Branch gezogen, der dann bis Freitag 26.10.07 in den Test geht, also nur zwei Tage. Demnach wird sicher automatisiert getestet. Ich werde weiter fragen ...

ProjectZero publiziert den gesamten agile Prozess in einem öffentlichen Kalendar, den man mit Goolge Calendar lesen kann. Ausserdem gibts drei interessante Blogs:

• Jerry's Strategie Blog
• Jason's Architecture Blog
  
• Marc Thomas Assembly Blog
• Team Zero Blog
  

Google grouplet

Julie Bick schreibt unter der Rubrik “Preoccupations” Artikel für die New York Times. Gestern, 21. Oktober hat Bharat Mediratta von Goolge in einem Interview Julie Bick darüber berichtet, wie man bei Google den Engineers 20% der Zeit überlässt, persönlichen Interessen nachzugehen, die nicht unbedingt von Interesse für das Unternehmen sind, um eventuell etwas Neues zu entwicklen.

Bharat Mediratta berichtet, dass Gmail, Google News und google shuttle busses aus eben diesen 20% als Idee entwickelt worden sind und umgesetzt wurden. Die Personen hinter solchen Ideen so motiviert, dass man nicht um Personal zur Realisierung "werben" muss, wenn man eine neue Geschäftsidee präsentiert.

Da nicht unmittelbar alle 20% Ideen zu einem Produkt führen und die restliche Zeit für die "normale" Arbeit verbleiben sollte, setzt Google auf "grouplets" - ein Board quer durch die gesamte Organisation.

Grouplets haben kein Budget und keine Entscheidungskompetenz. Sie haben ein paar Leute die einer Idee nachgehen und bereit sind, das Unternehmen mit der Idee zu überzeugen und mitzureissen.

Agile und Offshore - geht das?

Neben content-driven Community Portalen, Blogs, Photo Sharing, Syndication Feeds, MashUps und Google Tools wie GMail, Picasa, Docs and Spreadsheets und vielem mehr hat sich beim Web 2.0 Hype noch etwas gravierent geändert -

die Geschwindigkeit!

Plötzlich "lebt" man RAD (rapid application development). Buzzword von heute, wie Time-to-market, Feature-driven, Beta, Usability, desktop-behavior, rich interface etc ... endlich! Aus der Technologie Ecke gibts die zugehörigen Tools wie Rails, Groovy und AJAX - alles nach dem Motto:

"Whatever tools are necessary, we provide them, and then get the hell out of the way of the developers so that they can do their jobs."
Werner Vogel, CTO amazon.com

Vorbei die Zeit der endlosen Spezifikationen und Pflichtenhefte, vorbei endlose und kostspielige Analyse Phasen, nie wieder "Sorry, it's much to late to change your mind" ......

... und: Offshore ade!

Selbstorgansiert, selbstregulierend, hoch motiviert, interdisziplinär, kommunikativ, flexibel, schnell, iterativ und mit einer nie gekannten Portion job-enrichment arbeiten Teams von 3-8 Leuten an der Realisierung einer Applikation.

Während immer mehr Firmen bei der schnellen Umsetzung ihrer Internetstrategien auf agile setzen, bleiben andere ihrer Strategie treu und setzen auf Offshore.

Rein monetär betrachtet mag das zunächst günstiger sein, nur kann man es sich leisten, der Konkurenz einen Vorsprung im Internet zu gewähren?

Ubnuntu 7.10 ist da! jetzt auch auf Dell

Der Hersteller Dell möchte noch dieses Jahr das neue Betriebssystem Ubuntu 7.10 auf seinen PC's in den Handel bringen.

"We will offer Ubuntu 7.10 preinstalled on our systems soon," said Anne Camden of Dell corporate communications, in an e-mail interview. "For customers who are interested in updating their existing Ubuntu systems, we advise them to visit the Ubuntu 7.10 page on our wiki, which will go live [Oct. 18] after the official launch."

Die ganze Geschichte lesen ...

Best Practice: TDD und JSF managed beans bei agilem Vorgehen

"Änderungen werden erwartet, sie sind willkommen!" Das ist eine zentraler Gedanke bei agilem Vorgehen.

Was aber bedeutet das für die Vorgehensweise bei der Software Entwicklung? TDD! Am Beispiel von JSF möchte ich kurz zeigen, welcher klassische Fehler immer wieder gemacht wird, welche Konsequenzen daraus enstehen und wie man es besser machen kann. Im folgenden geht es um dieses Beispiel:

public class ChangePasswordBean
{
   private String password, passwordRepeat;

   public String doChangePassword() {
      // ...
   }

   public String getPassword() {
      return password;
   }

   public void setPassword(String password) {
      this.password = password;
   }

   public String getPasswordRepeat() {
      return passwordRepeat;
   }

   public void setPasswordRepeat(String passwordRepeat) {
      this.passwordRepeat = passwordRepeat;
   }
}

1# Managed Bean's und deren Abhängigkeiten

Bei JSF werden properties und action's in Managed Bean's zusammengefasst. Of braucht man innerhalb der action Methoden eine Reference zu einem Manager oder einem Service, dem die Verarbeitung delegiert wird. Das ist nicht problematisch, aber wie macht man das, damit das Managed Bean auch ohne Container testbar bleibt?

Nicht gut ist das hier: (faces-config.xml)

<managed-bean>
   <managed-bean-name>changePasswordBean</managed-bean-name>
   <managed-bean-class>example.ChangePasswordBean</managed-bean-class>
   <managed-bean-scope>request</managed-bean-scope>
</managed-bean>

... in Verbindung mit folgender Implementierung:

public String doChangePassword() {
   UserManager.getInstance().changePassword(uid, password);
}

Besser ist, den UserManager per Dependency Injection zu setzen und dann zur Verarbeitung die bean-interne Referenz zu verwenden:

<managed-bean>
   <managed-bean-name>changePasswordBean</managed-bean-name>
   <managed-bean-class>example.ChangePasswordBean</managed-bean-class>
   <managed-bean-scope>request</managed-bean-scope>
   <managed-property>
      <property-name>userManager</property-name>
      <value>#{userManager}</value>
   </managed-property>
</managed-bean>

... in Verbindung mit folgender Implementierung:

public String doChangePassword() {
   this.userManager.changePassword(uid, password);
}

Somit kann man eine Unit Test statt einem Integrationstest schreiben. Der UserManager in diesem Beispiel kann mittels JMock im Unit Test injected werden um State und Behavior des ChangePasswordBean sicherzustellen.

The Future of Software Development

Alex Iskold, einer der Writer bei Read/WriteWeb, schreibt in seinem Artikel "The Future of Software Development" warum der Wasserfall Ansatz bei Software Entwicklungsprojekten nicht funktioniert und wie agile Vorgehensweise die Entwicklung belebt, warum Umdenken Sinn macht und wie man generell mittels Testing den wechselnden Heraus- und Anforderungen bei agilem Vorgehen gerecht wird.

Danke an dieser Stelle an Markus, der mich auf diesen interessanten Artikel hingewiesen hat ...

InfoQ: Werner Vogels über Availability & Consistency

Werner Vogels, CTO Amazon.com, über die Prinzipien einer skalierbaren Service Landschaft, Architektur ein solchen, klassische Probleme wie Transaktionen und State Management und nicht zuletzt Testing ...

Interessant ist an der Stelle, dass Vogels auf die Vorgehensweise eingeht. Er erwähnt, dass es bei Amazon eine 2 Pizza Regel gibt:

Ein Team ist maximal so gross, dass man es mit 2 Pizzen ernähren kann. Wenn das nicht gegeben ist, dann ist das Team zu gross.

Services bei Amazon werden auf teambasis von 8 bis 12 Leuten entwickelt.

Der SOA Ansatz bei Amazon - agile?

Am 28./29. September 2007 habe ich auf dem T.Camp der namics ag einen Vortrag zum Thema SOA gehalten. Primär ging es darum zu erläutern, wie das Buzzword SOA zu vestehen ist, wie sich SOA entwickelt hat, was man heute darunter versteht und wie SOA sich langsam von einem technischen zu einem business Thema verlagert, Stichwort JBI, der zweite Teil meines Vortrags.

Im Anschluss an den Vortrag wurde ich von Tristian Woerth, ein Ruby on Rails Spezialist aus der Schweiz, angesprochen - er hat mich gefragt, ob ich den service-orientierten Ansatz von Amazon kenne ...

Zu meiner Schande, kannt ich ihn nicht. Heute, gut 3 Wochen später und um einige Erkenntnisse reicher habe ich mit Amazon beschäftigt - sehr interessant, sowohl technisch als auch methodisch.

Interessant in diesem Zusammenhang fand ich diese Aussage von Werner Vogels, CTO Amazon.com:

"There is another lesson here: Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. ... This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service. "

und

"Whatever tools are necessary, we provide them, and then get the hell out of the way of the developers so that they can do their jobs."

Klingt nach agile, wird auch agile sein -ich weiss es leider nicht! Würd' mich aber interessieren, besonders weil Herr Vogels die Problematik des testens anspricht - sicher nicht trivial bei einer verteilten Service Landschaft ...