Confluence

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
18.650
Reaktionen
402
Wer hat es, wer nutzt es?

Irgendwelche Tipps? Wie klappt das bei euch? Wird es wirklich genutzt?
Nutzt ihr es z.B. für Meeting Notizen?

Wie sieht eure Hierachie aus?

Wir wollen es jetzt erstmal fürs interne Knowledge Management nutzen.
 

Shihatsu

Administrator
Mitglied seit
26.09.2001
Beiträge
39.618
Reaktionen
5.686
Gute bis mittelmässige Toolchain, grausiger Umgang der Firma mit Sicherheitsproblemen, noch schlechtere Transparenz darüber, brutaler Cloudzwang -> don't. Es gibt besseres als Jira, und in Sachen toolchain ist eh gitlab der Platzhirsch.
Von solch einem Dienst will man seine Geschäftsprozesse nicht abhängig machen.
Das ist aber nun wirklich nichts mit Mathe, ich schubs mal ins Tech, okay?
 
Mitglied seit
19.11.2003
Beiträge
1.892
Reaktionen
26
für mich als Anwender: Bis jetzt das beste Tool für Organisation von Wissen und Planung, das ich bis jetzt hatte.

Was mache ich damit
*Abstimmungen/Orga vom Projekt
*Dokumentation Meetings
*Doku Ergebnisse
*Mittlerweile Ersatz von eigenem Wiki & Onenote für Wissenssammlung / Themenspeicher

Was nicht
*"Richtige" Projektplanung
*Fileserver
*Präsentationen (wäre nice, wenn man keine ppts mehr machen müsste)


Pro
*Intuitiv
*Gute Suchfunktion
*Optisch ansprechend / einfache Strukturierung möglich
*Gute, um Informationen gemeinsam zu erarbeiten und zu teilen
*Performant (nach mehreren Monaten Optimierung)
*"echtes" Multiuser (z.b. simultan, mehrere, gleiche Zeile)

Negativ
*Hierarchischer Aufbau bei Rechtevergabe
*Nicht offline nutzbar
*Abhängigkeit von Funktionen über Drittanbieter


@Shi: ich bin mir recht sicher, dass wir das "intern" hosten. was leider die intern IT involviert.
 
Mitglied seit
21.07.2012
Beiträge
949
Reaktionen
259
Wir nutzen es als internes Technik-Wiki, so Sachen wie:
  • allgemeine Designvorgaben
  • allgemeine Spezifikationen für Hardwaredesigns
  • "wie mache ich bei Projekt xy einen Release"
  • projektspezifische Übereinkünfte mit Kunden
  • Changelogs
  • ...
Funktioniert an sich recht gut, wären die meisten Leute nicht so dokumentationsfaul könnte man das sicher noch verstärkter einsetzen.
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
18.650
Reaktionen
402
Gute bis mittelmässige Toolchain, grausiger Umgang der Firma mit Sicherheitsproblemen, noch schlechtere Transparenz darüber, brutaler Cloudzwang -> don't. Es gibt besseres als Jira, und in Sachen toolchain ist eh gitlab der Platzhirsch.
Von solch einem Dienst will man seine Geschäftsprozesse nicht abhängig machen.
Das ist aber nun wirklich nichts mit Mathe, ich schubs mal ins Tech, okay?

Hatte ich von gelesen. Wir hosten so wie ich das erkennen kann selbst. Als Bundebehörden sind Clouds sowieso immer der Teufel.

Von mir aus ins Tech. Ich fand hier hatten sonst die Fragen auch immer gut gepasst.

für mich als Anwender: Bis jetzt das beste Tool für Organisation von Wissen und Planung, das ich bis jetzt hatte.

Was mache ich damit
*Abstimmungen/Orga vom Projekt
*Dokumentation Meetings
*Doku Ergebnisse
*Mittlerweile Ersatz von eigenem Wiki & Onenote für Wissenssammlung / Themenspeicher

Dokumentation Meetings fände ich an sich auch cool. Muss ich nur noch den Rest von überzeugen.
Aktuell mache ich und "mein" Team sehr viel mit OneNote und das ist an sich auch schon recht brauchbar.
Irgendwas soll sich da ja bald ändern und es ist nicht klar, dass wir das dann noch nutzen können.

Was nicht
*"Richtige" Projektplanung
*Fileserver
*Präsentationen (wäre nice, wenn man keine ppts mehr machen müsste)

Das brauch ich glaub ich auch nicht.

Pro
*Intuitiv
*Gute Suchfunktion
*Optisch ansprechend / einfache Strukturierung möglich
*Gute, um Informationen gemeinsam zu erarbeiten und zu teilen
*Performant (nach mehreren Monaten Optimierung)
*"echtes" Multiuser (z.b. simultan, mehrere, gleiche Zeile)

Negativ
*Hierarchischer Aufbau bei Rechtevergabe
*Nicht offline nutzbar
*Abhängigkeit von Funktionen über Drittanbieter

Suchfunktion bin ich auch mal gespannt. Vor allem wenn das mit den Schlagwörtern gut funktioniert.
Perspektivisch würde ich das gerne hausweit nutzen bzw. nutzen lassen :)

Gibt es eine Möglichkeit in einem Bereich Daten aus einer anderen Umfrage als einzelnen Seiten mit vorbelegten Feldern zu importieren?
Ich hab für verschiedenen Datenquellen bestimmte Informationen auf deren Basis ich gerne Seiten anlegen würde.
 
Zuletzt bearbeitet:

Shihatsu

Administrator
Mitglied seit
26.09.2001
Beiträge
39.618
Reaktionen
5.686
Nee, hier passen keine Fragen zu Software - dafür haben wir ein explizites Forum. Ich schubs mal.
Für alle die jetzt noch onpremise nutzen: Redet mit euren Entscheidern darüber, vielleicht haben die das nicht auf dem Schirm: Das wird für kleine bis mittlere Betriebe SCHWEINE teuer. Hintergrund ist, das die Server-Lizenzen abgeschafft werden. Danach gibt es nur noch Cloud oder Datacenter - und die klingen nicht nur groß und teuer, die sind es auch.
Aus
z.B.:
Du kannst bis zu 2 Jahre Support im Voraus bezahlen. Der letzte Termin für die Erstellung eines Angebots für die maximale Laufzeit von 2 Jahren war der 15. Februar 2022 (PT). Das Laufzeitende ist der 15. Februar 2024 (PT).
und
Die Preise für z.B. jira/confluence (also das Wiki/Knowledgemanagement/Assetmanagementhybriddingen) in der Datacentervariante sind NICHT ausgezeichnet - rechnet in der kleinsten Ausbaustufe mal mit 5stellig pro Jahr. Weitere Features gehen dann sehr schnell richtig ins Geld, da kommt dann ne weitere Stelle / Jahr dazu. Jeder der das nutzt sollte sich jetzt eine Exit-Strategie überlegen und die Entscheider darauf aufmerksam machen was das heißt.
Wir nutzen Atalassian voll, sind premiumpartner und für uns ist DC sogar billiger als on premise. Die Migration war aber komplett unsexy. Aber wir haben auch 2 K-Fall Rechenzentren und vertreiben das unter anderem für die EU Instanz von Azure oder unsere eigene private Cloud. Das ist halt nicht mehr Mittelstand (obwohl wir selber halt Mittelstand sind).
 
Zuletzt bearbeitet:

parats'

Tippspielmeister 2012, Tippspielmeister 2019
Mitglied seit
21.05.2003
Beiträge
18.275
Reaktionen
863
Ort
Hamburg
Wir nutzen Confluence im wesentlichen in Verbindung mit Draw.io als Plugin. Damit erstellen wir automatisch "Landkarten" von unseren Objekten samt Beziehungen im Datawarehouse und verlinken dazu auf interne Dokumentationen. Allerdings alles nur fachlich, da wir für den technischen Teil eine eigene Entwicklung bevorzugen und Confluence dort teils integriert nutzen.

Ansonsten # an Shi zum Thema Sicherheit. Mir scheint aber, dass man aus diesem Atlassian Kosmos nur schwer rauskommt. Wir nutzen seit jeher schon Jira und so fing es halt irgendwie dann auch an.
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
18.650
Reaktionen
402
Wir nutzen Confluence im wesentlichen in Verbindung mit Draw.io als Plugin. Damit erstellen wir automatisch "Landkarten" von unseren Objekten samt Beziehungen im Datawarehouse und verlinken dazu auf interne Dokumentationen. Allerdings alles nur fachlich, da wir für den technischen Teil eine eigene Entwicklung bevorzugen und Confluence dort teils integriert nutzen.

Landkarten des Datenmodells oder der Pipeline im Warehouse?

Generell such ich eh auch noch was wie man ein Datenmodell gut für den Rest meines Teams dokumentieren könnte. Enterprice Architect hilft da nur bedingt...
 

parats'

Tippspielmeister 2012, Tippspielmeister 2019
Mitglied seit
21.05.2003
Beiträge
18.275
Reaktionen
863
Ort
Hamburg
Im Prinzip beides so ein bisschen. Am Ende will man wissen, welcher Prozess befüllt welche Objekte und welche Objekte sind davon abhängig. Diese Kaskade kann nicht so wirklich für das ganze Datenmodell auf einmal darstellen, das würde wohl den Umfang sprengen. Wir machen das je "Thema" und dann kann es sein, dass Entitäten oder ganze Kaskaden auch mal doppelt vorkommen. Solange man seine Rohdaten aber sauber hält, kann man draw.io ja immer wieder drüber laufen lassen und generiert so aktualisierte Darstellungen.
Wie gesagt - es geht nur um eine Übersicht der Abhängigkeiten. Für eine technische Dokumentation wäre das ungeeignet und auch viel zu viel manueller Aufwand.
Was ich noch gerne benutze, hier jetzt aber nicht ganz passt ist PlantUML. Damit kann man auch ziemliche nette FlowCharts erstellen die einem aber mehr Möglichkeiten zur Darstellung von Eigenschaften der Objekte geben. Gibt es als Extension für VS Code. ;)
 
Zuletzt bearbeitet:
Mitglied seit
09.02.2021
Beiträge
988
Reaktionen
678
hab beim alten ag schon jira/confluence genutzt richtung projektmanagement und fands eher meh, bei mb ists quasi auch das standard-ticketool für pull-requests und bug-enrollments - finds immer noch meh.
 
Mitglied seit
18.07.2001
Beiträge
2.144
Reaktionen
1
Ort
Nürnberg
Bin ziemlich zufrieden mit Jira/Confluence.

Wir haben (leider) noch die self hosted Variante. Im Gegensatz zur Cloud gilt wie üblich, das man alte Bugs/Version hat wenn die admins nichts anfassen was läuft.

Positiv
Funktioniert
Jira ist gut anpassbar unterstützt scrum und kanban
Confluence auch nice, drawio Integration ist praktisch. Für plantuml soll es ein Plugin geben, werde Mal danach fragen wenn wir in die Cloud gezogen sind
Man kann (afaik konfigurierbar) gleichzeitig an der selben Seite arbeiten
Wir nutzen den Kram für scrum, die Doku, Besprechungsprotokolle...

Negativ
Wenn man mehr aktive User als Lizenzen hat, kann auf einen Schlag *niemand* mehr im Wiki schreiben bis man das behoben hat.
Eigentlich finde ich markdown zum dokumentieren nice. Leider verstehen selbst in der Entwicklung viele Benutzer nicht, dass man Überschriften verwenden sollte und nicht manuelle Formatierungen.
 
Zuletzt bearbeitet:
Mitglied seit
27.06.2014
Beiträge
2.267
Reaktionen
725
Ort
Hamburg
Ich bin mittlerweile im Camp von "keep it simple".
D.h. ich bevorzuge für 95% der Dokumentation Docs + Spreadsheets, seltener Slides.
Vorteile aus meiner Sicht ist nicht, dass es bessere Features hat -- aber dass die wichtigsten Features (sharing/access rights, Kommentarfunktion, querverlinkungen etc.) von jedem in der Org beherrscht werden.

