"Um Veränderungen vorzunehmen, muss man verstehen, warum sich die Leute dagegen wehren": Jim Holmes über das Testen von Kultur



    Was könnte eine Armee einem Tester beibringen? Was sind die beiden Extreme bei Testansätzen? Wie lässt sich erklären, dass die technische Verschuldung durch Zahlung rot ist? Was haben die vorherigen Fragen gemeinsam?

    Die allgemeine Sache ist, dass sie trotz ihres Unterschieds alle einer Person nahe stehen. Bei Jim Holmes hinter Jahrzehnten IT-Erfahrung, die in den 80er Jahren in der US Air Force begann - es ist nicht verwunderlich , dass er bereit ist , über eine Menge zu sprechen. Das Konzept der „Testkultur“ ist für ihn wichtig, und wir haben ihm Fragen gestellt, die sehr unterschiedlich sein können, aber letztendlich irgendwie mit der Testkultur zusammenhängen.

    - Einführungsfrage: Erzählen Sie uns von sich.

    - Mein Name ist Jim Holmes, ich bin ein unabhängiger Berater und Inhaber meiner eigenen Firma, Guidepost Systems. Ich habe mich auf die Qualität der Softwarebereitstellung spezialisiert und programmiere seit ungefähr 20 Jahren, bevor ich lange Zeit in der Armee gedient habe. Vor ungefähr 15 Jahren habe ich mich ernsthaft für Qualität interessiert, als ich an einigen nicht sehr erfolgreichen Projekten gearbeitet habe. Im Allgemeinen habe ich viel Testautomatisierung, Unit-Tests, Integrationstests und insbesondere Funktionstests, UI-Tests durchgeführt. Insbesondere habe ich für eine Firma gearbeitet, die das wunderbare Tool Telerik Test Studio geschrieben hat. Und in den letzten fünf bis acht Jahren habe ich angefangen, mich nicht nur mit rein technischen Aspekten, sondern auch mit der Qualität der Lieferung als Ganzes auseinanderzusetzen - das heißt, wie gut ist die Beziehung zwischen dem Versorgungsteam und dem Unternehmen. Gleichzeitig debugge ich immer noch WebDriver-Skripte für eine lange Zeit und löse Probleme wie periodische Ausfälle aufgrund falscher asynchroner Aktionen. Ich lebe in der Stadt Ashland in Oregon - wohlgemerkt nicht in Portland (wenn man in den USA „Oregon“ sagt, denkt normalerweise jeder „Portland“).

    - Wahrscheinlich ist für den Tester der Militärdienst der ungewöhnlichste Teil Ihrer Biografie. Was genau hast du dort gemacht?

    - Ich habe bei der US Air Force gedient, weil ich immer von Flugzeugen inspiriert war und mein Vater Pilot war. Er nahm mich mit auf meinen ersten Flug, als ich erst 4 Jahre alt war. In der Luftwaffe hatte ich großes Glück und war Mitglied des E-3-Teams. Dies ist ein so großes Flugzeug mit einer riesigen Scheibe, auf der ich für den Betrieb des Radars und einiger Kommunikationssysteme verantwortlich war. Seit elf Jahren verwalte und debugge ich dieses große elektronische System. Und in der Zeit, die frei von Flügen war, verwaltete ich Computer für unser Geschwader. Um diese Zeit wurde es möglich, Netzwerke am Arbeitsplatz zu schaffen. Da ich Soldat war, wurde ich für die Ausbildung bezahlt und besuchte eine Abendschule, um Software zu entwickeln.

    Was Ihre Frage betrifft, so ist die Erfahrung, in der Armee zu dienen, nicht nur für Tester, sondern auch für viele andere Bereiche ungewöhnlich. Ich kann sagen, dass mir dort zumindest Disziplin beigebracht wurde.

    - Ja, bei der Armee fällt mir als erstes die Disziplin ein. Und damit haben viele Tester und Entwickler Probleme. Glauben Sie, dass sie etwas vom Militär lernen können?

    - Das ist eine sehr interessante Frage. Tatsache ist, dass die Disziplin, die mir beigebracht wurde, sich etwas von den Fallschirmjägern unterschied, das heißt, es gab keine ständigen Schreie und Bestrafungen. Mir wurde ein disziplinierter Ansatz zum Testen und im Allgemeinen zum Lösen von Problemen beigebracht. Wichtig war auch die Disziplin am Arbeitsplatz - zu verstehen, was eine Hierarchie war; Um darin arbeiten zu lernen, muss man in der Lage sein, mit Vorgesetzten zu kommunizieren. Diese Art von Disziplin hat mir sehr geholfen.

    Ich habe die Armee vor 25 Jahren verlassen - ja, ich bin ein alter Mann - und die Arbeit im zivilen Sektor stand aufgrund der dortigen Prioritäten in einem sehr interessanten Gegensatz zu meinen früheren Erfahrungen. In der Armee diente ich in einem Flugzeug, das den Feind über ein großes Gebiet überwachen und meine eigene Sicherheit gewährleisten sollte. Jeder Fehler bedeutete ein Risiko für das Leben unserer Soldaten. Ich möchte nicht übertreiben, aber es war wirklich so. Wenn also jemand in der IT in Panik gerät und verlangt, dass eine Aufgabe dank meiner Disziplin und meiner Erfahrung sofort gelöst wird, kann ich die Menschen immer beruhigen - es droht uns nicht, dass jemand stirbt, und wir verlieren nicht Hunderttausende Dollar pro Minute (und ich war in solchen Situationen). Wir geraten oft in Panik und lassen uns von Unternehmen oder Aktionären unnötig einschüchtern und erzeugen unangemessene Spannungen. das bringt niemandem etwas Gutes. Das vielleicht Beste, was mir die Armee beigebracht hat, ist die Fähigkeit, Ruhe zu fordern, die Situation gründlich einzuschätzen und unsere Aktionen im Voraus zu planen, und mich nicht wegen künstlich verursachter Panik gedankenlos einer Aufgabe zu stellen.

    - Das heißt, Sie müssen sich Zeit nehmen, um eine Strategie zu durchdenken.

    - Ja, und in der IT war dieses Problem lange Zeit: Konstante Anforderungen, um das Projekt in Sekundenschnelle zu realisieren. Das Wichtigste ist, schnell zu handeln, und was genau getan wird, ist von untergeordneter Bedeutung. In den meisten Fällen kann dieser Druck kontrolliert werden, wenn der Dialog korrekt geführt wird. Dafür ist es jedoch wichtig zu sagen, dass wir mehr Wert schaffen, wenn wir etwas mehr Zeit aufwenden und das Problem rational angehen.

    - Lassen Sie uns zu Ihren aktuellen Aktivitäten übergehen. Bei der Arbeit sind Sie mit der Vorgehensweise beim Testen in verschiedenen Unternehmen auf unterschiedliche Weise vertraut. Es ist klar, dass der Ansatz zum Beispiel von der Größe des Unternehmens abhängen kann. Aber es gibt wahrscheinlich viel weniger offensichtliche Unterschiede - können Sie darüber sprechen?

    - Das ist eine wunderbare Frage. Neben meiner selbständigen Arbeit arbeite ich auch mit Pillar Technology aus Columbus, Ohio. Ich kenne Leute aus dieser Firma schon lange. Mittlerweile arbeiten dort rund 250 Personen, und fast alle von ihnen arbeiten nach dem Prinzip der extremen Programmierung (XP): Sie haben viele Unit-Tests, und die Entwicklung ist sehr gut durchdacht. Als ich vor drei Jahren dort angestellt wurde, war ich der einzige Tester, der ein sehr hochwertiges Produkt geschaffen hat. Sie näherten sich dem Testen ausschließlich von der Position von XP aus, von der Position der testgetriebenen Entwicklung. Dies ist ein großartiger Ansatz, den sie erfolgreich angewendet haben, und es ist mir zusammen mit einigen anderen Mitarbeitern gelungen, einige Aspekte der Softwarebereitstellung zu ändern.

    Und Sie können diese Erfahrung mit einem anderen Unternehmen vergleichen, in dem ich seit drei Jahren berate. Dies ist ein Industrieunternehmen, das in den Top Ten der Fortune-Liste aufgeführt ist und weltweit rund 200.000 Mitarbeiter beschäftigt. Sie haben eine sehr große IT-Abteilung für die internen Bedürfnisse des Unternehmens. Es gibt viele gute Leute dort, aber ihre Tests haben sich auf die Praktiken der 1980er oder 1990er beschränkt. Das Unternehmen stellt aus genau denselben Produkten große Mengen her, und viele sind daran gewöhnt, dass sich bei der Herstellung von beispielsweise Kugellagern die Anzahl der zu erwartenden Mängel durchaus abschätzen lässt. Das Problem ist jedoch, dass sie diese Art des Denkens auf die IT übertragen.

    Ich hatte ein Gespräch mit vier im Allgemeinen sehr intelligenten Mitarbeitern, die daran beteiligt waren, Fehlerberichte aus mehreren Projekten zu sammeln und die Anzahl möglicher zukünftiger Fehler vorherzusagen. Ich sagte ihnen, dass dies in der Branche durchaus sinnvoll ist, aber wie werden sie die Indikatoren, die für eine mobile Anwendung berechnet werden, von den Indikatoren von beispielsweise Webdiensten unterscheiden? Sie antworteten, dass es keinen Unterschied gibt. Ich hatte das Glück, völlig gegensätzliche Punkte im Spektrum der verschiedenen Ansätze und Testkulturen zu sehen.

    Außerdem habe ich mit einigen Unternehmen zusammengearbeitet, die es nicht geschafft haben, aus der Startphase herauszukommen, wenn sie die ganze Zeit ohne Rückblick arbeiten und nicht versuchen, die gesamte Situation abzudecken. Und dann, nach ein paar Jahren, werden in komplexen Projekten die Probleme, die in dieser Phase aufgetreten sind, stark spürbar, und ich muss die Leute davon überzeugen, dass dieser Ansatz falsch ist und dass ich jetzt anhalten und meine Handlungen richtig durchdenken muss. Im Allgemeinen war meine Antwort etwas umfangreich, ich hoffe, ich habe den Kontakt zu Ihrer Frage nicht vollständig verloren.

    - Und in Ihrer Beratungspraxis gab es Zeiten, in denen man Ihnen nach Abschluss der Arbeit im Unternehmen sagte, dass „nichts besser geworden ist“?

    - Ich verrate dir ein Geheimnis, dass es schwer mit Menschen ist, wir sind sehr schwierige Wesen. Dies ist einer der Gründe, warum ich so viele graue Haare habe (der zweite Grund ist meine Tochter). Das Ändern einer Person ist schwierig, das Ändern von Personen in einer Organisation noch schwieriger. Also ja, ich habe diese Situation ziemlich oft.

    Wir sagen sogar über einige Berater, dass er "ausgebrannt" ist. Das liegt daran, dass wir uns sehr bemühen, die Kultur, die sich in der Organisation entwickelt hat, zu verändern, und wir müssen viel mit Problemen auf persönlicher Ebene arbeiten - die Menschen haben Angst vor Veränderungen, sie müssen sich ständig davon überzeugen, dass dies notwendig ist und suche nach dem Weg, der zu ihnen passt. Egal wie stark und laut ich bin, ich kann nicht einfach kommen und sagen: Mach so und so. Muss zu einem Konsens kommen. Diese Arbeit muss jahrelang durchgeführt werden, um etwas zu erreichen, und wenn es den Anschein hat, dass Sie das Problem gelöst haben und sich an eine andere Organisation wenden, werden Sie dort auf genau dieselben Probleme stoßen wie zuvor. Sie verbringen wieder viel Zeit und Mühe, und dann stellt sich heraus, dass

    Die Leute sind so arrangiert, es ist schwer für uns, wir kehren oft zu unseren alten Gewohnheiten zurück. Trotzdem gibt es Beispiele für wirklich erfolgreiche Arbeit. Es gibt Organisationen, die es schaffen, das mit Ihnen erzielte Ergebnis zu konsolidieren. Im Allgemeinen würde ich sagen, dass einer den anderen ausbalanciert. Ich mache diese Arbeit weiter, weil diese Erfolgsfälle immens befriedigend sind.

    - In Ihrem Blog haben Sie über Ihre beruflichen Grundsätze geschrieben und dort über die Notwendigkeit gesprochen, offen zu sein, immer Neues zu lernen, mehr zuzuhören als zu reden, sich anzupassen und gleichzeitig freundlich mit Menschen umzugehen. Ich frage mich, ob Freundlichkeit wirklich Menschen in der IT hilft.

    - Ja, das hilft. Ich sagte, dass ich in der Armee gedient habe, in der wir streng diszipliniert waren - aber Sie müssen verstehen, dass Disziplin und Strukturiertheit gute Beziehungen und Empathie mit anderen Menschen nicht beeinträchtigen. Kennen Sie den schottischen Koch Gordon Ramsay? Er leitet die Hell's Kitchen Show. Ich erwähne es, weil die Köche in teuren Restaurants sich sehr oft widerlich gegenüber den Angestellten verhalten - sie schreien, beleidigen. Ich hasse diese Einstellung gegenüber Menschen. Für mich ist eine gute Einstellung zueinander wichtig. Wenn Sie Änderungen erreichen möchten, müssen Sie verstehen, warum die Leute sich ihnen widersetzen, das heißt, Sie brauchen Einfühlungsvermögen. Und es wird Ihnen erlauben, die Person selbst dazu zu bringen, sich zu verändern. Ein solcher Ansatz ist viel effektiver als Menschen anzuschreien und zu fordern, dass sie gehorchen und keine Fragen stellen. Jeder Mensch hat seinen eigenen Verstand, eigene Seele, eigene Erfahrung. Ich möchte mich nicht mit Philosophie befassen, aber ich glaube, dass Sie auf lange Sicht mit einer guten Einstellung und Empathie großartige Ergebnisse erzielen können. Also ja, sie helfen.

    - Sie führen Seminare durch und unterrichten bei einem von ihnen Programmierer, die nicht programmieren können. Ich habe zwei Fragen. Erstens: Welche Probleme hindern die Leute am häufigsten daran, sich selbst zu programmieren? Zweitens: Glauben Sie, dass automatisierte Tests im nächsten Jahr Vorrang vor manuellen Tests haben werden?

    - Nach meiner Erfahrung werden Menschen oft nicht durch technische Schwierigkeiten, sondern durch Angst gestört. Ich kann ein Beispiel aus meiner Erfahrung in einem Unternehmen aus Fortune 10 geben, über das ich bereits gesprochen habe. Ich habe mit einem Team von Testern zusammengearbeitet, die manuelle Tests durchgeführt haben, und wir mussten mit WebDriver automatisieren. Von diesen konnten die meisten Eclipse nicht einmal öffnen, um mit dem Schreiben von Code zu beginnen. Sie hatten Angst, ein Skript für die Automatisierung zu schreiben, da dies nach ihrem Verständnis nicht viel anders war als das Schreiben eines skalierbaren Webdienstes oder einer skalierbaren Datenbank mit Multithreading, also Dinge, die Entwickler seit Jahren gelernt haben. Diese Angst hinderte sie daran, im Allgemeinen einfache Dinge zu tun.

    Derzeit entwickle ich einen Kurs für das Testministerium auf der Grundlage eines Workshops, in dem ich Ihnen erläutere, dass Sie keine jahrelange Übung benötigen, um einfach ein Java-, C # - oder Ruby-Skript zu öffnen, es zu lesen und die allgemeine Struktur zu verstehen oder zu schreiben einfacher Test auf WebDriver. Selbst wenn Sie nicht alles verstehen, was im Code vor sich geht, können Sie eine allgemeine Einschätzung dazu abgeben, da Sie beispielsweise wissen, dass eine Methode nicht drei Bildschirme belegen sollte und es nicht vier verschachtelte if-Anweisungen geben sollte - diese sind schwierig Zu Testzwecken können Sie Variablen keine Namen mit einem Buchstaben usw. geben. Meiner Meinung nach besteht die Hauptschwierigkeit im Anfangsstadium darin, die Angst zu überwinden, dass Sie unglaublich komplexe Aufgaben lösen müssen. Und ich war immer daran interessiert zuzusehen Wie schnell werden meine Kunden von dieser Angst befreit? Sie müssen der Person lediglich einen einfachen Komponententest geben und sie bitten, zu schreiben, zu arrangieren, zu handeln und zu behaupten. Ich denke, diese menschliche Komponente ist sehr wichtig.

    Die meisten Technologien, mit denen wir arbeiten, sind nicht so kompliziert, nur wenige befassen sich mit Dingen wie unbemannten Fahrzeugen. Ich habe einmal ein Seminar für einen Kunden in Indien abgehalten, und es gab einen Manager ohne Programmiererfahrung. Dieser Manager war anfangs sehr wütend, und der Grund war genau diese Angst, von der ich gerade gesprochen habe, und diese Angst überlagerte die Zurückhaltung, dumm zu wirken. Aber am Ende der ersten Lektion stürzte er sich so sehr in das Schreiben von Tests, dass ich ihn eine Stunde nach dem Ende der Lektion aus dem Publikum verbannen musste - er saß, vergrub sich auf dem Monitor, paarte sich mit einem anderen Seminarteilnehmer und schrieb einfache Tests für den Gehaltsalgorithmus Bretter. Und hier geht es überhaupt nicht um meine Lehrfähigkeiten - es zeigt nur, wie wichtig diese Angst oder ihre Abwesenheit ist.

    Ihre zweite Frage bezog sich auf den Übergang vom manuellen zum automatisierten Testen. Ich habe einige Erfahrung hier, ich habe drei Jahre in einem Unternehmen gearbeitet, das sich mit Testautomatisierung beschäftigt. Ich glaube, dass die Frage anders gestellt werden sollte und nicht die Testautomatisierung zum Ziel hat, sondern die Entwicklung von Testern und deren Erwerb vieler technischer Fähigkeiten, von denen eine das automatisierte Testen sein sollte. Ich würde gerne solche Tester sehen, die mit einer User Story, Spezifikation und Anforderungen einen freien Dialog mit Entwicklern über eher spezielle Dinge führen und gemeinsam nach Lösungen suchen, die dann im Code enthalten sind. Dies unterscheidet sich etwas von dem Ansatz, bei dem der Tester das Programmieren lehrt, nur um WebDriver-Skripte schreiben zu können. Diese Fähigkeit ist natürlich auch wichtig, aber meiner meinung nach ist es nicht das wichtigste. Der Supertask ist meiner Meinung nach die Fähigkeit, einen Dialog mit dem Entwickler zu führen und sicherzustellen, dass er den Testprozess im Auge hat, wenn er den Code schreibt. Sogar TDD wird bereits ein bedeutendes Ergebnis sein - ich glaube, dass alle Organisationen in der Lage sein sollten, auf diese Weise zu schreiben.

    Das Fazit ist, dass korrekt gelieferte Tests keineswegs auf Komponententests oder Integrationstests beschränkt sind. Sehr oft sind die Leute damit zufrieden, einen typischen Code-Ausführungspfad zu testen - alle Tests sind bestanden, Kontrollkästchen sind überall, eine 100% ige Codeabdeckung wird erreicht. Aber nichts davon garantiert die Qualität des Codes, oder? Dies sind natürlich auch notwendige Verfahren. Daher sollte der Tester meines Erachtens nicht nur ein paar Funktionstests oder Tests in WebDriver schreiben, sondern auch darüber nachdenken, wie er eine engere Zusammenarbeit mit Entwicklern und Geschäftsanalysten aufbauen kann. Sie können zum Beispiel die Mob-Programmierung ausprobieren . Generell glaube ich, dass Automatisierung ein Werkzeug ist, kein Ziel.

    - Die Worte „enge Zusammenarbeit mit Entwicklern“ liegen uns als Heisenbug-Organisatoren sehr am Herzen - selbst das Motto der Konferenz lautet „Testen, aber nicht nur für Tester“. Und im Zusammenhang mit dieser Kooperation möchte ich folgende Frage stellen: Was möchten Sie als Person mit umfangreicher Testerfahrung unseren Lesern und Programmierern sagen?

    "Dass wir nicht alle böse sind!" Tester haben ihre Bekanntheit mit ihren eigenen Handlungen verdient. Sie bemängeln kleinste Details bei Besprechungen, kommunizieren oft Fehlerberichte, keine Worte. Der Entwickler kommt morgens zur Arbeit und sieht 50 Fehlerberichte, die über Grammatikfehler und nicht ausgerichtete Seiten berichten. Ich war in beiden Rollen und ich weiß, wie Programmierer darauf reagieren. Dies ist ein Teil der alten Schule des Testens, und ich selbst habe mich auch einmal so verhalten. Tester, die an den modernen Ansatz gewöhnt sind, wissen jedoch, dass es einfacher und besser ist, nur mit ihm zu sprechen, als einen Programmierer mit Fehlerberichten zu füllen.

    Meiner Meinung nach ist es für Entwickler wichtig zu verstehen, dass ein guter Tester sehr wertvoll sein kann. Wenn Sie im Voraus mit ihm sprechen, können Sie sich viel Zeit und Nerven sparen. Das sagt die Theorie der Zwänge. Angenommen, ich bin ein Entwickler und sehe, dass der Tester ein Problem festgestellt hat. Wenn ich nicht in TFS oder anderswo darüber eine SMS schreibe, sondern einfach zu ihm gehe und persönlich spreche, hilft mir dieses Gespräch dabei, die Anzahl der Fehler im von mir geschriebenen Code zu verringern. Darüber hinaus sind in der persönlichen Kommunikation die meisten Tester in der Regel alles andere als beängstigend. Im Allgemeinen können Sie als Entwickler die Qualität Ihres Codes verbessern, wenn Sie die üblichen Klischees über Tester beseitigen - die leider oft einen Grund haben und an denen wir auch arbeiten müssen.

    Deshalb hat es mir sehr gut gefallen, dass Sie auf Ihrer Konferenz versuchen, Menschen mit unterschiedlichen Spezialisierungen zusammenzubringen. Dies ist sehr wichtig, da sich alle wichtigen Konferenzen, die sowohl von Fachleuten als auch von der Community organisiert werden, lange Zeit selbst strikt eingrenzen - entweder nur Tester oder nur Entwickler. Wenn wir miteinander reden, wird es eine großartige Konferenz.

    Wenn Sie zu nahe des Konferenzgeschehens sind, und Jim Sie daran interessiert sind, beachten Sie, dass auch er in der Nähe von Moskau sprechen Heisenbug , wo mehr reden über ihre Erfahrungen in der Unternehmen aus der Liste der Fortune 10. Wie die Kultur zu ändern , in einem riesigen Unternehmen zu testen, wenn die Riesen in der Regel ungeschickt sind? Am 6. und 7. Dezember können Sie dies und vieles mehr bei Heisenbug erfahren .


    - Ich möchte Entwickler mit Testern vergleichen. Sie haben ein Buch über Führung geschrieben , Die Führungsreise . Es ist bekannt, dass Entwickler eine komplizierte Haltung gegenüber Führung haben: Während dies für andere ein geliebter Traum ist, verbinden Entwickler dies oft mit einer Reihe von unangenehmen Verantwortlichkeiten, die nicht mit dem interessantesten Teil - dem Schreiben von Code - zusammenhängen. Ist eine solche Sichtweise unter Testern weit verbreitet?

    - Ich denke, dies ist eine gängige Einstellung für die IT: Es spielt keine Rolle, ob Sie mit Datenbankverwaltung, Programmierung, Testen oder Projektmanagement befasst sind. Sie haben einen Job, den Sie gut machen, Sie fühlen sich wohl, Sie haben Erfahrung, Sie haben Einfluss auf diese Rolle. Im Vergleich dazu klingt die Notwendigkeit, mehr Verantwortung zu übernehmen und, entsetzt, mit Menschen zu arbeiten, viel unangenehmer und führt zu Ablehnung. Daher schlage ich ganz am Anfang meines Buches Wege vor, um herauszufinden, ob Sie all dies wirklich brauchen und was es bedeutet, ein Führer zu sein.

    Einige Führungsfunktionen können ausgeführt werden, ohne die Hierarchie nach oben zu verschieben. Eine Person innerhalb des Teams, die mehr Erfahrung und Fähigkeiten als andere hat, wird informell die Rolle eines Leiters in diesem Team spielen. Es geht also nicht unbedingt darum, Manager zu werden. Vielleicht denken Sie nur, dass Sie großen Einfluss auf Ihr Team haben müssen. Obwohl es in einigen Organisationen selbstverständlich ist, dass eine Person nach einiger Erfahrung Führungspositionen einnimmt. Er wird zum technischen Manager ernannt und ist jetzt neben dem Schreiben von Code für die Qualifikation seines Teams verantwortlich. Und auf höheren Ebenen hört er normalerweise auf, Code zu schreiben. Daher kann Führung im Allgemeinen viele verschiedene Formen annehmen. Die Besonderheit unseres Faches ist, dass wir Angst haben, Führungspositionen zu bekleiden, weil wir Angst haben, unsere technischen Fähigkeiten zu verlieren, weil wir aufhören, Code zu schreiben oder zu testen. Wenn der Tester nicht an der Entwicklung beteiligt ist, hat er außerdem Angst davor, Programmierer zu führen. Alle diese Probleme sind absolut natürlich, und ihre Überwindung ist ein wesentlicher Aspekt der Führungsrolle in unserer Branche.

    - Und noch eine Frage zum Vergleich von Entwicklern und Testern. Unter den Entwicklern gibt es eine aktive Diskussion in Bezug auf Remote-Arbeit: Einige sind der Ansicht, dass dies lange Zeit standardmäßig geschehen sollte, während andere beanstanden, dass Live-Kommunikation nicht durch Skype ersetzt werden kann. Sie arbeiten aus der Ferne - wie beurteilen Sie die Fernbedienung beim Testen?

    - Von den 18 Jahren, die seit der Geburt meiner Tochter vergangen sind, habe ich 13 oder 14 entfernt gearbeitet. Ich habe also wirklich eine Meinung zu diesem Thema. Meiner Meinung nach ist Fernarbeit ein wichtiges Instrument, mit dem Sie den Personenkreis erweitern können, mit dem Sie potenziell arbeiten können. Zum Beispiel mit einer Person, die in einem anderen Staat oder auf einem anderen Kontinent lebt. Ich bin also ein Unterstützer der Fernarbeit, in manchen Situationen ist es sehr nützlich.

    Gleichzeitig muss erkannt werden, dass beim Remote-Arbeiten erhebliche Kommunikations- und Produktivitätsprobleme auftreten. Aus technischer Sicht sollte ein Team, das vollständig oder größtenteils auf Distanz arbeitet, über eine gute Infrastruktur verfügen. Jedes Mitglied eines solchen Teams sollte nach dem DevOps-Prinzip arbeiten. Es sollte keine Situation geben, in der wir uns tagelang nicht an den Serveradministrator wenden können, um Protokolle für das Debuggen abzurufen. Darüber hinaus müssen Sie sich ernsthaft mit der Organisation von Kommunikationswerkzeugen befassen. Und wenn Sie der Meinung sind, dass Skype und ein Messenger für Sie ausreichen, hat Skype for Business die kostenlose Version von Google Hangouts nicht in Anspruch genommen, und es treten Probleme auf. Fernarbeit erfordert eine gute Infrastruktur. Darüber hinaus ist von Ihnen mehr Verantwortung und Disziplin gefordert. Ja

    Darüber hinaus sind Gespräche in den Korridoren und lebendige Kommunikation ein wesentlicher Bestandteil jeder Arbeit im Allgemeinen - die Menschen sind einfach so angeordnet. Und ich muss zugeben, dass hier die Fernarbeit einen erheblichen Nachteil hat. Lassen Sie Ihren Hangout in Slack und einem Live-Video-Chat laufen - das ist es nicht. Dieses Problem ist lösbar, erfordert jedoch Zeit und Disziplin und muss für jedes neue Teammitglied erneut gelöst werden.

    In den letzten 20 Jahren habe ich doppelt so weit wie im Büro gearbeitet, wie ich sagte - dies ist ein großartiges Werkzeug. Es ist jedoch notwendig, eine klare Vorstellung von den Vor- und Nachteilen einer solchen Arbeit zu haben. Darüber hinaus muss die Organisation mindestens viermal im Jahr das gesamte Team für die Live-Kommunikation zusammenbringen, um die Verbindungen herzustellen, die nicht über das Internet hergestellt werden können. Jeder muss in einem Raum sitzen, arbeiten, streiten, Spaß haben. All dies ist sehr wichtig, um ein gut koordiniertes Team zu bilden. Wenn Sie der Meinung sind, dass Remote-Arbeit nur eine Möglichkeit ist, Kosten zu senken, werden Sie enttäuscht sein. Ich habe wieder eine ziemlich lange Antwort bekommen, aber was zu tun ist, du stellst interessante Fragen.

    - Sie haben einen Beitrag mit dem Titel "Technische Schulden: Zahlungsplan". Der Ausdruck „technische Schulden“ ist häufig zu sehen, jedoch erstmals in Kombination mit dem Ausdruck „Zahlungsplan“, obwohl dies eine sehr logische Entwicklung der Metapher ist. Bedeutet dies, dass wir den Punkt der Verantwortung noch nicht erreicht haben, wenn wir technische Schulden so ernst nehmen wie Geld, und dass wir korrigiert werden sollten?

    - Dies ist ein sehr wichtiges Thema. Ich denke, dass jeder, der längere Zeit in der IT gearbeitet hat, notwendigerweise auf das Problem der technischen Verschuldung gestoßen ist. Hier muss ich mich bei Trish Khoo bedanken, auf Twitter ist es als Schweinsfisch zu finden. Sie ist eine hervorragende Testerin, ich kenne sie seit vielen Jahren. Tatsächlich schrieb sie den Beitrag „Technische Schulden: Zahlungsplan“. Ich wollte auch darüber schreiben, als ich diesen Beitrag las, weil ich fünf Jahre lang Reden auf Konferenzen hielt, auf denen ich im Allgemeinen ähnliche Gedanken äußerte.

    Das Problem der technischen Verschuldung ist in unserer Branche seit langem präsent. Wir alle müssen darüber nachdenken, wie wir es vermeiden können und was wir tun müssen, wenn es auftritt. Meiner Meinung nach hat Ihr Vorschlag, es als Finanzschuld zu betrachten, sehr wichtige Konsequenzen. Wenn Sie eine entsprechende Studie durchführen, werden Sie feststellen, dass diese technische Verschuldung zu finanziellen Kosten führt. Aufgrund der technischen Verschuldung nimmt Ihr Projekt X mehr Zeit in Anspruch, es arbeiten mehr Leute an Y und alle müssen ein bestimmtes Gehalt bezahlen. Das heißt, diese Kosten sind durchaus messbar, auch wenn sie möglicherweise nicht so einfach zu bewerten sind. Angenommen, Sie mussten 30 Bugs in anderthalb Monaten aufgrund technischer Schuldenprobleme beheben. Dies führt wiederum zu einem Anstieg des Projektpreises in Dollar. Außerdem,

    Vor vielen Jahren habe ich in einem Unternehmen gearbeitet, in dem alle 10 Tage an neuen Funktionen gearbeitet wurde, um die Probleme mit der Qualität und der technischen Verschuldung zu beheben. Und für jeden dieser 3 Tage gab es einen Tag der Korrektur von Korrekturen. Es gab Probleme, die viele Male wieder geöffnet wurden. Das alles kostet Geld. Ich verließ diese Organisation, so dass ich für die Zeit, in der ich dort arbeitete, die dort vorherrschende Kultur nicht ändern und sie zwingen konnte, zuzugeben, dass eine solche Situation inakzeptabel ist. Der letzte Strohhalm war mein erfolgloser Versuch, dem Direktor zu erklären, dass wir von den drei Jahren, die ich dort arbeitete, ein Jahr verloren haben, weil wir die technischen Schuldenprobleme behoben hatten. Ich konnte ihm meine Gedanken nicht übermitteln, er verlagerte das Gespräch auf ein anderes Thema. Ich glaube, dass die Leute in der IT arbeiten man muss lernen, die Bedeutung der technischen Verschuldung und die Kosten, zu denen sie führt, besser zu erklären. Wir können nicht einfach in unserer Ecke sitzen, arbeiten und mit niemandem kommunizieren. Wir müssen lernen, eine Sprache zu sprechen, die das Geschäft versteht. Und das Geschäft versteht die Sprache der Dollars und der verlorenen Zeit. Ein Unternehmen beginnt zu überlegen, wann Verkäufe oder Lizenzaktualisierungen sinken, und dies ist auf einen Qualitätsverlust zurückzuführen, der wiederum durch technische Schulden verursacht wird.

    Der Grund für die technische Verschuldung ist übermäßiger Druck, der Versuch, wichtige Dinge zu sparen, und die Tatsache, dass das Unternehmen die Bedeutung der von ihm getroffenen Entscheidungen nicht versteht. Dies ist auch dann zu bemängeln, wenn wir nicht über die erforderlichen Fähigkeiten verfügen, uns jedoch nicht an allgemein anerkannte Empfehlungen halten und nicht wissen, wie wir einen Dialog mit der Wirtschaft führen sollen. Das Lernen, technische Schulden in Bezug auf finanzielle Schulden zu formulieren, ist meiner Meinung nach eine sehr wichtige Fähigkeit, an der wir alle arbeiten müssen. Ich wiederhole, Sie haben eine sehr gute Frage gestellt.

    - Ich möchte hinzufügen, dass ich mit Situationen konfrontiert war, in denen das Schreiben von Modul- und Integrationstests als technische Pflicht angesehen wurde, da für die Ausführung der Hauptaufgaben keine Zeit mehr bleibt. Manager entscheiden, dass, da es ohne Tests funktioniert, wir alles so an die Produktion senden und Refactoring und Tests auf Kosten der technischen Schulden hinterlassen.

    - Dieses Problem hat zwei Seiten. Es ist für Unternehmen nicht klar, warum sie umgestalten und warum sie automatisierte Tests schreiben sollen. Sie sehen nur, dass die Leute doppelt so viel Zeit damit verbringen, Tests zu schreiben, als Code zu schreiben, und das erscheint ihnen monströs. Dies ist eine Frage der Bildung, daher muss erklärt werden, dass Entwicklung ein seit Jahrzehnten etablierter Prozess ist. Es gibt Statistiken und Studien, die belegen, dass der Versuch, Tests einzusparen, aufgrund von Verzögerungen und Korrekturen zu direkten Kosten in US-Dollar führt. Die Wirtschaft versteht das nicht.

    Wir haben unsererseits nicht gelernt, richtig mit dem Geschäft zu kommunizieren, und wir haben nicht gelernt, zu überzeugen. Außerdem fehlt es uns oft an Ausdauer, um zu erklären, dass einige Dinge nicht besprochen, ignoriert oder verschoben werden können. Es gibt sichere und produktive Praktiken, die sich in der Vergangenheit entwickelt haben, und wenn Sie als Manager diese befolgen, werden Sie am Ende glücklich sein, da eine Menge Kosten entstehen. Dies ist ein schwieriges Gespräch, und wir IT-Mitarbeiter wissen nicht, wie wir es führen sollen.

    - Deshalb ist es immer gut, wenn ein Manager oder Teamleiter Erfahrung in der Entwicklung hat - dann verstehen sie diese Dinge. Ein gutes Projekt ist einfacher zu erstellen, wenn das Management über technisches Fachwissen verfügt.

    - In der Firma von Fortune 10, über die ich oben gesprochen habe, hatten wir genau ein solches Problem. Die unteren und mittleren Führungskräfte haben nicht verstanden, warum das Testen so wichtig ist. Es ist uns gelungen, das Projekt neu zu starten und eine Einigung darüber zu erzielen, wann das Projekt als fertig betrachtet werden soll, dh, wir haben es geschafft, Manager in den Dialog einzubeziehen. Wir haben festgestellt, dass die User Story als fertig betrachtet wird, wenn es eine Dokumentation gibt, wenn der Support mit den neuen Funktionen vertraut ist und wenn das Produkt, der Kunde, die Anforderungen, die er geschrieben hat, mithilfe von Abnahmetests überprüft hat.

    Darüber hinaus erhielten wir die Zustimmung der Geschäftsleitung, bestimmte technische Maßnahmen umzusetzen, die er nicht verstand. Wir waren uns einig, dass der Code den Standardparametern der statischen Analyse (z. B. Analyse mit Sonar Cube) entsprechen sollte, das heißt, er sollte nicht zu kompliziert sein und nicht zu viele Zeilen in den Methoden enthalten. Die Manager erkannten, dass zur Aufrechterhaltung einer gesunden Codebasis Industriestandards für das Erscheinungsbild des Codes befolgt werden sollten. Darüber hinaus gab es in unserer Definition des abgeschlossenen Projekts die Formulierung „Notwendige Tests“, dh wir gaben keine bestimmte Anzahl von Tests an, die durchgeführt werden mussten, oder eine bestimmte Codeabdeckung mit automatischen Tests, die durchgeführt werden mussten. Dank dessen konnte der Projektteamleiter, Entwickler und Tester in Bezug auf jedes Modul bestimmen welche prüfung wird ausreichen. Jedes Mal, wenn dies während des Dialogs geschah, konnten die Manager lange Zeit nicht verstehen, dass dies wieder den allgemein akzeptierten Branchenpraktiken entspricht.

    - Hier endeten unsere Fragen. Vielen Dank für Ihre ausführlichen Antworten.

    - Danke, mir haben deine Fragen gefallen. Ich denke, es war sichtbar: Sie haben viele Themen angesprochen, die mir persönlich sehr nahe stehen.

    Jetzt auch beliebt: