Russland ist irrational. Es gibt korrekte Praktiken, es gibt hundert Mal, dass ein Rechen gefühlt wird, aber dennoch passiert etwas Episches mit beneidenswerter Beständigkeit. Manchmal aus dem Grund: "Nun, es wird mich mit Sicherheit umhauen", manchmal: "Immer getan und funktioniert", manchmal nur wegen Fehlern. Vielleicht in den Genen.
Das erste anschauliche Beispiel für ein unglaubliches Spiel (Details werden auf Wunsch der Sicherheitskräfte leicht geändert). Der Kunde ist im Kapitalbau tätig. Ich habe vor einigen Jahren ein System bei einem Auftragnehmer bestellt, der all dies verwaltet (insbesondere die geschätzte Arbeit). Das System wurde auf einem Dutzend ziemlich großer Objekte installiert und eingeführt. Plötzlich beschloss der Kunde, ihn zu bitten, ihm den Quellcode zu geben. Wie sich herausstellte, hatte der bestehende Auftragnehmer Pläne, die Software zu entwickeln und das Ergebnis dann als SaaS auf dem Markt zu verkaufen. Der Vertrag sagt nichts über den Code aus. Wir hatten einen Kampf.
Als sie uns anriefen, um zu verstehen, gab es ungefähr 10 verschiedene Softwareversionen (Releases von 0.9 bis 2.4). Es gibt 1,5 Quellen, diese Version wurde einmal von ihnen gesammelt. Keine Dokumentation. Und das System muss entwickelt und weiterentwickelt werden. Sie überlegten, „alles neu zu schreiben“ und „1.5 abzuschließen“ und entschieden sich für die zweite - TtM drei bis vier Monate gegenüber dem Jahr. Sie haben uns beigebracht, wie man Support-Spezialisten sammelt, die Quellen korrigiert, die Codebasen reduziert, die Infrastruktur erstellt und ein "Casting" organisiert, bei dem die Quelle dort empfangen, gesammelt und verteilt wird. Es hat uns und den Kunden viele Hämorrhoiden gekostet.
Kommen Sie herein, ich zeige Ihnen etwas mehr darüber, wie Sie einen Fehler im Entwicklungsprozess machen können und zu welchen interessanten Konsequenzen dies führt.
Ein weiteres Beispiel
Der Kunde - ebenfalls ein ziemlich großes Unternehmen - rollt ERP-Releases. Und der Witz ist, dass das System so gesund ist, dass es keinen Ort gibt, an dem es auf einer vollständigen Basis oder ähnlichem getestet werden kann. Es gibt einfach keine Infrastruktur. Genauer gesagt gibt es, aber es ist unmöglich, einen Belastungstest durchzuführen, nur kleine lokale Dinge werden überprüft. Die Veröffentlichung steigt - und niemand weiß, wie er sich in der Praxis verhalten wird. Einmal fiel alles merklich ab, als sich die Veröffentlichung nicht so verhielt, wie sie wollte. Am Ende haben sie uns eingeladen, zu sehen, was getan werden kann. Wir haben besprochen, dass sie das HP Performance Center sehen wollen, einen Piloten erstellt, dann integriert, geschult und ausgeliefert. Jetzt veröffentlicht durch. Diese normalisierten Operationen werden getestet, eine Zusammenfassung der Operationen SLA.
Oder der Staatskunde ist gekommen, um Substitution zu importieren. Das Geschäft kommt zu uns und sagt: Unsere IT-Spezialisten sagten uns, dass es sehr schwierig ist, die Oracle-Basis durch Postgress zu ersetzen. Wir glauben ihnen nicht, konsultieren. Zwei Wochen Verfahren - und das Ergebnis: „Ja, das Ändern der Basis ist einfach. In diesem Moment müssen Sie die gesamte Anwendungsebene neu schreiben. Ein bisschen. Ungefähr 90%. Sie haben riesige Pakete, Sie müssen die Ebene der Geschäftslogik übertragen - und kommen. Die Entwickler, die den Kernel geschrieben haben, können nicht mehr gefunden werden, da das System acht Jahre alt ist. " Sie glaubten dem IT-Team. Es stellte sich heraus, dass sie einfach nicht klar genug argumentierten.
Wir suchen irgendwo Sicherheit,
hier ist ein episches Beispiel . Glücklicherweise ist dieser immer noch einfach, da hat seit fünf Jahren einfach niemand mehr etwas getan, und das Geschäft ist nicht auf Bundesebene.
Das folgende Beispiel. Wir setzen die gleiche Geschichte mit der Annahme von Veröffentlichungen. Ideale Situation: Ein Drittanbieter schreibt den Code, übergibt ihn zum Testen, besteht die Tests, legt alles in das Repository und sammelt und verteilt es von dort aus. Ist es schön Schön. Wir leben seit drei Jahren ausnahmslos in unserem Unternehmen (vorher gab es nicht alle Abteilungen und Teams). Der Kunde verfügt jedoch über einen „Fundus an Algorithmen und Programmen“. Dort versendet jeder Künstler ein Leerzeichen oder eine Liste des Quellcodes. Sie schwelen dort. Wie sich während des Audits herausstellte, wurde Anime im Allgemeinen auf einer CD aufgezeichnet. Und selbst wenn der Fonds einen De-facto-Code enthält, macht dies keinen Sinn.
Ein weiterer ähnlicher Kunde. Sie haben einen typischen Schmerz - viele Auftragnehmer. Sie haben einen brancheninternen Integrator erstellt und überprüft, ob der Auftragnehmer die richtige Software mitbringt. Es gab Probleme darin, dass Rechte Dritter bestehen (Open-Source-Bibliotheken mit viralen offenen Lizenzen zum Beispiel) - skrupellose Auftragnehmer können all dies ohne Lizenzierung in der richtigen Reihenfolge liefern. Im Fall von Open Source können Sie das Problem immer noch bewältigen, aber manchmal stoßen kommerzielle Bibliotheken darauf. Schuldig, wer sein wird - dreimal raten. Dann ging einer ihrer Auftragnehmer bankrott und der Kunde lebte mit diesem Code. Solche Situationen müssen frühzeitig erkannt werden. Wir haben geholfen, den Prozess richtig einzurichten. Wir haben eine Lösung wie die Automatisierung einer Reihe von Algorithmen und Programmen. Technische Dokumentation, Versionen, Quellcodes, Verträge und alle Links zu Ausschreibungen. Mit einer durchschnittlichen CIO-Lebensdauer von zwei bis drei Jahren hilft es dem nächsten wirklich, es sofort herauszufinden.
Wir führen Agile auch in Russland ein. Ich lache jetzt nicht über den Zirkus. Fast jedes Mal beginnt es als modische Geschichte zur Digitalisierung von Unternehmen. Die Hauptsache ist, dass jeder versucht zu verstehen, was diese Wörter sind. Aber niemand versteht. Konzepte bestellen, fremde Leute einstellen. Sie sagen die Worte "es scheint", "Hypothese", Startups sind eingeladen, Beschleunigung ist trübe, Smoothies sind betrunken - im Allgemeinen hat alles die äußeren Anzeichen einer Art Tal. Dann beginnt Agile sich zu bewerben, aber es hebt nicht ab. Wenn Sie ein seriöses System erstellen, müssen Sie es lange überprüfen. Wenn Sie die Prozesse nicht platzieren, sind die Sprints lang (ein oder zwei Monate). Wenn Sie die Prozesse festlegen, müssen Sie mit der Testinfrastruktur beginnen, die Lieferpipeline entwickeln, die Arbeitsprozesse zwischen Teams und innerhalb von Teams erstellen. Und das alles wird normalerweise vergessen. Wenn die Prozesse der Altgläubigen 98% betragen, wird das Projekt nicht durchgeführt. Am Ende harken wir und rennen. Im Allgemeinen beschweren wir uns nicht: auch Brot. Aber manchmal möchte ich nur irgendwie erklären, oder was, dass IT zuerst eine Infrastruktur und dann schnelles TtM ist. Und nicht umgekehrt.
Was geht normalerweise schief? Reihe von Beispielen
Meine Kollegen und ich haben hier eine Reihe offener Probleme zusammengestellt, die nicht sehr objektiv sind, aber die Situation sehr gut beschreiben. Natürlich gehen wir nur an Orte, an denen es schlecht ist, und es ist nicht notwendig, es auf den Zustand der Branche zu extrapolieren. Trotzdem bin ich sicher, dass Sie etwas von Ihrem Unternehmen lernen werden. Ein kleiner Teil. Im Allgemeinen wird alles mit den Worten beschrieben: "Prozessineffizienz, unmotivierte Mitarbeiter, schlechte Werkzeuge oder schlecht verwendete Werkzeuge." Nun, Beispiele.
1. Strafe für Fehler in der Software, die von Entwicklern beigesteuert wurden.Ich weiß nicht einmal, wie ich es rational beschreiben soll. Nur eine Geldstrafe für identifizierte Fehler. Lebe jetzt mit diesem Wissen. Natürlich wird jede Veröffentlichung (auch kleine) zehnmal langsamer veröffentlicht als sie könnte.
2. Treffen von morgens bis abends.Der Entwickler muss daran teilnehmen. Er schweigt und nickt mit dem Kopf ins Telefon. Dies sind dieselben Besprechungen, wenn das gesamte Projektteam für die Besprechung sowie der zu kontrollierende Abteilungsleiter benötigt werden. Es ist unmöglich, nicht zu kommen. Aber es macht fast keinen Sinn, daran teilzunehmen. Dies ist der traditionelle Fehler des Projektmanagers, der als "übermäßige Kontrolle" bezeichnet wird.
3. Frachtkult. Wir nehmen flexible Methoden und setzen sie starr um.Das Beste, was ich gesehen habe: Aggile implementiert, aber wie zuvor funktioniert. Sie haben gerade Entwickler dazu gebracht, zum täglichen Stand-up zu kommen. Sie sind gebaut und sagen: Ich habe nichts getan. Es passiert jeden Tag.
4. Tools: Wir implementieren, um die implementierten zu melden."Wir haben einen Continuous Integration-Server, und nur ein Administrator kann eine Aufgabe hinzufügen." "Wir haben ein binäres Assembly-Repository implementiert, und es gibt eine sehr kleine Festplatte. Sie müssen die alten löschen, und es gibt nur die letzten drei Versionen." Oder hier: ein Task-Management-System in einer Ex-Datei auf einer freigegebenen Festplatte. So führt der Rückstand oft auch in großen Unternehmen, obwohl es Jira gibt. In diesem Fall wird es niemand tun, bis die Aufgabe in diese Datei fällt. Er ist offiziell.
Ein anderes Unternehmen verfügt über eine interne Wissensbasis, aber alles wird direkt im Versionskontrollsystem gespeichert: Dies ist für den Manager bequemer. Dort werden sogar Betriebssystemdistributionen hinzugefügt. Wenn keine Person für das Versionskontrollsystem verantwortlich ist, können Manager Gigabyte-Dateien ablegen, um sie an die Gegenpartei zu übertragen, da der Platz in Dropbox aufgebraucht ist.
5. Codierungsstandards: ohne Verständnis geschrieben oder 10 Jahre lang nicht aktualisiert.Nur ein paar Beispiele: Wir benötigen eine 100% ige Abdeckung des Codes mit Tests und Dokumentation. Insbesondere alle Bibliotheken von Drittanbietern. Der Nachteil ist das Fehlen von Standardtests. Kürzlich habe ich gesehen, wie ein Techniker das System bereitgestellt hat und der Benutzer sich nicht anmelden kann, da der Schlüssel vom Test zum Produkt nicht geändert wurde.
Wieder sah ich, wie der Anführer den Code in Notepad.exe schrieb und ihn dann fehlerfrei in den Compiler warf. Er lernte immer noch mit Lochkarten. Eine solche Fähigkeit verdient sicherlich Respekt. Aber nur bis diese professionelle Verformung beginnt, die Standards für den Rest der Entwicklungsabteilung zu beeinflussen.
6. Regelungsfehler.Zum Beispiel eine feste Mittagspause, die voll gelaufen ist. Dies ist ein Symptom. Ich frage warum. Sie erklären: Wenn Sie beim Mittagessen am Arbeitsplatz sitzen, sind Sie das Ziel. Muss in fünf Minuten auf Briefe antworten und so weiter.
Übermäßige Bürokratisierung: Befolgen Sie häufig dokumentierte Verfahren, die zu einem Stapel Papier führen. Die gleichen Testpläne für jedes Niesen. Dies ist eine Beschreibung jedes Filters, einschließlich der Datentypen in jedem Schnittstellenfeld, der Feldlänge usw. Dies wird normalerweise durch Beispiele und nicht durch vollständige Details gelöst.
In einem Unternehmen gab es keine Person, die für die aktuelle Version verantwortlich war. Manchmal wurden die Fristen für die Veröffentlichung von Produkten für zwei Wochen überschritten.
Kommunikation: Etwas kommt vom Kunden per Post. Außerdem schreibt er an denjenigen, der zuletzt mit ihm gesprochen hat. Selbst wenn Sie dies tun möchten, können sich Kommentare zu der Aufgabe an verschiedenen Stellen befinden, einschließlich Instant Messenger. Dann ist jemand gegangen, jemand ist gekommen, jemand hat die Mail gelöscht - das ist alles.
7. Kampf gegen die Sicherheitskräfte.Dies umfasst manuelle Updates aller Systeme (und Sie müssen diese automatisch verschütten, dies spart viel Zeit), physische Problemumgehungen mit einem Flash-Laufwerk über Netzwerkknoten, Portzuweisung für drei Wochen usw.
8. Die Kommunikation zwischen Entwicklern und Analysten ist nicht hergestellt.Dies ist ein solcher Pfosten, der bei jedem fünften Projekt wiederholt wird. Es ist nur so, dass der Analyst schrieb, was benötigt wird, der Entwickler es entwickelte und einen Monat später zeigte, dass es fertig ist. Der Analytiker ist entsetzt, weil er das nicht so gemeint hat. In diesem Monat arbeitete der Entwickler drei Wochen lang vergeblich, obwohl er einen Teil des Projekts zeigen und der Analyst fragen konnte, wie die Dinge laufen. Es gibt Methoden, die dies einfach schließen, aber das Problem ist, dass in dieser Situation beide Parteien nicht verstehen, warum das Projekt benötigt wird und wie es läuft.
9. Konferenzgesteuerte Entwicklung.Der Leiter sah auf der Konferenz etwas Cooles und stellte es spurlos vor. Drei Monate später wiederholt. Infolgedessen ist der Bericht schön, aber die Arbeit lohnt sich.
Aufgrund interner Konferenzen ist es weiterhin möglich, das Ergebnis gemäß dem Schema „Immer 80% bereit“ zu erzielen. Über öffentliche Berichte - "Fast fertig", und es ist endlos. Es kommt nie zu 100%. Warum? Siehe zum Beispiel Punkt 1.
Separat stelle ich die Unterprüfung von Systemen von Drittanbietern fest. Sie lesen den Artikel - wow, cool, lassen Sie uns ihn verwenden und lernen dann einfach, wie. Und Sie stoßen auf viele Einschränkungen, weil der Verkäufer erst bei den ersten beiden Treffen Honig in seine Ohren gegossen hat. Wir selbst sind auf einen Rechen getreten. Es gab eine interne Implementierung eines Systems für Online-Dokumentationsspeicher zum Entwurf von Infrastrukturen, inkl. Rechenzentren für sehr interessante Objekte. Es wurde ein Fall entdeckt, in dem die Kosten für Waren auf 100 Millionen begrenzt wurden. Der Trick ist, dass im Themenbereich der Stückpreis des Dokuments höher ist. Und dort musste das System den Index schaufeln, um zu suchen, und wir haben Investitionen von 1 Gigabyte in die Dokumente. Die erwartete Indizierungszeit beträgt einen Monat. Der Anbieter warnte nicht davor.
10. Beängstigend, um Änderungen vorzunehmen.Es gibt einen solchen Zustand des Projekts: Sie müssen umgestaltet werden, kommen Sie in einem Monat zurück. Aber es gibt keine Tests, keine Dokumente, nichts. Und die Entwickler sitzen: "Wir haben Angst, Änderungen vorzunehmen, wir haben Angst, alles zu brechen."
Ich habe auch gesehen, wie ein Unternehmen die Integration mit einem System entwickelt hat, das vom Entwickler nicht bereitgestellt werden kann, weil es sehr schwierig ist. Tester testen die Datenübertragung durch den Dienst (soweit möglich). Gehen Sie vor der Lieferung zum Kundenstand - und weitere zwei Wochen mit Verbesserungen, da das Transaktionsmodell falsch war. Es ist empfehlenswert, einen Stub für dieses System zu erstellen, der Antworten zurückgibt. Infolgedessen wurde es einfacher, sie zu testen und zu akzeptieren.
Ein anderer Kunde kann wirtschaftliche Beschreibungen in seiner üblichen Sprache verfassen. Bei diesem Projekt haben wir eine Art Pseudo-Sprachkonstruktor (eine Reihe von Standards) angegeben, der dann in Analystendaten konvertiert wird. Im Sinne von "Wenn Wanja krankgeschrieben ist, kann er nicht zur Produktion gehen."
Und der letzte Akkord. Jemand anderes in einer Firma codiert direkt auf dem Produkt. "Es gibt eine kleine Geige, ich weiß was ich tue." Danke, lieber Mann, aber wenn ich dich finde, weiß ich nicht einmal, was ich mit dir machen soll.
Im Allgemeinen sprach aus. Wenn Sie Ihre Probleme herausfinden, schreiben Sie an oeremeev@croc.ru. Für große Unternehmen haben wir fast kostenlose Piloten mit Expressdiagnose (Suche nach Engpässen in 3-5 Tagen). Wenn jemand aus Ihrem Unternehmen erklärt werden muss, dass es unmöglich ist, technische Schulden in Kauf zu nehmen, - schreiben Sie auch, wir können dies normal zählen.