[Entwicklungsprozess] Lasst eure Erfahrungen sprechen

[Jaiel]

Hallo liebe Community,

als angehender Programmierer möchte ich den Schritt vom HobbyEntwickler zum Profi gehen und meine Brötchen damit verdienen in naher Zukunft.

Ich muss noch viel lernen und ein wichtiger Aspekt ist für mich das Arbeiten im Team und der Entwicklungsprozess einer Software von Ideenfindung, Planung, Aufgabenverteilung im Team, Projektmanagement , Kommunikation, uns was sonst noch so alles dazu gehört.

Ich fände es wirklich sehr interessant, von denen die schon länger im Geschäft sind, ob ihr nicht mal etwas erzählen könntet was ihr schon an Erfahrung gesammelt habt in der Softwareentwicklung und das Arbeiten im Team und oder an Projekten.

Vielleicht könntet ihr mal etwas darüber schreiben welche Prozesse bei euch auf der Arbeit ablaufen, Erfahrungen im Team gesammelt habt oder was euch so einfällt.

Evtl. so:

1. Kurze Vorstellung: zur Person, Erfahrung, Beruf, Motivation, etc. ...
2. Euer Werdegang: Ausbildung/Studium/Hobby, Karriere, Projekte, etc. ...
3. Eure Erfahrung : Entwicklung Prozesse , sprich wie geht ihr an Software ran, welche Erfahrungen habt ihr sammeln können, positive wie negative ...
4. Tipps für Anfänger: Es gibt verschiedene Herangehensweisen und Durchführungsarten was empfiehlt ihr, Tipps und Tricks, Lifehacks etc. ...

Ihe könnt auch einfach unstrukturiert aus dem Nähkästchen plaudern wenn ihr möchtet.

Vielen Dank

Jaiel

 

[DagobertDokate]

Hey Jaiel,

erstmal Respekt das du noch da bist =) (und auch manchmal das Forum gut unterhälst) hätte ich mit deinem Start-Posts nie mit gerechnet... klang wie eins dieser "one-hit-wounder" die hier jeden Tag auflaufen =)

Jetzt zum Post, welchen ich von der Thematik sehr interessant finde, jedoch glaube ich nicht das dieser sonderlich viele Reaktionen hervorbringt weil das Thema/die Themen die du hier ansprichst ganze eigene Foren haben Und PM (Projektmanagement) erstmal so nichts mit der eigentlichen Entwicklung zu tun hat, sonder mehr eine Meta-Ebene ist. (Die Allgemein auch auf andere Projekte nicht nur IT/Programmieren übertragbar ist) Zumindest die allgemeinen Projekt schritte.

1. Kurze Vorstellung: zur Person, Erfahrung, Beruf, Motivation, etc. ...

Jo ich bin jung, naja so jung auch nicht mehr^^, Studiere und arbeite nebenbei als Studentische Hilfskraft (App Job Angebote in Do und Umgebung sind immer gerne gesehen =)) und meine Motivation besteht in der Sache selbst. Informatik/PM ist einfach ein Traum Berufsfeld, naja fast^^.

Euer Werdegang: Ausbildung/Studium/Hobby, Karriere, Projekte, etc. ...

Ganz klassisch Realschule -> Abi (Mathe/Info) -> Bachelor of Science Dienstleistungsinformatik-> Master of Science in DLI Nebenbei ist mein Hobby mein Beruf geworden

Eure Erfahrung : Entwicklung Prozesse , sprich wie geht ihr an Software ran, welche Erfahrungen habt ihr sammeln können, positive wie negative ...

Communication is everything
Nein im erst, mit anderen reden können und auch keine scheu haben ist mM mit das wichtigeste...
Naja um den Bereich hier mit Wissen zu füllen, fehlt mir
a) Wissen ^^ und
b ) vor allem Zeit^^

Agile Methoden finde ich ganz nett. Scrum ist nett. Hab ich aber zu wenig praxisnahe Erfahrungen damit um das in der Realität wirklich bewerten zu können. In meiner Firma wird wohl mehr das klassische Wasserfallmodell benutzt. Aber gerade im Bereich App Entwicklung finde ich das agil passt. Dazu gepaart mit dem Gitflow und das VCS ist auch ordentlich.
Ein anderer Ansatz den ich mir gerade angucke ist Continuous Delivery & Lean StartUp und ich versuche gerade eine CD Pipeline für eine App aufzusetzen.(Continuous Delivery - Ein pragmatischer Einstieg ist eine schöne Lektüre zum reinkommen - sogar auf deutsch^^)
Naja aber wie gesagt da gibt es ganze Themengebiete, Subgebiete und Studiengänge um das Thema zu füllen^^
Wenn du dich für PM interessierst, die Bücher von Tom, DeMarco wurden in den passenden Vorlesungen immer gelobt.

4. Tipps für Anfänger: Es gibt verschiedene Herangehensweisen und Durchführungsarten was empfiehlt ihr, Tipps und Tricks, Lifehacks etc. ...

Verschiedene Methoden kennen schadet nicht um die Richtige oder seinen Liebling zu finden

So muss erstmal weiter, bis später mal.

lg. Dagobert

 

[zumafx]

Dann will ich auch mal, aber ich bin da eher "old-fashioned"

Ich:
seit ca 30 Jahren in der EDV tätig, derzeit befristeter Rentner. Job war für mich immer
das Hobby, mit dem ich mein Geld verdiente.
Und bin immer noch neugierig auf neues (weshalb ich auch hier im Forum bin bzw. mich auf Androidprogrammierung stürze derzeit )

Werdegang:
Realschule, Bundeswehr (dort erste Programmiererfahrung gesammelt an Großrechnern), während und danach 4 Berufsausbildungen gemacht, bis auf eine alle im EDV-Bereich. In vielen verschiedenen Fachgebieten/Firmen gearbeitet, somit eine große Bandbreite an Projekten. Softwareprojekte reichten von Auftragsbearbeitung über Schweinebesamung, Produktionssteuerung bis hin zu meinem letzten Projekt, das ich zum Marktführer in Deutschland bringen konnte (fachliches Nischenprodukt)

Arbeitsweise/Entwicklung:
Sehr unterschiedlich. Ist man "nur" der Programmierer oder macht man auch die Ist-Analyse/ Pflichtenhefterstellung. Wasserfallmodell und TopDownverfahren sind eigentlich die am meisten genutzten, denke ich mal. Da ich auch viel die Ist-Analyse gemacht hab, hab ich immer erstmal seitenweise geschrieben, was der Kunde wollte/sich vorstellte. (Achtung: meistens weiß der Kunde gar nicht genau, was er will, da ihm meist die Detailtiefe abgeht).
Meine Faustregel: ganz doof fragen und ganz schlau zuhören!
Dann aus dem Erfragtem/Aufgeschriebenen zuerst mal die verschiedenen Aufgaben rausschreiben, im Idealfall und nach einiger Übung ergibt das schon mal ein Grobkonzept. Das wiederum nochmal durchackern und gucken, was man zu welchen Modulen/Funktionen zusammen fassen kann. Das ganze dann wieder in eine Kundengerechte Form schreiben und noch mal mit dem durcharbeiten.
Dann erste Programmierarbeiten beginnen, wobei ich mich immer an folgende Reihenfolge gehalten hab:
zuerst die Datenhaltung (z.B. Datenbankdesign). Zum Testen entstehen da quasi nebenbei auch die Zugriffsroutinen. Dann die Logiken je Aufgabenmodul, Modul für Modul. Dann die ersten Oberflächen und die "Steuerungslogik" zwischen den Modulen.
Das wieder beim Kunden vorstellen und abnicken lassen. Dann testen (am besten immer durch andere, niemand testet den eigenen Code so schlecht wie man selber ) und "feinschleifen" der GUI und Funktionen bis zur Betaphase. Dann Installation beim Kunden und dann erstmal kein Urlaub, sondern ständig auf Standby zur Fehlerkorrektur
So ungefähr hab ich das oft gemacht, aber auch manchmal ganz anders, das ist oft davon abhängig, wie umfassend ein Projekt ist, in welcher Rolle man da mitarbeitet (macht man den Leiter oder steuert man nur ein paar Funktionen bei).
Kommunikation ist dabei alles, aber das heißt nicht, die anderen "totsabbeln"
Gerade Kunden gegenüber braucht man viel Fingerspitzengefühl, nur die allerwenigsten lassen sich gerne sagen, wie was zu laufen hat (das sind meist die Chef's und die sind es gewohnt, anderen zu sagen, was die zu tun haben). Wenn man wirklich gut ist, bringt man sein Gegenüber dazu, das der glaubt, selber die Idee gehabt zu haben
Sich zurückhalten und nicht gleich jeden Gedanken auf die Zunge ist sowohl bei Kundengesprächen wie auch im Team die bessere Taktik. Lieber weniger, aber dafür durchdachter was vorbringen.
Puh, wird ja schon ein halber Roman, ich glaub, ich könnte ein Buch füllen
Aber eins noch:
Psychologie ist bei der ganzen Sache nicht zu verachten. Zum einen für die Kommunikation mit Kunden/Kollegen/Chef. Aber auch auf einer ganz anderen Ebene: Wenn man weiss, wie Menschen denken, kann man auch bessere Software schreiben (z.B. durch besseres verknüpfen von Funktionalitäten oder dem Aufbau der GUI. Das reicht von einfachem strukturieren der GUI-Elemente bis zur Farbgebung).
Übertrieben gesagt: Eine Software ist erst dann wirklich gut, wenn sie macht, was sie soll UND deine Oma die ohne Anleitung bedienen kann ) Einige Zeit im Support arbeiten kann da helfen, man glaubt gar nicht, was User so alles fertig bringen ... würde noch ein Buch füllen .
Man sollte auch nicht vergessen, das die Software für den User nur ein Werkzeug ist, das ihm bei seiner eigentlichen Arbeit helfen soll. Als Programmierer ist man ja gerne "verspielt", aber genau da beginnen die Probleme beim Kunden

 

[Jaiel]

Danke schonmal für eure Teilnahme das bedeutet mir sehr viel das ihr Euch die Mühe gemacht habe, alle Achtung.

erstmal Respekt das du noch da bist =)

Ich bin gekommen um zu bleiben

Agile Methoden finde ich interressant habe neulich erst gelesen dass segr viele firmen die Methoden benutzen.

@zumafx dein Werdegang ist beeindruckend und genau so die Tatsache das du dich "trotz deines alters" einem so spannenden und eigentlich stressigen Hobby nachgehst

Schweinebesamung

hahahaha ich kann nciht mehr und das du das so einfach nebenbei einwirfst macht es noch lustiger

 

[zumafx]

hahahaha ich kann nciht mehr und das du das so einfach nebenbei einwirfst macht es noch lustiger

Das war auch mein echt witzigstes Projekt ever
Anruf von Kunden (Frau am Apparat): Hallo, können Sie mal gucken kommen, der Samen ist gaaanz schlecht heute
Oder (wieder sie): Ich hatte heute sehr viele Besamungen und dann ist der PC abgestürzt
Da fällt dir erstmal der Hörer aus der Hand

Stressig finde ich die Androidprogrammierung überhaupt nicht
Ich kann ja machen, was wann und wie ich will

Im Job hast du ständig Zeitdruck, wirst nie wirklich fertig und musst lauter Dinge machen,
die du schon viel zu routiniert machst, als das da noch viel Spass bei aufkommt ... .
Da gilt das Motto: Soll's perfekt werden oder willste Geld verdienen
In der freien Wirtschaft schließt sich das meist gegenseitig aus, da reicht dann auch "einigermaßen dicht dran",
denn bis eine größere Software perfekt fertig ist, ist sie schon wieder veraltet

 

[deek]

Hi,

ich bin Master of Science in Informatik (ganz klassich und pur, nicht Wirtschaft, Bio oder wasweißich ) und inzwischen seit guten 3 Jahren im Job. Die ersten 2 Jahre als Java-Entwickler in einem sehr geilen Team mit aktuellen Entwicklungsmethoden (Scrum, Continuous Integration, aktuelle Frameworks, nicht zu dogmatischen Test Driven Development, etc...). Das war super. Dort habe ich dann auch nach einem Jahr App-Entwicklung in einem neuen Projekt gemacht und einen App Baukasten ziemlich komplett alleine aus dem Boden gestampft. Das war sehr cool, weil ich für den Android Bereich im Prinzip komplett allein verantwortlich war. (trotz meiner wenigen Berufserfahrung).
Leider ging das wegen drohender Insovlenz auseinander, dann bin ich temporär für 11 Monate in einer Firma gelandet die in vielen Dingen das komplette Gegenteil war. Zwar auch super Kollegen, das muss man sagen. Aber festgefahrene Prozesse, ein diktatorischer, cholerischer Chef, Quasi ein nicht existenter Entwicklungsprozess (wir haben dass dann in Eigenregie versucht auf was Scrum-ähnliches zu mappen) und ständig wechselnde Vorgaben und Anordnungen.
Dort habe ich hauptsächlich JavaScript gemacht und es war geplant eine Multi-Plattform App zu erstellen, das wurde so aber nix.
Bei meiner aktuellen Firma bin ich wieder komplett auf der Java Serverseite unterwegs. Teilweise etwas altbackene Prozesse und Frameworks, (die Firma ist über 30 Jahre alt, unser Produkt fast 10) aber es wird sich extrem bemüht auf die Mitarbeiter zu hören und da Dinge umzustellen. Das geht in einem stehenden Produkt halt auch nicht von heute auf morgen. Super Team und man darf auch ein paar eigenverantwortliche Etnscheidungen treffen.
Hier habe ich auch einiges mehr an Kundenkontakt als bisher, was manchmal stressig ist, aber einen auch nochmal näher an den Kunden, der das Produkt benutzt, ranbringt.

Android Entwicklung mache ich aktuell nur noch privat bzw. nebenberuflich. (Kleingewerbe)
Das hat den Vorteil, dass man machen kann was einem Spaß macht und den Nachteil, dass man für die 1000 offenen Projekte zu wenig Zeit hat
Ich habe da ein paar Sachen in der Pipeline, die im Prinzip zu 70-80% releasefertig wären, aber der Feinschliff fehlt immer noch. Das ist das Problem bei der privaten Entwicklung, so Sachen wie ordentlich Einstellungen, die richtigen Texte und Übersetzungen bleiben am Ende halt hängen, wenn die App für einen selbst läuft.


Scrum finde ich als Prozess schon ganz gut, sofern man es wirklich schafft, die verschiedenen Rollen gut zu besetzen. Mit einem ordentlichen Product Owner und einem guten Scrum Master kann man damit wirklich schnell qualitativ gute Software zaubern, weil bei der Planung einzelner Features das ganze Team involviert ist.

Aktuelle Frameworks zu verwenden macht Unit Testing um einiges einfacher, wenn man sich beispielsweise schnell Mock-Objekte injizieren lassen kann, statt der konkreten Implementierungen.

Für den Projektanfang ist es immer gut jemanden zu haben, der das große Ganze im Blick hat (Product Owner) und weiß wie was zu priorisieren ist. Außerdem ist jemand mit Architekturerfahrung extrem wichtig imho. Ansonsten krankt es gleich schon an der Struktur des Programms. (Das ist übrigens das, was meiner Meinung nach den Anfängern und "Quereinsteigern" fehlt. Programmieren lernen ist eine Sache, aber Software-Architektur eine ganz andere)
Inzwischen (nach 5 Jahren Info-Studium und 3 Jahren Erfahrung in verschiedenen Projekten/Umfeldern) würde ich sagen, könnte ich eine kleine bis mittelgroße Anwendung architektonisch unter meine Fittiche nehmen, für große Anwendungen fehlt mir noch die Erfahrung.
Architektur heißt für mich zum Einen der Aufbau und die Struktur des Codes, der Module etc. aber zum Anderen auch die Entscheidung der zu verwendenden Techonlogien. Welche Frameworks verwende ich hierfür, welche besser nicht. Wie sieht es in Zukunft aus, was verbaue ich mir, wenn ich es so oder so mache....

Tipp für Anfänger:
Klein anfangen. Es ist schön wenn man die Mega App oder ein super umfangreiches Spiel im Kopf hat... Aber als Einsteiger in der Software Entwicklung wird man a) kläglich scheitern und aufgeben, b) sich laaaange durchkämpfen und immer wieder Fehlentscheidungen revidieren und umbauen oder c) was abliefern was bei der kleinsten Berührung mit Kunden/Usern zusammenbricht.

So langer Text... aber ich weiß ja das mindestens Jaiel alles liest

 

[Jaiel]

Das war ein wirklich sehr interessanter Einblick...Schade dass es mit deiner ersten Stelle nicht so gut lief wegen der Insolvenz sache...Es scheint wohl wirklich so das die meisten Firmen von Projekt zu Projekt leben...

 

