Einmal besprach der Vorarbeiter mit einem potenziellen Kunden die Renovierung eines kleinen Hauses. Der Hausbesitzer machte sich Sorgen, dass die Wände kippen würden. Das Haus wurde aus Ziegeln gebaut, die Ziegelmauern standen einfach auf dem Boden. Holzstützen wurden um den gesamten Umfang des Hauses verstärkt, aber die Wände versuchten immer noch zusammenzubrechen.
- Ihr Haus ist in einem schlechten Zustand, Wiederaufbau ist erforderlich, - sagte der Vorarbeiter. - Wir werden das Stromkabel spannen, um die Ausrüstung mit Strom zu versorgen, eine Grube zu graben, Entwässerung vorzunehmen, das Fundament zu füllen ... - Nein, nein! - der Hausbesitzer unterbrach ihn, - ich brauche keine Fundamentgrube, ich brauche Mauern! Haus! - In diesem Fall denken Sie vielleicht über den Kauf eines modularen Hauses nach? - schlug der Vorarbeiter vor.
Ich habe letzten Monat mit einem Startup gesprochen. Er hat einen funktionierenden Webdienst, den verschiedene Leute seit mehreren Jahren schreiben, und jetzt überlegt das Management, was es damit anfangen soll. Die Gründer erzählten mir von ihrem Wunsch, ein Team von zehn Entwicklern einzustellen, um die Anwendung neu zu schreiben oder zu modernisieren. Ich fragte sie nach der User Story, der Dokumentation und dem Issue Tracker und sie antworteten, dass sie diese nicht hätten. Sie fragten nach einer Liste meiner Vorschläge, und ich schrieb Folgendes:
Listen Sie die wichtigsten Parameter auf, die sich auf den Verkauf auswirken: SLA, Funktionalität, was auch immer, um virtuelle Aufgaben an die reale Welt zu binden.
Definieren Sie DDD-Kontexte und erstellen Sie eine allgemeine Dokumentation, um die Architektur zu diskutieren und neuen Entwicklern zu helfen, sich mit dem Projekt vertraut zu machen.
Identifizieren Sie Systemengpässe, die zu Skalierungs- und Verfügbarkeitsproblemen führen.
Vereinbaren Sie mit der Geschäftsleitung die mittelfristigen Ziele des IT-Teams.
Erstellen Sie einen Workflow basierend auf Teaminteraktionstools wie Board, Tracker, Messenger und Repository.
Organisieren Sie den Prozess der Einstellung und Teilnahme am Projekt neuer Entwickler.
Richten Sie Überwachungs- und Sicherungssysteme ein.
Zerlegen Sie mittelfristige Aufgaben schrittweise und schreiben Sie einen Zeitplan.
Machen Sie CI / CD.
Schreiben Sie einen Architekturänderungsplan.
Priorisieren Sie Aufgaben im Backlog.
IT- .
, , . . , , .
.
, : , , , , , . , , - , IT- - , . . , , - . - , . . , , , . Oracle. : , , — , , , , , , , . , -, , . Oracle corp, .
- - . , . , - . , .
- , . .
- , IT-. - , , , , .
, , , , , code review, , - . SLA - , .
. . , , . . . - , , , . . , , . , - .
, , - , MVP. , . , , . - , .
, , . - , .
(CI/CD) . , , . CI/CD - . , . . git. CI/CD - , , QA , , , . , . , , .
- , , . . . . , . , .
-, . SCRUM planning-. . - . , . , , .
, , , , , - . .
, -? , " Wordpress, 38% - ». . SAAS, outsource. , IT. , , . , , , -, , , , , .
Was ist, wenn Sie nur Code ohne Pläne, Tests und Tracker schreiben - rufen Sie einfach an und diskutieren Sie unterwegs? Vielleicht verstehen die Entwickler das Problem richtig und schreiben die richtige Lösung, oder sie müssen die Entwickler mehrmals wechseln und die Anwendung mehrmals neu schreiben. Der Unterschied liegt in der Vorhersagbarkeit des Ergebnisses.