Kommentare zu: Entwicklungsmethoden in der Praxis http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/ Beobachtet das Internet - Web 2.0, Ajax, Online Marketing, Usability, Best Practices etc. Tue, 17 Jan 2012 12:28:59 +0000 http://wordpress.org/?v=2.8.4 hourly 1 Von: Blogger Portraits – Reto Hartinger http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/comment-page-1/#comment-272705 Blogger Portraits – Reto Hartinger Mon, 18 Jan 2010 08:50:09 +0000 http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/#comment-272705 [...] glaube es ist der über Outsourcing – er ist dann auch in der Computerworld [...] [...] glaube es ist der über Outsourcing – er ist dann auch in der Computerworld [...]

]]> Von: DEMANDIT blog http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/comment-page-1/#comment-71556 DEMANDIT blog Sun, 03 Feb 2008 21:57:51 +0000 http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/#comment-71556 <strong>Wie Blogs in den Medien stattfinden...</strong> In unserem Internet-Briefing-Blog fand kürzlich eine Diskussion zum Thema Entwicklung statt. Kurz darauf veröffentlichte die Computerworld den passenden Artikel dazu. Seite 1/Seite 2 Clevere Journalisten werden in Zukunft Blogs für eine schnelle ... Wie Blogs in den Medien stattfinden…

In unserem Internet-Briefing-Blog fand kürzlich eine Diskussion zum Thema Entwicklung statt. Kurz darauf veröffentlichte die Computerworld den passenden Artikel dazu. Seite 1/Seite 2
Clevere Journalisten werden in Zukunft Blogs für eine schnelle …

]]> Von: Internet Briefing Blog / Wie es Blogeinträge mit Diskussionen in die Zeitung schaffen http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/comment-page-1/#comment-70631 Internet Briefing Blog / Wie es Blogeinträge mit Diskussionen in die Zeitung schaffen Wed, 30 Jan 2008 13:18:01 +0000 http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/#comment-70631 [...] Entwicklungsmethoden in der Praxis [...] [...] Entwicklungsmethoden in der Praxis [...]

]]> Von: Internet Briefing Blog / Das war das Internet Briefing 2007 http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/comment-page-1/#comment-64836 Internet Briefing Blog / Das war das Internet Briefing 2007 Fri, 28 Dec 2007 15:15:53 +0000 http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/#comment-64836 [...] Entwicklungsmethoden in der Praxis Mein Blog wieder ohne Werbung - dank Google [...] [...] Entwicklungsmethoden in der Praxis Mein Blog wieder ohne Werbung – dank Google [...]

]]> Von: Bloglinks am 20. Dezember « Cyrus Warrick - Blog http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/comment-page-1/#comment-63367 Bloglinks am 20. Dezember « Cyrus Warrick - Blog Thu, 20 Dec 2007 17:30:39 +0000 http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/#comment-63367 [...] Entwicklungsmethoden in der Praxis bei Internet Briefing Blog [...] [...] Entwicklungsmethoden in der Praxis bei Internet Briefing Blog [...]

]]> Von: Internet Briefing Blog / Einfache, komplizierte und komplexe Probleme in der Entwicklung http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/comment-page-1/#comment-62573 Internet Briefing Blog / Einfache, komplizierte und komplexe Probleme in der Entwicklung Mon, 17 Dec 2007 00:19:29 +0000 http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/#comment-62573 [...] sucht die goldene Antwort auf die Frage; “welches ist die richtige Entwicklungsmethode“. Die intensive Diskussion zeigt, die Frage stellen sich auch andere Mitglieder im Club. Ein [...] [...] sucht die goldene Antwort auf die Frage; “welches ist die richtige Entwicklungsmethode“. Die intensive Diskussion zeigt, die Frage stellen sich auch andere Mitglieder im Club. Ein [...]

]]> Von: Markus Hegi-Nagavkar http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/comment-page-1/#comment-61631 Markus Hegi-Nagavkar Wed, 12 Dec 2007 15:52:27 +0000 http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/#comment-61631 Keine Patentrezepte - Fighting complexity - Mit grossem Interesse habe ich Eure Kommentare gelesen - Wir sind mittlerweile 7 Jaher hier in Pune (Indien) mit einem Team zwischen 30 und 60 Angestellten. Ich selber bin 50% in Indien (6 Wochen Rhytmus). Wir arbeiten am Projekt mit Reto seit 3 Monaten. Kulturelle Faktoren spielten am Anfang eine grosse Rolle, mittlerweile hat sich das Team gut eingespielt und kurlturelle Eigenheiten & Missverstäntnisse sind nur noch ein klener Teil. Die Fluktuation ist ein Hauptproblem: Speziell für kleinere Firmen hier. Zu einem gewissen Grad kann man dem mit speziellen Verträgen entgegenwirken (Bonus für langes Bleiben) Methodik ist gut, verlangsamt jedoch den Entwicklungsprozess, und "kills the innovation". Als Produktefirma orientieren uns an Extreme Programming Prinzipien. Damit machten wir die besten Erfahrungen - auch wegen dem pragmatischen, auf Innovation ausgerichteten Approach. Für das Produkt haben wir eine high-Level Dokumentation, meist in PowerPoint, im Übrigen fokusieren wir auf den Source Code als Dokumentation. Mit dem Projekt mit Reto war das Problem, dass die ppts zu grob waren und die Entwickler unsicher über die Spezifikationen waren. Deswegen arbeiten wir in Projekten oft mit Testscripts. Ein Testscript besteht bei uns aus einem Hauptscript (oft weniger als 20%) und diversen Nebenscripten: - Das Hauptscript wird vor der Implementation geschrieben und der Programmierer kann seine Funktionalität laufend prüfen. - Die Nebenskripte entstehen während und nach der Implementation und enthalten spezielle Konditionen, wie: ohne JavaScript, Validierungen von Extremwerten, Umgekehrte Reihenfolge etc. Nach jedem Release (also auch dann, wenn das Feature nicht verändert wurde), werden alle Haupskripte ausgeführt, und vor jedem grossen Release werden dann auch alle Nebenskripte getestet. Schlussendlich jedoch ist das Hauptproblem immer die Komplexität, und dieser ist selten mit Theorie beizukommen. Der Hauptfokus speziell bei komplexen und langfristigen Projekten sollte immer auf SIMPLIFICATION, der Reduktion von Komplexität liegen. Dies gilt insbesondere für die Methodik! Keine Patentrezepte – Fighting complexity -

