Clean Code Developer

Posts 1-10 of 12

Back
Next

Tim Frederic Hans Group moderator
The company name is only visible to registered members.

erste Schritte
Hallo zusammen!

ich, aber auch wir als Team können berichten, dass wir die ersten Änderungen an unserem bisherigen System vornehmen werden. Größter Einschnitt bislang wird sein, dass wir eine Art Standard Arbeitsanweisung erstellen, wo wir als Entwicklerteam festlegen, wie gewisse Programmiertechniken angewendet werden. Z.B. einigen wir uns auf bestimmte Variablendeklerationen, Kommentarstile und werden unsere CVS Umgebung aufbohren und an unser Team anpassen. In diese Anweisungen werden wir auch Regeln festlegen, wie wir und wann wir Refaktoieren, Updates einspielen und Änderungen an bestehenden Teilprojekten und deren Quellcodes vornehmen.

Dies soll natürlich nicht nur schriftlich "irgendwo" stehen um sich darauf auszuruhen sondern das ganze entstand durch zunehmenden Leistungsdruck und dadurch (leider) resultierende Fehlerquellen in Updates die wir zur Verfügung gestellt haben.

Zur Zeit sind wir ganz aktuell dabei zu Refaktorieren und in dem zuge auch unsere neuen Standards nach und nach um zu setzen.

...und noch eine Sache...so ein Armband bringt doch mehr Aufmerksamkeit als ich dachte!! ;-)

Also, wenn es interessiert werde ich gerne immer wieder mal aus eigener Erfahrung berichten, wie sich CCD auf unser kleines Entwicklerteam auswirkt.
- 11 Aug 2009, 10:27 am
Tim Frederic Hans wrote: > Hallo zusammen! > > ich, aber auch wir als Team können berichten, dass wir die ersten > Änderungen an unserem bisherigen System vornehmen werden. Größter > Einschnitt bislang wird sein, dass wir eine Art Standard > Arbeitsanweisung erstellen, wo wir als Entwicklerteam festlegen, wie > gewisse Programmiertechniken angewendet werden. Z.B. einigen wir uns > auf bestimmte Variablendeklerationen, Kommentarstile und werden > unsere CVS Umgebung aufbohren und an unser Team anpassen. In diese > Anweisungen werden wir auch Regeln festlegen, wie wir und wann wir > Refaktoieren, Updates einspielen und Änderungen an bestehenden > Teilprojekten und deren Quellcodes vornehmen. > > Dies soll natürlich nicht nur schriftlich "irgendwo" stehen um sich > darauf auszuruhen sondern das ganze entstand durch zunehmenden > Leistungsdruck und dadurch (leider) resultierende Fehlerquellen in > Updates die wir zur Verfügung gestellt haben. > > Zur Zeit sind wir ganz aktuell dabei zu Refaktorieren und in dem zuge > auch unsere neuen Standards nach und nach um zu setzen. > > ...und noch eine Sache...so ein Armband bringt doch mehr > Aufmerksamkeit als ich dachte!! ;-) > > Also, wenn es interessiert werde ich gerne immer wieder mal aus > eigener Erfahrung berichten, wie sich CCD auf unser kleines > Entwicklerteam auswirkt.
Martin Mayr
The company name is only visible to registered members.

Re: erste Schritte
Hallo Tim,

klingt interessant. Ich freue mich schon auf weitere Details.

Wir überlegen für unser Team auch immer wieder gemeinsame Standards, bzw. "normierte" Codingstandards für bestimmte Probleme einzuführen. Leider bleibt es aufgrund zum Teil sehr unterschiedlicher Auffassungen, meist bei Absichtserklärungen.

Erschwerend kommt bei uns hinzu, dass unser Kunde selbst Teile der Software schreibt und wartet. Und es ist sehr schwer seinem Kunden vorzuschreiben, was er zu tun und zu lassen hat :-).

Eine kleine Frage noch, wie groß ist euer Team ungefähr?

Viel Erfolg weiterhin bei eurem Vorstoß.

