meine Firmenerfahrung ist nicht die Größte, neben der Firma in der ich meine Ausbildung gemacht habe, habe ich sonst nur in zwei Firmen richtig gearbeitet. Mich würde aber mal interessieren, wie sehr andere Entwickler im allgemeinen in die Prozessgestaltung eingebunden werden.
Gibt es ein vorbildliches Scrum, mit regelmäßigen Retrospektivenmeetings? Wird auf Zuruf gearbeitet? Setzt ihr euch dafür ein, dass sich Prozesse bei euch ändern und an das echte Leben angepasst werden? Macht ihr euch überhaupt Gedanken um die Prozesse?
Ich komme auf die Diskussion, weil ich mich mit einem befreundeten Entwickler unterhalten habe. Der es komisch findet, dass ich, als Softwareentwickler, jetzt schon zum 2. Mal einer Firma helfe TFS einzurichten, inkl. Mithilfe einer Ausarbeitung der Prozesse, die hinter dem System stehen. Während ich es bei ihm eher komisch finde, dass es für ihn so ganz egal ist wie die Firma arbeitet und es in Ordnung findet, dass er eigentlich gefühlte 50% Überstunden macht, weil seine Firma anscheinend nicht planen kann.
Meine goldene Regel: je größer die Firma ist, umso schlimmer ist es. Entweder sind die Prozesse hoffnungslos bürokratisiert und man muss sich durch Berge an Dokumentationen arbeiten und Entscheidungen und Meetings hinter sich bringen, bevor man ein Diagramm zeichnen oder eine Zeile Code schreiben darf. Oder es ist agil-agil, sprich das Business liefert die Änderungswünsche direkt beim Entwickler ab (vorbei am Architekten und Projektleiter) ohne dass sich der Projektplan anpasst. Vor allem ist es schwierig, da Änderungen herbeizuführen.
Am besten sind kleinere Firmen (keine Start-Ups, die sind meist chaotisch und verbrennen ihre Entwickler) die schon ein paar Jahre Projekterfahrungen haben. Mehr oder weniger flexible Prozesse. Jeder ist Spezialist für etwas und wird auch entsprechend eingesetzt. Technologische Änderungen etc. werden schneller mitgemacht als in großen Firmen oder risikokapitalfinanzierten Start-Ups, welche heute ASP.NET machen und morgen ihre Plattform auf Flash umstellen.
Ich finde es z.B. eher komisch, dass du erst den TFS einrichtest und dann die Prozesse definierst, die dahinter stehen. Daran sieht man mal wieder wunderbar den Grund, warum in vielen Firmen sowas nicht funktioniert. Und das hat meiner Erfahrung nach nichts mit der Größe zu tun. Ich arbeite jetzt bei einer großen Firma, bei der die Prozesse nicht vorhanden sind und komme von einer kleinen Firma, die nur auf Zuruf gearbeitet hat und das dann als agil verkauft hat.
Für die Softwareentwicklung in allen Größen und Komplexitäten gilt: Ohne Prozess funktioniert es nicht. Und einen richtigen Prozess gibt es nicht. Der muss anpassbar sein an das jeweilige Projekt und die Aufgaben. Es ist numal ein Unterschied, ob das Projekt 4 Wochen läuft und 3 Entwickler beteiligt sind, oder 3 Jahre und hunderte Entwickler involviert sind. Dann kann ich beide Projekte agil betreiben, aber das ist dann auch schon der gemeinsame Nenner.
Was meiner Meinung nach immer zu kurz kommt ist das Requirement Engineering. Und dass zu wenige der Aspekte eines solchen Softwareprojektes bewertet wird. Das ganze ist komplex und nur weil ich einen TFS einrichte habe ich noch lange keinen Prozess. Und ich kann mir auch keinen Prozess aus dem TFS ableiten. Der Prozess muss aus den rjekten udn der Firma und deren Mitarbeiter entwickelt werden. Und dann nehme ich mir den TFS her um diesen Prozess abzubilden. Und dann muss ich mir den TFS oder meinen Prozess anpassen. Auf jeden Fall macht sich in den meisten Fällen niemand im vorfeld umfassend Gedanken macht.
Zu deiner Eingangs gestellten Frage, wie weit man sich als entwickler in solche Prozessfindung mit einspannen lässt oder das sogar selbst betreibt, ist denke ich eine persönliche Entscheidung. Wie bei deinem Bekannten zu sehen sind viele Entwickler mit einer Situation zufrieden und arrangieren sich damit. Andere sehen das Problem dahinter und versuchen an der Basis daran waszu ändern. Wenn die Zeit sich hier zu beteiligen gegeben ist, dan ist es ok. wenn man sich quasi zu seiner Arbeit um solche Dinge kümmern muss, dann ist an dem ganzen Prozess schon wieder was faul und kann so nicht funktionieren.
Ich sagte ja "inkl. Ausarbeitung der Prozesse". Es wird natürlich nicht installiert und dann geguckt, wie man mit arbeiten könnte. ;) Einem kleinen Satz stimme ich nicht zu: "Und ich kann mir auch keinen Prozess aus dem TFS ableiten.". Man könnte schon, MSF Agile und Scrum sind ziemlich eng miteinander verbunden. Nur funktioniert halt nicht jeder Prozess in jeder Firma.
Einem kleinen Satz stimme ich nicht zu: "Und ich kann mir auch keinen Prozess aus dem TFS ableiten.". Man könnte schon, MSF Agile und Scrum sind ziemlich eng miteinander verbunden. Nur funktioniert halt nicht jeder Prozess in jeder Firma.