-
Das großartige Treffen dieses Jahr wird nächstes Jahr wiederholt. Wir treffen uns wieder im Sauerlandpark. Diesmal ist der Termin noch nicht fixiert. Also schau im Thread vorbei und gib Bescheid, ob und wann du teilnehmen willst und kannst. Ich will auch!
Kollab-Tools im Unternehmensumfeld
- Ersteller Caesar III
- Erstellt am
Firo
Stadtbekanntes Mitglied
Order bei Mufti. Es soll konzernweit irgendwann das selbe Tooling genutzt werden, und da wurde halt vor Jahren (bevor ich überhaupt jemals von Git gehört hatte) beschlossen, SVN/Jira zu nutzen.
SVN ist dabei nicht das große Problem, außer dass wir natürlich soviele Branches und Revisions da drin liegen haben, dass man NIE NIE NIEMALS NICHT den Revisionbrowser öffnen sollte - denn dann kannst du deine Kiste gleich neustarten
Das interessante ist: Das ist die dritte Firma, bei der die Projektlandschaft dermaßen komplex ist.
In der ersten Firma wurde für die Arbeitspakete ein internes Tool auf Access Basis (das dann irgendwann Access nur noch als Oberfläche benutzt hat, der Rest war ne DLL ) genutzt, welches sehr gut die benötigten Umfänge abgedeckt hat. Dazu gab es fürs Ticketing ein uralt Siemenstool. Grauenhaft veraltet sah das Ding aus, hat aber alles gekonnt, was nötig war. Versioniert wurde über... PVCS. Das Teil war schlimm
Bei der zweiten Firma wurde das alles in einem Tool erledigt: MKS
Es war grauenhaft aufgesetzt und damit war in den Projekten Sodom und Gomorrha los, aber richtig benutzt, wäre das Tool schon ziemlich gut hingekommen.
Dritte Firma: Wieder ein intern zurechtgebasteltes Access Tool. Bedienung etwas unintuitiv, aber wurde gut gewartet, schnell verbessert, und konnte eigentlich alles, was notwendig war. Lief in Verbindung mit CM Synergy, hatte aber dann auch Support für das jetzige Ablage Konzept (SVN).
Davon wurde weggewechselt auf jetzt Jira. Und das historisch gewachsene und damit in den einzelnen Dateien fies verstrickte Projekt überfordert halt ein Ticketsystem, das ursprünglich für ein modulares Projekt gedacht war, mal komplett.
Es scheint wohl zuwenig geeignete Dritthersteller Software zu geben, bei diesen zahlreichen Eigenlösungen. Dabei ist dieses Projektsetup zumindest in der Branche hier die absolute Normalität. Und es sind immer die selben Probleme um die es geht. Egal bei welcher Firma ich bisher war.
SVN ist dabei nicht das große Problem, außer dass wir natürlich soviele Branches und Revisions da drin liegen haben, dass man NIE NIE NIEMALS NICHT den Revisionbrowser öffnen sollte - denn dann kannst du deine Kiste gleich neustarten
Das interessante ist: Das ist die dritte Firma, bei der die Projektlandschaft dermaßen komplex ist.
In der ersten Firma wurde für die Arbeitspakete ein internes Tool auf Access Basis (das dann irgendwann Access nur noch als Oberfläche benutzt hat, der Rest war ne DLL
) genutzt, welches sehr gut die benötigten Umfänge abgedeckt hat. Dazu gab es fürs Ticketing ein uralt Siemenstool. Grauenhaft veraltet sah das Ding aus, hat aber alles gekonnt, was nötig war. Versioniert wurde über... PVCS. Das Teil war schlimm Bei der zweiten Firma wurde das alles in einem Tool erledigt: MKS
Es war grauenhaft aufgesetzt und damit war in den Projekten Sodom und Gomorrha los, aber richtig benutzt, wäre das Tool schon ziemlich gut hingekommen.
Dritte Firma: Wieder ein intern zurechtgebasteltes Access Tool. Bedienung etwas unintuitiv, aber wurde gut gewartet, schnell verbessert, und konnte eigentlich alles, was notwendig war. Lief in Verbindung mit CM Synergy, hatte aber dann auch Support für das jetzige Ablage Konzept (SVN).
Davon wurde weggewechselt auf jetzt Jira. Und das historisch gewachsene und damit in den einzelnen Dateien fies verstrickte Projekt überfordert halt ein Ticketsystem, das ursprünglich für ein modulares Projekt gedacht war, mal komplett.
Es scheint wohl zuwenig geeignete Dritthersteller Software zu geben, bei diesen zahlreichen Eigenlösungen. Dabei ist dieses Projektsetup zumindest in der Branche hier die absolute Normalität. Und es sind immer die selben Probleme um die es geht. Egal bei welcher Firma ich bisher war.
Achmed20
von beruf gestört
ich frag mich ernsthaft wie und was Linux kernel developer so benutzen und amchen. die stehen doch quasi vor ähnlcihen problemen.
ist bei uns halt relativ einfahc gestrickt.
ticketsystem -> tickets abarbeiten (commits lösen tickets und tragen auch zeitent und änderungen ein) -> aufm Dev testen > auf dem Stage QA > irgendwann release
ich glaub bei dem szenario da oben würd ich irre werden
ist bei uns halt relativ einfahc gestrickt.
ticketsystem -> tickets abarbeiten (commits lösen tickets und tragen auch zeitent und änderungen ein) -> aufm Dev testen > auf dem Stage QA > irgendwann release
ich glaub bei dem szenario da oben würd ich irre werden
Caesar III
Oh Noes
Jira und git geht... Mit stash.
Firo
Stadtbekanntes Mitglied
ich glaub bei dem szenario da oben würd ich irre werden
Bin ich schon längst. Aber es gibt gut Geld. Weswegen ich ab nächstes Jahr nur noch ne 3 Tage Woche machenmöchte, und zwei Tage Zeugs das geil ist, und wo ich nicht schaun muss, dass es profitabel ist.
Firo
Stadtbekanntes Mitglied
Wir hatten kurzzeitig sogar die Erlaubnis, Firefox oder Chrome zu isntallieren, weil standardmaäßig war ja vor einiger Zeit noch Windows XP und damit IE7 installiert... Jira hat natürlich den ollen IE7 überfordert und war grenzenlos langsam bei jedem einzalnen Klick... 
Mittlerweile haben wir alle Rechner auf Win7 (das war ein Drama, bis sich da mal alle den Umstieg getraut haben. Ich hab meinen Build PC einfach neu installieren lassen und alles lief problemlos. Angsthasen.) udn somit haben wir einen topaktuellen IE8...
... 
Nutzen trotzdem alle Firefox oder Chrome.
Mittlerweile haben wir alle Rechner auf Win7 (das war ein Drama, bis sich da mal alle den Umstieg getraut haben. Ich hab meinen Build PC einfach neu installieren lassen und alles lief problemlos. Angsthasen.) udn somit haben wir einen topaktuellen IE8...
... Nutzen trotzdem alle Firefox oder Chrome.
thething
Kackafurz Pipinase
Wir hatten kurzzeitig sogar die Erlaubnis, Firefox oder Chrome zu isntallieren, weil standardmaäßig war ja vor einiger Zeit noch Windows XP und damit IE7 installiert... Jira hat natürlich den ollen IE7 überfordert und war grenzenlos langsam bei jedem einzalnen Klick...
Mittlerweile haben wir alle Rechner auf Win7 (das war ein Drama, bis sich da mal alle den Umstieg getraut haben. Ich hab meinen Build PC einfach neu installieren lassen und alles lief problemlos. Angsthasen.) udn somit haben wir einen topaktuellen IE8...
.
Das ist so veraltet und grundlos, ich hoff die Unternehmen stellen sich in absehbarer Zeit mal um. Gottseidank momentan keine B2B Tools am kraudern, bis 2012 musste bei einem noch IE6 Unterstützung sein - ging 80% der Zeit dafür drauf das Dingen noch zu unterstützen -.- Auf welcher Grundlage wurde die Entscheidung den getroffen?
@Firo: Hört sich insgesamt recht fies an, SVN lässt sich aber meines Wissens nach ganz gut zu GIT konvertieren und den Wildwuchs an Branches sollte sich über gute Workflows in Griff bekommen lassen. Macht schon Sinn, sind atm auch dabei da noch nachzubessern.
Und falls es untergegangen ist im anderen Thread, ein Projekt MA hat kürzlich Phabricator eingeführt:
http://phabricator.org
Ist bisher soweit richtig gut (Außenzugriff zickt hier noch etwas rum) und hat z.B. auch ein mächtiges CLI Tool (https://secure.phabricator.com/book/phabricator/article/arcanist/ - muss ich mir nächste Woche mal antun). Vielleicht für den ein oder anderen hier einen Blick wert.
Firo
Stadtbekanntes Mitglied
Wir reden von einem Großkonzern. Die stellen erst um, wenn Git veraltet ist
Aber wie gesagt: SVN ist tatsächlich nicht das Problem. Revision Graph ("Show Revisions" den meinte ich oben) brauchen wir ohnehin so gut wie nie, die Revision History eines Branches ist schnell genug.
thething
Kackafurz Pipinase
Wir reden von einem Großkonzern. Die stellen erst um, wenn Git veraltet ist
Schon seltsam alles...
Firo
Stadtbekanntes Mitglied
Letzten Endes verstehe ich schon, was sie mit dem Setup vorhaben.
Die Entwickler sollen fast ausschließlich an ihren Komponenten arbeiten, und das Projektsetup in der Regel dabei so gut wie nie anfassen msüsen. Dann funktioniert das ganze auch so halbwegs, aber...
...unser Projekt ist halt als Jugend Forscht muss bis 2011 auf den USA Markt Projekt gestartet. Ich muss nicht weiter erwähnen, was für ein Code da binnen eines Jahres zusammenwuchert, wenns nur um make it work in Time geht.
Gut, ist ja auch ok, um die Testflotte zumlaufen zu bringen, nur dann kam das Management daher und hat irgendwas von wegen "Zukunft... blabla... Nachhaltigkeit... blabla... Baukasten" erzählt, und seitdem hatten wir also offiziell ein komponentenbasiertes Projekt, und wurden so nach und nach auf diese Toolkette geprügelt.
Mit dem Resultat, dass du für annähernd jede Softwareänderung nicht nur einen Komponentenbranch anlegst, sondern auch noch einen Projektbranch brauchst - und somit doppelt reintegrieren darfst. Wegen der Verflechtungen waren nun die in Managerköpfen projektunabhängigen (sozusagen Multiplattform ) Komponenten mal so überhaupt nicht projektunabhängig, also hat man das in der Regel dann gleich viermal am Stück gemacht. Teilweise nur weil ein scheiß (z.T. automatisch erzeugtes) Interface anders heißt.
Diese vermurkste Projektplanung verfolgt das ganze Ding bis heute - eine Feature- und Releasepause um das ganze Konstrukt zu entflechten wäre sehr sehr dingend notwendig gewesen - hat die Releaseplanung aber nicht zugelassen...
Aber ein riesiger Erfolg ist die ganze Geschichte geworden... eigentlich ganz schön ernüchternd, wenn man bedenkt wie sehr sich andere Firmen den Arsch aufreißen, um eine ordentliche Codebase zu haben, und dann mit Nichtbeachtung abgestraft werden...
Die Entwickler sollen fast ausschließlich an ihren Komponenten arbeiten, und das Projektsetup in der Regel dabei so gut wie nie anfassen msüsen. Dann funktioniert das ganze auch so halbwegs, aber...
...unser Projekt ist halt als Jugend Forscht muss bis 2011 auf den USA Markt Projekt gestartet. Ich muss nicht weiter erwähnen, was für ein Code da binnen eines Jahres zusammenwuchert, wenns nur um make it work in Time geht.
Gut, ist ja auch ok, um die Testflotte zumlaufen zu bringen, nur dann kam das Management daher und hat irgendwas von wegen "Zukunft... blabla... Nachhaltigkeit... blabla... Baukasten" erzählt, und seitdem hatten wir also offiziell ein komponentenbasiertes Projekt, und wurden so nach und nach auf diese Toolkette geprügelt.
Mit dem Resultat, dass du für annähernd jede Softwareänderung nicht nur einen Komponentenbranch anlegst, sondern auch noch einen Projektbranch brauchst - und somit doppelt reintegrieren darfst. Wegen der Verflechtungen waren nun die in Managerköpfen projektunabhängigen (sozusagen Multiplattform
) Komponenten mal so überhaupt nicht projektunabhängig, also hat man das in der Regel dann gleich viermal am Stück gemacht. Teilweise nur weil ein scheiß (z.T. automatisch erzeugtes) Interface anders heißt.Diese vermurkste Projektplanung verfolgt das ganze Ding bis heute - eine Feature- und Releasepause um das ganze Konstrukt zu entflechten wäre sehr sehr dingend notwendig gewesen - hat die Releaseplanung aber nicht zugelassen...
Aber ein riesiger Erfolg ist die ganze Geschichte geworden... eigentlich ganz schön ernüchternd, wenn man bedenkt wie sehr sich andere Firmen den Arsch aufreißen, um eine ordentliche Codebase zu haben, und dann mit Nichtbeachtung abgestraft werden...
Firo
Stadtbekanntes Mitglied
Wenn ich diese alten Posts lese... zum Glück hab ich beim aktuellen Projekt diverse Entscheidungen einfach auf eigene Faust getroffen und meinem Team indoktriniert. Seitdem läuft das alles recht gut - nicht zuletzt wegen Einführung eines Integrationskalenders.
Jetzt mussten wir aber kundenbedingt von Redmine nach RTC wechsels
In Redmine war das alles so schön. Es ging flott, man hat schön editiert, hat immer das aktuelle angezeigt bekommen, es war intuitiv...
...nicht so RTC. Es sieht hübsch aus, und es hat hübsche Spritn Features, aber das Ding macht eines, das ich HASSE WIE DIE PEST.
Wenn ich irgendetwas öffne, sei es ein Query, ein Task.. egal. Es zeigt immer erst das zuletzt geöffnete ein, und zeigt dann oben ein "Loading" fehlt an. Dann wartet man erstmal, bis alle Felder aktualisiert wurden.
Die Felder sind während dieser Phase aber nicht gesperrt, man kann also - was auch imemr aktuell angezeigt wird - gnadenlos zerpfuschen.
WOAH!
Wenn man das mal gecheckt hat, geht es halbwegs, aber das ist soooooo scheiße gelöst...
IBM sollte es doch besser wissen.
Jetzt mussten wir aber kundenbedingt von Redmine nach RTC wechsels
In Redmine war das alles so schön. Es ging flott, man hat schön editiert, hat immer das aktuelle angezeigt bekommen, es war intuitiv...
...nicht so RTC. Es sieht hübsch aus, und es hat hübsche Spritn Features, aber das Ding macht eines, das ich HASSE WIE DIE PEST.
Wenn ich irgendetwas öffne, sei es ein Query, ein Task.. egal. Es zeigt immer erst das zuletzt geöffnete ein, und zeigt dann oben ein "Loading" fehlt an. Dann wartet man erstmal, bis alle Felder aktualisiert wurden.
Die Felder sind während dieser Phase aber nicht gesperrt, man kann also - was auch imemr aktuell angezeigt wird - gnadenlos zerpfuschen.
WOAH!
Wenn man das mal gecheckt hat, geht es halbwegs, aber das ist soooooo scheiße gelöst...
IBM sollte es doch besser wissen.