Goulasz

Meine Frau wollte nach der Schule eine Ausbildung zur KfZ-Mechatronikerin machen. Hat nichts gefunden, weil es keine Betriebe gab, die sanitäre Anlagen und separate Umkleiden für Frauen bereitstellen konnten. Vorgabe vom Gesetzgeber. Das wäre einer der ersten Punkte zur Grundlagenschaffung, die es Firmen möglich machen würde, überhaupt die Vorteile der Diversität zu nutzen, wo sie gebraucht werden und den Nachteilen einer heterogeneren Gruppe überwiegen.
Macht euch mal einfach frei von "Bei Männern/Frauen ist das so". Der Großteil ergeht aus gesellschaftlich etablierten Normen und Handlungsmustern hervor und hat mit einer sich aus dem Geschlecht ergebenden Veranlagung nicht viel zu tun.
Rein hormonell ist es in der Tat so, dass Frauen mangels der produzierten Menge an Testosteron niemals die gleiche Menge Muskeln aufbauen können, die ein Mann bei vergleichbarem Aufwand aufbaut. 
Die Berufe oder Felder, in denen diese physiologischen Unterschiede wirklich permanent in der Praxis benötigt werden, sind aber zumindest nach meinem Bauchgefühl wirklich überschaubar.
Gruß, Goulasz  
 

Beispiel: Wir führen grade im Unternehmen die ISO 27001 ein(Bei- und Mitleidsbekundungen gerne per PN). Hier werden zig kleine Projekte durchgeführt, die dem Ziel einer Zertifizierung dienen. Du kannst dir nicht im Entferntesten vorstellen, wie viel hier grade dafür dokumentiert und klassifiziert wird.

Und jetzt kommt der Knaller: Wenn die GL nen Report darüber will, was meinst du, wer den Stand präsentiert? Natürlich mieten wir uns dafür nen Externen Dozenten oder Fachanwalt für IT-Recht. Verdammt nein, das machen die Admins selbst. Und das sind FiSis. Also pack deinen Trollkoffer und geh oder öffne deine Augen und Blick der Realität in selbige.
 
Gruß, Goulasz

Weder glaube ich an die Existenz eines oder mehrerer Götter, noch kann ich sie widerlegen. Der reinen Begrifflichkeit nach bin ich also "agnostischer Atheist".
Ich habe aber kein Problem damit, wenn Menschen glauben und ihren Glauben offen praktizieren, solange sie mich nicht missionieren wollen oder damit in meiner persönlichen Freiheit einschränken.
Ich würde mich auch nicht als "spirituell" bezeichnen, verspüre aber bei Spaziergängen im Wald etwas außerhalb der bebauten Zivilisation eine besondere Ruhe, die durchaus besonders ist.
 

Hallo @Michl92!
 
Ein Proof of Concept als Projekt ist völlig in Ordnung. Mein Projekt ging auch nicht unmittelbar in Produktion. Ich habe eine nicht-monetäre Bewertungsmöglichkeit(konkret: Nutzwertanalyse) zur Rechtfertigung des Entwicklungsaufwandes benutzt. 
Ist in deinem Antrag zu erkennen, dass es sich um so einen "Proof" handelt oder hast du dort von einem für einen internen oder externen Kunden zu entwickelnden Produkt gesprochen? An sich ist die Dokumentation in allen Phasen das Mittel der Wahl, um diesen Sachverhalt darzustellen. Auch ein gescheitertes Projekt kann eine sehr gute Note ergeben, wenn klar ist, warum das Projekt nicht erfolgreich durchgeführt werden konnte und dies gut dokumentiert ist. Im Übrigen scheitern auch im "echten Leben" sehr, sehr viele Projekte. (Meist aufgrund schlechter Abstimmung der tatsächlichen Anforderungen)
Eine Betrachtung der Wirtschaftlichkeit innerhalb der Doku ist eigentlich immer notwendig. "In echt" lässt dich auch niemand aus Jux und Dallerei irgendetwas entwickeln, wenn er sich davon nichts erhofft. Bei deiner zuständigen IHK sollte es dort Infomaterial geben. Hier ist der Link zu meiner Kammer: Berufsinformation und Dokumente Fachinformatiker IHK Kassel/Marburg
Gruß, Goulasz  

