Muss jedes Mitglied eines agilen Teams ein Softwareentwickler sein?

In meinem Unternehmen haben wir kürzlich begonnen, agile Methoden anzuwenden. Da ich für Agile noch recht neu bin, frage ich mich, ob unsere Art der Implementierung gemäß den Grundprinzipien von Agile korrekt ist.

Zuvor hatten wir Funktionen wie Business Analyst, QS-Tester und Softwareentwickler. Aber jetzt hat das Management entschieden, dass diese Rollen entfernt werden sollten und jeder als Softwareentwickler arbeiten wird.

In der Praxis bedeutet dies, dass ein Softwareentwickler die gleichen Verantwortlichkeiten hat wie drei separate Rollen zuvor (dh ein Geschäftsanalyst, ein QS-Tester und ein Softwareentwickler).

Sie begründen die Änderung damit, dass dies agil ist. Implementieren andere Unternehmen auf diese Weise auch Agilität?

Nein, das ist definitiv nicht agil. Es ist auch keine gute Idee.

Funktionsübergreifende Teams, dh Teams, die alle Rollen umfassen (Analyst, Serveradministrator, Datenbankadministrator, UX-Designer, QS-Tester, technischer Redakteur, Grafikdesigner), die für die erfolgreiche Bereitstellung funktionierender Software erforderlich sind, sind eine Grundvoraussetzung für viele agile Methoden. Tatsächlich wird in vielen Methoden auch der Kunde selbst als Teil des Teams betrachtet.

Tatsächlich ist dies jedoch orthogonal zu agil. Funktionsübergreifende Teams sind einfach eine gute Idee, unabhängig davon, ob Sie agil sind oder nicht.

Was jedoch zutrifft, ist, dass mit dem stetigen Anstieg von automatisierten Tests, Entwicklertests, testgetriebenen und verhaltensgetriebenen Entwicklungen einerseits und softwaredefinierter Infrastruktur, hochautomatisierter Inbetriebnahme, Konfiguration und Bereitstellung DevOps und Beim Cloud-Hosting haben sich einige der Workloads möglicherweise von Administratoren zu DevOps-Ingenieuren und von der Qualitätssicherung zur Entwicklung verlagert. Dies bedeutet jedoch nicht , dass diese Rollen ausgestorben sind. Dies bedeutet nur, dass die Qualitätssicherung interessantere Fehler zu verfolgen hat, da alle trivialen Fehler durch Entwicklertests gefunden wurden und Administratoren sich mehr darauf konzentrieren, DevOps die Verwaltung der Infrastruktur mit automatisierten Tools zu ermöglichen, als sie selbst zu verwalten.

Es gibt einen einfachen Test, um zu überprüfen, ob etwas agil ist: Wenn jemand sagt "Sie tun dies, weil es agil ist", ist es nicht agil. Bei Agile dreht sich alles um selbstverwaltende Teams, die ihre Prozesse ständig reflektieren und anpassen. Immer wenn jemand sagt "du machst das", ist es nicht agil. Es ist nur agil, wenn das Team sagt: " Wir tun dies, weil wir nach dem Nachdenken über unsere früheren Erfahrungen festgestellt haben, dass es funktioniert, und wir werden weiter darüber nachdenken und aufhören, es zu tun, sobald wir feststellen, dass dies nicht der Fall ist."

Implementieren andere Unternehmen auf diese Weise auch Agile?

Leider ja. Es gibt viele Unternehmen, in denen Agile vom Management auferlegt wird oder zumindest das, was sie für Agile halten (was natürlich nicht der Fall ist).

Wenn Sie sich den Scrum-Leitfaden ansehen , von dem wahrscheinlich Ihr Management die Idee aufgegriffen hat, finden Sie Folgendes:

Scrum erkennt keine Titel für andere Mitglieder des Entwicklungsteams als Entwickler an, unabhängig von der von der Person ausgeführten Arbeit