Aber es kann auch sein, dass das ein entwickelter Bias ist, weil wir es bei uns intern so handhaben.
Ich hätte vorher nicht gedacht, dass das in so großen Organisationen hinreichend ist.
(Gut, es gibt einige Sachen für die ganze Org -bspw HR-Prozesse- die eher in einer Art Help Center/Wiki sind -- aber das sind vielleicht 1%).
 

Shihatsu

Administrator
Mitglied seit
26.09.2001
Beiträge
39.618
Reaktionen
5.686
Vergleichst du gerade Äpfel mit Birnen? Confluence (bzw. die ganze Atlassian Suite) geht WEIT über Dokumentation hinaus. Also so weit das das nicht mal eine andere Liga ist - das ist ein anderes Game.
 
Mitglied seit
27.06.2014
Beiträge
2.267
Reaktionen
725
Ort
Hamburg
Zugegebenermaßen habe ich seit einigen Jahren kein Confluence mehr genutzt, und vielleicht ist was ganz anderes dazugekommen.
Ich war früher durchaus Fan von solchen Tools.

Meine wertungsfreie Beobachtung ist nur, dass bei uns eine Org mit zigtausend Leuten quasi ausschließlich die Basis-Google-Tools nutzt (also Docs, Sheets, Slides, Calendar, Mail). Dazu kommen natürlich ein CRM, ein Ticketsystem & Dashboards / Backends, aber nichts mehr von dem, was ich bei Confluence als Features in Erinnerung habe.

Und meine zweite Beobachtung wäre, dass das auch bei allen Startups, die ich etwas näher kenne, ähnlich ist.

Was sind aus deiner Sicht die Killerfeatures, die du total vermissen würdest, wenn du auf so "normale" Business Suites wie Microsoft oder Google ausweichen müsstest?
 

Shihatsu

Administrator
Mitglied seit
26.09.2001
Beiträge
39.618
Reaktionen
5.686
Datenschutz als aller erstes. Dann natürlich CI/CD und voll integriertes Assetmanagement mit Problem- und Incidentmanagement. Letzteres kann man ganz vielleicht mit Officetools abbilden, aber ich kann auch Dokumentenmanagement mit Textpad + Dateiexplorer. Completely different Kind of Beast.
Vergessen: Überhaupt die Möglichkeit die Kontrolle über die eigenen Geschäftsprozesse zu behalten, aka "NO Cloud". Cloud sind die Computer anderer Leute.
 
Mitglied seit
19.11.2003
Beiträge
1.892
Reaktionen
26
noch ein nützliches Feature: Aufgabenmanagement

Natürlich ist das Problem, dass man seine Todos jetzt in Outlook, Onenote, (insert random todo-list app) + confluence hat -> confluence muss jetzt auch für meine "persönlichen" Todos herhalten.
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
18.650
Reaktionen
402
@Xantos2
Wie läuft das denn ab ? Wie ist die Struktur? Haben die Teams eigenen Bereiche? Kommt dann eine höhere Ebene auch daran?
Stell mit das mit zigtausend Leuten und der Pflege schwer vor, selbst wenn alle motiviert sind.

In Startups und kleinen Bereichen kann ich mir auch vorstellen das sowas wie One Note ausreicht.
Einzelnen Bücher für Bereicht mit Tabs für Unternehmen und in den Unternehmen noch mal Seiten.
Mehr als drei Ebenen wird irgendwann eh unübersichtlich.

Das versuchen wir jetzt bei uns fürs Confluence. Spannende Frage ist halt wenn es aufs ganze Haus weiter geht. Und sich z.B. jemand drittes über Sachen meiner Einheit informieren möchte.

@n00dl
Nutzt du dann die Gesprächstnotizen?
An sich scheint das cool, aber verliert man da nicht auch schnell den Überblick
 
Mitglied seit
27.06.2014
Beiträge
2.267
Reaktionen
725
Ort
Hamburg
Datenschutz als aller erstes. Dann natürlich CI/CD und voll integriertes Assetmanagement mit Problem- und Incidentmanagement. Letzteres kann man ganz vielleicht mit Officetools abbilden, aber ich kann auch Dokumentenmanagement mit Textpad + Dateiexplorer. Completely different Kind of Beast.
Vergessen: Überhaupt die Möglichkeit die Kontrolle über die eigenen Geschäftsprozesse zu behalten, aka "NO Cloud". Cloud sind die Computer anderer Leute.
Danke für die Antwort!

Datenschutz und No Cloud sind natürlich gute Argumente. Aber keine nutzerseitigen Features in dem Sinne.

Assetmanagement kann ich mir je nach Tätigkeitsschwerpunkt und Art der Assets als gutes Argument vorstellen.

@Xantos2
Wie läuft das denn ab ? Wie ist die Struktur? Haben die Teams eigenen Bereiche? Kommt dann eine höhere Ebene auch daran?
Access Management für Dokumente läuft über Mail Aliases. Die dann wiederum für alle relevanten Subteams existieren.
Stell mit das mit zigtausend Leuten und der Pflege schwer vor, selbst wenn alle motiviert sind.
Maintenance ist mMn immer eine Challenge, die aber weniger vom System abhängt als von den Prozessen. Ist generell natürlich ein Pain point.

Die Menge der Leute ist aber eher egal. Da du ja auch in großen Organisationen nicht mit allen arbeitest, bzw mit großen Teams in abstrakter Weise -- so wie du bei einem Newsletter ja auch nicht drüber nachdenkst ob das jetzt 100 oder 10000 Rezipienten sind.
 
Mitglied seit
19.11.2003
Beiträge
1.892
Reaktionen
26
@Xantos2
Wie läuft das denn ab ? Wie ist die Struktur? Haben die Teams eigenen Bereiche? Kommt dann eine höhere Ebene auch daran?
Stell mit das mit zigtausend Leuten und der Pflege schwer vor, selbst wenn alle motiviert sind.

In Startups und kleinen Bereichen kann ich mir auch vorstellen das sowas wie One Note ausreicht.
Einzelnen Bücher für Bereicht mit Tabs für Unternehmen und in den Unternehmen noch mal Seiten.
Mehr als drei Ebenen wird irgendwann eh unübersichtlich.