Mit grossem Interesse habe ich Eure Kommentare gelesen –
Wir sind mittlerweile 7 Jaher hier in Pune (Indien) mit einem Team zwischen 30 und 60 Angestellten. Ich selber bin 50% in Indien (6 Wochen Rhytmus). Wir arbeiten am Projekt mit Reto seit 3 Monaten.

Kulturelle Faktoren spielten am Anfang eine grosse Rolle, mittlerweile hat sich das Team gut eingespielt und kurlturelle Eigenheiten & Missverstäntnisse sind nur noch ein klener Teil.

Die Fluktuation ist ein Hauptproblem: Speziell für kleinere Firmen hier. Zu einem gewissen Grad kann man dem mit speziellen Verträgen entgegenwirken (Bonus für langes Bleiben)

Methodik ist gut, verlangsamt jedoch den Entwicklungsprozess, und “kills the innovation”. Als Produktefirma orientieren uns an Extreme Programming Prinzipien. Damit machten wir die besten Erfahrungen – auch wegen dem pragmatischen, auf Innovation ausgerichteten Approach. Für das Produkt haben wir eine high-Level Dokumentation, meist in PowerPoint, im Übrigen fokusieren wir auf den Source Code als Dokumentation. Mit dem Projekt mit Reto war das Problem, dass die ppts zu grob waren und die Entwickler unsicher über die Spezifikationen waren. Deswegen arbeiten wir in Projekten oft mit Testscripts.

Ein Testscript besteht bei uns aus einem Hauptscript (oft weniger als 20%) und diversen Nebenscripten:
- Das Hauptscript wird vor der Implementation geschrieben und der Programmierer kann seine Funktionalität laufend prüfen.
- Die Nebenskripte entstehen während und nach der Implementation und enthalten spezielle Konditionen, wie: ohne JavaScript, Validierungen von Extremwerten, Umgekehrte Reihenfolge etc.
Nach jedem Release (also auch dann, wenn das Feature nicht verändert wurde), werden alle Haupskripte ausgeführt, und vor jedem grossen Release werden dann auch alle Nebenskripte getestet.

Schlussendlich jedoch ist das Hauptproblem immer die Komplexität, und dieser ist selten mit Theorie beizukommen. Der Hauptfokus speziell bei komplexen und langfristigen Projekten sollte immer auf SIMPLIFICATION, der Reduktion von Komplexität liegen. Dies gilt insbesondere für die Methodik!

]]> Von: Daniel Niklaus http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/comment-page-1/#comment-60553 Daniel Niklaus Sat, 08 Dec 2007 10:41:09 +0000 http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/#comment-60553 Hallo Andreas Ein hervorragender Beitrag. Mach doch diesen als eigenständigen Blogeintrag und dann diskutieren wir über Einstellungskriterien von Entwicklern. Hallo Andreas