Ciao
Martin
- 11 Aug 2009, 10:10 pm
Martin Mayr wrote: > Hallo Tim, > > klingt interessant. Ich freue mich schon auf weitere Details. > > Wir überlegen für unser Team auch immer wieder gemeinsame Standards, > bzw. "normierte" Codingstandards für bestimmte Probleme einzuführen. > Leider bleibt es aufgrund zum Teil sehr unterschiedlicher > Auffassungen, meist bei Absichtserklärungen. > > Erschwerend kommt bei uns hinzu, dass unser Kunde selbst Teile der > Software schreibt und wartet. Und es ist sehr schwer seinem Kunden > vorzuschreiben, was er zu tun und zu lassen hat :-). > > Eine kleine Frage noch, wie groß ist euer Team ungefähr? > > Viel Erfolg weiterhin bei eurem Vorstoß. > > Ciao > Martin
Adrian Mörchen
The company name is only visible to registered members.

Re^2: erste Schritte
Hi,

um sich auf gemeinsame Code Conventions zu einigen kann man einen Fragebogen erstellen, der die wichtigsten Dinge enthält. Die Sachen mit den meisten Stimmen werden eben angewand. So tritt man zumindest niemanden auf den Schlips, da somit eine gewisse Gültigkeit erklärt wird. Vllt. gibt es irgendwo sogar schon solche Fragebögen.
Will man es dann ganz rigoros durchsetzen lehnt das Repository den Commit mit der Meldung, dass irgendwelche Konventionen nicht eingehalten wurden, ab. In Zeiten von Code Formattern sollte es ja eigentlich kein Problem mehr darstellen, die meisten Dinge automatisch zu erschlagen.

Ansonsten denke ich ist es wohl am Sinnvollsten innerhalb des Teams (besser Unternehmen) einen Standard zu etablieren, der dann von Kundenvorgaben überschrieben wird.
- 11 Aug 2009, 10:24 pm
Adrian Mörchen wrote: > Hi, > > um sich auf gemeinsame Code Conventions zu einigen kann man einen > Fragebogen erstellen, der die wichtigsten Dinge enthält. Die Sachen > mit den meisten Stimmen werden eben angewand. So tritt man zumindest > niemanden auf den Schlips, da somit eine gewisse Gültigkeit erklärt > wird. Vllt. gibt es irgendwo sogar schon solche Fragebögen. > Will man es dann ganz rigoros durchsetzen lehnt das Repository den > Commit mit der Meldung, dass irgendwelche Konventionen nicht > eingehalten wurden, ab. In Zeiten von Code Formattern sollte es ja > eigentlich kein Problem mehr darstellen, die meisten Dinge > automatisch zu erschlagen. > > Ansonsten denke ich ist es wohl am Sinnvollsten innerhalb des Teams > (besser Unternehmen) einen Standard zu etablieren, der dann von > Kundenvorgaben überschrieben wird.
Ralf Westphal Premium Member Group moderator
The company name is only visible to registered members.

Re^2: erste Schritte
hallo, martin!

der kunde entwickelt mit? ihr habt also ein verteiltes team?
wie ist denn da der code aufgeteilt, dass es zu problemen kommt, wenn dein team konventionen einführen will?

-ralf
- 12 Aug 2009, 08:34 am
Ralf Westphal wrote: > hallo, martin! > > der kunde entwickelt mit? ihr habt also ein verteiltes team? > wie ist denn da der code aufgeteilt, dass es zu problemen kommt, wenn > dein team konventionen einführen will? > > -ralf
Tim Frederic Hans Group moderator
The company name is only visible to registered members.

Re^3: erste Schritte
Hi zusammen!

unser Team ist mit 4 Leuten und einem Azubi sehr klein, daher ist es für uns natürlich extrem leicht Konventionen festzulegen. Bislang war es natürlich so, dass jeder so coded wie er wollte allerdings hat die Erfahrung allen Beteiligten gezeigt, dass es so nicht funktionieren kann. Und wenn sich dahingehend ein Team einig ist, ist es natürlich leichter Std. zu definieren an die sich alle versuchen (!!) zu halten ;-)
Eine Spezialität haben wir allerdings noch: wir haben unsere DB-Software auf Oracle Basis gekauft inkl der gesamten Entwicklungsumgebung und den benötigten Lizenzen. Über ein CVS System arbeiten wir auch mit dem Softwarehersteller zusammen und müssen daher auch schauen, wie wir uns mit denen einigen. Was aber auch leichter sein wird als es sich anhört, da die Zusammenarbeit hier sehr gut ist....

Ich bin mal gespannt, wie es bei uns weiter geht, die Anfänge sind zumindest gemacht und viel versprechend!!

Lucky Coding

