Planung Treffen III/2012 11.04.12 MUC

Thema nächstes mal: Michi: Lucene

Telco: Recap und Diskussion

• Froh: „Wenn Du viel bewirken willst: 1. Sei da 2. Schreib Protokoll“ :)
• Teamfoto? Gibt dem abstrakten „Workshop“ Ding ein menschliches Gesicht.
• Zusammenfassungen: Meinungen am besten immer mit Namen, das ist wertvolle Metainformation. („Joe findet XText cool. Michi auch.“)
• Kosten: Transparent machen. Was machen wir nach dem aktuellen FreeRide bei Sencor?
  • Michi: Evtl können wir weiter bei Senacor eingeladen sein – Wir könnten das frühere „Chief Developer Abendessen“ augmentieren / ersetzen?
  • Flo kann wahrscheinlich kostenlose Räumlichkeiten in München anbieten - im neuen IT:Agenten Büro
  • Vielleicht rennen wir auch in vielen Firmen offene Türen ein – und das „Wachstumsproblem“ könnte sich damit auch recht elegant erledigen
    • Aber zu bedenken: Kann man genauso offen über Projekte sprechen, wenn Beteiligte dabei sind?
  • Froh, Joe, Flo, (wer noch?) finden „Rumziehen“ gut. „Softwarearchitekten auf der Walz?“
• Michi: Xing Gruppe?
  • Froh: Simon könnte das moderieren.
  • Michi: Evtl. „Qualität vor Quantität“ gefährdet?
  • Joe: Vllt. Gruppe mittels der wir Zugehörigkeit demonstrieren können, mit Link auf das Wiki? Invitation only?
  • Einstimmig (Froh, Michi, Joe, Martin, Flo): TODO für Simon: Invitation-Only Gruppe anlegen, kurze Beschreibung mit großem Link auf unsere Seite anlegen, uns alle einladen.
• Diskussionen auf Slashdot / Stackoverflow als Themengenerator und um unterschiedliche Sichtweisen zu erschließen?
• Tagcloud ist erledigt, Flo birst vor Stolz

Aufgaben für's nächste mal

• Simon: Xing-Gruppe anlegen, siehe oben
• Froh: „Scott Ambler: The Object Primer - Agile Model Driven Development with UML2“ mitbringen
• Michi: Video link „The Website is down“ in der Inbox (Wiki) eintragen
• Froh: Flo's Mitschrieb Deines ARC42-Vortrages reviewen & ergänzen & die ganze Seite ins Wiki übertragen

Recap letztes mal

• Planspiel, als gemeinsame Diskussion. Joe findet, Froh hat's gut gemacht.
• Joe: Trennen: „Was ist es“ / „Wie funktioniert es (Details)“ / „Wie fühlt sich's an“

Joe: „Bright club“ videos gucken lohnt sich. (10-min stand up comedy zu akademischen Themen)

ARC42(Froh)

• http://www.arc42.de/
• Funktioniert gut im Wiki (Froh nimmt Confluence und lässt von dem direkt ne PDF generieren. Funktioniert gut.) (Anmerkung: Normalerweise generieren wir KEINE PDFs, die Stakeholder haben Zugriff auf das Wiki. –Froh)
• Kontextabgrenzung ist wichtig: „Wir machen NICHT: Billing“
• Superwertvoll: Entwurfsentscheidungen. Bei Froh auch eine einzelne Wiki-Seite.
• Kann Soll Vision, Trends, Business-Entscheidungen etc enthalten
  • Wichtiger Punkt: Hi-Fi Prototypen um Dinge ans Management zu verkaufen (Flo: „Hubschrauberflieger wollen iPhone Apps sehen“)
• Mann kann auch Dinge erst mal offen lassen, und ausfüllen, wenn sich das klärt.
• Stakeholder dokumentieren! ↔ SGS Workshop (Stakeholder, Goals, Scope) (http://www.volere.co.uk)
  • Stakeholder map: The intended product < The affected business area < The rest of the enterprise < The world outside
• Sponsor: Klar machen, auf wessen Mist das Projekt gewachsen ist.
• Meta / Frage von Martin: Wie kriegt man aus Confluence so ein schönes PDF Dokument – speziell mit so guten Nummerierungen – heraus?
• ARC42 Templates gibts auch für „Wenn Ihr nicht vermeiden könnt, UML Tools zu nutzen“:
  • Froh Buchempfehlung: Scott Ambler: The Object Primer - Agie Model Driven Development - UML und Agile Entwicklung: Wie setze ich UML richtig ein? Nicht so genau nehmen, Tools: Whiteboard + Photoapparat
  • Froh ist über dessen gute UML Dokumentation drauf gekommen

• Pause Meta-Diskussion: Interface Generatoren
  • Joe: SWIG - Standard Wrapper Interface Generator: Generiert Interfaces von C/C++ Software für alle möglichen Sprachen
  • Python: CTypes ist „P/Invoke für Python“ (P/Invoke macht in C# native calls)
    • Martin: „Performant! Aber in Python durch C Structs zu iterieren ist auch nicht optimal. Funktioniert aber gut.“
  • Video „The Website is down“
  • Shodan Computer Search Engine

• Exkurs: Protkolldesign / NAT und anderes gefiltertes Internet und Real-Time Daten. RTP / RTCP / RTSP / SDP. Realtime via Internet / das „Internet of Things“ ist nicht in einem guten Zustand. Das Session_Description_Protocol als Negativbeispiel / Antipattern. TR-069|TR-069]] ist wesentlich weniger schlecht? Martin: „Gewinnt keine Schönheitspreise, aber funktioniert.“

… und weiter:

• ARC42 fragt viele Dinge ab, die man früher oder später wissen will, aber evtl. selber vergisst rechtzeitig in Erfahrung zu bringen (Bsp: „Legal Constraints“, gibt es zu erfüllende Standards?)
• Das Dokument muss leben – Inaktuelle Dokumentation ist schlimmer als zu wenig detaillierte. Deswegen lieber kürzer, dafür aktueller! (Anmerkung: Wichtig: Nicht mehr aktuelle Sachen löschen! –Froh)
• Requirements: Klare Ansagen statt schwammiger Formulierungen: „Level A“, „Level B“, „not supported“ platforms / devices / browsers etc pp
• „Requirements missing“ quasi als To-Do Liste, wenn fehlende Req's schon bekannt.
• Randbedingungen („System Scope and Context“
• „Ein bissel“ hat ARC42 auch eine zeitliche Reihenfolge bzw. funktionale Abhängigkeit – Typischerweise wird man bei der Arbeit mit dem Template die „vordere Hälfte“ vor der „hinteren Hälfte“ ausfüllen, und das Dokument iterativ füllen.
• Es geht darum, „gemeinsames Verständnis“ herzustellen – d.h. das Dokument klärt, was Begriffe bedeuten. Das heißt insbesondere, dass jeder im Team das Dokument verstehen können muss!
  • Je komplexer die Konzepte, desto weniger kann man präsentieren
  • „5 +/- 2 Regel“ (Arbeitsgedächtnis der Menschen) (Früher hieß das mal 7 +/- 2, aber das ist .OLD)
• Nichtfunktionale Requirements sind nicht leicht zu dokumentieren: Vage Ideen wie „es läuft 24/7“ sind in den Teamgehirnen verankert, aber schriftlich nicht immer leicht festzuhalten. Problem: Requirements müssen hart sein, sollten von extern kommen.