[zumafx]

Ich hab auch ganz ähnliche Erfahrung im Laufe meines Berufslebens gemacht wie deek.
Besonders unterstreiche ich seine Aussagen zu Programmieren und Softwarearchitektur.
Ich habe damals (da wurde man noch viel genereller ausgebildet, von Hardware über
Netzwerk und Programmieren bis eben hin zur Softwareentwicklung) u.a. Softwareentwickler gelernt.
Wochenlang wurde man mit trockenster Theorie belabert, aber im Nachhinein kann ich nur
sagen, das war sehr wertvoll für mein späteres leben als Softwareentwickler.
Und es besteht ein riesiger Unterschied zwischen Softwareentwickler und Programmierer, definitiv.
Der Programmierer ist sozusagen nur die Tippse des Entwicklers (überspitzt gesagt). Damals war man
noch eher der "Generalist", die heutige schulische Unterteilung in die diversen Bereiche der EDV hat
zwar den Vorteil, das es viele Experten auf den jeweiligen Gebieten gibt, aber eben auch den Nachteil, das nur
wenige von Anfang an große Projekte stemmen können, da ihnen einfach in einigen Bereichen der fachliche
Hintergrund für den berühmten Blick über den Tellerrand fehlt.
Ich würde auch sagen, nachdem man seine ersten Erfahrungen gemacht hat, 1-2 Programmiersprachen beherrscht,
ist es nicht das schlechteste, sich mal ein Buch über die Softwareentwicklung generell zuzulegen.

@deek:
freu dich, das du so verschiedene Erfahrungen sammeln kannst, das wird dir noch zu gute kommen, glaub mir
Projekte, in denen man nicht "mal eben" alles umstrukturieren kann, gibt's gerade in erfolgreicheren Firmen öfter.
Allein schon die Größe des Sourcecode's macht das oft nahezu unmöglich. Mein letztes Projekt hatte etwas
über 700.000 Zeilen Sourcecode. Da erschlägt einen schon allein die Masse

 

[deek]

sagen, das war sehr wertvoll für mein späteres leben als Softwareentwickler.
Und es besteht ein riesiger Unterschied zwischen Softwareentwickler und Programmierer, definitiv.

Jop. Ich mag auch den englischen Begriff des Software Engineer sehr. Ich finde Engineer trifft es irgendwie. Ich erschaffe was, ich plane was...

@deek:
freu dich, das du so verschiedene Erfahrungen sammeln kannst, das wird dir noch zu gute kommen, glaub mir

Ja, gerade durch das letzte Jahr weiß ich auch meinen aktuellen Job und meinen ersten Job sehr viel mehr zu schätzen! Gut, wenn man mal sieht, dass es nicht überall so geil zugeht. (und ich bin glücklicher obwohl ich aktuell erstmal bei weitem weniger verdiene als letztes Jahr)

 

[zumafx]

und ich bin glücklicher obwohl ich aktuell erstmal bei weitem weniger verdiene als letztes Jahr)

Geld ist nicht alles
Natürlich sollte man davon leben können und nicht jeden Cent 2x umdrehen müssen, aber was nutzt die dicke Kohle,
wenn man schon gefrustet zur Arbeit geht und wenn man da ist, nur denkt, wann kann ich endlich wieder weg hier ?
Gerade bei so einem kreativen Job ist es imho sehr wichtig, das man mit Spass dabei ist.
Wer nur des Geldes wegen zur Arbeit geht, darf sich nicht wundern, wenn er
relativ schnell ein Burnout oder auch nur "die Schnauze voll" hat
Ich bin heute noch stolz auf einige Programme, die aus meiner Hand stammen und zumindest bei einem
bin ich mir absolut sicher, das es mich überleben wird.
Kein schlechtes Gefühl und kann auch nicht jeder von sich sagen

 

[RED-BARON]

Hi,
(Das ist übrigens das, was meiner Meinung nach den Anfängern und "Quereinsteigern" fehlt. Programmieren lernen ist eine Sache, aber Software-Architektur eine ganz andere)

 

[Jaiel]

Hört hört...Mal ne Analogie : es ist nicht schwer zu lerne wie man legoblöcke aneinander baut aber wie und auf welche Weise man damit komplexere Strukturen erbaut ist eine andere Hausnummer