Kategorien
Stellt die richtigen Fragen!
Als Scrum-Master darf ich derzeit nicht wirklich aktiv mitprogrammieren. Ist einerseits ok, da die anderen sonst eh neidisch sind auf den tollen Code, den ich schreibe, andererseits kann man natürlich nicht so viel von seinen Erfahrungen weitergeben. Und da ich gerne mein Wissen teile, mache ich das derzeit auf einer Metaebene. Konkret sieht das im Moment so aus, dass ich versuche das Team dazu zu bringen, die richtigen Fragen selbst zu stellen.
Warum ist das aber so wichtig? Ich glaube sobald wir aufhören kritisch zu uns selbst zu sein, beginnen wir unsauber zu arbeiten. Derzeit arbeiten wir an einem großen Symfony2-Projekt und das Team ist eines der besten mit dem ich je zusammenarbeiten durfte. Jetzt gab es vor kurzem einen Zeitpunkt, wo wir den Symfony-Weg verlassen haben, um performanter Rendern zu können. Ist das gut? Nein, den Standardweg zu verlassen ist sicher keine gute Idee, denn ab dort wird es für andere schwierig sich einzuarbeiten und allgemeine Tutorials helfen einem auch nicht mehr. Ist es für unsere Situation trotzdem der bessere Weg? Ja ist es. Die Standard-Seite rendert 5-fach so schnell wie zuvor.
Das Team hat vorher nicht explizit über dieses Thema geredet, jeder hatte im Kopf, dass wir Performance gewinnen mit dem Vorgehen und das ist ja schließlich gut. Was es aber wirklich heißt, das war den meisten nicht klar. Wichtige Fragen, die wir uns also stellen mussten waren zum Beispiel “Verlassen wir den Standard-Weg?”, “Was bringt uns diese Optimierung?”, “Brauchen wir sie im Moment?”, “Optimierungen haben meist auch Nachteile, welche sind diese hier?”.
Nachdem wir alle Pros und Contras aufgenommen hatten, haben wir uns dafür entschieden die Änderungen vorzunehmen. Jetzt denken einige, dass wir so lange diskutiert haben und dann kam trotzdem das gleiche bei raus, was schon vorher im Raum stand. So viel haben wir also nicht gewonnen. Naja wenn man Dinge nicht hinterfragt und trotzdem richtig liegt, dann nennt man das Glück und das kann man ja bekanntlich nicht immer haben.
Wichtig ist auch, wenn man die richtigen Fragen in einem formellen Rahmen immer wieder fragt, wird sich jeder Entwickler diese schon im Vorfeld gestellt haben und damit sind die Antworten bereits bekannt. Dadurch werden die Entwickler wieder ein Stück besser.
Wenn eure Lösung zum rendern so viel schneller ist, habt ihr dann auch vor sie wieder der Community zur Verfügung zu stellen? Da könnten schliesslich noch viel mehr Leute was von haben.
Hi Nils
Ja, ich finde es auch ganz wichtig, immer wieder Fragen zu stellen und diese auch im Team zu beantworten. Die Entwickler müssen wissen, warum sie es so und nicht anders machen.
Ich finde es auch sehr wichtig, dass solche Entscheidungen dokumentiert werden. Vielleicht sogar mit den verschiedenen Varianten und warum man sich für eine konkrete Variante entschieden hat.
So fällt es leichter, wenn neue Entwickler in das Projekt einsteigen. Diese können dann nachvollziehen, warum etwas so und nicht anders gelöst wurde.
@Christian: Hier ein wenig ausführlicher als über Twitter. Wir haben Symfony2 nicht beschleunigt. Wir haben es geschafft schneller zu werden bei den hunderten von Teilsnippets die wir vom CMS bekommen und rendern müssen.
Open Source ist aber in der Tat großes Thema bei uns und sicherlich wird einiges an Bundles die entstehen auch wieder wieder zurückfließen.
@Nils: „Open Source ist aber in der Tat großes Thema bei uns und sicherlich wird einiges an Bundles die entstehen auch wieder wieder zurückfließen.“ -> Besser hätte man einer konkreten Aussage, ob ihr der Community was zurückgebt nicht aus dem Weg gehen können… 😉 Alleine das Wort – sicherlich – lässt alles offen… Schade eigentlich!!
Man glaubt garnicht, wie viel einfacher das Leben wird, wenn man einfach mal in die Runde fragt: „War was eine Entscheidung?“ Das hionterlässt nicht diesen leeren Raum, wo sich ja angeblich alle noch einig waren 😉
@Stefan: Wir haben schon einiges als Open-Source rausgegeben und contributen auch bei sf2 mit (wenn das mein Deutschlehrer lesen würde). Ob es in dem konkreten Fall klappen wird, kann ich erst sagen, wenn das Feature fertig ist und wir den Mehrwert für die Community sehen.
@Nils, denn schreib das doch auch so… 😉 Sicherlich, mal sehen, bestimmt unter Umstände, so totschlag Wörter bin ich eigentlich nur von Politikern oder Google gewohnt… Und da wird meist nur Mist mit veranstaltet… 😛
Moin Nils,
ich denke das der „Standardweg“ zwar immer für 98% funktioniert, aber das wahre Problem anfängt wenn man mehr am Standard festhält als den Fokus für eine gute Lösung zu behalten.
Ich habe schon viele Projekte gegen die Wand fahren sehen weil krampfhaft versucht wurde im vermeintlichen Standard zu bleiben, anstatt die Software (SF2, ZF, FLOW3, …) als Teil der eigenen Lösung zu betrachten, den man aber jeder Zeit anpassen und verändern kann.
Frameworks und CMS sind gute Tools, bieten aber, gerade im Open Source Umfeld, immer Spielraum sie für das jeweilige Scenario zu verändern. Die einzige Frage die sich dann meist stellt ist ob es sich lohnt „den Weg“ zu verlassen, und bis wo es eine Anpassung ist und ab wann ein Fork.
Cheers
Chris
Die Diskussion ist ein bisschen von dem Hauptthema des Artikels (Wichtige Frage stellten) in die Richtung „Framework“ vs. „Hausgemacht“ gegangen.
Ich hätte aber gerne einen Antwort auf folgenden Fragen:
Wie schwierig war es diesen Elefanten in Raum – Performance Issues – zu nennen? Wie hat das Team darauf reagiert? Wie schnell konnte man umsteigen. Und ob diese schwierige Frage die Moral in Team beschädigt? Nach dem Motto, alles, was wir gemacht haben war umsonst.
Ich stimme Andrey zu, bitte teile uns doch mehr über den Weg der Entscheidungsfindung mit, und was dies für dein Team bedeutete. Ich selbe habe schon oftmals erlebt, dass man sich selbst mit zwei, drei Leuten kaputt diskutieren kann (einmal schafften wir sogar einen opionion swap, anschließend waren wir uns immer noch nicht einig, aber jeder hatte einen früheren Standpunkt eines anderen übernommen!). Da ich SCRUM – so, wie es im Buche steht – noch nie selbst angewandt hatte wäre es auch toll wenn du kurz aufzeigen könntest, inwiefern du glaubst dass SCRUM einen Einfluss auf euren Weg hatte (denn natürlich kann man auch ohne SCRUM diskutieren :))