Das versuchen wir jetzt bei uns fürs Confluence. Spannende Frage ist halt wenn es aufs ganze Haus weiter geht. Und sich z.B. jemand drittes über Sachen meiner Einheit informieren möchte.

@n00dl
Nutzt du dann die Gesprächstnotizen?
An sich scheint das cool, aber verliert man da nicht auch schnell den Überblick
In der Tat ist das nicht ganz trivial. Aber ist gut gelabelt (wer hat was wann geschrieben), die Suchfunktion ist gut und dann ist es an dir die Notizen in einer eingängigen Struktur abzulegen und sinnvoll zu beschreiben
 
Mitglied seit
21.08.2010
Beiträge
6.955
Reaktionen
389
Also … nachdem ich für das Engineering die ganze Jira+Confluence-Instanz bei uns, zusammen mit einem Kollegen, definiert und eingerichtet habe, kann ich sagen: Atlassian soll sterben.
Sobald man nicht mehr nur die absoluten Basics nutzt, funktioniert nichts mehr oder man muss für jedes Bisschen zusätzlich zahlen. Unsere (Cloud-)Instanz kostet gut fünfstellig im Jahr, man sieht im Backend des Dings, dass es nur durch Spucke zusammengehalten wird und schlecht designt ist, und das Advanced Roadmapping ist an vielen Stellen nur schlecht drangeschraubt. Vieles funktioniert nicht mit gemischten Teams, Rechtemodell ist unnötig umständlich weil manche Rechte nur zusammen vergeben werden können … usw usw.
Nutzt lieber irgendwas anderes wenn ihr es vermeiden könnt. Atlassian ist ziemlich teuer und nicht supertoll. Ein gehostetes gitlab bietet schon auch einiges. Bei Projektmanagement bin ich mittlerweile klar Team Kanban > Scrum, weil es am Besten zu meinen Anforderungen passt. Am Ende will das Management ja ohnehin, dass man feste Kosten und ein perfektes Ergebnis in Nullzeit verspricht.

Am Ende ist eines der größten Probleme aber: Jira & Confluence sind sehr viel Overhead wenn die Leute zu blöd und/oder zu faul zum ordentlichen benutzen sind.
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
18.650
Reaktionen
402
Ist das Jira Board nicht eine Umsetzung von einem Kanban Board?
Das nutze ich aktuell nur extern in einem Projekt und bin damit mehr oder weniger zufrieden.
Würde sonst nie den Überblick behalten was noch gemacht werden muss etc.

Hab leider sonst keine Wahl :) Scheinbar haben wir jetzt Confluence und das ist besser als gar nichts zu haben.
Wobei mancher hier sieht das ja anders :) One Note in den einzelnen Teams würde es ja auch tun.
Hauptnutzen von Confluence ist imho auch die Dokumentation über die Teams hinweg.
 
Mitglied seit
15.09.2000
Beiträge
897
Reaktionen
33
Worte der Weisheit

Von der Organisation her bin ich völlig bei Euch.

Eine Sache, die ich von Leuten auf der Business Seite schon oft gehört habe, ist, dass es über die Zeit halt allen Druck von den Devs nimmt.

Item braucht halt so lange es braucht. Muss ja richtig gemacht werden. Backlog kann hin und her geschoben werden, ohne Time Estimates ist das aber auch schwierig und dem Entwickler ists eh egal und er arbeitet eins nach dem anderen ab. Mal schauen wie lange es dauert.

Das ist sicher kein Problem, wenn Motivation und Kompetenz voll da ist, aber wie geht Ihr damit um, wenn ihr mals Gefühl habt, bestimmte Entwickler sind nicht voll am performen? In Scrum wird das schön in den Sprint Reviews thematisiert, in Kanban wiederum verschwindet es einfach im stetigen Fluss, oder habt ihr da andere Instrumente für?
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
18.650
Reaktionen
402
Bißchen stimmt das wir haben auch noch Tickets, die aus der ersten Projekt Phase über sind. Da die aber eher nice to have sind stört uns das weniger, weil bezahlt sind sie und der Dienstleister schneidet sich eher ins eigene Fleisch, weil so die Leistung noch nicht fertig ist und wir immer wieder neue Sachen finden. Über die würde man sich bestimmt anders streiten wenn die Leistung einmal angenommen wäre.

Aufwands Schätzung und Abgleich mit realisieren Aufwand ginge ja an sich über das Board. Aber beim Fixpreis war es mir egal und bei change requests hab ich jetzt auch Pech wenn es länger dauert als geplant weil ich will es ja trotzdem
 
Mitglied seit
15.09.2000
Beiträge
897
Reaktionen
33
Ja, ok, wenn Du in der Rahmenkonstruktion Fixpreis gegen ne Spez hast, ist das ja eh nen Wasserfall/agiler Hybrid. Da versteh ich, dass man innendrin den Admin Aufwand einfach so klein wie moglich halten will und dazu gehört sicher nicht Sprints zu planen, durchzuführen und zu reviewen. Dank Fixpreis kann Dir Performance auch egal sein.

Macht Sinn für mich. Frage mich nur wie das bei reinem Kanban ganz ohne Aufwandsschätzungen, Spez oder fixe Vereinbarungen läuft. Zieht das hier jemand konsequent durch?
 
Mitglied seit
02.09.2002
Beiträge
3.187
Reaktionen
42
Item braucht halt so lange es braucht. Muss ja richtig gemacht werden. Backlog kann hin und her geschoben werden, ohne Time Estimates ist das aber auch schwierig und dem Entwickler ists eh egal und er arbeitet eins nach dem anderen ab. Mal schauen wie lange es dauert.

Das ist sicher kein Problem, wenn Motivation und Kompetenz voll da ist, aber wie geht Ihr damit um, wenn ihr mals Gefühl habt, bestimmte Entwickler sind nicht voll am performen? In Scrum wird das schön in den Sprint Reviews thematisiert, in Kanban wiederum verschwindet es einfach im stetigen Fluss, oder habt ihr da andere Instrumente für?
Mhh, gute Frage. Also ich sehe das natürlich aus Perspektive des Entwicklers. Meiner Erfahrung nach finden PMs Meetings total toll, darum sitzen PMs über kurz oder lang in jedem regelmäßigen Meeting und damit wird jedes Meeting über kurz oder lang ein PM Meeting für das sich hauptsächlich der PM interessiert.
Und so sitzt man dann in der VK und spielt für den PM Augsburger Puppenkiste, während parallel dazu ein Gruppenchat offen ist in dem man sich über die Entwicklung unterhält. Das kann doch so nicht im Sinne des Erfinders gewesen sein :ugly:
 
Mitglied seit
21.08.2010
Beiträge
6.955
Reaktionen
389
Ist das Jira Board nicht eine Umsetzung von einem Kanban Board?
Das nutze ich aktuell nur extern in einem Projekt und bin damit mehr oder weniger zufrieden.
Würde sonst nie den Überblick behalten was noch gemacht werden muss etc.
[…]
Jein. Jira ist für Scrum und Kanban geeignet. Das eine ist mit Sprints, das andere mit Durchflussmessung.
Die Software ist auch okay, allerdings ärgere ich mich, dass Youtrack von Jetbrains noch keine volle Alternative ist, weil Atlassian einfach richtig teuer ist.
Eine Sache, die ich von Leuten auf der Business Seite schon oft gehört habe, ist, dass es über die Zeit halt allen Druck von den Devs nimmt.
Item braucht halt so lange es braucht. Muss ja richtig gemacht werden. Backlog kann hin und her geschoben werden, ohne Time Estimates ist das aber auch schwierig und dem Entwickler ists eh egal und er arbeitet eins nach dem anderen ab. Mal schauen wie lange es dauert.
Das ist sicher kein Problem, wenn Motivation und Kompetenz voll da ist, aber wie geht Ihr damit um, wenn ihr mals Gefühl habt, bestimmte Entwickler sind nicht voll am performen? In Scrum wird das schön in den Sprint Reviews thematisiert, in Kanban wiederum verschwindet es einfach im stetigen Fluss, oder habt ihr da andere Instrumente für?
Das ist auch mit Scrum nicht besser. Habe da grad so ein Projekt wo ein Teil der Entwickler rumpimmeln weil sie genau wissen, dass die Firma sie braucht. Da kannst Du im Review und in der Retro sagen was Du willst. Gerade wenn es sich um Legacy-Systeme handelt, die man mit etwas halbwegs zeitgenössischen ersetzen will, was nicht nur einer der alten Entwickler beherrscht. Da wird sich mit Händen und Füßen gegen jedes strukturierte Vorgehen gewehrt, was das geheime Herrschaftswissen in Gefahr bringen könnte. Immer ist dann alles ganz schwierig und muss 10x getestet und recherchiert werden. Zeitschätzungen sind imo Schwachsinn (aber vom Management gewollt) und für Komplexitätsschätzungen sind die meisten zu doof. Am Ende wird es dann ein "Hupsi, alles viel aufwendiger als gedacht. Konnte ja keiner ahnen." Gerade bei Projekten wo man viel neues macht, was noch nie einer in der Firma gemacht hat, wird es mit dem Schätzen noch sinnloser, weil man sich irgendeine Zahl aus dem Arsch ziehen muss (weil das Management es so will).
Und weil der Arbeitsmarkt so ist wie er ist … kommen die Entwickler am Ende mit ihrer Verweigerungshaltung auch noch durch. Da vergiftet auch ein "Alter" ohne Bock, problemlos die Attitüde eines ganzen Teams indem er ständig wegen jedem Mist rumheult und es schon als Sklaventreiberei bezeichnet wenn man mal fragt was er eigentlich die letzten Wochen so gemacht hat. (Und wenn man ihm sagt, dass er gerade das Rad neuerfunden hat, und es für Problem X schon eine fertige Spezifikation gab (die ich mit dem Team mehrfach diskutiert hatte), dann beschwert er sich, dass ich ihm in seine Kompetenz als Entwickler reinreden will, indem ich Implementierungsdetails vorgebe. Buhuuu no shit Sherlock, wir haben es gemeinsam ausgemacht ich hab es definiert und dann habt ihr es euch trotz mehrfacher Aufforderung nie angeschaut.)
Ich habe da zero Mitleid mit solchen Entwicklern und wünsche mir einen Arbeitsmarkt zurück in dem nicht selbst das dümste Fallobst noch einen Job hinterhergeschmissen bekommt. Diese Menschen leben am Ende vom Einsatz ihrer motivierten und teamorientierten Kollegen.
Im aktuellen Kontext, muss man solchen Leuten signalisieren, dass man nicht mehr mit ihnen plant, und dass sie sich was neues suchen sollen … auf die Gefahr hin, dass man sie 3 Monate lang freistellen muss (vorausgesetzt man kann sie ersetzen). Rausekeln ist auch asi, aber leider ist es quasi unmöglich jemanden wirklich loszuwerden. Wer charakterlich scheiße ist lässt sich nämlich, meiner Erfahrung nach, auch nicht mehr richtig einnorden nach einem gewissen Alter. Die geben dann einfach ficks und ziehen die Leistung runter.

