Overblog
Folge diesem Blog Administration + Create my blog

IREB RE@Agile Primer: Termine 2019 bei Software Quality Lab

Der IREB RE@Agile Primer ist ein Standard, der die agile Welt mit dem Requirements Engineering versöhnt. In einem zweitägigen Kurs lernen Sie, wie Sie das Beste des Requirements Engineering mit den Stärken der Agilität vereinen. In diesem Kurs werden Sie auf die Zertifizierungsprüfung vorbereitet und vertiefen die Methodenkenntnis durch eine Fallstudie. 2019 findet dieser Kurs beim Software Quality Lab zu neun verschiedenen Terminen mit mir als Trainerin statt und kann zusätzlich auch gerne inhouse gebucht werden.

Hier geht es zum Programm.

 

Kommentare anzeigen

Rechtschreibung heute

Eine aktuelle Studie zur Rechtschreibung bestätigt, dass die systematische Fibel-Methode, nach der ich noch das Schreiben gelernt habe, am besten funktioniert. Das wundert mich nicht. Mich hat nur immer erstaunt, dass man so lange geglaubt hat, es schade nichts, wenn man Schüler erst die Worte falsch schreiben lässt, um sie nicht zu demotivieren. Ich habe die Rechtschreibung seinerzeits gleich richtig gelernt und so wurde das zur Gewohnheit. In Fremdsprachen habe ich mir gelegentlich in einsamen Hausaufgaben oder beim häuslichen Selbstlernen das eine oder andere falsch angewöhnt, das ich mir mühsam wieder abgewöhnen musste. Darum weiß ich aus Erfahrung, wie schwer man wieder davon weg kommt, wenn man etwas mehrfach falsch gemacht hat. Darum vermeide ich auch in meinen Kursen, den Teilnehmern falsche Lösungen zu präsentieren, sei es zur Abschreckung, sei es in Multiple-Choice-Fragen. Unser Gehirn spielt uns da oft Streiche, und wir merken wir uns genau das, was wir gleich wieder vergessen sollten, und wenn man uns sagt, was wir nicht tun sollen, tun wir genau das.

Lernen erfolgt idealerweise in einem Zyklus von:

  • Erklärung
  • Vorbilder sehen
  • nachahmen versuchen
  • Feedback erhalten
  • Fehler korrigieren

Auch bei meinen eigenen Versuchen mit anderen Lernvorgängen hat sich dies bewährt. Beispielsweise problemorientiertes Lernen habe ich sehr schnell wieder verworfen. Meine Kursteilnehmer fanden das zu Recht irritierend und überfordernd. Lernende benötigen Führung.

Schade, dass man der ganzen Generation Y die Rechtschreibung verdorben hat. Und am Ende stellt man fest, dass unsere Altvorderen mit ihrem systematischen Vorgehen vom Einfachen zum Schwierigen, mit der engen Anleitung hinein ins Reich des Wissens Recht gehabt haben. Die haben sicher auch gelegentlich erfolglos etwas anderes probiert!

Gerade in Bezug auf das Requirements Engineering spielt die Rechtschreibung durchaus eine Rolle. Enthalten die Anforderungen zahlreiche Schreibfehler, sind sie zwar einem Muttersprachler meistens dank Raten noch verständlich, aber was macht ein Fremdsprachler? Er sucht das falsch geschriebene Wort vergeblich im Wörterbuch. Und Grammatikfehler machen oft den Text gar noch unverständlich.

