Allgemein: Agile Softwareentwicklung
Warning: preg_match(): Compilation failed: group name must start with a non-digit at offset 8 in /www/htdocs/w0102873/mediawiki/includes/MagicWord.php on line 739
Aus It2010-g1
(→Verwaltung des Projekts, Story Cards, Planung, Prioritäten) |
Admin (Diskussion | Beiträge) K (26 Versionen: Eine alte Version der Wiki ist hier her gezogen (1)) |
||
Zeile 6: | Zeile 6: | ||
==Festlegung von Programmiersprachen, Daten- und Klassenstrukturen== | ==Festlegung von Programmiersprachen, Daten- und Klassenstrukturen== | ||
− | Ganz zu Beginn eines Softwareprojektes sollten selbstverständlich die Programmiersprache oder bei Bedarf auch mehrere Programmiersprachen festgelegt werden, in der das Projekt implementiert werden soll. Dabei spielt die größte Rolle, welche Sprache sich am besten für die Aufgabe eignet, aber auch, welche von den Programmierern am besten beherrscht wird. Gegebenenfalls müssen Schulungen für die | + | Ganz zu Beginn eines Softwareprojektes sollten selbstverständlich die Programmiersprache oder bei Bedarf auch mehrere Programmiersprachen festgelegt werden, in der das Projekt implementiert werden soll. Dabei spielt die größte Rolle, welche Sprache sich am besten für die Aufgabe eignet, aber auch, welche von den Programmierern am besten beherrscht wird. Gegebenenfalls müssen Schulungen für die Programmierer eingeplant werden. Wenn die Sprache festgelegt ist, muss man eine geeignete Daten- und Klassenstruktur festlegen. Dabei muss ein Kompromiss zwischen Redundanz und Geschwindigkeit gefunden werden. Das heißt, dass unter Umständen einige Dateien an verschiedenen Orten gespeichert werden müssen, um einen schnellen parallelen Zugriff von unterschiedlichen Orten zu garantieren. |
==Code Conventions== | ==Code Conventions== | ||
Ebenfalls vor Beginn sollten gewisse Standards für das Schreiben von Code festgelegt werden. Es bietet sich an, dafür allgemein bekannte / übliche Standards zu verwenden, da diese in der Regel intuitiv anwendbar sind, oftmals sind diese den Programmierern auch bereits bekannt. <br> | Ebenfalls vor Beginn sollten gewisse Standards für das Schreiben von Code festgelegt werden. Es bietet sich an, dafür allgemein bekannte / übliche Standards zu verwenden, da diese in der Regel intuitiv anwendbar sind, oftmals sind diese den Programmierern auch bereits bekannt. <br> | ||
− | Code Conventions dienen dazu, den Code übersichtlich, gut | + | Code Conventions dienen dazu, den Code übersichtlich, gut lesbar und leicht anpassbar zu machen.<br> |
Es wird dabei die Art der Einrückung, die Klammersetzung, die Namensgebung usw. beschrieben. Auch werden hier die Standards zur Kommentierung des Codes festgehalten.<br> | Es wird dabei die Art der Einrückung, die Klammersetzung, die Namensgebung usw. beschrieben. Auch werden hier die Standards zur Kommentierung des Codes festgehalten.<br> | ||
[http://de.wikipedia.org/wiki/Code_Convention mehr auf wikipedia (en)] | [http://de.wikipedia.org/wiki/Code_Convention mehr auf wikipedia (en)] | ||
Zeile 22: | Zeile 22: | ||
*ID (nützlich für die Programmier-Dokumentation) | *ID (nützlich für die Programmier-Dokumentation) | ||
*Datum der Erstellung | *Datum der Erstellung | ||
− | *Autor der Story Card (nützlich | + | *Autor der Story Card (nützlich bei Fragen) |
*Beschreibung | *Beschreibung | ||
*Geschätzter Aufwand | *Geschätzter Aufwand | ||
*Entwickler | *Entwickler | ||
− | *Priorität (eine Zahl | + | *Priorität (beispielsweise eine Zahl zwischen 1 und 3) |
− | Folgende Informationen | + | Folgende Informationen beinhaltet die Karte zur Nachvollziehbarkeit, ob die Schätzungen der Planung eingehalten werden konnten, um für spätere Aufgaben und zukünftige Projekte diese Planungen und eigenen Schätzungen optimieren zu können: |
− | * | + | *Tatsächlicher Aufwand (wird erst nach der Erledigung der Aufgabe ausgefüllt) |
− | *Datum der Erledigung ( | + | *Datum der Erledigung (wird erst nach der Erledigung der Aufgabe ausgefüllt) |
− | *Kundenzufriedenheit ( | + | *Kundenzufriedenheit (wird erst nach der Erledigung der Aufgabe ausgefüllt) |
*Status ("wartend", "in Arbeit" oder "fertig") | *Status ("wartend", "in Arbeit" oder "fertig") | ||
[http://en.wikipedia.org/wiki/User_story mehr siehe '''"User story"''' auf wikipedia (en)]<br> | [http://en.wikipedia.org/wiki/User_story mehr siehe '''"User story"''' auf wikipedia (en)]<br> | ||
Zeile 36: | Zeile 36: | ||
===Daily Stand-Up Meeting=== | ===Daily Stand-Up Meeting=== | ||
− | Wie der Name schon vermuten lässt, | + | Wie der Name schon vermuten lässt, wird dieses Meeting jeden Tag, in der Regel auch gleich zu Arbeitsbeginn, abgehalten. "Stand-Up" impliziert, dass es nach Möglichkeit auch im Stehen durchführt wird, da es nicht länger als 5 bis 10 Minuten dauern sollte.<br> |
− | Hierbei treffen sich alle Programmierer | + | Hierbei treffen sich alle Programmierer, möglicherweise auch weitere [http://de.wikipedia.org/wiki/Stakeholder Stakeholder], und beantworten (zumindest die Programmierer) jeweils die folgenden drei Fragen: |
− | *Was habe ich bis jetzt getan? | + | *Was habe ich bis jetzt getan? (seit dem letzten Stand-Up Meeting) |
− | *Welche Probleme | + | *Welche Probleme traten auf? |
− | *Was werde ich jetzt | + | *Was werde ich jetzt tun? |
− | In dem Meeting werden jedoch keine Diskusionen | + | In dem Meeting werden jedoch keine Diskusionen geführt! Diese können später besprochen werden, hier soll lediglich eine Bestandsaufnahme erfolgen.<br> |
[http://en.wikipedia.org/wiki/Stand-up_meeting mehr auf wikipedia] | [http://en.wikipedia.org/wiki/Stand-up_meeting mehr auf wikipedia] | ||
==Teamarbeit, Kommunikation== | ==Teamarbeit, Kommunikation== | ||
===Kommunikation=== | ===Kommunikation=== | ||
− | Programmierer, | + | Programmierer, die gemeinsam an einem Projektes arbeiten, sollten auch zusammen in einem Büro sitzen, um immer schnell und effektiv miteinander kommunizieren zu können. Mitarbeiter und Programmierer, die nicht in das Projekt involviert sind, sollten dagegen nach Möglichkeit räumlich getrennt untergebracht werden, um unnötige Störquellen und Ablenkung zu vermeiden. |
− | === | + | |
− | + | ===Versionskontrolle=== | |
− | Bei | + | Eine Versionskontrolle wie [http://de.wikipedia.org/wiki/Apache_Subversion Subversion], oder [http://de.wikipedia.org/wiki/Git Git] sollte in jedem Softwareprojekt genutzt werden.<br> |
− | + | Bei dieser liegt der Quelltext (oder auch andere Dateien) als eine Sammlung von Änderungen auf einem Server. Jeder Programmierer lädt sich den Quelltext von dort herunter und kann diesen anschließend lokal auf seinem Rechner bearbeiten. Ist Projekt nach Fertigstellung der Implementierung noch lauffähig, so lädt er seine Änderungen wieder auf den Server hoch.<br> | |
+ | Damit hat jeder Programmierer immer den aktuellen Code, ohne dass alle direkt auf dem Server arbeiten müssen.<br> | ||
[http://de.wikipedia.org/wiki/Versionsverwaltung mehr auf wikipedia] | [http://de.wikipedia.org/wiki/Versionsverwaltung mehr auf wikipedia] | ||
==Pair Programming== | ==Pair Programming== | ||
− | + | Beim Pair Programming programmieren zwei (höchstens drei) Programmierer gemeinsam an einem Computer. Dabei tippt einer den Code und der andere sieht Ersterem über die Schulter und steht diesem beratend zur Seite. So kann man sich schneller absprechen, Ideen aufgreifen und Fehler im Keim erkennen und beseitigen.<br> | |
− | Auch wenn diese | + | Auch wenn diese Methode sehr ungewöhnlich klingt, so hat sie sich in der Praxis als äußerst effektiv bewiesen.<br> |
[http://de.wikipedia.org/wiki/Pair_Programming mehr auf wikipedia] | [http://de.wikipedia.org/wiki/Pair_Programming mehr auf wikipedia] | ||
==Testen== | ==Testen== | ||
− | Für das Testen einer Software ist | + | Für das Testen einer Software ist normalerweise die Qualitätssicherung zuständig, aber auch Programmierer kommen nicht um diesen wichtigen Baustein herum.<br> |
− | Die meisten Programmierer testen ihren implementierten Code während der Entstehung. Zusätzlich sollte | + | Die meisten Programmierer testen ihren implementierten Code bereits während der Entstehung. Zusätzlich sollte aber nach Möglichkeit zu jeder implementierten Methode auch ein automatisierter Test, ein sogenannter [http://de.wikipedia.org/wiki/Unit-Test Unit-Test] geschrieben werden. Damit sollen immer alle erdenklichen Fehlerquellen getestet werden, ohne unnötig viel Zeit verschwenden zu müssen. Eine Liste verschiedener Unit-Tests für verschiedene Sprachen findet man [http://de.wikipedia.org/wiki/Liste_von_Modultest-Software hier]. |