Ja, ok, wenn Du in der Rahmenkonstruktion Fixpreis gegen ne Spez hast, ist das ja eh nen Wasserfall/agiler Hybrid. Da versteh ich, dass man innendrin den Admin Aufwand einfach so klein wie moglich halten will und dazu gehört sicher nicht Sprints zu planen, durchzuführen und zu reviewen. Dank Fixpreis kann Dir Performance auch egal sein.
Ja, das haben sie bei uns auch noch nicht kapiert und glauben, dass ein paar Fresszettel mit groben Ideen ausreichend für große Projekte sind … und, dass man bei agilen Projekten auch vorher sowohl Kosten, Zeit als auch Qualität festlegt und dann den köpft der darauf hinweist, dass es nicht funktionieren konnte. (Wenn man gleich zu Beginn darauf hinweist wird man einfach ignoriert … "man muss sich einfach nur anstrengen und es richtig wollen.")
Mhh, gute Frage. Also ich sehe das natürlich aus Perspektive des Entwicklers. Meiner Erfahrung nach finden PMs Meetings total toll, darum sitzen PMs über kurz oder lang in jedem regelmäßigen Meeting und damit wird jedes Meeting über kurz oder lang ein PM Meeting für das sich hauptsächlich der PM interessiert.
Und so sitzt man dann in der VK und spielt für den PM Augsburger Puppenkiste, während parallel dazu ein Gruppenchat offen ist in dem man sich über die Entwicklung unterhält. Das kann doch so nicht im Sinne des Erfinders gewesen sein :ugly:
Ist bei uns nicht so schlimm, sondern anders schlimm. Wir spielen eher das Spiel
"Der PM wünscht sich etwas, weigert sich seine Anforderungen ordentlich aufzuschreiben. Beschwert sich, dass die Schätzungen so hoch sind, eskaliert zum Vorstand bis die Schätzungen das sind was man hören wollte, und ignoriert die die sagen, dass es so nicht funktionieren kann. Das Ignorieren jeglicher technischer Details die Showstopper sind gehört natürlich dazu 'Ich bin nicht für Technik zuständig!'"
Und es mündet dann in
"Das ist ganz anders als ich es wollte. Hättet ihr mir mal richtig zugehört, dann wäre klar gewesen, dass mein Dreizeiler für ein 100 PT+-Projekt ganz anders interpretiert werden musste. Ihr müsst nachbessern aber ich sage euch nicht wie, sondern entscheide erst wenn ich fertig bin ob es mir gefällt und was ich eigentlich wollte."
Am Ende sind die Entwicklungsteams schuld weil sie nicht Gedankenlesen konnten. PM natürlich Engel.

Meine 2c: PMs die nicht selbst aus der Technikecke kommen oder dafür Verständnis aufbringen kann man direkt im Moor versenken. Unsere PMs sind bis auf eine Ausnahme Vollidioten die sich vor allem durch Skill im Blame Game ausweisen … und, um zum Thema zurückzukommen: Die sich auch jedem Bisschen strukturierter Arbeit in Jira und Confluence verweigern. Das ist nämlich so Nerdkram für die Kellerkinder. Diese Leute möchte man jedes Mal mit dem Knüppel verarzten wenn man ihre Scheiße sieht.

Macht Sinn für mich. Frage mich nur wie das bei reinem Kanban ganz ohne Aufwandsschätzungen, Spez oder fixe Vereinbarungen läuft. Zieht das hier jemand konsequent durch?
Für mein eines Team ist es eine Art Scrumban (weil Jira einen durch adv Roadmaps zu Scrum zwingt). Da machen wir den Sprint voll und es wird fertig was fertig wird. Dadurch, dass das Projekt viel Neues enthält was nicht einschätzbar ist, sparen wir uns die Schätzungen und arbeiten im Endeffekt Schritt für Schritt.
Das Problem ist imo, dass Schätzungen genau nur dann funktionieren, wenn man einigermaßen abschätzen kann wie viel Aufwand etwas ist. Und das ist eben nur dann gegeben, wenn ein Team etwas macht, was es vorher schon einmal in anderer/ähnlicher Form getan hat. Leider zeichnet sich einiges bei uns dadurch aus, dass entweder die Leute zu juniorig sind, um diese Erfahrung zu haben, oder der Kram ist einfach Neu.
Entsprechend erfinde ich in Absprache mit dem Team irgendwelche Zahlen die halbwegs plausibel erscheinen, weil es so gefordert wird … und hoffe, dass das Team nicht zu sehr rumpimmelt. Zsfg.: Ich möchte mit kompetenteren Leuten arbeiten :/
 

parats'

Tippspielmeister 2012, Tippspielmeister 2019
Mitglied seit
21.05.2003
Beiträge
18.275
Reaktionen
863
Ort
Hamburg
Meine 2c: PMs die nicht selbst aus der Technikecke kommen oder dafür Verständnis aufbringen kann man direkt im Moor versenken.
Kann ich absolut rautieren, aber auf der anderen Seite fehlt Technikern oft auch das nötige Etwas um Projekte voranzubringen.
Leider sind die PMs mit nem grundlegenden Tech-Stack selten, weil der überwiegende Teil das einfach irgendwie nebenbei "gelernt" hat.
Also es sind es entweder verkappte PMs, die unzureichend Ressourcenmanagement betreiben können und sich zu tief "einmischen" oder es sind Seiteneinsteiger, die wenig Ahnung von Technik haben.

Glückerweise muss ich mich mit sowas nicht rumschlagen. :ugly:
 
Mitglied seit
21.08.2010
Beiträge
6.955
Reaktionen
389
Joar, da stimme ich Dir absolut zu.
Genauso Krebs sind aber Devs die meinen alles besser zu wissen. Ironischerweise einer davon Quereinsteiger. Holt sich einen auf seine Erfahrung runter, ist aber meistens einfach nur stur und will seinen Kopf durchsetzen und Diskussionen ad infinitum verlängern. Natürlich ist er dann (wie die PMs auch) beleidigt wenn er nicht bekommt was er will.
Mit solchen Menschen Teamarbeit zu machen ist echt eine Strafe.

Die einen kriegen es nicht hin in Confluence schriftlich zu definieren was sie wollen, die anderen sagen entweder "wir brauchen mehr Details, um überhaupt zu wissen was wir tun sollen!!!" (meist zu Recht), oder "wääää, sämtliche Implementierungsdetails sind Hoheit der Devs, niemand darf uns irgendetwas vorschreiben!!!!!" (immer zu unrecht).
Kein Scheiß, die wollten mal ganz hip was mit gRPC anstatt REST implementieren weil sie es ganz toll interessant fanden. Das musste erst zum Bereichsleiter hoch bis sie eingesehen haben, dass "das ist dann aber nicht SCRUM!!!!" kein Argument ist. Natürlich waren sie dann beleidigt wegen der "krass hierarchisch gestrigen Führungskultur". Puh.

