AG Softwaretechnik

Der Plan™

Idee, Motivation, Strategie

http://ag-softwaretechnik.de/

http://ag-softwareentwicklung.de


Situation BundesIT

• infrastrukturell überfordert

• zeitlich überfordert

• teils fachlich überfordert

• „Software-Entwicklung“ Randthema




Situation BundesIT

• infrastrukturell überfordert

• zeitlich überfordert

• teils fachlich überfordert

• „Software-Entwicklung“ Randthema

Neuentwicklungen

unrealistisch.




• Wordpress

• Drupal

• MediaWiki

• EtherPad Lite

• Lime Survey

• …

• …

• …

Situation SoftwareBund und Landesebenen

Primär: Anpassungen




Eigenentwicklungen

• Clearingstelle

• von Alios in Haskell.

• PiratenID

• von Jan S. in PHP

• ohne Trennung Code/HTML, 0 Tests, etc.

Bund und Landesebenen




Eigenentwicklungen

• Liquidizer und co.

• Java

• undokumentiert, ohne Tests.

Bund und Landesebenen




Ausser Konkurrenz

• Liquid Feedback• externe Entwicklung

• lua, haskell, c

• keine Tests, keine Dokumentation




Ausser Konkurrenz 2

• Saftige Kumquat• Frontend für Liquid Feedback 2

• node.js

• keine Tests, keine Dokumentation

• erstes node.js Projekt der Entwickler (laut eigener Aussage)




Probleme

• zwischen 1-3 aktiven Entwicklern

• nahezu undokumentiert

• nahezu ohne Tests

• oftmals „zu viel Eigenentwicklung“




Zu viel Eigenentwicklung

• Etablierte Frameworks ignoriert

• Etablierte Bibliotheken ignoriert

• Rad selbst neu erfinden

• „schlauer sein“

• „only learning by doing“





• „Community Review“ fehlt

• Übersehen von Standards

• kompliziertes Deployment/Ops

• Abhängigkeit von 1-2 Entwicklern über den „reinen Zweck“ der Anwendung hinaus (zB. Webframework)

Probleme:





• Obskuritäten erschweren Einarbeitung

• Hohe Hürden für Interessierte Mitentwickler

• Know-How nicht übertragbar

Probleme #2:





• Alles hängt an einzelnen Personen

• Partei macht sich abhängig

• Mitarbeit wird (in)direkt verhindert

• keiner kommt „lebend heraus“

(=> kein Nachfolger => Von Vorne.)

Fazit:





• Alles hängt an einzelnen Personen

• Partei macht sich abhängig

• Mitarbeit wird (in)direkt verhindert

• die aus der Situation nicht „lebend herauskommen“ (=> kein Nachfolger)

Fazit:

Neuentwicklungen

unrealistisch.




Erfolgreiche OpenSource Projekte

• strenge Regeln (Architektur, Formatierung, Projektziel)

• starke Integration von Nutzern (Kollaboration, Bugtracking) z.B. durch GitHub

• Hohe Ansprüche an Tests und Dokumentation

(der letzten Jahre)





• Mitarbeit steigt nachhaltig

• Bugs werden schneller gefixt

• Projekt-Konsens ist „größer“, demokratischer

• Kommunikation steigt

Erstaunliches Resultat:





• Transparente Arbeitsweise und Kritik hilft Neueinsteigern besser, sich in Projekte einzufinden

• Tools helfen dabei, diese Kommunikation zu vereinfachen

• Qualität steigt!

Erstaunliches Resultat:

„Bozo Explosions“

• A player hire A+ player, B player hire C player hire ... Z player

• was Steve Jobs sagte :-)




Politische Relevanz

• US-Präsidentschaft 2008/Obama

• Bundestagswahl 2009

• AGH-Wahl 2011

• US-Präsidentschaft 2012

Beispiele Deutschland

• Schuldenuhr Berlin

iPhone App von @plaetzchen

• „3 Tage Wach“ der Grünen

• 2009: „PiratenVogel“ auf Twitter.




Beispiele Deutschland

• Schuldenuhr Berlin, iPhone App von @plaetzchen

• „3 Tage wach“ der Grünen

• …

Wahlkampf-

Mobilisierung




„Wir sind eine Partei — keine Softwarebude!“• Erheben technologischen Anspruch

• haben kein Geld für externe Entw.

• stehen für ortsungebundene Teilnahme

• haben aber massive organisatorische Probleme damit: „People don‘t scale.“

ungenutzte Chancen

• Knowledge-Management

• Neupiraten-Information

