Literatur-Tipps zum Thema Software-Entwicklung gesucht

Die Recherche nach passender Literatur sollten studierte Leute bzw. 
Studenten an Universitäten eigentlich selbst leisten können. (Das wurde 
uns im Studium sinngemäß von den Profs so gesagt.)

Peter123 schrieb:
> Die Recherche nach passender Literatur sollten studierte Leute
> bzw. Studenten an Universitäten eigentlich selbst leisten können. (Das wurde
> uns im Studium sinngemäß von den Profs so gesagt.)

Sehe ich auch so. Deswegen habe ich ja schon Recherche betrieben. Habe 
nun mit einem Fernstudium in Informatik begonnen, den Scrum-Master 
gemacht (weil ja überall nur noch von Sprints die Rede ist..) und eigne 
mir Sachen bisher über verschiedene Medien bei Bedarf an. Ich hatte mir 
erhofft, dass sich hier auch andere weiterbilden und gute Tipps haben.

Einen Tipp kann ich dir aber doch geben:

Ist quasi ein Standardwerk mit vielen Auflagen:

- Ian Sommerville, Software Engineering

Einfach mal den Titel in der Amazon Suche eingeben

@Peter123 & Walter T.
Danke! Werde ich mir mal genauer anschauen.

In einem Informatikstudium ist Softwareentwicklung eigentlich nur (wenn 
überhaupt) ein Randthema. Das meiste ist einfach nur knallharte 
Mathematik. GUIs und Sprints interessieren da auch niemanden. Es geht um 
Algorithmen, Beweise und Mathematik. Das wird dir also für die Praxis 
nicht viel bringen.

@Test (Gast)
Ja, dem bin ich mir bewusst. Ich bin derzeit als Akademie-Student an der 
Fernuni-Hagen eingeschrieben. Gerade lerne ich Software Engineering 
(sehr UML lastig), was ich interessant finde. Mit dem Thema Datenbanken 
hatte ich beruflich Berührungspunkte und werde ich das kommende Semester 
auch belegen.

Programmierkenntnisse habe ich in Maßen, weil ich beruflich ab und zu 
kleinere Anwendungen schreibe (Daten abgleichen, Texte verarbeiten). Ob 
ich mir wirklich ein komplettes Studium antue, weiß ich noch nicht. 
Mathe hatte ich schon im Maschinenbau-Studium genug und braucht man als 
Projektleiter realistisch gesehen nicht. Mir geht es eher darum, mir das 
Vokabular anzueignen.

Als Projektleiter im Maschinenbau sind die Tätigkeiten (meine Vermutung) 
ähnlich wie in der Software-Entwicklung:
- Anforderungen richtig erfassen (nicht das machen, was der Kunde einem 
vorgibt, sondern das machen, was den Kunden am Ende wirklich zufrieden 
stellt)
- Arbeitspakete planen und Abhängigkeiten der Pakete auf dem Schirm 
haben
- Arbeitspakete gut vorbereiten, dass man für die Abarbeitung nicht 
zwingend das beste Pferd im Stell einsetzen muss
- Die Änderungswünsche der Kunden aus den Besprechungen bewerten und 
koordiniert ins Team streuen
- Schauen, wer aus dem Team dafür geeignet (und verfügbar ist). Sprich: 
Macht's der Senior oder kann ich darauf auch mal einen Einsteiger 
loslassen, weil da nichts anbrennt.
- Wenn ein Arbeitspaket nicht nach Plan läuft, darauf verstärkt den 
Fokus legen
- Zeitabschätzungen & Kompetenzen der Mitarbeiter hinterfragen (ich hab 
manchmal Berufseinsteiger, die bessere Leistung liefern als manch ein 
geduldeter "Erfahrener")
- Schauen, dass kein unkontrolliertes Produkt an den Kunden geht
- und das Finanzielle wie Stunden haken, Projekt ausplanen, 
Lenkungsausschüsse, Rechnungen stellen, Chef beruhigen, dass man alles 
im Griff hat etc.

Mir fehlt ein bisschen der Abgleich, ob der Arbeitsalltag so viel anders 
ist als jetzt im Maschinenbau. Am schwierigsten stelle ich es mir 
derzeit vor, die Kompetenz von anderen Mitarbeitern richtig 
einzuschätzen, da mir die Kompetenz dafür fehlt.

Ja in Zukunft noch mehr, wenn nicht schon heute, wird die IT das Zentrum 
sein.. Hypewort"Digitalisierung"...
Klar klassisches Engineering bzw Leute die es verstehen, wird man immer 
noch benötigen. Aber auch da, wird vieles automatisiert werden... Von 
IT..

@Einfach unverbesserlich (Gast)
Ja, leider.. ich war bisher stets bemüht, nicht das typische Ende von 
Peterchen zu erleiden.. Wie Klaus schreibt, schreitet die 
Digitalisierung immer mehr voran, auch im Maschinenbau. Ich hab ab und 
zu Studenten, die für mich Sachen programmieren und Chefs, die nicht 
einsehen, dass diese auch von kompetenten Fachleuten betreut werden 
müssen. Am Ende muss ich als Laie selbst drüber schauen, warum irgendwas 
nicht funktioniert oder das Programm anpassen, wenn der Student wieder 
weg ist. Oder ich soll in Vorstellungsgesprächen beurteilen, ob der 
Werkstudent kompetent genug für den Job ist.