Da hilft echt auch kein Projektmanagementtool … gerade auch weil es damit steht und fällt, dass es ordentlich genutzt wird. Die Entwickler sind zu faul, um ihre Tasks ordentlich zu managen, die PMs sind zu faul ihre Wünsche zu formulieren. Und Jira/Confluence hängt zwischendrin und ist scheiße.

Dazu: https://ifuckinghatejira.com/44/

Grad durch Zufall gefunden. Gerade #44 ist Gold, was jeder versteht, der mal mit Custom Fields irgendwelche Sonderwunsch-Plugins für Automatisierungen implementieren musste. Denn ohne Automatisierung kann man direkt noch ein paar Jira/Confluence-Babysitter einstellen, damit nicht das Chaos ausbricht. Achja, Automatisierung kostet natürlich extra :deliver:


Edit: Zeitloggen in Jira geht natürlich nicht weil Betriebsrat. Dabei wäre es echt mal schön, um zu analysieren wie viel Arbeit den Devs bei dem ganzen Meeting-Overhead noch zum Arbeiten bleibt. Und es wäre natürlich auch schön, um manche Leuten, die auf Kosten des Teams herumpimmeln, mal zum Reflektieren zu bringen indem man ihnen zeigt, dass sie von Werkstudenten mit halb so viel Stunden pro Woche und Mindestlohn outperformt werden. Leider verboten weil ganz böse.
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
18.650
Reaktionen
402
Kann ich absolut rautieren, aber auf der anderen Seite fehlt Technikern oft auch das nötige Etwas um Projekte voranzubringen.
Leider sind die PMs mit nem grundlegenden Tech-Stack selten, weil der überwiegende Teil das einfach irgendwie nebenbei "gelernt" hat.
Also es sind es entweder verkappte PMs, die unzureichend Ressourcenmanagement betreiben können und sich zu tief "einmischen" oder es sind Seiteneinsteiger, die wenig Ahnung von Technik haben.

Glückerweise muss ich mich mit sowas nicht rumschlagen. :ugly:
Was wäre denn ein grundlegender Tech Stack?
 
Mitglied seit
21.08.2010
Beiträge
6.955
Reaktionen
389
Ich vermute er meint damit, dass ein PM ein zumindest grundlegendes Verständnis aller im konkreten Fall genutzten Technologien haben sollte. Also v.a. was prinzipiell geht und was nicht, was teuer wird und was nicht, und was die wesentlichen technischen Alternativen sind usw.
Wenig ist schlimmer als ein PM der irgendein Feature bei Google gesehen hat und jetzt nicht einsehen will, dass man das nicht mal eben so von einem Werkstudenten nachbauen lassen kann.

"Du bist doch der Data Scientist und redest immer von so tollen KI-Lösungen, mach doch mal. Ich brauch's nächste Woche in Production Ready"

Immer schön die Einschränkung "gib mir Zeit und Ressourcen" vergessen Bro :|
 

parats'

Tippspielmeister 2012, Tippspielmeister 2019
Mitglied seit
21.05.2003
Beiträge
18.275
Reaktionen
863
Ort
Hamburg
Was wäre denn ein grundlegender Tech Stack?
Beispiel aus meinem Alltag. Ein PM der kein grundlegendes Verständnis von relationalen, multidimensionalen oder tabularen Datenmodellen hat ist nutzlos. Er muss verstehen, wie man neue Anforderungen in unserem Stack modelliert. Wenn er noch SQL, MDX oder DAX kann, wäre das nett aber kein muss. Alles darüber hinaus wie .net, python etc. Pp. Ist egal, weil es nur noch im backend verwendet wird.
Ob on prem oder in azure ist auch wumpe. Ich erwarte nicht, dass er stream analytics beherrscht oder ein json parsen kann, das ist alles zu tief. Aber er muss verstehen, was geht und was nicht.
Kurzum: die basics in der Datenanalyse und Modellierung müssen sitzen.
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
18.650
Reaktionen
402
Beispiel aus meinem Alltag. Ein PM der kein grundlegendes Verständnis von relationalen, multidimensionalen oder tabularen Datenmodellen hat ist nutzlos.

Ist das so eine hohe Hürde, die man sich nicht selbst aneignen kann?

Er muss verstehen, wie man neue Anforderungen in unserem Stack modelliert.

Was meinst du damit?

Wenn er noch SQL, MDX oder DAX kann, wäre das nett aber kein muss. Alles darüber hinaus wie .net, python etc. Pp. Ist egal, weil es nur noch im backend verwendet wird.
Ob on prem oder in azure ist auch wumpe. Ich erwarte nicht, dass er stream analytics beherrscht oder ein json parsen kann, das ist alles zu tief. Aber er muss verstehen, was geht und was nicht.
Kurzum: die basics in der Datenanalyse und Modellierung müssen sitzen.

Wer Daten Modelle etc versteht kann wohl auch ein bisschen SQL. DAX ist dann schon sehr spezifisch am Ende der Kette oder?


Wer erklärt mir die Analogie

Holte man bei einem Segelboot die Segel ein und griffe stattdessen auf den kleinen Dieselmotor zurück – es käme kein vernünftiger Mensch je auf die Idee, den abnehmenden Diesel-Bestand im Tank als Beweis dafür zu verwenden, dass Segeln ja gar nicht funktionieren könne
 

parats'

Tippspielmeister 2012, Tippspielmeister 2019
Mitglied seit
21.05.2003
Beiträge
18.275
Reaktionen
863
Ort
Hamburg
Natürlich kann man sich das "selbst" aneignen. Das ist alles keine rocket science und die basics hat man denke ich schnell drauf, wenn man sich denn dafür interessiert.

Was meinst du damit?
Wir haben hier bspw. keine wirklichen Silos oder Insellösungen, wie man sie von vor 10 Jahren noch kennt. Es gibt größere und teils lose Klammern die bestimmte Bereiche zusammenfassen, allerdings schneiden sich diese an vielen Stellen. Neue Anforderungen sind also kein "bau neues Silo mit Daten", sondern müssen in das gesamte Modell eingearbeitet werden. Das macht Änderungen manchmal umständlicher, weil Informationen für mehrere Fachbereiche relevant sind, aber man vermeidet redundante Logik und hat einen single point of truth. Der PM muss sowas halt einordnen können, weil es die Aufwände durchaus beeinflusst und manche Sachen nicht out of the box umgesetzt werden können.