Außerdem habe ich beobachtet, dass Menschen, die sich nicht an Rechtschreibregeln halten, ihre Texte auch ansonsten nicht sehr sorgfältig behandeln. Da fehlt oft auch inhaltlich ein roter Faden, eine sinnvolle Reihenfolge der Erzählung, Worte werden nicht sorgfältig gewählt und die Grammatik entspricht der Umgangssprache. Der Text wirkt nicht nur schlampig hingeschmotzt, sondern auch bei genauem Lesen bleibt er wirr. Darum vermute ich, dass das disziplinierte Lernen der Rechtschreibung die Grundlage darstellt für einen sorgfältigen Umgang mit Sprache insgesamt. Wenn man spontan etwas hinschreibt, was einem gerade einfällt, ist das kein in Stein gemeißeltes Endergebnis, sondern ein erster Entwurf. Es ist normal, alles Geschriebene zu korrigieren. Kritik am eigenen Text muss akzeptiert werden können und Korrekturen durchgeführt. Es gibt viele mögliche Arten, etwas schriftlich auszudrücken, aber manche sind besser als andere. Schreiben ist ein hartes Handwerk, bei dem es auf Präzision ankommt. Auch das lernt man durch die Fibel-Methode.

 

 

 

 

 

 

 

 

Kommentare anzeigen

Call for papers: REFSQ 2019 Konferenz "International Working Conference on Requirements Engineering"

Für die REFSQ-Konferenz 2019 laufen nun die Einreichungsfristen: 24.09.2018 für die Artikel-Abstracts, am 2.10. sind die Artikel fällig, Workshop proposals bis zum 15.10.2018. Ich selbst brüte auch die eine oder andere Einreichung aus.

Bei dieser Konferenz bin ich Mitglied im Programmkomitee.

 

Kommentare anzeigen

Workshop "Ethische Entscheidungen im Software Engineering" am 15.01.2019

Am 15.01.2019 findet erneut mein Workshop "Ethische Entscheidungen im Software Engineering" auf der SQD-Konferenz statt. Wir beginnen gleich morgens um 9 Uhr. Wir diskutieren dort die ethischen Entscheidungen, die während der Software-Entwicklung auftreten, in wie fern sie ethisch relevant sind und wie man ein ethisches Dilemma löst.

Nähere Informationen zum Workshop finden Sie im Programm der Konferenz, wenn Sie auf den Titel klicken.

 

Kommentare anzeigen

h-Index = 11

Neulich recherierte ich meinen h-Index. Über meinen aktuellen Wert wusste ich nicht Bescheid. Ihn von Hand zu recherchieren und zu berechnen ist mir zu aufwändig. Frage ich Google Scholar, dann habe ich nur 20 Publikationen (2013 hört die Zählung auf), die genau drei Mal zitiert wurden, und einen H-Index von 1. (Das heißt: Eine meiner Veröffentlichungen wurde einmalig zitiert. Es gibt keine zwei Artikel, die zweifach oder öfter zitiert wurden.) Das kann nicht sein. Citeseer führt mich unter mehreren E-Mail-Adressen. Mein University-of-Braunschweig-Ich kommt dort auf fünf Publikationen und einen h-Index von 2. Bei dblp sind 31 wissenschaftliche Konferenzbeiträge plus 7 elektronische Tagungsbände gelistet (statt 45, also fast richtig) und 25 Zeitschriftenartikel, aber der h-Index wird leider nicht ermittelt.

Darum schwebte ich nun lange im Ungewissen über meinen wahren Wert.

Nach meiner Zählung komme ich auf deutlich mehr als 100 Publikationen, davon 54 wissenschaftlich, peer-reviewed. Den h-Index hatte ich nicht von Hand gezählt. Dank eines besseren Algorithmus und meiner Mithilfe ist meine Publikationsliste bei ResearchGate mit 71 Artikeln ordentlich lang und sollte bei den wissenschaftlichen Publikationen vollständig sein. Sie wurden insgesamt 436 Mal zitiert. Und dort beträgt mein h-Index 11. Das heißt, elf meiner Artikel wurden mindestens elf Mal zitiert! Na, wenn das kein ordentlicher Wert bzw. Impact ist! Ich bin immer noch ein wenig hibbelig wegen dieser Erkenntnis. Das motiviert!

Andrea Herrmann

Kommentare anzeigen

Workshop "Requirements Engineering mit Fachabteilungen" am 11. März 2019

Zeit: Montag, 11. März 2019, 09:00 - 13:00 Uhr
Ort: REConf, München
https://www.hood-group.com/reconf/workshops/htws23-requirements-engineering-fuer-nicht-informatiker/

Viele Techniken und Methoden, die im Requirements Engineering genutzt werden (wie z. B. UML-Modelle), sind den Mitarbeitern/-innen in den Fachabteilungen nicht bekannt und teilweise auch nicht ohne weiteres verständlich. Im Projektgeschäft arbeiten jedoch nicht nur Informatiker/-innen unter sich. Durch die Verlagerung von Verantwortung auf die Fachabteilungen und gerade im Kontext von Agilität wird es mehr und mehr üblich, dass das Requirements Engineering durch unterschiedliche Rollen (z. B. Product Owner) durchgeführt wird. Komplexität erfordert Naht- statt Schnittstellen.
In diesem Workshop geben die vier Experten ihre Erfahrungen mit dem Thema weiter, sowie Lösungen und Methoden, die sich bewährt haben. Wo verwenden wir welche Techniken? Wie lässt sich Requirements Engineering vereinfachen und schulen?

Die Dozenten
Nikolaas Döbel: Seit 2009 freiberuflicher und branchenübergreifender Business Analyst/Requirements Engineer, davor 12 Jahre als Requirements Engineer angestellt.
Jörn Fahsel: Wissenschaftlicher Mitarbeiter seit 2013 an der FAU Erlangen, davor 13 Jahre als Prozessberater im ITK- und Sozialumfeld.
Dr. habil. Andrea Herrmann: Freiberufliche Trainerin und Beraterin für Software Engineering seit 2012 mit mehr als 20 Berufsjahren in Praxis und Forschung.
Prof. Rüdiger Weißbach: Seit 2009 Professor für Wirtschaftsinformatik am Department Wirtschaft der HAW Hamburg, vorher 22 Jahre IT-Arbeit in Anwendungsbetrieben (Elektroindustrie, Bausparkasse).

Workshop-Level: Fortgeschrittene

Anmeldung hier

Kommentare anzeigen

nächste Woche: IREB-Schulung

Nächste Woche findet vom 12. bis 14. September meine IREB Foundation Level Prüfungsvorbereitungsschulung an der Technischen Akademie Esslingen statt.

Link zur Schulung

 

Kommentare anzeigen

neue Fallstudie: Warum man Verträge lesen MUSS, bevor man sie unterschreibt.

In meinem ganz normalen geschäflichen Alltag sammle ich fleißig Fallstudien für meine Kurse. Hier meine neueste... Ich schärfe meinen Kursteilnehmern immer ein, dass sie Verträge unbedingt lesen sollen, bevor sie sie unterschreiben. Man muss nicht alles unterzeichnen, die Unterzeichnung erfolgt freiwillig. Auch Sätze wie "Alle unsere Dienstleister unterschreiben diesen Vertrag" sind kein gültiges Argument. Und dann nenne ich ein paar Beispiele von Klauseln, die in Verträgen standen, die ich dann NICHT unterschrieben habe.

Ein Highlight war mal ein Vertrag, der mir auf die nächsten zehn Jahre verbot, im Bereich Requirements Engineering noch irgendetwas ohne Zusammenarbeit mit Firma X zu machen. Ich musste laut Vertrag alle meine Tätigkeiten in diesem Bereich mit dieser Firma abstimmen und ihr gehörten auch automatisch alle Rechte an sämtlichen meinen Arbeitsergebnissen. Diesen Vertrag zu unterschreiben wäre einem wissenschaftlichen und geschäftlichen Selbstmord gleich gekommen. An dieser Stelle kommt jetzt gerne der Kommentar, dass ich dafür ja sicher gut bezahlt worden sei. Nein, eben nicht. Es war eine Zusammenarbeit "auf gleicher Augenhöhe" (haha) im wissenschaftlichen Bereich. Zu den gemeinsamen Arbeitstreffen musste natürlich immer ich anreisen, da die Zeit meiner Geschäftspartner zu wertvoll dafür war, und die Reisekosten bezahlte ich natürlich auch selbst. Einige meiner Arbeitsergebnisse werden nun in der Firma als Schulungsmaterial verwendet und es ist sogar ein Patent daraus entstanden. Bezahlt wurde mir dafür nie irgendetwas. Ich habe, obwohl ich diese Geheimhaltungsvereinbarung nie unterzeichnet habe, trotzdem nicht so recht gewagt, auf dem speziellen Gebiet unserer Zusammenarbeit noch etwas zu machen oder meine eigenen Arbeitsergebnisse weiterzuverwenden, weil ich sonst vermutlich patentrechtliche Schwierigkeiten bekommen hätte. Die Firma ist dafür bekannt, in solchen Fällen ganz schnell zu klagen. Aber immerhin darf ich noch im Requirements Engineering arbeiten, ohne von X verklagt zu werden. Wie schön!