Tim
- 12 Aug 2009, 08:47 am
Tim Frederic Hans wrote: > Hi zusammen! > > unser Team ist mit 4 Leuten und einem Azubi sehr klein, daher ist es > für uns natürlich extrem leicht Konventionen festzulegen. Bislang war > es natürlich so, dass jeder so coded wie er wollte allerdings hat die > Erfahrung allen Beteiligten gezeigt, dass es so nicht funktionieren > kann. Und wenn sich dahingehend ein Team einig ist, ist es natürlich > leichter Std. zu definieren an die sich alle versuchen (!!) zu halten > ;-) > Eine Spezialität haben wir allerdings noch: wir haben unsere > DB-Software auf Oracle Basis gekauft inkl der gesamten > Entwicklungsumgebung und den benötigten Lizenzen. Über ein CVS System > arbeiten wir auch mit dem Softwarehersteller zusammen und müssen > daher auch schauen, wie wir uns mit denen einigen. Was aber auch > leichter sein wird als es sich anhört, da die Zusammenarbeit hier > sehr gut ist.... > > Ich bin mal gespannt, wie es bei uns weiter geht, die Anfänge sind > zumindest gemacht und viel versprechend!! > > Lucky Coding > > Tim
Ralf Westphal Premium Member Group moderator
The company name is only visible to registered members.

Re: erste Schritte
hi, tim!

find ich super, dass ihr euch solche gedanken macht darüber, wie ihr als team zukünftig besseren code schreiben könnt. schön, dass die armbänder helfen :-)

allerdings werde ich hellhörig, wenn ich "dokumente" heraushöre, in denen "richtlinien" aufgeschrieben werden. für ein paar konventionen (z.b. zum "aussehen" von code) mögen die passend sein, solange sie nur ein paar seiten umfassen. doch alles andere... hm... "wann refaktorisieren wir?" antworten auf solche fragen kann man, glaube ich, nicht in einem dokument festlegen.

wenn ein chef möchte, dass endlich mal alles festgelegt wird, was guten code erzeugt, dann verstehe ich das. aber ein dokument, dass dann ein neuer programmierer nur lesen muss, um solchen code auch zu schreiben, kann es kaum geben.

das ccd-wiki mag so aussehen, ist aber am ende kein solches dokument. es enthält nämlich eigentl keine entscheidungsregeln, sondern beschreibt codequalität auf einer grundlegenderen ebene. oder seine einzige regel ist ganz einfach: wende jeden baustein immer an :-)

ich bin also skeptisch, wenn ich höre, dass ein team erstmal ein konventionendokument entwickeln muss. das hört sich für mich nach "kontrollzwang" (sorry!) an und danach, dass am ende das dokument schon dafür sorgt, dass die qualität sich einstellt.

vermissen tue ich in deiner beschreibung dreierlei:
-den prozess
-reviews
-zieldefinition

der prozess, ja der muss tatsächlich explizit definiert und eingehalten werden. es muss halt ein vorgehensmodell geben, eine "rhythmisierung" der arbeit. ein beispiel wäre scrum. ccd nennt dafür als mindestbaustein die iteration.

innerhalb dieses prozesses muss es dann definierten raum für reviews geben (code review und prozess review (retrospektive)). aufgabe des prozesses ist es, genau dafür einen rahmen zu bieten.

innerhalb der reviews ist dann zu prüfen, ob die ccd bausteine angewandt wurden. aber dafür braucht es eben kein weiteres dokument. das ccd-wertesystem ist ja kompakt. für jeden ein poster, wie es hier im forum vorgestellt wurde, reicht.

doch auch wenn die ccd bausteine alle natürlich total klasse sind ;-), braucht ihre anwendung einen rahmen. damit meine ich kein dokument, das sie reglementiert, sondern eine zielvorstellung. code muss im hinblick auf gemeinsame zielvorstellungen des teams durchgesehen werden. ausgangspunkt dafür sind die werte von ccd. die frage ist dann immer wieder "kompromittiert diese oder jene codesituation einen ccd wert?" wenn ja, welcher baustein verbessert die situation? zu den ccd werten können aber natürlich auch andere treten, wie "minimale reaktionszeit bei kundenanfragen" oder so.

für die gemeinsamen ziele ist auch noch konsens nötig. die müssen wirklich alle teilen. als auch der chef die evolvierbarkeit :-) aber das war quasi das letzte mal, dass konsenS nötig war. anschließend geht es nur noch im konsenT (mit T).