Hallo @Crash2001!
Für mich klingt das abwertend. Aber sei's drum, ich will mal nicht so sein.   
UX heißt hier übrigens "User Experience". "User Experience Lieferungen" sind hier also die Ergebnisse der einzelnen Teilprozesse.
Als Usability Engineer bin ich Schnittstelle zwischen den Projektverantwortlichen auf Kunden- bzw. Anwenderseite und den Umsetzenden auf der Auftragnehmerseite. Zum einen unterstütze ich alle anderen Rollen bei ihrer Arbeit, zum anderen sehe ich als Verantwortlicher zu, dass alle Rollen die Mittel zur Verfügung haben, die sie zur Erfüllung ihrer Tätigkeiten benötigen.
Ich organisiere also für den User Requirements Engineer Interviewpartner und schaffe Situationen, in denen er Anwender beim Lösen des  Problems, bei dem das Produkt, das entwickelt werden soll, helfen soll, beobachten kann. Ich kümmere mich um die Erstellung von Listen relevanter Zielgruppen für die Rekrutierung von Usability Testenden, rekrutiere diese ggfs. direkt oder gebe diese Informationen an eine Agentur weiter. Ich diene dem Informationsarchitekten und dem Interaktionsdesigner sowie dem User Interface Designer als ständiger Sparrings- und Reviewpartner und gleiche als Gesamtverantwortlicher zusätzlich die Ergebnisse mit den Nutzungsanforderungen ab.  So gesehen bin ich in der Rolle des "Usability Engineers" eine Art Projektmanager für den gesamten Teil eines Projekts, in dem es in Gesamtverantwortung um "Usability" geht.
Schwammig ist das nicht unbedingt. Zumindest nicht nach meiner Sicht.
Das "Hochgestochene", das du meinst, rührt daher, dass es, wenn man die formalen Inhalte der ISO kennt, eine sehr trennscharfe und spezifische Sprache mit spezifischen Begriffen gibt, damit sich die verschiedenen Usability Professionals eben nicht darüber streiten müssen, ob ein Kunde jetzt etwas "will" oder "braucht", sondern dass klar zwischen Erfordernissen und Anforderungen unterschieden wird.
Am Agile Monday Kassel habe ich dazu einen Vortrag gehalten. Die begleitenden Slides dazu findest du hier:
https://de.slideshare.net/secret/lgsDzRLiNVREp7
Eine Videoaufnahme, auf der man die Erläuterungen dazu findet, existiert leider nicht. Würde ich das alles so im Detail erläutern, müsste ich dafür aber vermutlich schon fast eine Rechnung schreiben. 
Gruß, Goulasz  