Andere meiner Beispiele sind weniger dramatisch, aber der neuste Aufreger ist mal wieder ein Meisterwerk. Ich hatte eine 40-stündige Schulung maßgeschneidert nach Vorgaben entwickelt, hochwertig, mit Musterlösungen und allem Drum und Dran. Laut meiner Faustformel, dass eine Stunde Kurs fünf Stunden Vorbereitung verursacht, und laut meinen Aufschrieben waren das 200 Stunden Arbeit. Man hatte mir in Aussicht gestellt, dass das eine längerfristige Zusammenarbeit würde und ich den Kurs mehrmals pro Jahr halten könne. Inzwischen haben sie beschlossen, den Kurs doch nicht mehr durch eine externe Dozentin halten zu lassen, sondern durch einen ihrer Angestellten. Um mich zu trösten (oder von einer Klage abzuhalten, die Kunden machen das immer so, wenn sie mir Unrecht tun) stellte man mir in Aussicht, dass ich dafür einen anderen 40-Stunden-Kurs neu entwickeln dürfe (was ich wegen Vollauslastung ablehnte) und dass sie gelegentlich ja feste Stellen ausschreiben und ich mich darauf bewerben dürfe. Natürlich ohne Garantie, eingestellt zu werden. Bevor nun der Kontakt ganz abbricht, sendet man mir noch einen neuen Rahmenvertrag, der eine Klausel enthält, dass die Nutzungsrechte an meinen Kursunterlagen an den Kunden übergehen. Ich habe sofort die vorige Version aufgeschlagen, um zu sehen, ob ich beim Unterschreiben etwas übersehen hatte, aber dort stand dieser Satz noch nicht drin. Es wäre mir neu, dass ich solche Klauseln unterschreibe. Einerseits ist es ja rechtlich korrekt, dass sie den Diebstahl meiner Unterlagen rechtlich absichern. Andere tun das nicht und riskieren, dass ich irgendwann durch einen bösen Zufall dahinter komme, dass sie meine Kursunterlagen weiterverwenden. (Solche bösen Zufälle gibt es. Sie wissen schon, das berüchtige Gespräch in einer Hotelbar... So habe ich von dem Patent erfahren.) Aber ich werde diesen Vertrag nicht unterschreiben. Ich wüsste nicht, was mich dazu motivieren sollte. Ich wurde bezahlt für 80 Kursstunden, und die habe ich auch gehalten. Ich schenke denen nicht noch 200 Stunden Kursvorbereitung dazu, auch wenn ich vermutlich diesen Kurs sonst nirgends mehr halten kann.

Puh, also mit Leuten, die solche Verträge erstellen, sollte man gar nicht zusammenarbeiten... Und dann wollte mir neulich noch jemand einreden, ich trage kein finanzielles Risiko, weil ich für jede Kursstunde bezahlt werde. Tja, schon, aber der Großteil der Arbeit ist ja die Vorbereitung! Und dafür bezahlt mich keiner. Es ist nicht so, dass ich mich weigern würde, Lizenzgebühren für meine Kursunterlagen zu akzeptieren. Nur ist momentan das Urheberrecht in Deutschland noch genauso unbekannt und irrelevant wie die Datenschutzgesetze vor diesem Mai.

Also echt, Sachen gibt's... Papier ist geduldig, da kann man die unmoralischsten Klauseln drauf drucken...

 

Kommentare anzeigen