Bisher agiere ich nur anhand von "gesundem Menschenverstand" wie 
Variablen sinnvoll benennen, Versionierungen einführen, modularer Aufbau 
der Programme  Wiederverwendung von Modulen  Testen von Extremfällen 
etc.
Ich merke bei meinem AG, dass man aus Mangel an guten IT-Projektleitern 
irgendwelche Entwickler nimmt, die die Anforderungen an die Software 
nicht verstehen, keine sinnvollen Prioritäten setzen und teilweise 
unnütze Software ausrollen (die dann den üblichen Tod stirbt, weils 
keiner benutzt).

Ich persönlich halte ja wenig von deutschen Büchern in dem Bereich, weil 
die Musik einfach in den USA spielt und deutsche Autoren den 
Entwicklungen nur hinterherlaufen und von amerikanischen Standardwerken 
abschreiben. Zudem liest sich das häufig so spannend wie 
Steuerparagraphen.

Mythical Man Month wurde ja schon genannt.

Der Termin ist ein sehr gutes Buch über Projektmanagement, als 
kurzweiliger Roman verpackt.

Peopleware ist der Klassiker zum Umgang mit den Entwicklern.

Wenn's praktischer sein soll auch Clean Architecture. Einfach, damit man 
weiss, dass es sowas wie Software Architektur überhaupt gibt und die 
Entwickler nicht alles nur schnell zusammen hacken sollen.

@Tobias B.
Der edx-Kurs klingt sehr gut! Danke!
Vom Phoenix- Buch hatte ich bisher nur eine kindle Leseprobe. Dort gings 
um die Beförderung vom Protagonisten, weniger um technische Details. 
Ändert sich das im Laufe des Buchs?

@Dipl. Inf
Danke für die Buchtipps! Bisher lese ich sehr "pragmatische" Bücher und 
schau mir ab und zu Youtube-Videos dazu an, aber Romane sind zur 
Auflockerung auch gut.

Mir ist bewusst, dass in der IT Englisch noch wichtiger ist als im 
Maschinenbau. Für den Scrum Master habe ich mit dem Original Scrum-Guide 
gelernt, weil mir der Umweg über die deutsche Übersetzung auch zu 
umständlich vorkam. Bin aber auch nicht abgeneigt, wenn es gute deutsche 
Literatur gibt. Liest sich schneller und ich bin nicht so mit der 
Interpretation von manchen Begriffen beschäftigt.

Dipl. Inf (FH) schrieb:
> Ich persönlich halte ja wenig von deutschen Büchern in dem Bereich, weil
> die Musik einfach in den USA spielt und deutsche Autoren den
> Entwicklungen nur hinterherlaufen und von amerikanischen Standardwerken
> abschreiben.

Dann könnte man auch chinesische Literatur empfehlen.

Dipl. Inf (FH) schrieb:
> Zudem liest sich das häufig so spannend wie Steuerparagraphen.

Das ist mein Hauptargument für amerikanische Literatur und Vorlesungen. 
Es wird so einleuchtend erläutert, dass es im Prinzip jeder direkt 
versteht. Zitat eines Professors: Ich habe Elektrotechnik nicht während 
des Studiums verstanden, nicht während meiner Promotion, nicht in meiner 
10 jährigen Industrietätigkeit, sondern richtig tiefgreifend erst seit 
dem ich Professor bin. Ein Teilgrund dafür ist meiner Meinung nach, dass 
die deutschen Lehrbücher ähnlich formuliert sind wie das deutsche 
Steuerrecht.

Samenstau im Maschinenbau schrieb im Beitrag #5935860:
> Das Softwareteam streitet sich immer mit dem Elektronikteam.
> Aber beide können sich darauf einigen, dass die Maschinenbauer gegenüber
> die wahren Deppen sind.

Kindergarten!

Tobias B. schrieb:
> Allerdings ist die englische Originalfassung wirklich in verstaendlichem
> Englisch geschrieben, das koennte laessig als Schullektuere durchgehen.

Das ist meistens so.

Also ehrlich! Ihr seid wieder einmal so über alle Maßen überheblich und 
teilweise beleidigend! Muß das wirklich so sein? Mit Euch würde ich, 
wenn Ihr Euch im Betrieb auch so benehmt, nicht arbeiten wollen. Auch 
Maschinenbauer sind Menschen:-)

Der TO hat aus seiner Sicht bestimmt guten Grund zu seiner Frage und es 
ist sein Privileg und Angelegenheit. Wenn ihr was dagegen habt, dann 
bleibt doch einfach still. Man ist auch in einem Forum nicht zu einer 
Entgegnung gezwungen.