Hallo @Crash2001!
Basierend auf der ISO-9241 und diversen Fachpublikationen zur Gestaltung interaktiver Systeme ergeben sich folgende Rollen, die ein Usability Professional im Laufe des Prozesses zur Gestaltung gebrauchstauglicher Systeme einnehmen kann:
TL;DR:
Usability Engineer: Managt den UX Prozess User Requirements Engineer: Beschreibt Nutzungskontext und Nutzungsanforderungen Usability-Tester: Führt Usability-Tests aus Informationsarchitekt: Kreiert die Informationsarchtitektur und die Navigationsstruktur Interaktionsdesigner: Definiert die Interaktion zwischen Mensch und System User Interface Designer: Implementiert das Benutzererlebnis Mittelfassung:
Usability Engineer: Betreut in einer Querschnittsfunktion den menschzentrierten Gestaltungsprozess, quasi der "SCRUM Master" des Prozesses. Idealerweise hat er bereits Erfahrung in der Ausfüllung der anderen Rollen. Mindestens jedoch User Requirements Engineer und Usability Tester. User Requirements Engineer: Identifiziert und beschreibt den Nutzungskontext, leitet daraus Erfordernisse und Nutzungsanforderungen ab. Er priorisiert die Nutzungsanforderungen, damit die Erfordernisse erfüllt werden können Usability-Tester: Evaluiert die Benutzungsschnittstellen und erstellt für die verschiedenen Stadien im Gestaltungsprozess die entsprechenden UX Lieferungen, z.B. einen Usability-Testbericht, quantitative/qualitative Umfragen und Ähnliches Informationsarchitekt: Er kreiert und organisiert die Struktur für das effiziente Auffinden von Informationen im interaktiven System durch den Benutzer Interaktionsdesigner: Er konzipiert und definiert die Interaktion zwischen Mensch und interaktivem System auf Basis der Nutzungsanforderungen und der zu erledigenden Aufgaben. Die für die Erstellung der Interaktion genutzten Szenarien werden gemessen an der Effektivität, Effizienz und dem Grad der Zufriedenstellung im Verlauf der User Experience User Interface Designer: Er implementiert letztendlich das konkrete Benutzererlebnis anhand von Gestaltungsregeln, Styleguides und den Ergebnissen des Informationsarchitekten, des Interaktionsdesigners und des User Requirements Engineers. Langfassung:
Setz dich mit der ISO auseinander und/oder besuch entsprechende Weiterbildungen zu dem Thema, bevor du hier mit Begriffen wie "heiße Luft" um dich wirfst. Nur weil es Menschen gibt, die keine Ahnung haben und Begriffe "buzzwordig" verwenden, trifft das nicht auf alle zu. 
Gruß, Goulasz  
P.S.: Zum besseren Verständnis hier der Prozess zur Gestaltung interaktiver Systeme. Wer Anleihen an William Edwards Deming erkennt, darf sie behalten:

 

Das sagt jemand, der in eine zwei Mann Bude arbeitet und nach Bewerbern sucht?
Stell dir vor, bei euch unterschreibt jemand. Ihr kauft dann vermutlich Laptop, Handy, etc. Bereitet alles vor. Und dann kündigt die Person am ersten Tag.
Da kommt sicher Freude auf... ^^

Denkt euch doch mal bitte auf die andere Seite. Stellt euch vor der AG würde so handeln. "Ich schicke dem jetzt einen Vertrag. Und wenn ein besserer Kndidat kommt, kündige ich halt einfach."

Redet einfach mit den Menschen. Wenn der Arbeitsbeginn nicht schon nächste Woche ist, wird niemand böse sein, wenn man sich Bedenkzeit einfordert.

In Vorbereitung auf die am 25.5. (kommenden Freitag) wirksam werdende DSGVO (Datenschutzgrundverordnung)  habe ich unsere Datenschutzerklärung, sowie die Bedingungen für die Registrierung angepasst. Gleichzeitig habe ich alle User ausgeloggt, so dass bei der nächsten Anmeldung den neuen Bedingungen zugestimmt werden kann. Die Zustimmung zu den Bedingungen wird im Backend vom CMS protokolliert, was im Übrigen auch eine Anforderung ist.

Der Link zu unserer Datenschutzerklärung: https://www.fachinformatiker.de/privacy
Die Datenschutzerklärung ist auf jeder Seite im Footer verlinkt.