konsent ist eine andere entscheidungsform. bei der müssen nicht alle einem vorschlag zustimmen. vielmehr wird nur danach gesucht, ob irgendwer einen wirklich wesentlichen einwand hat. da schlägt jmd vor, "wir sollten aus dem code hier eine klasse rausziehen, die..." (also eine refaktorisierung) mit der müssen eben nicht alle übereinstimmen, sondern sich nur fragen: "widerspricht dieser vorschlag einem unserer ziele?"

wenn man im team nicht mehr immer nach konsens sucht, sondern konsent, dann werden entscheidungsprozesse erstens beschleunigt und zweitens die resultate tragfähiger. hier habe ich konsent in 2-3 artikeln näher beschrieben: http://ralfw.blogspot.com/search/label/Soziokratie

beschreib doch mal, tim, wie ihrs im team mit prozess, reviews und zielen/entscheidungsfindung haltet?

cheerio!

ralf
- 12 Aug 2009, 09:12 am
Ralf Westphal wrote: > hi, tim! > > find ich super, dass ihr euch solche gedanken macht darüber, wie ihr > als team zukünftig besseren code schreiben könnt. schön, dass die > armbänder helfen :-) > > allerdings werde ich hellhörig, wenn ich "dokumente" heraushöre, in > denen "richtlinien" aufgeschrieben werden. für ein paar konventionen > (z.b. zum "aussehen" von code) mögen die passend sein, solange sie > nur ein paar seiten umfassen. doch alles andere... hm... "wann > refaktorisieren wir?" antworten auf solche fragen kann man, glaube > ich, nicht in einem dokument festlegen. > > wenn ein chef möchte, dass endlich mal alles festgelegt wird, was > guten code erzeugt, dann verstehe ich das. aber ein dokument, dass > dann ein neuer programmierer nur lesen muss, um solchen code auch zu > schreiben, kann es kaum geben. > > das ccd-wiki mag so aussehen, ist aber am ende kein solches dokument. > es enthält nämlich eigentl keine entscheidungsregeln, sondern > beschreibt codequalität auf einer grundlegenderen ebene. oder seine > einzige regel ist ganz einfach: wende jeden baustein immer an :-) > > ich bin also skeptisch, wenn ich höre, dass ein team erstmal ein > konventionendokument entwickeln muss. das hört sich für mich nach > "kontrollzwang" (sorry!) an und danach, dass am ende das dokument > schon dafür sorgt, dass die qualität sich einstellt. > > vermissen tue ich in deiner beschreibung dreierlei: > -den prozess > -reviews > -zieldefinition > > der prozess, ja der muss tatsächlich explizit definiert und > eingehalten werden. es muss halt ein vorgehensmodell geben, eine > "rhythmisierung" der arbeit. ein beispiel wäre scrum. ccd nennt dafür > als mindestbaustein die iteration. > > innerhalb dieses prozesses muss es dann definierten raum für reviews > geben (code review und prozess review (retrospektive)). aufgabe des > prozesses ist es, genau dafür einen rahmen zu bieten. > > innerhalb der reviews ist dann zu prüfen, ob die ccd bausteine > angewandt wurden. aber dafür braucht es eben kein weiteres dokument. > das ccd-wertesystem ist ja kompakt. für jeden ein poster, wie es hier > im forum vorgestellt wurde, reicht. > > doch auch wenn die ccd bausteine alle natürlich total klasse sind > ;-), braucht ihre anwendung einen rahmen. damit meine ich kein > dokument, das sie reglementiert, sondern eine zielvorstellung. code > muss im hinblick auf gemeinsame zielvorstellungen des teams > durchgesehen werden. ausgangspunkt dafür sind die werte von ccd. die > frage ist dann immer wieder "kompromittiert diese oder jene > codesituation einen ccd wert?" wenn ja, welcher baustein verbessert > die situation? zu den ccd werten können aber natürlich auch andere > treten, wie "minimale reaktionszeit bei kundenanfragen" oder so. > > für die gemeinsamen ziele ist auch noch konsens nötig. die müssen > wirklich alle teilen. als auch der chef die evolvierbarkeit :-) aber > das war quasi das letzte mal, dass konsenS nötig war. anschließend > geht es nur noch im konsenT (mit T). > > konsent ist eine andere entscheidungsform. bei der müssen nicht alle > einem vorschlag zustimmen. vielmehr wird nur danach gesucht, ob > irgendwer einen wirklich wesentlichen einwand hat. da schlägt jmd > vor, "wir sollten aus dem code hier eine klasse rausziehen, die..." > (also eine refaktorisierung) mit der müssen eben nicht alle > übereinstimmen, sondern sich nur fragen: "widerspricht dieser > vorschlag einem unserer ziele?" > > wenn man im team nicht mehr immer nach konsens sucht, sondern > konsent, dann werden entscheidungsprozesse erstens beschleunigt und > zweitens die resultate tragfähiger. hier habe ich konsent in 2-3 > artikeln näher beschrieben: > http://ralfw.blogspot.com/search/label/Soziokratie > > beschreib doch mal, tim, wie ihrs im team mit prozess, reviews und > zielen/entscheidungsfindung haltet? > > cheerio! > > ralf
Tim Frederic Hans Group moderator
The company name is only visible to registered members.

