Agiles Vorgehen Ausschreibungen/Ergebnisse AG Agile
Beschaffung - Vergabe von öffentlichen Aufträgen[Bearbeiten | Quelltext bearbeiten]
Mit gutem Grund ist die Vergabe von öffentlichen Aufträgen an diverse Regelungen gebunden (z.B. Landeshaushaltsordnung, Vergabegesetze der Länder, Gesetz gegen Wettbewerbsbeschränkungen, Unterschwellenvergabeordnung, VOL, VOB). Obwohl oder gerade weil es so vielfältige Regelungen gibt, macht es eine Auftragsvergabe nicht einfacher.
Finanzkalkulation in Verwaltungen[Bearbeiten | Quelltext bearbeiten]
In vielen Verwaltungen und Landesbetrieben ist im September eine mehr oder weniger begründete Finanzplanung für das nächste Jahr einzureichen. In der Regel werden dabei Exceldateien per E-Mail von einer Finanz- oder Serviceinheit zu den Abteilungen und von den Abteilungsleitern an die Fachbereichsleiter und von dort an die jeweiligen Mitarbeiter verschickt. Die jeweiligen Mitarbeiter müssen dann im September wissen wofür sie im nächsten Jahr wie viel Geld ausgeben wollen oder müssen. Die dabei entstandenen und per E-Mail zurückgesandten vielen Exceldateien werden dann (hoffentlich) von irgendjemandem zusammengefügt und eine Ebene nach oben in die Betriebsleitung gebracht. Dort wird geprüft und abgewogen um dann einen Finanzplan mit den entsprechenden "Budgets" für die einzelnen Fachbereiche aufzustellen.Der Beauftragte des Haushaltes (BdH) segnet diesen ab und erhält die ehrenvolle Aufgabe, den Rest des Jahres den geregelten Mittelabfluss zu kontrollieren.
Beschaffung[Bearbeiten | Quelltext bearbeiten]
Der Beschaffer muss schon sehr früh Klarheit über die voraussichtliche Höhe des Betrages, der bei der Beschaffung ausgegeben werden soll, haben. Entsprechend der Höhe des voraussichtlich auszugebendem Betrag und des sich daraus ergebenem Vergabeverfahrens ist die richtige Form des Beschaffungsantrages abhängig.
Bei einem Beschaffungswunsch muss der Beschaffer einen Beschaffungsantrag ausfüllen. Meist sind das mehrseitige Wordformulare in denen mehr oder weniger detailliert dargelegt werden muss was, wann und warum beschafft werden soll. Das Produkt bzw. die Leistung ist so zu beschreiben, dass nachfolgende Stellen verstehen, was gemeint ist. Wenn eine Verwaltung oder ein Landesbetrieb eine gewisse Leistung selten oder erstmalig beschafft, muss diese genauer beschrieben werden. Beispielsweise kann sich heute jeder etwas unter einem Notebook vorstellen, da muss man nicht mehr so viel beschreiben, bei einer Software, die nicht MS-Office ist, schon. Weiterhin sind eine Neutralitätserklärung des Beschaffers und eine Leistungsbeschreibung beizufügen. Die Leistungsbeschreibung soll noch einmal umfassender beschreiben, was beschafft werden soll und (eigentlich) als Vorlage für die in den Vergabeunterlagen beizulegende Leistungsbeschreibung dienen.
Da die Vergabestellen in der Regel wenig Wissen über das zu Beschaffende haben, wird es nicht gerne gesehen, wenn die Leistungsbeschreibung nach Beantragung geändert wird. Eine kollaborative Bearbeitung der Leistungsbeschreibung erfolgt oftmals nicht.
Dieser Beschaffungsantrag geht an mindestens einen Vorgesetzten und wird dort gezeichnet und an die (interne) Vergabestelle weitergeleitet. Dort wird geprüft ob das Geld eingeplant war, ob es wirklich keine Generalverträge gibt und ob die Beschaffung in das Konzept der Verwaltung passt. Wenn dass alles passt geht es an den BdH der prüft ob Mittel vorhanden sind. Nach der Prüfung ist zumindest klar, dass Geld vorhanden ist und ob aus interner, formaler und fiskalischer Betrachtung beschafft werden kann.
Entsprechend der jeweiligen Schwellwerte sind drei Angebote einzuholen und die Wahl zu begründen. Gefordert ist, dass die Wahl auf das "wirtschaftlichste" Angebot fällt. Wenn die Wahl allerdings nicht auf das billigste Angebot fällt ist deutlich mehr Begründungsarbeit zu leisten.
Wenn der Schwellenwert für freihändige Vergaben voraussichtlich überschritten wird (oft > 5000 €), ist eine beschränkte Ausschreibung bzw. eine Verhandlungsvergabe ( < 100 000 €) oder eine öffentliche Ausschreibung (> 100 000 €) durchzuführen. In der Regel muss auch bei beschränkten Ausschreibungen oder Verhandlungsvergaben eine Bekanntmachung erfolgen und Teilnehmern der Zugang gewährt werden. Die Verwaltungen sind in der Regel an einen "Vergabemarktplatz" gebunden. Für die Vergabe sind noch diverse weitere Formulare auszufüllen. Neben all diesen Formularen ist die Leistungsbeschreibung und die Bewertungsmatrix elementar. Der Beschaffer hat in der Regel kaum Wissen zum Vergaberecht und zur Bewertung der Angebote. Deshalb bleibt ihm zumeist gar nichts anderes übrig als bisher gut gelaufene Ausschreibungen und Vergaben als "Vorlagen" zu nutzen. Die Vergabestellen haben wiederum kaum Wissen vom Fachgebiet des Beschaffers und gleichzeitig die Befürchtung, dass das Budget überzogen werden könnte. Dementsprechend bleibt der Vergabestelle kaum etwas anderes übrig als vom Beschaffer möglichst detaillierte Beschreibungen und nachvollziehbare Bewertungen einzufordern. Wenn die Vergabestelle nicht Versteht was der Beschaffer meint, bleibt der Antrag liegen.
Was ist agiles Vorgehen?[Bearbeiten | Quelltext bearbeiten]
Agiles Vorgehen wird am besten durch den Spruch beschrieben, dass "jeder Plan nur so gut ist, wie die Werkzeuge, um ihn zu ändern". Um einen Plan dauernd an die Realität anpassen zu können, ist Transparenz erforderlich und dauernde Kurskorrekturen. Das ist so wie Fahrradfahren. Ständig muss der Lenkeinschlag korrigiert werden, um nicht umzufallen. Wenn der Lenker fest umkrallt und der Einschlag nicht geändert wird, muss das Fahrrad unweigerlich umfallen. Außerdem muss das Fahrrad immer in Bewegung bleiben. Nach einer Weile geht das von ganz alleine und irgendwann sogar freihändig.
Agile Software-Entwicklung bedeutet, dass ein Ziel nur in kleinen Iterationen umgesetzt wird.
- Zunächst gibt es nur eine Vision und ein Ziel.
- Als erstes wird die Grundlage geschaffen, um dieses Ziel erreichen zu können
- Dann wird schrittweise auf dieser Grundlage aufgebaut.
- Der konkrete, fein-granulare Plan liegt immer nur für die nächste Iteration vor.
- Nach jeder Iteration muss ein vorzeigbares "Ding" zu sehen sein.
- Dieses "Ding" wird bewertet und die nächsten Schritte und Aufgaben definiert, um das "Ding" dem Ziel näher zu bringen. Immer nur für die nächste Iteration.
"Regeln"[Bearbeiten | Quelltext bearbeiten]
- Während der Iterationen arbeitet das Team ungestört (die Anforderungen ändern sich während dieser Iteration nicht).
- Gleichzeitig / parallel werden die Pläne für die jeweils nächste Iteration erstellt.
Methoden[Bearbeiten | Quelltext bearbeiten]
Es gibt verschiedene Methoden des agilen Vorgehens. Dabei besteht natürlich immer auch die Gefahr, sich wieder in einer Methode zu verfangen, was dann nicht mehr agil ist. Die wahrscheinlich bekanntesten Methoden sind:
- Scrum
- XP (eXtreme Programming -> eigentlich eine Super Sache, siehe Clean Code)
- Kanban
Jede Methode hat Vor- und Nachteile, letztendlich muss jedes Projekt und jedes Team die am besten geeignete Methode herausfinden. Das übergreifende Leitbild ist unter agile Manifesto zu finden. Es hat sich herausgestellt, dass Scrum ein guter Einstieg in die agile Software-Entwicklung ist.
Buch- und Leseempfehlungen:[Bearbeiten | Quelltext bearbeiten]
- Der agile Festpreis: https://www.hanser-kundencenter.de/fachbuch/artikel/9783446454361
- Wikipedia: https://de.wikipedia.org/wiki/Agiler_Festpreis
- Text OSBA: Nachhaltiger Open Source Einsatz für die digital souveräne Verwaltung: https://osb-alliance.de/publikationen/veroeffentlichungen/nachhaltiger-open-source-einsatz-fuer-die-digital-souveraene-verwaltung-paper
- Handreichung zur Nutzung der EVB-IT beim Einsatz von Open Source Software: https://osb-alliance.de/publikationen/veroeffentlichungen/handreichungen-zur-nutzung-der-evb-it-beim-einsatz-von-open-source-software
- agilemanifesto.org: https://agilemanifesto.org/iso/de/principles.html
Fallbeispiele[Bearbeiten | Quelltext bearbeiten]
- BfS (Marco Lechner)
- eine der letzen Ausschreibungen, die gut funktioniert haben
- Helmholtz Zentrum (Volkers Beispiel)
- Rahmenvertrag
- Phasen: Vorbesprechung (Design Camp)
- Erster Plan (agil entwickelt, überschaubares Budget)
- ...
- ...
Entwicklungswunsch eines Wissenschaftlers[Bearbeiten | Quelltext bearbeiten]
Ich als Wissenschaftler benötige für Feldaufnahmen die von Unternehmern durchgeführt werden sollen und für die anschließende Auswertung und Veröffentlichung eine Datenbank, ein Aufnahmeformular, eine Möglichkeit zur Synchronisierung der Daten und eine Möglichkeit zur Auswertung und Visualisierung der Daten. Ich als Wissenschaftler habe die Methodik für die Feldaufnahmen und zur Auswertung entwickelt. Für die Erstellung der Datenbank habe ich ein konzeptuelles Datenmodell in Anlehnung an UML entworfen. Wie genau die Datenbank und alle daranhängenden Softwarekomponenten aussehen und funktionieren sollen weiß ich nicht. Ich möchte, dass die OGC-Standards eingehalten werden, alle Daten in offenen, nicht proprietären Formaten ausgetauscht und OpenSource Technologien genutzt werden. Ich möchte gerne die Quelltexte übergeben bekommen und gegebenenfalls selbst weiterentwickeln. Die Datenbankengine soll eine PostgreSQL mit PostGIS-Erweiterung sein. Die Leistungsbeschreibung umfasst die für mich als Wissenschaftler greifbaren Anforderungen. Aussagen zur IT-Grundausstattung kann ich nicht machen, da sie vom Landesbetrieb, der auch Vergabestelle ist, vorgehalten und entwickelt wird. Ich als Wissenschaftler möchte den Entwicklungsprozess so weit wie möglich begleiten und steuern. In der Leistungsbeschreibung ist deshalb beschrieben, dass die Entwicklung weitestgehend kollaborativ verlaufen soll. Die Leistung ist in mehrere Arbeitsschritte unterteilt die immer in einem Workshop zur Abnahme der bis dahin geleisteten Entwicklungsarbeit und Verabredung zukünftiger Arbeiten enden. Die Vergabestelle versteht nicht was die Leistung und das Produkt ist. Sie befürchtet, dass es dadurch wesentlich teurer wird als ich kalkulierte. Der BdH hat die von mir veranschlagten Mittel freigegeben. Eine Ausschreibung erfolgt nicht da der Vergabestelle die Leistungsbeschreibung zu Vage ist. Möglichkeiten zur gemeinsamen Fixierung finden sich nicht. Ich ahne aber, dass ich mit dem Einkauf einer fertigen App mit Datenerfassungsgerät mehr Erfolg hätte da diese Dinge der Vergabestelle bekannt sind. Die Vergabestelle hätte wahrscheinlich auch ausgeschrieben wenn ich die Leistung und vor allem das letztlich entstehende Produkt detailliert, umfassend und abschließend beschrieben hätte. Ich als Wissenschaftler will für ein Fachverfahren die technischen Möglichkeiten zur Feldaufnahme und Auswertung. Ich kann und will also gar nicht beschreiben, welche Schnittstellen genutzt werden, wie die GUI aussieht und welche Programmiersprache genutzt wird.
Ausschreibungs- und Vertragsformen[Bearbeiten | Quelltext bearbeiten]
- Mehrstufige Ausschreibung?
- Antrag des Beschaffers
- Beratung der Vergabestelle und des Beschaffers durch IT-Profi der die "Übersetzung" von Anforderung, Vergaberecht und IT-Slang vornimmt und geeignete Techniken/Wege vorschlägt
- Wie kann agile Software-Entwicklung auf Basis eines EvB IT Vertragsmodells unterstützt werden / dazu passen.
- Rahmenvertrag mit Abruf von Stunden-Kontingenten (ist nur eine Voraussetzung / Rahmenbedingung, definiert aber noch nicht agiles Vorgehen)
Offene Fragen - Weiteres Vorgehen[Bearbeiten | Quelltext bearbeiten]
... das könnte Teil unserer Arbeit sein oder werden?
- Erstellung und Veröffentlichung einer Beraterliste
- Erarbeitung der Gliederung für einen Leitfaden zur Vergabe öffentlicher Aufträge für agile Entwicklung und OpenSource-Software
- Entwicklung von Schulungsmodulen für Vergabestellen
Open Source Governance[Bearbeiten | Quelltext bearbeiten]
- Kann eine Funktion in eine Open Source Software "gekauft" werden.
- Wer entscheidet, wie sich das Open Source Projekt weiter entwickelt?
- Was ist die "Community"?
- ...
Kontakt mit OSBA und FSFE[Bearbeiten | Quelltext bearbeiten]
- Beschäftigung mit Agiler Softwareentwicklung?
- gibt es Vertragsbeispiele für Agiles Vorgehen?