Die Idee, dass jeder im Team ein "Entwickler" ist, ist jedoch, dass sie unabhängig von ihrer Rolle (Qualitätssicherung, Programmierer, Designer usw.) gemeinsam mit gleichen Anstrengungen und gleicher Verantwortung und Verantwortlichkeit zur Entwicklung der Anwendung beitragen . Die Programmiererin ist nicht wichtiger als die Testerin, nur weil sie den Code schreibt und die Testerin ihn nur testet. Der Designer erstellt die Drahtmodelle nicht und verschwindet dann, während die Front-End-Entwickler sie implementieren. Jeder ist wichtig. Jeder trägt dazu bei. In dieser Hinsicht sind alle gleich. Berufsbezeichnungen spielen keine Rolle. Deshalb ist jeder ein "Entwickler".

Dies bedeutet jedoch nicht, dass der Designer plötzlich mit der Architektur der Anwendung oder dem Schreiben des Codes beginnt. Und im gleichen Gedankengang, nur weil Sie jetzt alle "Entwickler" sind, weil das Management dies gesagt hat, heißt das nicht, dass Sie Agile machen.

Was sie tun, ist Unsinn. Wenn Sie beispielsweise einen Softwareentwickler dazu bringen, eine QS-Rolle zu übernehmen:

Erstens verfügt der Softwareentwickler nicht über die erforderliche Erfahrung. Es sind alles Dinge, die gelernt werden können, aber ich persönlich würde als Junior-QS-Ingenieur anfangen und weitaus weniger effektiv sein als Softwareentwicklungsarbeiten.

Zweitens haben Menschen unterschiedliche Talente und gehen in Positionen, in denen ihre Talente zählen. Menschen werden Softwareentwickler, weil sie ein Talent dafür haben, und andere werden QS-Ingenieure, weil sie ein Talent dafür haben. Und beide wären im anderen Job weniger gut gewesen.

Drittens, wenn dieselbe Person sowohl Softwareentwicklung als auch Qualitätssicherung durchführt, stehen sie in Konflikt. QA findet Probleme, die Softwareentwicklern mehr Arbeit verursachen. Softwareentwickler mögen wie alle anderen nicht mehr Arbeit. Was erwarten Sie von einem Softwareentwickler, der als Qualitätssicherung arbeitet?

Obwohl Agiles Ursprünge im Bereich der Softwareentwicklung liegen, gibt es seit den späten 50er Jahren iterative Entwicklungsansätze, die in den frühen Tagen der NASA verwendet wurden (siehe https://en.wikipedia.org/wiki/Iterative_and_incremental_development ). Diese Teams waren offensichtlich nur Softwareentwickler.

Wir haben in meinen Unternehmen und für das von mir betreute Roboterteam erfolgreich verschiedene agile Ansätze eingesetzt. Das Konzept von Sprints, Spikes und iterativem Design mit übergreifenden Epen hat sich im gesamten Team als sehr erfolgreich erwiesen - Software, Hardware, CAD, Marketing usw. Dafür haben wir keine der "DevOps" -Infrastrukturen, die die Kinder tun Geradliniges Prototyping und Demonstrationen ihrer Erkenntnisse in zweiwöchigen Sprints. Von dort aus werden Entscheidungen über das weitere Vorgehen getroffen, aber im Kern befindet sich ein Roboter, der mit jedem Sprint allmählich besser wird. In Bezug auf die Rolle besteht dies aus "Softwareentwicklern", "CAD-Mitarbeitern", "Buildern" und "Outreach". Der Großteil dieses Teams ist NICHT direkt an Codierungssoftware beteiligt.

Für meine Softwareunternehmen besteht das Team normalerweise aus Entwicklern, Testern, Entwicklern, Designern und Support.

Im Allgemeinen ist Agile keine Sache und es gibt viele Ansätze zur Umsetzung der Philosophie. Im Kern geht es jedoch um die Idee der iterativen Entwicklung, der Aufteilung der Arbeit in kurze Aufgaben und der kontinuierlichen Neubewertung. Dinge wie tägliche Scrum-Meetings, Rückstände, User Stories usw. werden oft verwendet, müssen aber in keiner Weise "agil" sein. Bei Agile geht es darum, sich ständig anzupassen. Dazu gehört auch, wie ein bestimmtes Team Agile selbst implementiert.

Kurze Antwort: Ihr Managementteam versteht Agile entweder nicht oder verwendet dies als Rechtfertigung, um Dinge zu beseitigen, die es für Geldverschwendung hält. Es mag gerechtfertigt sein, Änderungen vorzunehmen, aber nicht, weil Agile nur für Programmierer gedacht ist.