Re^2: erste Schritte
Hi Ralf,

da hast Du natürlich recht, dass man nicht festlegen kann ab welchem Zeitpunkt es am besten ist zu refakturieren etc. Wir wollen einfach versuchen überhaupt mal fest zu halten, dass wir uns zukünftig mit dem Thema mehr beschäftigen müssen/sollten und nach welchen Regeln wir das dann tun: sprich welche Konventionen wir dabei festlegen, nicht Zeitpunkte.

Das ist aber eigentlich bei allen Entscheidungen und Prozessentwicklungen so, dass wir uns im Team zusammen setzen und eine Codeänderung, Anwenderanforderungen, Updates/Releases etc. diskutieren. Der Abteilungsleiter bzw. unser Chef hält sich da eigentlich raus aus dem eigentlichen Programmieren. Denn er kann es technisch nicht beurteilen bzw. überlässt die Umsetzung uns. Um aber im Team einen festen Ansprechpartner und Projektverantwortlichen zu haben fungiere ich als Teamleiter und damit als Bindeglied zwischen Team und dem "rest der Welt"... ;-)

Ich denke da haben wir auch den Vorteil bei der größe unseres Teams, dass jegliche Entscheidungswege sehr kurz sind. Man setzt sich mal eben schnell zusammen oder diskutiert an der Kaffeemaschine das weitere Vorgehen durch. Schön wäre natürlich, wenn der Wunschtermin eines Releases auch bei uns läge...;-) aber wer träumt da nicht von!?

Frage ist natürlich, was erhoffen wir uns mit einer Std.Arbeitsanweisung....? Wir denken, dass wir einfach nur mal für uns klarziehen, wie wir in Zukunft arbeiten wollen und jedem klar ist wie wir an ein Projekt rangehen. Ein großer Punkt ist da gerade bei uns das überarbeiten von bestehenden Code und deshalb auch das Thema refakturieren. Denn das hielt jeder bislang wie ein Dachdecker :-D
Und das ist einfach auch eher als die Zieldefinition für uns zu sehen. Ein Versuch sich auf Grundregeln zu einigen und nicht nur darüber zu sprechen, dass man das wohl mal machen müsste sondern einfach klar ist: das unser Ziel, wir wollen strukturierter arbeiten; haben einen gemeinsamen Std.; versuchen den Code zu verbessern und all das auf eine Weise, die jeder umsetzen kann und jeder sofort übernehmen kann, wenn der Kollege im Urlaub ist.
Mir ist natürlich bewusst, dass das ein verdammt hohes Ziel ist, was mit Sicherheit nicht einfach zu 100% umsetzbar ist, aber machbar. Ich wiederhole mich ja ungern, aber ich denke wir als kleines Team haben da gute Chancen. Und dieses Forum und das ganze CCD Konzept hilft uns hier schon ungemein...

..hoffe ich habe jetzt einiges klarer ausgedrückt...

lucky coding

