In ein Projekt einarbeiten

Also die arbeiten da bei uns mit Jira und ja, Scrum Bords wo jede 2 Wochen Sprints 2 Wochen lange Sprints mit den entsprechenden Tickets eingeplanet werden.
Gibt halt sozusagen die Business-Seite des Shops, mit Anforderungsmanagement, die dann das ganze an die entwickelnde Seite weiter gibt, wo auch wieder ein Anforderungsmanger sitzt und entscheidet, ob der Vorschlag überhaupt umgesetzt werden soll, etc.
Dann gibts immer die Entscheidung zw Bug oder Weiterentwicklung, Release-Termine, Hotfixes, bla bla.

Ist schon eig. alles ziemlich solide und kommunikativ aufgebaut dort, freut mich auch da ich da eine Menge mitnehmen kann. Ist auch alles sehr persönlich kommuniziert, die laufen halt dann eifnach die 10 Meter zum Arbeitsplatz vom Kollegen und besprechen eins der Themen, die halt so anstehen.
Dann wird das Besprochene meistens ins Ticket kommuniziert, damit der Rest auch weiß was abgeht und ansonsten wird halt enorm viel telefoniert.

Ich würd in dem Projekt echt gerne produktiv werden, weil es mir denke ich sehr viel Spaß bereiten würde, irgendwelche Bugs auf der Spur zu sein, dies das zu evaluieren und auszugrenzen, dann man den und jenen dazu befragen, etc.

So wie es gerade halt ist, ist es allerdings sehr ... bedrückend. Man sitzt vor dem Projekt, hilft niemandem bei irgendwas und versucht sein bestes, auch nur ein Bruchteil des Wissens zu erlangen, das jeder andere um einen rum schon hat.

Da ich mit Webdevelopment leider nichts am Hut habe ist mir auch die komplette Struktur eines EJB (Enterprise JavaBean ) Webprojektes gar nicht vertraut.
Es scheint aber als würde das ganze einem relativ bekannten ... Design-Muster folgen, das man so für Enterprise Java-Websiten benutzt.

Würde mir dazu echt gerne ein Buch kaufen, um einfach mal wesentlich besser die Grundstruktur zu verstehen.
Bin allerdings noch am suchen, was sich da als Lektüre eignet.

Mechanics

Unsure schrieb:

Ich würd in dem Projekt echt gerne produktiv werden, weil es mir denke ich sehr viel Spaß bereiten würde, irgendwelche Bugs auf der Spur zu sein, dies das zu evaluieren und auszugrenzen, dann man den und jenen dazu befragen, etc.

Hört sich an, als würdest du bei "Bugs jagen" an irgendwelche Krimis denken ^^ Kann schon sein, dass es ab und zu so läuft und man auch manchmal Kollegen fragen muss, was die sich schon wieder gedacht haben, ich würd das ganze aber eher neutral sehen. Bugfixing ist eigentlich auch nicht wirklich was für Praktikanten, würde ich sagen. Wenn man sich auskennt, kann man einfache Bugs in paar Minuten fixen. Wenn man sich nicht auskennt, ist es hauptsächlich Zeitverschwendung, weil man sich erst vielleicht tagelang zusammenreimen muss, was zig andere eh schon wissen. Auch Praktikanten kann man produktiver einsetzen. Und an schwierige Bugs werden die wahrscheinlich eh nicht rangelassen. Wir haben in unserem 3D Kernel auch Bugs, die wir seit Jahren kennen, aber die hat jetzt auch noch keiner fixen können, da würden wir sicher keine Praktikanten ranlassen. Der hätte danach auch nicht viel zu erzählen.

Ja, bei der ganzen Java Enterprise Entwicklung gibts viele Standards. Da hilft es schon sehr viel, wenn man die Standard Patterns und Vorgehensweisen kennt, dann kommt man in die meisten Projekte sehr schnell rein.

Mechanics schrieb:

Wir haben in unserem 3D Kernel auch Bugs, die wir seit Jahren kennen, aber die hat jetzt auch noch keiner fixen können

Wie kann man nur so dumm sein und sowas verraten in Anbetracht der Tatsache das hier einige Leute wissen wo du arbeitest.

Mechanics

Selbst wenn... JEDER 3D Kernel hat Bugs, auch Acis und Parasolid Das dürfte jetzt für niemanden eine Offenbarung sein.

Naja, du hast vermutlich recht, ja.

Aber was ich so mit bekomme haben die Jungs trotz dem ständigen "Oh mein Gott was ist denn jetzt schon wieder los"-Getue irgendwie Spaß daran, kaputte Dinge und Probleme zu fixen.

Lustig ist, dass gerade die Leute, die wirklich breites Wissen über das ganze Projekt haben ständig von Kollegen heimgesucht werden und irgendwas gefragt werden.

Zu der ganzen Java Enterprise Web-Entwicklungs Sache gibt es ja tatsächlich jede Menge im Internet.

Aber ich komme mir immer so doof vor, wenn ich im Internet nen Tutorial über sonst was lese, während alle um mich rum arbeiten.
Aber im Endeffekt wäre das wohl bei meinem aktuellen Wissenstand das sinnvollste.

Marthog

Unsure schrieb:

Aber ich komme mir immer so doof vor, wenn ich im Internet nen Tutorial über sonst was lese, während alle um mich rum arbeiten.
Aber im Endeffekt wäre das wohl bei meinem aktuellen Wissenstand das sinnvollste.

Mach auf einem Bildschirm oder einer Bildschirmhaelfte das Tutorial, auf der anderen den Sourcecode auf. Dann sieht es so aus, als wuerdest du nur mal ein Detail nachschlagen.

Mechanics

Unsure schrieb:

Aber was ich so mit bekomme haben die Jungs trotz dem ständigen "Oh mein Gott was ist denn jetzt schon wieder los"-Getue irgendwie Spaß daran, kaputte Dinge und Probleme zu fixen.

Das macht ja auch Spass. Ich verbringe auch einen recht großen Teil meiner Zeit freiwillig mit dem untersuchen von Problemen. Nur würde ich das nicht unbedingt mit "Detektivarbeit" vergleichen. Mir macht es u.a. Spass, weil ich mich so in irgendwas neues einarbeiten kann, oder mir zumindest etwas interessantes anschauen, womit ich sonst nichts zu tun hätte.

@Marthod Mach ich tatsächlich eh schon so, haha

@Mechanics Ja gut, mein Vergleich war vermutlich ein bisschen übertrieben :p

Ethon

TyRoXx schrieb:

Eine systematische Herangehensweise würde vielleicht helfen. Sorry, aber "Software Engineering" ist gescheitert und "Agile" ist nur ein Buzzword, um Schulungen zu verkaufen.

Ach komm bitte. Nur weil es bei euch nicht läuft, schließe nicht auf den Rest der Welt.

Unsure schrieb:

Aber ich komme mir immer so doof vor, wenn ich im Internet nen Tutorial über sonst was lese, während alle um mich rum arbeiten.
Aber im Endeffekt wäre das wohl bei meinem aktuellen Wissenstand das sinnvollste.

Aber das ist doch auch ein Teil des Berufes. Bei den meisten anderen Berufen weißt du halt was du zu machen, schließlich hast du es ja gelernt. Ein paar Details ließt man dann aber auch mal was nach, wie gesagt "mal" und nicht ständig.

Beim Entwickler, der nun aber jeden Tag Google braucht, kann auch was nicht stimmen.