Wer Daten Modelle etc versteht kann wohl auch ein bisschen SQL. DAX ist dann schon sehr spezifisch am Ende der Kette oder?
Ja, SQL basics sind in der Tat am verbreitetsten, auch weil die Syntax relativ einfach ist um zumindest rudimentäre Abfragen hinzubekommen.
 
Mitglied seit
21.08.2010
Beiträge
6.955
Reaktionen
389
Achja … ich hatte heute wieder sowas.

PM: "ich will A, weil es X schneller macht"
Ich: "Nein, es macht nur den Teil von X schneller der dich mehr interessiert, und den Rest langsamer, weil die Kapazität insgesamt gleich bleibt, und nur die Priorisierung innerhalb von X geändert wird. Die Gesamtgeschwindigkeit bleibt gleich."
PM: "Aber Du hast doch gesagt es wird schneller."

… später im Confluence in seinem Projektentwurf: "A ist sinnvoll, weil es X schneller macht und damit Z beheben hilft"

Bei manchen Menschen ist halt Hopfen und Malz verloren, weil sie sowohl zu doof sind um manche Zusammenhänge zu kapieren, oder––schlimmer noch––sie jammern sofort los und verweigern das Zuhören, wenn ein Problem mal eine Lösung braucht, die nicht auf Sandkastenkinderniveau ist.

"Aber Du musst die Daten doch nur in die Datenbank laden. Das kann doch nicht so lange dauern."

… weil die Daten in perfekter Form vom Himmel fallen und sich ein sinnvolles DB-Schema von allein definiert usw.
obvsly gab es als Anforderung ans System nur einen Halbsatz in einer Email "das muss ungefähr den Usecase G abdecken"
Die Definition von Usecase G besteht aus genau einem Wort.

:|
 

Benrath

Community-Forum
Mitglied seit
19.05.2003
Beiträge
18.650
Reaktionen
402
Auch wenn es abschweift. Ist das jetzt ein Problem von Confluence oder der Unternehmenskultur / führung?

Dann schreibst du halt. "A ist nicht sinnvoll, weil es nur einen Teil von X schneller macht und den Rest langsamer. Aufwand hoch, blabla"
Und dann muss halt jemand darüber entscheiden und wenn die auch dafür sind hast du halt Pech gehabt.
 
Mitglied seit
15.09.2000
Beiträge
897
Reaktionen
33
Confluence ist da immerhin insofern hilfreich, dass jeder so Sachen nachlesen kann und zeitnah eingreifen, wenn es wichtig genug ist.

In der alten Welt in der Word Dokumente per E-Mail rumgeschickt werden, wenn man nicht cc ist, läufts schnell mal zu nem Entscheider und das Projekt wird einfach gestartet.

Was ist eigentlich Deine Rolle in dem ganzen Bootdiskette? Kann Dich nicht so richtig verordnen.
 
Mitglied seit
21.08.2010
Beiträge
6.955
Reaktionen
389
@Benrath das ist ein Problem der Unternehmenskultur. Mein Punkt dabei: solange es nicht sanktioniert wird wenn man sich den eingeführten Prozessen widersetzt, bringt auch das beste Tool nichts. Wenn das Management es seinen Lieblingen durchgehen lässt den ganzen Prozess zu sabotieren, dann stinkt der Fisch überall, aber nicht am Werkzeug.
Das betreffende Projekt hat der PM jetzt übrigens nicht einmal im Portfolio-Board vorgestellt … keine Ahnung warum. Vielleicht hat er die Implikationen nicht verstanden. Ist eigentlich brutal simpel.

@TealC Wie gesagt, die Leute müssen es dann auch nutzen und verständliche ganze Sätze schreiben. Bei vielen ist das echt ein Problem weil sie zu unorganisiert und zu dum sind.
Meine Rolle ist, dass eines meiner Teams dieses Projekt umsetzen müsste, und dass ich zahllose Stunden darauf verwenden musste dem Management die Implikationen zu erklären. Und ganz nebenbei bin ich (zusammen mit unserem Enterprise Architekt) derjenige, der im Auftrag der obersten Management-Ebene unser gesamtes strategisches und operatives Projekt- und Prozessmanagement geplant und umgesetzt hat. Also das ganze Gedöns "was ist ein Projekt?", "wie ist der Prozess von der Idee zum Projekt bis hin zur Abnahme?", "wie ist das Post-Investment-Review ungefähr gegliedert?" … nicht alles haben wir 100% alleine gemacht, aber halt die Grundsteine dafür gelegt, dass Controlling und die Leitung strategische Projekte damit arbeiten kann. Letztlich arbeitet jetzt das ganze Unternehmen in der Cloud-Atlassian-Suite die wir eingerichtet haben. Da nervt es schon gewaltig wenn sich die Hälfte der Leute nicht an die Prozesse halten und jammern wie komplex das alles sei buhuuu buhuuu. Ich kann euch versichern, es ist nicht schwer wenn man nicht komplett bescheuert ist. Und … quelle surprise … die Verweigerer sind alle aus den Bereichen Produktmanagement, Marketing usw.
Die wollen einfach weiter wursten und frickeln wie sie es gewohnt sind … ohne sich ändern zu müssen.

Und das ganze war eigentlich nur ein Side-Project für uns, weil ich mich in der falschen Runde zu laut darüber aufgeregt habe, dass es echt kein Zustand ist, dass jeder Bereich sein eigenes Projektmanagement-Tool nutzt, und es vollkommen unnachvollziehbar ist was eigentlich gerade so alles passiert. Ja, dann hatte ich den Job nebenbei das Projektmanagement neu aufzuziehen. Wie gesagt nicht ganz alleine, aber am Ende waren wir halt auch nur zu dritt.
 
Oben