tim
This post was modified on 12 Aug 2009 at 09:58 am.
- 12 Aug 2009, 09:57 am
Tim Frederic Hans wrote: > Hi Ralf, > > da hast Du natürlich recht, dass man nicht festlegen kann ab welchem > Zeitpunkt es am besten ist zu refakturieren etc. Wir wollen einfach > versuchen überhaupt mal fest zu halten, dass wir uns zukünftig mit > dem Thema mehr beschäftigen müssen/sollten und nach welchen Regeln > wir das dann tun: sprich welche Konventionen wir dabei festlegen, > nicht Zeitpunkte. > > Das ist aber eigentlich bei allen Entscheidungen und > Prozessentwicklungen so, dass wir uns im Team zusammen setzen und > eine Codeänderung, Anwenderanforderungen, Updates/Releases etc. > diskutieren. Der Abteilungsleiter bzw. unser Chef hält sich da > eigentlich raus aus dem eigentlichen Programmieren. Denn er kann es > technisch nicht beurteilen bzw. überlässt die Umsetzung uns. Um aber > im Team einen festen Ansprechpartner und Projektverantwortlichen zu > haben fungiere ich als Teamleiter und damit als Bindeglied zwischen > Team und dem "rest der Welt"... ;-) > > Ich denke da haben wir auch den Vorteil bei der größe unseres Teams, > dass jegliche Entscheidungswege sehr kurz sind. Man setzt sich mal > eben schnell zusammen oder diskutiert an der Kaffeemaschine das > weitere Vorgehen durch. Schön wäre natürlich, wenn der Wunschtermin > eines Releases auch bei uns läge...;-) aber wer träumt da nicht von!? > > Frage ist natürlich, was erhoffen wir uns mit einer > Std.Arbeitsanweisung....? Wir denken, dass wir einfach nur mal für > uns klarziehen, wie wir in Zukunft arbeiten wollen und jedem klar ist > wie wir an ein Projekt rangehen. Ein großer Punkt ist da gerade bei > uns das überarbeiten von bestehenden Code und deshalb auch das Thema > refakturieren. Denn das hielt jeder bislang wie ein Dachdecker :-D > Und das ist einfach auch eher als die Zieldefinition für uns zu > sehen. Ein Versuch sich auf Grundregeln zu einigen und nicht nur > darüber zu sprechen, dass man das wohl mal machen müsste sondern > einfach klar ist: das unser Ziel, wir wollen strukturierter arbeiten; > haben einen gemeinsamen Std.; versuchen den Code zu verbessern und > all das auf eine Weise, die jeder umsetzen kann und jeder sofort > übernehmen kann, wenn der Kollege im Urlaub ist. > Mir ist natürlich bewusst, dass das ein verdammt hohes Ziel ist, was > mit Sicherheit nicht einfach zu 100% umsetzbar ist, aber machbar. Ich > wiederhole mich ja ungern, aber ich denke wir als kleines Team haben > da gute Chancen. Und dieses Forum und das ganze CCD Konzept hilft uns > hier schon ungemein... > > ..hoffe ich habe jetzt einiges klarer ausgedrückt... > > lucky coding > > tim
Ralf Westphal Premium Member Group moderator
The company name is only visible to registered members.

Re^3: erste Schritte
hi, tim!

hört sich schon besser an :-) die motivation verstehe ich in jedem fall und finde es gut, dass ihr euch bewusster aufstellen wollt.

macht es euch andererseits aber auch nicht zu schwer!

wenn ihr euch an der kaffeemaschine auf CCD als mittel und sein wertesystem als ziel einigt, dann müsst ihr nur 1 seite "arbeitsanweisung" schreiben. der rest steht im wiki und so. dann kann zukünftig jeder im team den anderen auf etwas hinweise mit bezug auf CCD: "schau mal, hier würde ich nach SRP refaktorisieren, um die evolvierbarkeit zu erhöhen." (baustein + wert) oder "lasst uns doch mal einen codereview abhalten, um zu checken, ob wir schon alle wesentlichen fälle mit tests abdecken" (baustein + wert korrektheit)

du erwähnst noch den traum, einen releasetermin als team festlegen zu können. da möchte ich noch kurz einhaken: solch einen traum halte ich für irrig (in den allllermeisten fällen). ich träume ihn zumindest nicht. releasetermine im sinne von großen meilensteinen, d.h. konkreten inhalten (fixer scope) funktionieren für softwareentwicklung schon seit 40 jahren nicht so recht. wer daran weiterhin glaubt und versucht, sie anzustreben (chef, kunde oder entwickler), wird ewig frustriert sein.

deshalb überlegt doch mal, ob ihr euren traum nicht ändert. träumt doch mal von der einführung von timeboxes ohne fixen scope. wie wäre das? das ist (für den kunden) gewöhnungsbedürftig, aber viiiel realistischer. dieses buch kann ich dazu grad empfehlen:

http://www.amazon.de/Scrum-User-Stories-Ralf-Wirdemann/dp/34...

ein wenig scrum-vorwissen ist dafür allerdings nützlich. wer das noch nicht hat, der kann vorweg dies lesen:

http://www.amazon.de/Scrum-Produkte-zuverlässig-schnell-entw...

beide bücher von hanser sind nicht nur schön anzufassen, sondern auch gut zu lesen, finde ich.

enjoy!

ralf
- 12 Aug 2009, 11:31 am
Ralf Westphal wrote: > hi, tim! > > hört sich schon besser an :-) die motivation verstehe ich in jedem > fall und finde es gut, dass ihr euch bewusster aufstellen wollt. > > macht es euch andererseits aber auch nicht zu schwer! > > wenn ihr euch an der kaffeemaschine auf CCD als mittel und sein > wertesystem als ziel einigt, dann müsst ihr nur 1 seite > "arbeitsanweisung" schreiben. der rest steht im wiki und so. dann > kann zukünftig jeder im team den anderen auf etwas hinweise mit bezug > auf CCD: "schau mal, hier würde ich nach SRP refaktorisieren, um die > evolvierbarkeit zu erhöhen." (baustein + wert) oder "lasst uns doch > mal einen codereview abhalten, um zu checken, ob wir schon alle > wesentlichen fälle mit tests abdecken" (baustein + wert korrektheit) > > du erwähnst noch den traum, einen releasetermin als team festlegen zu > können. da möchte ich noch kurz einhaken: solch einen traum halte ich > für irrig (in den allllermeisten fällen). ich träume ihn zumindest > nicht. releasetermine im sinne von großen meilensteinen, d.h. > konkreten inhalten (fixer scope) funktionieren für > softwareentwicklung schon seit 40 jahren nicht so recht. wer daran > weiterhin glaubt und versucht, sie anzustreben (chef, kunde oder > entwickler), wird ewig frustriert sein. > > deshalb überlegt doch mal, ob ihr euren traum nicht ändert. träumt > doch mal von der einführung von timeboxes ohne fixen scope. wie wäre > das? das ist (für den kunden) gewöhnungsbedürftig, aber viiiel > realistischer. dieses buch kann ich dazu grad empfehlen: > > http://www.amazon.de/Scrum-User-Stories-Ralf-Wirdemann/dp/3446416560 > > ein wenig scrum-vorwissen ist dafür allerdings nützlich. wer das noch > nicht hat, der kann vorweg dies lesen: > > http://www.amazon.de/Scrum-Produkte-zuverlässig-schnell-entwickeln/dp/3446419136 > > beide bücher von hanser sind nicht nur schön anzufassen, sondern auch > gut zu lesen, finde ich. > > enjoy! > > ralf
Martin Mayr
The company name is only visible to registered members.

Re^4: erste Schritte
Hallo Ralf,

unser Team ist tatsächlich geteilt. Im Prinzip sogar in 3 Standorte. Zum einen sind wir in unserer eigenen Firma in 2 nebeneinanderliegende Gebäude aufgeteilt und der Kunde ist geographisch noch weiter entfernt. Innerhalb der Firma treffen wir uns einmal täglich zu einer kurzen Besprechung um uns auszutauschen.

Was den Kunden angeht, gibt es einen Ansprechpartner auf unserer und einen auf Kundenseite. Abstimmung gibt es aber fast außschließlich, was die Aufgaben angeht, die wir erledigen sollen. Was der Kunde konkret am SourceCode macht wird uns nur schemenhaft mitgeteilt.

Die gemeinsame Schnittstelle in Sachen Code ist die SourceCode-Verwaltung, auf die alle Teamteile Zugriff haben.

Absprachen, die wir mit den Entwicklern auf Kundenseite treffen haben oft nur kurz Bestand, da der Abteilungsleiter auf Kundenseite sich nicht an sein "Geschwätz von gestern" gebunden fühlt und Dinge anweist, die unseren Absprachhen widersprechen.

Das ist die eine Seite, die wir nicht direkt ändern können. Auf der anderen Seite sind nur Teile unseres eigenen Teams dazu bereit, sich auch mal außerhalb der normalen Geschäftszeiten sich mit dem Thema Clean Code außeinander zu setzen und die Disziplin aufzubringen, sich an derartige Regeln zu halten. Nur mit gutem Zureden kommen wir da leider nicht weiter und es fehlt die Unterstützung von Vorgesetzten um dieses Ziel anderweitig durchzusetzen.