Link zu den Registierungsbedingungen (https://www.fachinformatiker.de/terms

Dabei habe ich ebenfalls unsere Board-Regeln überarbeitet, die unser Miteinander regeln und nach denen sich jedes Mitglied von Fachinformatiker.de richten sollte https://www.fachinformatiker.de/guidelines/
 
 

Zu KeePass. Der Quellcode ist nicht versioniert in z.B. Github und wurde lange Zeit vom Entwickler "auf seinem PC" gehostet und gepflegt. Hier zum Nachlesen: https://sourceforge.net/p/keepass/discussion/329220/thread/b0bb5457/
Es ist Open Source, aber nicht Open Collaboration. Hier der Kommentar vom Entwickler dazu:
Der ist jetzt 11 Jahre alt und seitdem kam da kein Update in Hinsicht Github o.ä.
Gruß, Goulasz

Zu KeePass. Der Quellcode ist nicht versioniert in z.B. Github und wurde lange Zeit vom Entwickler "auf seinem PC" gehostet und gepflegt. Hier zum Nachlesen: https://sourceforge.net/p/keepass/discussion/329220/thread/b0bb5457/
Es ist Open Source, aber nicht Open Collaboration. Hier der Kommentar vom Entwickler dazu:
Der ist jetzt 11 Jahre alt und seitdem kam da kein Update in Hinsicht Github o.ä.
Gruß, Goulasz

Abholen mit relevanten Beispielen aus ihrem Leben und ihrem Alltag.
Auch: Pseudocode. Jede Programmiersprache hat wie eine natürliche Sprache eine Syntax. Da kannst du ihr ein "Mapping" erläutern, welcher Teil der "natürlichen" Sprache welchem Konstrukt der Programmiersprache zuzuordnen ist. 
Wenn 1 eingegeben wird, soll "Baum" zurückgegeben werden. Wenn 2 eingegeben wird, soll "Blume" zurückgegeben werden. Wenn 3 eingegeben wird, soll "Kaffee" zurückgegeben werden. Wenn Zahlen größer als 3 eingegeben werden, soll "" zurückgegeben werden. "So, Mama. Und jetzt kannst du ja überlegen, du siehst schon, die Sätze, sehen für alle 3 ersten Eingaben gleich aus. Damit man nicht für jeden weiteren Fall ein neues Stückchen Code schreiben muss, denn Programmierer sind ja grundsätzlich faul (kennst du ja von mir), könnte man das natürlich so schreiben, dass man nur einmal die Eingabe prüft und dann guckt, ob es dafür ein passendes Resultat in unserer Liste gibt. Da würde man dann statt einer direkten Überprüfung auf eine feste, bestimmte Eingabe erstmal alle Eingaben entgegennehmen und dann prüfen. Aber für den Anfang zum Verständnis kannst du auch erstmal jede Option so aufschreiben, dann siehst du denke ich, was ich meine."
Sowas in der Art. Was hat deine Mutter beruflich für eine Historie? Gerne auch per PN, wenn das zu privat ist.
Gruß, Goulasz  

Hallo @Goulasz
 
dein beschriebener Ablauf ist korrekt. Was ich suche geht aber über eine einfache Geokodierung hinaus. Ich suche tatsächlich einen Dienst der eine Adresse standardisiert (also jegliche Schreibweise in eine einheitliche Form bringt) und prüft ob es diese Adresse auch gibt (z.B ob es die Hausnummer in der Straße überhaupt gibt).
Solche Dienste gibt es. Sie werden von jedem Online-Shopping Unternehmen und Postdienstleister verwendet um die Zustellung von Paketen sicherzustellen. In der USA werden solche Dienste extra zertifiziert. (https://en.wikipedia.org/wiki/Coding_Accuracy_Support_System)
Also kein Dienst der eine Adresse einfach in GPS - Daten umwandelt sondern wirklich in eine länderspezifische standardisierte Form bringt und auf existenz überprüft (Geodaten lieferen diese Dienste meistens als Beifang mit dazu).
Als Beispiel kannst du dir das mal anschauen: https://smartystreets.com/ => Darauf verlassen sich DHL und Amazon

Abholen mit relevanten Beispielen aus ihrem Leben und ihrem Alltag.
Auch: Pseudocode. Jede Programmiersprache hat wie eine natürliche Sprache eine Syntax. Da kannst du ihr ein "Mapping" erläutern, welcher Teil der "natürlichen" Sprache welchem Konstrukt der Programmiersprache zuzuordnen ist. 
Wenn 1 eingegeben wird, soll "Baum" zurückgegeben werden. Wenn 2 eingegeben wird, soll "Blume" zurückgegeben werden. Wenn 3 eingegeben wird, soll "Kaffee" zurückgegeben werden. Wenn Zahlen größer als 3 eingegeben werden, soll "" zurückgegeben werden. "So, Mama. Und jetzt kannst du ja überlegen, du siehst schon, die Sätze, sehen für alle 3 ersten Eingaben gleich aus. Damit man nicht für jeden weiteren Fall ein neues Stückchen Code schreiben muss, denn Programmierer sind ja grundsätzlich faul (kennst du ja von mir), könnte man das natürlich so schreiben, dass man nur einmal die Eingabe prüft und dann guckt, ob es dafür ein passendes Resultat in unserer Liste gibt. Da würde man dann statt einer direkten Überprüfung auf eine feste, bestimmte Eingabe erstmal alle Eingaben entgegennehmen und dann prüfen. Aber für den Anfang zum Verständnis kannst du auch erstmal jede Option so aufschreiben, dann siehst du denke ich, was ich meine."
Sowas in der Art. Was hat deine Mutter beruflich für eine Historie? Gerne auch per PN, wenn das zu privat ist.
Gruß, Goulasz  

Markus Söder gefällt das. 
SCNR

Ah, ok. Unter den Bedingungen würde ich sagen:
 
Ich denke da aufgrund meiner persönlichen Erfahrung an den Atlassian Stack + x 
Backlog/Issue Tracking: JIRA (mit Custom Workflows zur Abbildung der Schritte im SCRUM-Prozess) Wenn du da kein Admin bist oder auf dem Flurfunk einen erreichen kannst, können Workflow-Anpassungen langwierig sein. Und wenn du ein Template zerschießt, hat das mitunter auch hässliche Auswirkungen auf andere Projekte, die den nutzen. Repository: Bitbucket Review: Bitbucket + Crucible/Fisheye Buildserver: Teamcity  Der Homeoffice-Punkt zieht natürlich. Da schlägt ein digitales Tool ein "nur im Büro" verfügbares um Längen. Ich wollte ja immer ein Smartboard, das die JIRA-Boardansicht zeigt. Idealerweise mit Touch-Oberfläche für "Stories verschieben".  
Gruß, Goulasz  

Moin @Ulfmann!
Sitzt das Team in einem Raum?
Falls ja: Stellt ein Whiteboard in den Raum, es hat einen anderen psychologischen Wert, Tickets nach "Done" zu ziehen, seinen Avatar auf ein Ticket zu pinnen, eine Story vom Backlog auf der Rückseite in "Doing" zu ziehen und (mit das Wichtigste), das Board immer im Raum stehen zu haben.
Falls nein: Setzt das Team in einen Raum.  
Ich zitiere mal:
"Individuen und Interaktionen mehr als Prozesse und Werkzeuge"
Einer der Haupt-Benefit von echtem SCRUM (also 1 Projekt pro Team) ist Fokus und das schnelle Ausliefern von Wert generierenden Paketen. 
Bevor ihr euch mehr mit der Verwaltung als mit der tatsächlichen Arbeit beschäftigt, startet mit einem physischen Board. Bevor ihr einen JIRA-Workflow anpassen müsst, nehmt ein physisches Board und wischt im Zweifel einfach die alten Linien weg. Bevor ihr FAQs wälzt, wie man Items aus einem Workflow entfernt und in eine andere Lane/Spalte hängt oder externe Impediments visualisiert, nehmt ein physisches Board. Die Liste ließe sich noch etwas fortführen, aber ich denke, du ahnst, worum es mir geht. ? Wenn ihr als Team warm mit dem ganzen Arbeiten seid, könnt ihr überlegen, ob ihr euch den Benefit des Toolings gönnt. Ich rate euch aber aus eigener Erfahrung in dem Fall dringend zu einem anfassbaren Board, am besten zentral im Raum als Anker und Sammelpunkt für das Daily Scrum und Co. Und ich nutze sonst für wirklich JEDEN SCHEIß ein digitales Tool.
Gruß, Goulasz  
P.S.: Wir haben beim Start die Daten für die Metriken zur Auswertung auf die Karten geschrieben. Start-Datum, End-Datum.  Für die Velocity, damit man irgendwann mal nen "Burnup" Chart für die Releaseplanung erstellen kann (natürlich inkl. Drift), weil es ja leider immer wieder Kunden gibt, die auch bei SCRUM fragen, "wann das fertig ist".

Ah, ok. Unter den Bedingungen würde ich sagen:
 
Ich denke da aufgrund meiner persönlichen Erfahrung an den Atlassian Stack + x 
Backlog/Issue Tracking: JIRA (mit Custom Workflows zur Abbildung der Schritte im SCRUM-Prozess) Wenn du da kein Admin bist oder auf dem Flurfunk einen erreichen kannst, können Workflow-Anpassungen langwierig sein. Und wenn du ein Template zerschießt, hat das mitunter auch hässliche Auswirkungen auf andere Projekte, die den nutzen. Repository: Bitbucket Review: Bitbucket + Crucible/Fisheye Buildserver: Teamcity  Der Homeoffice-Punkt zieht natürlich. Da schlägt ein digitales Tool ein "nur im Büro" verfügbares um Längen. Ich wollte ja immer ein Smartboard, das die JIRA-Boardansicht zeigt. Idealerweise mit Touch-Oberfläche für "Stories verschieben".  
Gruß, Goulasz  

Hi @Goulasz
Danke dir für deine kleine Ausführung. Die Development Organisation hier ist schon ein klein wenig komplexer: Wir haben insgesamt 3 Teams von unterschiedlicher Größe, mit anderen Kernkompetenzen und jedes Team darf autonom entscheiden, wie sie arbeiten wollen. Ich hab ja eingangs betont, dass ich ein physisches Board am allerbesten finde (eben aus den von dir genannten Punkten), nur leider sind da die Geschmäcker verschieden. Meins ist das einzige Team, das mit Whiteboard + Trello arbeitet, der Rest ausschließlich digital (zu viel Papiergebammsel, man muss immer hinlaufen, dann gehen Task-Zettel verloren, das Burndown wird vergessen zu malen usw). Ein Manko, das ich leider auch eingestehen muss ist die Zentralisierung. Wer Home Office macht, muss zusehen, wie er an Infos kommt und man muss aufpassen, dass nicht ausgerechnet 2 Leute am gleichen Task arbeiten. Daher, und weil wir in regelmäßigen Backlog Sessions ja auch in einem Meetingraum verschwinden um über anstehende Stories zu sprechen, brauchen wir einfach eine digitale Version. Der Benefit des digitalen Toolings ist also längst da und inzwischen fast unerlässlich. Ich würde sogar soweit gehen, dass mein Team das physische Board auch wieder abschafft, sobald ein gutes Tool da ist. Zum einen müssen wir die 2 Übersichten immer in sync halten und zum Anderen bin ich echt der Einzige im Büro, der die Arbeit mit Zetteln, Magneten und Whiteboard cool findet.
Tl;DR: Ich teile deine Hinweise in vollem Umfang, aber das ist ziemlich sicher kein realistischer Weg. Deshalb fragte ich ja nach gutes Tools  

Moin @Ulfmann!
Sitzt das Team in einem Raum?
Falls ja: Stellt ein Whiteboard in den Raum, es hat einen anderen psychologischen Wert, Tickets nach "Done" zu ziehen, seinen Avatar auf ein Ticket zu pinnen, eine Story vom Backlog auf der Rückseite in "Doing" zu ziehen und (mit das Wichtigste), das Board immer im Raum stehen zu haben.
Falls nein: Setzt das Team in einen Raum.  
Ich zitiere mal:
"Individuen und Interaktionen mehr als Prozesse und Werkzeuge"
Einer der Haupt-Benefit von echtem SCRUM (also 1 Projekt pro Team) ist Fokus und das schnelle Ausliefern von Wert generierenden Paketen. 
Bevor ihr euch mehr mit der Verwaltung als mit der tatsächlichen Arbeit beschäftigt, startet mit einem physischen Board. Bevor ihr einen JIRA-Workflow anpassen müsst, nehmt ein physisches Board und wischt im Zweifel einfach die alten Linien weg. Bevor ihr FAQs wälzt, wie man Items aus einem Workflow entfernt und in eine andere Lane/Spalte hängt oder externe Impediments visualisiert, nehmt ein physisches Board. Die Liste ließe sich noch etwas fortführen, aber ich denke, du ahnst, worum es mir geht. ? Wenn ihr als Team warm mit dem ganzen Arbeiten seid, könnt ihr überlegen, ob ihr euch den Benefit des Toolings gönnt. Ich rate euch aber aus eigener Erfahrung in dem Fall dringend zu einem anfassbaren Board, am besten zentral im Raum als Anker und Sammelpunkt für das Daily Scrum und Co. Und ich nutze sonst für wirklich JEDEN SCHEIß ein digitales Tool.
Gruß, Goulasz  
P.S.: Wir haben beim Start die Daten für die Metriken zur Auswertung auf die Karten geschrieben. Start-Datum, End-Datum.  Für die Velocity, damit man irgendwann mal nen "Burnup" Chart für die Releaseplanung erstellen kann (natürlich inkl. Drift), weil es ja leider immer wieder Kunden gibt, die auch bei SCRUM fragen, "wann das fertig ist".

Moin @Ulfmann!
Sitzt das Team in einem Raum?
Falls ja: Stellt ein Whiteboard in den Raum, es hat einen anderen psychologischen Wert, Tickets nach "Done" zu ziehen, seinen Avatar auf ein Ticket zu pinnen, eine Story vom Backlog auf der Rückseite in "Doing" zu ziehen und (mit das Wichtigste), das Board immer im Raum stehen zu haben.
Falls nein: Setzt das Team in einen Raum.  
Ich zitiere mal:
"Individuen und Interaktionen mehr als Prozesse und Werkzeuge"
Einer der Haupt-Benefit von echtem SCRUM (also 1 Projekt pro Team) ist Fokus und das schnelle Ausliefern von Wert generierenden Paketen. 
Bevor ihr euch mehr mit der Verwaltung als mit der tatsächlichen Arbeit beschäftigt, startet mit einem physischen Board. Bevor ihr einen JIRA-Workflow anpassen müsst, nehmt ein physisches Board und wischt im Zweifel einfach die alten Linien weg. Bevor ihr FAQs wälzt, wie man Items aus einem Workflow entfernt und in eine andere Lane/Spalte hängt oder externe Impediments visualisiert, nehmt ein physisches Board. Die Liste ließe sich noch etwas fortführen, aber ich denke, du ahnst, worum es mir geht. ? Wenn ihr als Team warm mit dem ganzen Arbeiten seid, könnt ihr überlegen, ob ihr euch den Benefit des Toolings gönnt. Ich rate euch aber aus eigener Erfahrung in dem Fall dringend zu einem anfassbaren Board, am besten zentral im Raum als Anker und Sammelpunkt für das Daily Scrum und Co. Und ich nutze sonst für wirklich JEDEN SCHEIß ein digitales Tool.
Gruß, Goulasz  
P.S.: Wir haben beim Start die Daten für die Metriken zur Auswertung auf die Karten geschrieben. Start-Datum, End-Datum.  Für die Velocity, damit man irgendwann mal nen "Burnup" Chart für die Releaseplanung erstellen kann (natürlich inkl. Drift), weil es ja leider immer wieder Kunden gibt, die auch bei SCRUM fragen, "wann das fertig ist".

Ich würde mich im Zweifel immer für das weiter verbreitete/etablierte entscheiden. Und das ist und bleibt - zumindest vorerst - der Bachelor. Das kennt jeder, damit kann jeder etwas anfangen und fast alle Unternehmen sind auf den Unterschied Gelernt/Studiert eingestellt.
Der OP mag inhaltlich eine dolle Sache sein, das möchte ich nicht in Abrede stellen, aber er ist ein Nischenprodukt. Wenn es also vorrangig um den Wisch geht, damit Du Dich für höhere Positionen qualifizieren kannst, wüsste ich, zu welcher Option ich greifen würde.

Da schon alles gesagt wurde, würde ich hier anderweitig kurz nachhaken. 
Da es thematisch passt, aber keinen eigenen Thread rechtfertigt: Ist ein Zwischenzeugnis überhaupt relevant bei einer Bewerbung aus einer festen Position heraus? Wird es nicht eher negativ, denn positiv ausgelegt? Stichwort: Soll der MA vielleicht weggelobt werden?
Bei allen Gesprächen, die ich aus einer aktuellen Position hatte, wurde ein fehlendes Zwischenzeugnis nie angesprochen. Allen war bewusst, dass es keins geben kann. Und wenn sich bei mir jemand bewirbt, dann wird auch nicht nach einem Zwischenzeugnis gefragt. Klar, wenn man 20 Jahre irgendwo beschäftigt ist, hilft das Arbeitszeugnis des vorherigen AGs von 1980 sicher nicht weiter. Aber in 20 Jahren hat man doch die ein oder andere Aufgabenveränderung mitgemacht und sich sicher eins ausstellen lassen, ohne groß aufzufallen.
Wenn man ansonsten proaktiv - ohne einen organisatorischen Grund - nach einem Zeugnis fragt, befindet man sich ab der ersten Silbe doch gedanklich bereits auf der Farewell-Liste. Die negativen Schwingungen überwiegen meiner Meinung nach deutlich den möglichen Vorteil durch ein aktuelles Zwischenzeugnis. Wie seht Ihr das?
 

Markus Söder gefällt das. 
SCNR

Da habe ich mich in der Tat missverständlich ausgedrückt, danke für den Hinweis @sylenz. 
Für den öffentlichen Dienst ist es in der Tat so, dass der OP (obwohl auf der gleichen Stufe wie ein Bachelor) aufgrund der Tatsache, dass es ein IHK- und kein akademischer Abschluss ist, nicht für den gehobenen Dienst berechtigt.
Ich bezog mich mit meiner Aussage auf Erfahrungswerte, die ich selbst gesammelt habe, durch Kollegen bei meinem ehemaligen Arbeitgeber, die den OP abgeschlossen haben, erfahren haben, und bei Networking-Veranstaltungen von Personalern und Techies im Gespräch sammelte.
Also Kulanz in einer "Filterblase" von Arbeitgebern, denen es eher auf Inhalte und Praxiserfahrung ankommt als auf Titel.
Von daher muss die Aussage korrigieren in:
Gruß und sorry für die Verwirrung, Goulasz  

Mahlzeit @Envoy!
Backups einrichten Datenschutzerklärung aktualisieren Cookie-Auslieferung und Hinweis anpassen  Social Media Buttons anpassen Plugins auf Vulnerabilities prüfen Gibt schon ein paar Aufgaben, die über "Design" hinausgehen.   *hust* DSGVO *hust*
Klingt aber allgemein nicht danach, als würden die außer dem 1st Level Support und Praktikantenaufgaben relevante Themen vermittelt.
Hast du eine Laborumgebung oder etwas vergleichbares?
Gruß, Goulasz