Security im agilen Kontext

Diese Tage kam ich in der Diskussion mit einem Kunden auf die Berücksichtigung von Security Requirements in einem agilen Kontext.

Hintergrund war, dass bislang Security vor allem für den Betrieb und für die Produktsicherheit thematisiert wird, aber Sicherheitsaspekte in der Entwicklung und in einer Projektphase noch eher stiefmütterlich behandelt werden. Auf der anderen Seite finden agile Vorgehensweisen immer weiter Einzug in die Unternehmen und die Ausgangsfrage des Kunden war, wie man Sicherheitsbelange im agilen Kontext berücksichtigen kann.

Für die Projektsicht gibt es vor allem zwei Themenstränge (und dabei müssen wir noch nicht mal zwischen agil und klassisch unterscheiden):

  • Die Sicherheit im Projekt
  • Die Entwicklung der Sicherheit für Produkt und Betrieb

Bei letzterem Punkt könnte ich mir unterschiedliche Strategien vorstellen:

  • Ein stufenweiser Hochlauf, bei dem systematisch das Sicherheitsniveau angehoben wird. (Anfangs mit einer Sandbox, dann Aufbau einer Entwicklungsumgebung, erst noch ohne Daten, dann nur mit einem Teilset der Daten, bis hin zur vollumfänglichen Produktion)
  • Vorgabe von Leitplanken (im Qualitätsmanagement gibt es dafür das Control Chart als Werkzeug).

Grundsätzlich würde ich Security-Anforderungen im Normalfall den nicht-funktionalen Anforderungen zuordnen.

Agile SW-Entwicklung fokussiert tendenziell auf funktionalen Anforderungen. Werden dabei wichtige nicht-funktionale Anforderungen vergessen, so kann dies eine Schwäche agilen Vorgehens sein.

Im Wesentlichen finden sich drei Ansätze zur Berücksichtigung von Security Requirements im agilen Kontext:

  • Eigene nicht-funktionale Einträge ins Backlog (beispielsweise eigene User Stories. Ein Kollege hat mir berichtete mir, dass er ein eigenes Backlog für Security Anforderungen aufgebaut hat.)
  • Berücksichtigung nicht-funktionaler Anforderungen als Constraints
  • Berücksichtigung als Kriterien im Definition of Done

Wenn die Vorgaben für Security oder nicht-funktionale Anforderungen allerdings zu sehr formalisiert werden, dann birgt das bereits einen kulturellen Konflikt: Ein formaler Prozess entspricht jetzt nicht ganz den agilen Vorstellungen von eigenverantwortlichem Handeln, d.h. auch da bräuchte es klar definierten Handlungsspielraum für das Team.

Maturity Ansätze fand ich zur Berücksichtigung von Security Anforderungen nicht hilfreich. Da finden sich  CMMI-Adaptionen auf agile Vorgehensweisen. Thematisiert wird aber das Vorgehensmodell an sich und nicht die Berücksichtigung nicht-funktionaler oder sicherheitsrelevanter Anforderungen.

Beitrag #723 auf schlossBlog

#562 Gelesen: Management 3.0


Jurgen Appelos Buch „Management 3.0 – Leading Agile Developers, Developing Agile Leaders“ ist der legitime Nachfolger von DeMarco/Lister´s „Peopleware“ (zu Deutsch: „Wien wartet auf dich„).

Appelo versucht Management-Konzepte vor dem Hintergrund agiler Software-Entwicklung und moderner Systemtheorie neu aufzurollen. Dies gelingt ihm sympatisch und kompetent. Das Buch hat sicherlich seine Macken (ich finde die Konzentration auf Software-Entwicklungsteams etwas künstlich und sein Umgang mit Fußnoten, die i.d.R. auf die eigene WebSite referenzieren ist zumindest gewöhnungsbedürftig, obwohl interessierte Leser mehr als genug (auch wissenschaftliche) Literaturhinweise finden). Alles in allem ist es aber anregend, kritisch, trotz theoretischem Fundaments praktisch orientiert und vor allem gut lesbar. Jurgen Appelo´s Pragmatismus kommt in seinem Schlusswort zum Ausdruck:

I know my book is „wrong,“ but I sincerely hope you find it useful.

Aus dem bunten Konglomerat von Agiler Software Entwicklung, Systemtheorie und moderner Management Theorie leitet Jurgen sein Management 3.0 Modell mit der Comic-Figur Martie (sein Buch lebt auch von den Illustrationen), die sechs Augen hat und damit sechs unterschiedliche Sichtweisen repräsentiert, die ein agiles Management nach Jurgens Auffassung haben sollte:

  • Energize People
  • Empower Teams
  • Align Constraints
  • Develop Competence
  • Grow Structure
  • Improve Everything


Den ganzen Beitrag lesen…

#437 Nachtrag: Agile Softwareentwicklung mit verteilten Teams

In Beitrag #435 von der Scrum-Konferenz bin ich noch die Inhalte von Jutta Ecksteins Podcast schuldig geblieben:

Die Zeiten eines Outsourcing und Offshoring in der Software-Entwicklung aus reinen Kostengründen sind aus ihrer Sicht vorbei, denn Spezifikationsaufwand, kulturelle Unterschiede und die erforderliche Kommunikation bergen erhebliche Risiken. Wer rein aus Kostengründen outsourct, wird vom Ergebnis in der Regel enttäuscht sein, so ihr Fazit.

Gründe, die auch heute dafür sprechen sind Personal-/Skill-Mangel und marktliche Anforderungen, etwa bei der Erschließung neuer Märkte oder um Kundennähe zu gewährleisten.

Die Entscheidung für verteilte Teams in der Software-Entwicklung ist in der Regel aus einer Notwendigkeit heraus geboren und keine „Liebesentscheidung“.


Den ganzen Beitrag lesen…

#394 PM-Reader

Was zuletzt in meinem Feedreader als lesenswert hängen blieb: