Re: [Tasktlogger-devel] =?iso-8859-1?q?Input_Realisierungsans=E4tze?= =?iso-8859-1?q?=2C_Architektur?=

[Teiniker E. <Ego...@fh...>]

Hallo miteinander,

ich habe die Diskussion mit Interesse verfolgt und m=F6chte dazu =
folgendes sagen:

o) Ich bin immer begeistert, wenn Vorschl=E4ge von Studenten kommen und =
wir dar=FCber diskutieren k=F6nnen - ich denke das ist ja der Sinn der =
Veranstaltung. Also sagen Sie bitte Ihre Meinungen!

o) F=FCr die Planung des Projekts ist es in jedem Fall notwendig, die =
User-Stories zu analysieren und in Tasks aufzuteilen. Wenn Sie das bis =
zum Ende der Woche machen, k=F6nnten wir am Sa noch diverse =
Priorit=E4ten setzen und Probleme beseitigen.=20

o) F=FCr die Organisation der Teams (konkret f=FCr die Zuordnung Taks zu =
Teams) gibt es zumindest zwei Ans=E4tze:
    (1) Technologie orientierte Teams (Web Team, DB Team, BL Team, etc. =
wie es Herr Walter vorschl=E4gt)
    (2) User-Story orientierte Teams (mein Vorschlag siehe =
Iteration1-Organisation)
  =20
Da Software Engineering keine exakte Wissenschaft ;-), und auch stark =
von der jeweiligen Anwendungsdom=E4ne abh=E4ngig ist, gibt es =
prinzipiell keinen absolut richtigen Weg!

Ich m=F6chte aber kurz argumentieren, warum ich Ansatz (2) gew=E4hlt =
habe:

o) Das Wichtigste an einem Projekt ist, dass der Kunde zufrieden ist.=20
   Daher haben die Kunden-Anforderungen (User-Stories) absolute =
Priorit=E4t. =20
   Die Wahl der Architektur richtet sich nach den Anforderungen des =
Kunden (mit welcher Architektur kann ich die Anforderungen gut =
umsetzen).

o) Es ist selten, dass sich die Architektur innerhalb eines Projektes =
=E4ndert (die Erfahrung zeigt, dass Architekturen innerhalb einer =
Dom=E4ne meist einige Projekte =FCberdauern).=20
   F=FCr gr=F6=DFere Projekte gibt es oft ein eigenes Architektur-Team, =
das sich mit der Implementierung und Weiterentwicklung der Architektur =
besch=E4ftigt.=20
   Zu einer Architektur geh=F6ren auch entsprechende Vorgehensweisen =
(Regeln f=FCr die Applikationsprogrammierer) zB: wie wird auf die DB =
zugegriffen, wie werden User-Requests verarbeitet, etc. Man kann daher =
davon ausgehen, dass die Applikationsprogrammierer (nach einer =
Lernphase) mit der Architektur vertraut sind, und wissen wie sie zB: ein =
DAO implementieren (oder aus einem Modell generierten) k=F6nnen.=20

o) Es mu=DF auch zwischen Design und Implementierung unterschieden =
werden.=20
Das grobe Design betrifft immer alle Teams, und mu=DF gemeinsam =
erarbeitet werden (das sollte das Integrationsteam koordinieren).=20
Kleine =C4nderungen (zB: ein Attribut in der Category Klasse =
hinzuf=FCgen) und Refactorings sind den Entwicklern =FCberlassen, die ja =
alle auf einem gemeinsamen Source-Stand arbeiten (dank Subversion).

Daraus folgt:
   =3D> Architektur- und Grob-Design erfolgen eher am Beginn eines =
Projets und =E4ndern sich meist nur geringf=FCgig.=20
      Diese Kommunikation kann etwas "teurer" sein, d.h. die Teams reden =
untereinander (es sind dann meist auch alle Teams betroffen).
      In diesem Zusammenhang kommt auch die Rolle eines =
Software-Architekten ins Spiel (das w=E4r doch was f=FCr's =
Integrationsteam).

   =3D> Die User-Stories kommen vom Kunden und =E4ndern sich oft nach =
jeder Iteration.=20
      Daher ist es sinnvoll, die Kommunikation f=FCr eine User-Story =
"billig" zu machen, d.h. es reden die Entwickler eines Teams =
miteinander.=20

   =3D> Auch Bugfixes, die sich aus Kundensicht einer User-Story =
zuordnen lassen, sollten innerhalb eines Teams gefixt werden k=F6nnen =
(statt einen Verantwortlichen in jedem Layer suchen zu m=FCssen).

o) Eine Agile Vorgehensweise bedeutet auch, dass es eine sehr enge =
Kopplung der Teams =FCber den gemeinsamen Source Code gibt. Jeder =
Entwickler checkt den gesamten Code aus und implementiert seinen Task =
dazu. Es ist daher erw=FCnscht =FCber die Team-Grenzen hinaus Source =
Code zu lesen, um Redundanzen zu finden und zu beseitigen (Entwickler =
m=FCssen miteinander reden!!).

o) Die User-Story orientierte Organisation der Teams erlaubt ja auch die =
Spezialisierung von Entwicklern (Web, DB, BL, etc.), wobei Entwickler =
die  sich in verschiedenen Layers auskennen zu bevorzugen sind =3D> =
bessere Skalierbarkeit des Teams.

Ich freue mich auf Ihre Anmerkungen...

Liebe Gr=FC=DFe
Egon Teiniker


-----Original Message-----
From: tas...@li... on behalf of =
Martin Kuhn
Sent: Sun 10/8/2006 9:43 PM
To: tas...@li...
Subject: Re: [Tasktlogger-devel]Input Realisierungsans=E4tze, =
Architektur
=20
Hi,

=20

die Gruppen w=FCrde ich auch ganz anders aufteilen aber irgendwie war =
der Hr.
Teiniker von meinem Vorschlag nicht wirklich begeistert.=20

Ich bin aber pers=F6nlich auch auf jeden Fall der Meinung dass eine =
Aufteilung
wie sie Roland beschrieben hat viel zielf=FChrender w=E4re.

=20

LG

=20

Martin

=20

  _____ =20

Von: tas...@li...
[mailto:tas...@li...] Im Auftrag von
Roland Walter
Gesendet: Sonntag, 08. Oktober 2006 21:37
An: tas...@li...
Betreff: [Tasktlogger-devel] Input Realisierungsans=E4tze, Architektur

=20

Hallo,

=20

bin ganz beim Martin. Auch wenn der Umfang des Projektes "klein" ist =
m=FCssen
einige Definitionen getroffen werden, welche bei einem gr=F6=DFeren =
Projekt
nicht viel

anders aussehen.

=20

Nur ein paar Anregungen:

*	In welche Schichten wird die Anwendung aufgeteilt=20

*	(Vorschlag f=FCr Projektgr=F6=DFe BusinessLogic mit Persistenzmethoden =
und
Oberfl=E4che)

*	Namenskonventionen (Anwendung, Datenbank, Programmfiles,
Ordnerstruktur)
*	Oberfl=E4chentemplate

*	Wo werden Aktionsbuttos positioniert
*	Wie sieht die Optik der Detail und =DCbersichtsseite aus

*	Wo werden welche CSS Klassen eingesetzt

*	Benennung =DCbersichtsseite, Detailseite und Auswertungsseiten,
Ordnerstruktur

usw.

=20

=20

Da es unser Ziel als Gruppe ist, die Aufgabenstellung zu l=F6sen, wei=DF =
ich
nicht in wie weit wir dabei selbst Entscheidungen treffen k=F6nnen.

Mein Vorschlag w=E4re eine ganz andere Projektstruktur, welche aus =
meiner
Erfahrung sehr gut funktioniert.

Somit w=FCrde ich die Gruppen wie folgt ausrichten:

*	Gruppe A: Integration
*	Gruppe B: Projektvorgaben (Namenskonventionen.),
Oberfl=E4chentemplates, DB Modell (Aufbau und Betreuung bei =
=C4nderungen)
*	Gruppe C: Businesslogic + Persistenz f=FCr Objekte sicherstellen.
*	Gruppe D: Oberfl=E4chenentwicklung und Visualisierung der Auswertungen
(Auswertungslogik klarerweise in Businesslogic)

=20

=20

Dadurch h=E4tten alle Teams klare Aufgaben und jedes Team hat seinen =
Bereich
wo es sich bewegt, anstatt dass jedes Team alle Schichten abbilden

muss. Weiters w=FCrden die Schnittstellen unter den Teams wesentlich =
kleiner
werden und die Koordination vereinfacht. Jedes Team sollte in jedem Fall

einen Verantwortlichen f=FCr die Abkl=E4rung der Schnittstellen zwischen =
den
Teams ernennen.

=20

So, ich hoff jetzt gibt's mal ne Diskussion =FCber das Thema ;o)

=20

LG

Roland