Der "willige" Teil des Teams hat sich jetzt soweit abgestimmt, dass wir für uns eine Zeit lang versuchen wollen, unser Bestes in Sachen Clean Code zu geben, soweit es unter diesen Bedingungen möglich ist, in der Hoffnung, dass unsere Kollegen die Vorteile sehen und diesem Weg folgen.

Viele Grüße
Martin
- 13 Aug 2009, 9:16 pm
Martin Mayr wrote: > Hallo Ralf, > > unser Team ist tatsächlich geteilt. Im Prinzip sogar in 3 Standorte. > Zum einen sind wir in unserer eigenen Firma in 2 > nebeneinanderliegende Gebäude aufgeteilt und der Kunde ist > geographisch noch weiter entfernt. Innerhalb der Firma treffen wir > uns einmal täglich zu einer kurzen Besprechung um uns auszutauschen. > > Was den Kunden angeht, gibt es einen Ansprechpartner auf unserer und > einen auf Kundenseite. Abstimmung gibt es aber fast außschließlich, > was die Aufgaben angeht, die wir erledigen sollen. Was der Kunde > konkret am SourceCode macht wird uns nur schemenhaft mitgeteilt. > > Die gemeinsame Schnittstelle in Sachen Code ist die > SourceCode-Verwaltung, auf die alle Teamteile Zugriff haben. > > Absprachen, die wir mit den Entwicklern auf Kundenseite treffen haben > oft nur kurz Bestand, da der Abteilungsleiter auf Kundenseite sich > nicht an sein "Geschwätz von gestern" gebunden fühlt und Dinge > anweist, die unseren Absprachhen widersprechen. > > Das ist die eine Seite, die wir nicht direkt ändern können. Auf der > anderen Seite sind nur Teile unseres eigenen Teams dazu bereit, sich > auch mal außerhalb der normalen Geschäftszeiten sich mit dem Thema > Clean Code außeinander zu setzen und die Disziplin aufzubringen, sich > an derartige Regeln zu halten. Nur mit gutem Zureden kommen wir da > leider nicht weiter und es fehlt die Unterstützung von Vorgesetzten > um dieses Ziel anderweitig durchzusetzen. > > Der "willige" Teil des Teams hat sich jetzt soweit abgestimmt, dass > wir für uns eine Zeit lang versuchen wollen, unser Bestes in Sachen > Clean Code zu geben, soweit es unter diesen Bedingungen möglich ist, > in der Hoffnung, dass unsere Kollegen die Vorteile sehen und diesem > Weg folgen. > > Viele Grüße > Martin
Tim Frederic Hans Group moderator
The company name is only visible to registered members.

Re^5: erste Schritte
Hi Martin!

ja das Problem kennen wir natürlich auch. Wir haben zwei Arten von Kunden:

1. die internen die unser DB System nutzen und erweitert wissen wollen
2. unsere eigentlich Firmenkunden (wir sind Dienstleister), die immer mehr verstärkt auf Schnittstellen zurückgreifen möchten

So bekommt man doppelt Druck, wobei der interne manchmal stärker ist, da es ja alle Kollegen sind und die Wege dort natürlich kurz sind und jeder seine Anforderungen schnellstmöglich durchgesetzt haben möchte. Deshalb weiss ich nicht, was schlimmer ist. Interne oder externe Kundschaft ;-)
- 14 Aug 2009, 09:42 am
Tim Frederic Hans wrote: > Hi Martin! > > ja das Problem kennen wir natürlich auch. Wir haben zwei Arten von > Kunden: > > 1. die internen die unser DB System nutzen und erweitert wissen wollen > 2. unsere eigentlich Firmenkunden (wir sind Dienstleister), die immer > mehr verstärkt auf Schnittstellen zurückgreifen möchten > > So bekommt man doppelt Druck, wobei der interne manchmal stärker ist, > da es ja alle Kollegen sind und die Wege dort natürlich kurz sind und > jeder seine Anforderungen schnellstmöglich durchgesetzt haben möchte. > Deshalb weiss ich nicht, was schlimmer ist. Interne oder externe > Kundschaft ;-)

Back
Next