• Organisation

• Automatisierung d. Kommunikation

• Dynamische Koordination




ungenutzte Chancen

• politische Arbeit

• Jenseits von Etherpad, LimeSurvey und Liquid Feedback

• Thematische Kampagnen-Apps

• Crowdsourcing/Bürgerfeedback




ungenutzte Chancen

• uvm. etc. pp.




Voraussetzungen

• Verlässliche Infrastruktur

• Automatisierung der Entwicklung

• Praxiserprobte Technologien

• Dokumentation und Tests zur Transparenz und gegen „Wissensmonopole“ (Lock-in)




Voraussetzungen

• Verlässliche Infrastruktur

• Automatisierung der Entwicklung

• Praxiserprobte Technologien

• Dokumentation und Tests zur Transparenz und gegen „Wissensmonopole“ (Lock-in)

+ Wissen, Erfahrung & Fleiss




Wie erreicht man die Zielgruppe?

• „Kein Scheiss-Policy“. No Holy Wars.

• Wenig Experimente

• Klar definiertes und limitiertes Engagement (keine „Helden“)

• Community-übliche Qualität

Freiheiten

• AG Softwaretechnik

ist nur eine Möglichkeit.

• Kein „Alleinanspruch“ / Zentralismus

• Offen für Technologien, die community-/marktübliche Qualitätsanforderungen erfüllen.




Qualität

• Agile Vorgehensweise

(Kanban, Scrum, XP)

• Automatisierte Tests

• Lebende Dokumentation

• Erleichtert die Entwicklung, Wartung, Wissenstransfer, Review/Audit.




Qualität

• Somit klares Zeitmanagement

• Auch für berufstätige Vollzeitentwickler

• welche nur ein kleines Maß an Zeit übrig haben.




Grundlagen schaffen.

• Technologieteams in „Stacks“ organisieren.

• Basisinfrastruktur schaffen die alle Teams nutzen können.

• Rapid Application Development




Qualität

• Klares Zeitmanagement.

• Berufstätige Entwickler einschliessen.

• Zeit ist teuer. Effiziente Zeit-Nutzung.




Qualität

• Klares Zeitmanagement.

• Berufstätige Entwickler einschliessen.

• Zeit ist teuer. Effiziente Nutzung.

Weniger Stress.

Weniger Streit.

Weniger Risiken.




Fundamente

• Planung

• Entwicklung

• Betrieb




Planung

• Wer soll es benutzen?

• Wer definiert die Anforderungen?

• Wer begleitet die Entwicklung?

• Ansprechpartner

• Realistische Erwartungen




Entwicklung

• GitHub

• Automatisierte Tests,

ggf. Test Driven Development

• Kanban (z.B. Trello)




Betrieb

• Wo läuft die Anwendung später?

• Wer stellt Ressourcen?

• Setup/Wartung?

• Deployment?




Disziplin!

• YAGI — You aint gonna need it!

• KISS — Keep it simple, stupid.

• DRY — Don‘t repeat yourself.

• It‘s a problem, when it‘s a problem.




Disziplin!

• Lösungen finden

• keine neuen Probleme suchen.

• Deadline: Maximale Projektdauer.




Vorstellung Stack #1

• Ruby 1.9

• Ruby on Rails 3.2

• Twitter Bootstrap

• SQLite3, MySQL, PostgreSQL

• Deployment mit Capistrano ggf. DevOps mit „chef“

(Hier kenne ich mich sehr gut aus ;-)




Vorstellung Stack #2

• ???

• ???

• ???

• ???

• ???

durchdachte, gleichwertige Alternativen?




DevOps

• chef, puppet, …

• hängt vom „Hoster“/“Zulieferer“ ab (LandesIT, BundesIT, …)

Gescriptetes Operations




Ambitioniert?

• Sicher :-)




Wenn keiner will?

• Ich habe gefragt.

• Ich kann delivern.

• Wenn Leute nicht wollen…

…überlasse ich sie ihrem Schicksal :-)(Denn ich habe absolut keine Lust mehr, meine (Frei-)Zeit mit Frickel-Scheiss zu verschwenden. Sorry.)




Wenn keiner will?

• Ich habe gefragt.

• Ich kann delivern.

• Wenn Leute nicht wollen…

…überlasse ich sie ihrem Schicksal :-)(Denn ich habe absolut keine Lust mehr, meine (Frei-)Zeit mit Frickel-Scheiss zu verschwenden. Sorry.)




ag-softwaretechnik.de…mitmachen!



Documents

AG Softwaretechnik