Ein hervorragender Beitrag. Mach doch diesen als eigenständigen Blogeintrag und dann diskutieren wir über Einstellungskriterien von Entwicklern.

]]> Von: Andreas Graf http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/comment-page-1/#comment-60549 Andreas Graf Sat, 08 Dec 2007 10:11:44 +0000 http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/#comment-60549 Ich möchte hier mal noch einen anderen Aspekt einbringen: Qualität, Produktivität und Fluktuation hängen zu einem grossen Teil vom Managment inkl. Einstellungsprozess ab. Meine Beobachtung ist, dass dies im Outsourcing oft von Betriebswirtschaftern gemacht wird. In der Schweiz stellt man auch nicht einfach mal ein paar Entwickler an und probiert das mal aus. Passiert aber im Outsourcing, da man meint bei tieferen Kosten sich Experimente eher erlauben zu können => Planspiele. Wir betreiben in Novosibirsk seit 8 Jahren erfolgreich ein Entwicklungszentrum mit 20 Entwicklern. Ich kenne jeden persönlich mit seinen Stärken und Schwächen und bin regelmässig Vorort und wir bieten den Mitarbeitern wie das auch hier üblich ist, attraktive Arbeitsbedingungen (keine Galeeren Ruderer). Unsere Fluktuation liegt im normalen Rahmen wie ich das auch aus der Schweiz kenne, sie ist sogar etwas tiefer da in Russland heiraten und kinderkriegen viel früher stattfindet als bei uns => Stabilität ist wichtig. Meine persönliche Schlussfolgerung: Wer es schafft in der Schweiz ein Entwicklungsteam aufzubauen und erfolgreich zu betreiben schafft es auch in fernen Landen sofern er bereit ist Vorort auch persönlich regelmässig präsent zu sein und einen lokalen Manager hat mit dem man sich sehr gut versteht und auf Augenhöhe kommunizieren kann. Bei uns ist das ein Deutscher Ingenieur der mit einer Russin verheiratet ist (Einstellungsprozess). Codequalität und Entwicklungsmethoden sind Diskussionen die meiner Meinung nach nichts mit Outsourcing zu tun haben. Das ist etwa so wie die Diskussion welche Uni nun die besseren Leute produziert. Es gibt bei allen gute und schlechte. Man muss halt die guten auswählen. Was zählt sind Resultate. Ich möchte hier mal noch einen anderen Aspekt einbringen:
Qualität, Produktivität und Fluktuation hängen zu einem grossen Teil vom Managment inkl. Einstellungsprozess ab.
Meine Beobachtung ist, dass dies im Outsourcing oft von Betriebswirtschaftern gemacht wird. In der Schweiz stellt man auch nicht einfach mal ein paar Entwickler an und probiert das mal aus.
Passiert aber im Outsourcing, da man meint bei tieferen Kosten sich Experimente eher erlauben zu können => Planspiele.
Wir betreiben in Novosibirsk seit 8 Jahren erfolgreich ein Entwicklungszentrum mit 20 Entwicklern. Ich kenne jeden persönlich mit seinen Stärken und Schwächen und bin regelmässig Vorort und wir bieten den Mitarbeitern wie das auch hier üblich ist, attraktive Arbeitsbedingungen (keine Galeeren Ruderer).
Unsere Fluktuation liegt im normalen Rahmen wie ich das auch aus der Schweiz kenne, sie ist sogar etwas tiefer da in Russland heiraten und kinderkriegen viel früher stattfindet als bei uns => Stabilität ist wichtig.
Meine persönliche Schlussfolgerung:
Wer es schafft in der Schweiz ein Entwicklungsteam aufzubauen und erfolgreich zu betreiben schafft es auch in fernen Landen sofern er bereit ist Vorort auch persönlich regelmässig präsent zu sein und einen lokalen Manager hat mit dem man sich sehr gut versteht und auf Augenhöhe kommunizieren kann.
Bei uns ist das ein Deutscher Ingenieur der mit einer Russin verheiratet ist (Einstellungsprozess).
Codequalität und Entwicklungsmethoden sind Diskussionen die meiner Meinung nach nichts mit Outsourcing zu tun haben.
Das ist etwa so wie die Diskussion welche Uni nun die besseren Leute produziert. Es gibt bei allen gute und schlechte. Man muss halt die guten auswählen.
Was zählt sind Resultate.

]]> Von: Franco Dal Molin http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/comment-page-1/#comment-60221 Franco Dal Molin Fri, 07 Dec 2007 15:15:41 +0000 http://blog.internet-briefing.ch/2007/12/06/entwicklungsmethoden-in-der-praxis/#comment-60221 Gute Diskussion! Unsere Erfahrung mit Teams in Ukraine, Bulgarien und Indien spricht im Moment für die Ukraine (Kharkov). Es sind ja immer Trade-off Entscheide zu fällen zwischen Distanz, Verfügbarkeit guter Entwickler am Markt, Preise, Zeitzonen, Kulturunterschiede, usw. Kharkov ist eine grosse Unistadt mit ca. 20 Unis und 400'000 Studenten. Nur eine Zeitzone weit weg. Man kommt da über Wien gut hin. Noch nicht so hart "umkämpft" und teuer wie Kiev. Insgesamt sind wir recht zufrieden. Methodik ist wichtig, aber hier bitte nur das Minimum, dafür sollte sie gut "verinnerlicht" sein und vom remote Team getragen werden. Ein iteratives, agiles Vorgehen ist wünschenswert. Es gibt einem einfach schneller Feedback und Korrekturmöglichkeiten. Eine gute Vorlage hierfür ist "openUP" (http://epf.eclipse.org/wikis/openup/index.htm). So wie beschrieben ist die Methodik für co-located Teams optimiert, d.h. mit remote Management muss man noch mehr Wert auf offene, direkte und häufige Kommunikation legen. Vor Ort Besuche alle 3-4 Monate sind ein Muss. Auch sauberes Requirements Engineering (Dokumente) gekoppelt mit einem sehr kompetenten Technical Lead ("Senior") vor Ort sind zentrale Erfolgsfaktoren. Gewisse Prozess und Methodikschulungen sind immer nötig. Das Testcase-driven Development ist eine gute bottom-up Vorgehenstechnik aus dem "Extreme Programming" Ansatz und vor allem dann effektiv, wenn noch 2-3 andere Punkte eingehalten werden, so wie kontinuierliches Builden und automatische Unit Regressionstests. Ich würde es aber aber nicht auf die dogmatische Spitze treiben. Aus Product- und Projectmanagement Sicht scheint mir ein Use-Case-getriebenes Vorgehen (d.h. Use-Cases als kleinste Einheit für die Spezifizierung, Schätzung, Planung, und Test/Abnahme) eine gute und auch für Offshore Entwicklung praktikable Vorgehensweise. Gute Diskussion! Unsere Erfahrung mit Teams in Ukraine, Bulgarien und Indien spricht im Moment für die Ukraine (Kharkov). Es sind ja immer Trade-off Entscheide zu fällen zwischen Distanz, Verfügbarkeit guter Entwickler am Markt, Preise, Zeitzonen, Kulturunterschiede, usw. Kharkov ist eine grosse Unistadt mit ca. 20 Unis und 400′000 Studenten. Nur eine Zeitzone weit weg. Man kommt da über Wien gut hin. Noch nicht so hart “umkämpft” und teuer wie Kiev. Insgesamt sind wir recht zufrieden.

Methodik ist wichtig, aber hier bitte nur das Minimum, dafür sollte sie gut “verinnerlicht” sein und vom remote Team getragen werden. Ein iteratives, agiles Vorgehen ist wünschenswert. Es gibt einem einfach schneller Feedback und Korrekturmöglichkeiten. Eine gute Vorlage hierfür ist “openUP” (http://epf.eclipse.org/wikis/openup/index.htm). So wie beschrieben ist die Methodik für co-located Teams optimiert, d.h. mit remote Management muss man noch mehr Wert auf offene, direkte und häufige Kommunikation legen. Vor Ort Besuche alle 3-4 Monate sind ein Muss. Auch sauberes Requirements Engineering (Dokumente) gekoppelt mit einem sehr kompetenten Technical Lead (”Senior”) vor Ort sind zentrale Erfolgsfaktoren. Gewisse Prozess und Methodikschulungen sind immer nötig.

Das Testcase-driven Development ist eine gute bottom-up Vorgehenstechnik aus dem “Extreme Programming” Ansatz und vor allem dann effektiv, wenn noch 2-3 andere Punkte eingehalten werden, so wie kontinuierliches Builden und automatische Unit Regressionstests. Ich würde es aber aber nicht auf die dogmatische Spitze treiben. Aus Product- und Projectmanagement Sicht scheint mir ein Use-Case-getriebenes Vorgehen (d.h. Use-Cases als kleinste Einheit für die Spezifizierung, Schätzung, Planung, und Test/Abnahme) eine gute und auch für Offshore Entwicklung praktikable Vorgehensweise.

]]>