@Ron Jeremy
Vermutlich Mangel an Alternativen. Die ITler & Consultants bei meinem AG 
verstehen die komplexen Anwendungsfälle nicht. Befriedigen ihre Tickets 
und ignorieren User-Rückmeldungen, so lang der Chef oder Kunde die Tools 
"cool" findet. Die merken erst Jahre später, dass es ein Millionengrab 
ist, weils keiner nutzt. Dann kommen sie wieder zu mir, weil ich ihnen 
das von Anfang an so prognostiziert habe & andere Ideen hatte. Bin 
vielleicht IT-technisch ein Noob, aber zumindest das Buttons nicht nur 
schön aussehen müssen, weiß ich.

Ich würde sagen, die Kunst als Projektleiter besteht darin die Leute mit 
ihren Fähigkeiten richtig einzuschätzen und die richtigen Leute 
zusammenzubringen.

Tobias B. schrieb:
> Peter123 schrieb:
>> Ich würde sagen, die Kunst als Projektleiter besteht darin die Leute mit
>> ihren Fähigkeiten richtig einzuschätzen und die richtigen Leute
>> zusammenzubringen.
>
> Full ACK. Leider braucht man selbst entsprechende Expertise und die
> Expertise anderer einzuschaetzen. Interessant dazu auch foglender Wiki
> Artikel:
>
> 
https://de.wikipedia.org/wiki/Anti-Pattern#Organisations-,_Management-_bzw._Prozess-Anti-Pattern
>
> Ich wuerde daher sogar noch eine Stufe runtergehen und behaupten, ein
> guter Projektleiter vertraut auf die Expertise seiner Experten.

Sehr interessanter Artikel. Vielen Dank für den Link!

@Tobias B.
Das klingt gut! Kommt auf meine Liste, wenn ich mal ein wenig was 
Entspanntes zwischendrin lesen will. Von der Story her war die Leseprobe 
unterhaltsam. Wobei ich auch genug Storys von meinem AG schreiben 
könnte.. Hatte in letzter Zeit viel mit der Management-Ebene zu tun. Da 
wundere ich mich oft, wie manche Leute an so eine hohe Stelle kommen 
konnten.

Der Link ist echt genial. Gilt nicht nur für den IT-Bereich.
Mir wurde zu dem Thema ein gutes Video von Fefe empfohlen:
https://www.youtube.com/watch?v=E0_Y53ci9cw

@Peter
Ich habe mir angewöhnt, sehr misstrauisch zu sein. Jeder macht Fehler 
und unter Stress versemmeln die besten Leute was. Wenn man das als Team 
abfängt und immer ein bisschen für den anderen mitdenkt, ist jedem 
geholfen. Was ich blöd finde, wenn man sich im Projekt den schwarzen 
Peter zu schiebt. Sprich, Leute, die nichts können (obwohl sie ggf. 
viele Jahre diese Stelle besetzen) und der Chef hofft, ein Projekt zu 
finden, wo derjenige nicht so viel Schaden anrichtet.

Quereinsteiger schrieb:
> @Peter
> Ich habe mir angewöhnt, sehr misstrauisch zu sein. Jeder macht Fehler
> und unter Stress versemmeln die besten Leute was. Wenn man das als Team
> abfängt und immer ein bisschen für den anderen mitdenkt, ist jedem
> geholfen. Was ich blöd finde, wenn man sich im Projekt den schwarzen
> Peter zu schiebt. Sprich, Leute, die nichts können (obwohl sie ggf.
> viele Jahre diese Stelle besetzen) und der Chef hofft, ein Projekt zu
> finden, wo derjenige nicht so viel Schaden anrichtet.

Mag ja alles wahr sein. Aber das hängt auch von der Größe und Struktur 
Eurer Organisation (Firma) ab, ob der Projektleiter (der Chef) im 
operativen Geschäft (bei der Softwareentwicklung) noch direkt mitmischen 
sollte oder nicht. Weil ich die ja nicht kenne, kann ich auch dazu keine 
Aussagen machen.

Es ist nämlich ein großer Unterschied, ob du als Projektleiter z.B. 10 
Mitarbeiter/Softwareentwickler oder 100 Mitarbeiter/Softwareentwickler 
leitest. Bei 10 Mitarbeitern wirst du eher noch die Zeit haben, bei der 
Erstellung einer Softwarelösung mitzuarbeiten. Aber ich denke bei 100 
Mitarbeitern, aufgeteilt in verschiedene Projektgruppen, wird es schon 
schwierig.

Hi Peter,
sind je nach Projektphase 5-15 Leute.

Peter123 schrieb:
> Bei 10 Mitarbeitern wirst du eher noch die Zeit haben, bei der
> Erstellung einer Softwarelösung mitzuarbeiten.

Selbst bei 10 Leuten ist der SW Projektleiter normalerweise wegen 
Meetings, Freigaben, Releaseplanung und Koordination so zu, dass er 
bestenfalls mal über die SW schauen kann, aber nicht mehr selbst 
programmieren.

Ausnahme: Sein Team besteht aus Frischlingen, die es nicht gebacken 
bekommen.