Ich arbeite in einem kleinen Team in einem mittelständischen Unternehmen, von dem die meisten nicht an der Softwareentwicklung beteiligt sind. Ich bin der neueste und am wenigsten erfahrene Entwickler und hatte vor dem Start keinen beruflichen oder akademischen Hintergrund in Software, aber ich bin sehr zufrieden mit dem Respekt meiner Beiträge und dankbar, dass ich in einem so frühen Stadium meiner Karriere ernst genommen wurde.
Trotzdem habe ich das Gefühl, ich sollte mit dieser großzügigen Sendezeit mehr anfangen. Als Team scheinen wir Probleme zu haben, Dinge zu erledigen. Ich würde gerne etwas vorschlagen können, um die Situation zu verbessern, und ich denke, ich würde angehört werden, wenn es eine gute Idee wäre, aber ich weiß nicht, was ich vorschlagen soll.
Zu den Dingen, die ich als Probleme identifizieren kann, gehören:
- Die Spezifikation der anstehenden Aufgaben ist spärlich. Dies liegt zum Teil daran, dass das Management ein Engpass ist und wir nicht das Geld oder die Leute haben, um so viele detaillierte Anforderungen zu erarbeiten, wie wir möchten. Dies liegt zum Teil auch daran, dass die von uns entwickelte Software recherchierend ist und die genaue Methode erst klar wird, wenn sie demonstriert und zur Bestimmung ihrer Wirksamkeit verwendet wird.
- Der Lead Dev ist sehr angetan von dem, was er "Prototyping" nennt, bis zu dem Punkt, dass er in letzter Zeit darauf besteht, dass alles "Prototyping" ist, was für den Rest von uns so aussieht, als würde man schlechten Code schreiben und ihn den Modellbauern zum Spielen geben. Es ist nicht klar, was er in vielen Fällen von dieser Übung erwartet. Die "tatsächliche" Implementierung leidet dann daran, dass er darauf besteht, dass bewährte Verfahren zu viel Zeit für das Prototyping benötigen. Ich habe noch nicht einmal begonnen, diese verdrehte Logik zu entwirren, und ich bin mir nicht sicher, ob ich es versuchen möchte.
- Von den Modellbauern wird erwartet, dass sie uns alles über die gewünschte Methodik im Detail erzählen, und es wird absolut darauf vertraut, dass das, was sie herausbringen, theoretisch fehlerfrei ist. Dies ist kaum wahr, aber es werden keine Maßnahmen ergriffen, um diese Situation zu korrigieren. Niemand auf der Modellierungsseite äußert Bedenken in einer strukturierten Weise, auf die wahrscheinlich reagiert wird, und sucht auch keine Anleitung bei der Anwendung von Best Practices. Auch gegen ihre Passivität wird nichts unternommen.
- Ich habe schon früher versucht, TDD in das Team zu bringen, fand es aber schwierig, da es für mich neu ist und obwohl diejenigen, die meine Arbeit beaufsichtigt haben, bereit waren, es zu tolerieren, hat sich niemand anders begeistert. Ich kann nicht rechtfertigen, wie viel Zeit ich damit verbringe, mich zu suhlen und Features nicht fertigzustellen, daher wurde die Idee - im Moment - aufgegeben. Ich mache mir Sorgen, dass es nicht wieder aufgenommen wird, weil niemand gerne erfahren möchte, wie er seine Arbeit machen soll.
- Wir haben jetzt einen Server für die kontinuierliche Integration, der jedoch meist nur zur Durchführung mehrstündiger Regressionstests verwendet wird. Es wurde offen gelassen, dass es auch Unit- und Integrationstests mit vollständiger Abdeckung ausführen sollte, aber im Moment schreibt niemand sie.
- Jedes Mal, wenn ich das Qualitätsproblem mit dem leitenden Entwickler anspreche, erhalte ich eine Antwort auf den Effekt von 'Testfunktion A ist unkompliziert, Funktion B ist für den Benutzer viel wichtiger, aber zu schwierig zu testen, daher sollten wir die Funktion nicht testen EIN'. Ich habe wieder einmal keine Fortschritte gemacht, um diese Logik zu entwirren.
....Puh. Wenn ich es so formuliere, sieht es viel schlimmer aus als ich dachte. Ich nehme an, wie sich herausstellt, ist dies ein Hilferuf.
quelle
Antworten:
Lassen Sie mich für einen Moment den Anwalt des Teufels spielen:
Der leitende Entwickler liebt Prototyping, weil die Spezifikationen spärlich sind. Das ist wahrscheinlich eine gute Sache; So funktionieren iterative Shops.
Dies funktioniert in einem iterativen Shop nicht. Die Natur der iterativen Entwicklung besteht darin, dass die Anforderungen häufig unvollständig sind. Die Iterationen sind erforderlich, um die Anforderungen zu konkretisieren.
Das wird auch nicht funktionieren; Sie müssen die Technologie verstehen, bevor Sie sie evangelisieren können. Darüber hinaus kann TDD in einem iterativen Geschäft mit geringen Anforderungen zu viel Overhead verursachen. Es ist besser, eine angemessene Abdeckung durch Unit-Tests zu fördern.
Das kann in einem kleinen, iterativen Geschäft angebracht sein.
Es hört sich so an, als ob Ihr Geschäft einige ziemlich enge Zeitbeschränkungen hat. ob es Ihnen gefällt oder nicht, Sie sind an diese Einschränkungen gebunden.
Es hört sich auch so an, als wären Sie aus einem Teil der Softwareindustrie gekommen, der Wert darauf legt, Dinge "richtig" zu machen, anstatt sie zuerst auf den Markt zu bringen. Daran ist nichts auszusetzen (es ist in der Tat bewundernswert), außer dass der erste, der eine fehlerhafte Software auf den Markt bringt, oft der Gewinner ist. Es ist nicht fair, aber so ist es.
quelle
Ich werde mich hier auf das Prototyping konzentrieren
Das Hauptproblem bei Prototypen ist, dass sie als Proof of Concept gedacht sind
Wenn Sie jedoch nicht weiter auf dem Prototyp aufbauen können und das Endprodukt von Grund auf neu erstellen müssen, haben Sie den Prototyp möglicherweise genauso gut nicht erstellt und Ihre Zeit damit verschwendet, ihn zu erstellen
Mein Rat an Ihr Team ist, Qualität und Flexibilität bei diesen Prototypen zu erreichen. Ich weiß, dass es nicht möglich ist, beim ersten Mal perfekte Inhalte zu erstellen, aber ich versuche, für zukünftige Anforderungen erweiterbar zu bleiben
quelle
Das sind gute Antworten. Ich kann nur hinzufügen, dass "versuchen zu kommunizieren" bestenfalls eine zweifelhafte Aussage ist. Änderungen in der Arbeitsweise einer Organisation kommen nicht schnell zustande. Wenn es passiert, ist es oft wie eine Flut, bei der sich der Schwung von unten und von oben aufbaut. Sie sind also glücklicher, wenn Sie Ihre Erwartungen niedrig halten und entweder auf Ihre Chance warten, zu sagen, wie die Dinge gemacht werden, oder sich darauf freuen, mit einer anderen Organisation zusammenzuarbeiten.
quelle
Haben Sie jemanden in der Firma identifiziert, der es "bekommt", wenn ja, halten Sie sich an diesen Typen und lernen Sie so viel wie möglich von ihm. Wenn nicht, nehmen Sie sich Zeit, lernen und wachsen Sie selbstständig (treten Sie einem Open Source-Projekt bei oder starten Sie Ihr eigenes Projekt) und suchen Sie nach einem Ort, der Ihr Wachstum fördern kann.
Das Schlimmste, was passieren kann, ist, dass Sie dort bleiben und lernen, wie man Dinge falsch macht. Ja, es sollte Pragmatismus herrschen, aber ein wirklich kompetentes Team kann die Dinge richtig machen und trotzdem pünktlich mit einem Qualitätsprodukt sein. Es hört sich so an, als ob Ihr aktuelles Team nicht das Zeug dazu hat und Sie sollten nach einem neuen suchen.
quelle