Hallo zusammen, ich arbeite gerade an einem Projekt für die Uni. Für dieses Projekt sind aktuell drei Mikrocontroller mit zusätzlicher Hardware wie ADCs, Speicher, Display... im Einsatz. Jeder Controller wird dabei von einem Studenten programmiert, die Schnittstellen zur Kommunikation legen wir dann immer zu 3. fest. Das klappt soweit auch ganz gut aber nun kam die Idee, alles mit einem Controller abzudecken. Den passenden Controller haben wir auch schon gefunden, also von der Hardwareseite ist nicht mit Problemen zu rechnen. Softwareseitig haben wir da allerdings Fragen. Speicher und Performance sind nicht das Problem sondern die verteilte Softwareentwicklung. Da wir verschiedene Vorlesungen besuchen haben wir selten Zeit um uns zu 3. zu treffen. Eine Idee wäre, die Software aus den drei Controllern "zusammen zu schmeißen" und auf einen Stand zu bringen, den man compilieren kann. Danach würde dann jeder seine Sourcen bearbeiten und über SVN ( oder was auch immer ) abspeichern und sich die neuen Sourcen der anderen ziehen. Da muss man halt an die Disziplin jedes einzelnen appelieren, damit der eigene Code immer compilierbar ist, dass eine Änderung von Objekten mitegeteilt wird usw. Eine andere Idee ist, dass zwei Leute ihren Code per Lib zur Verfügung stellen, aber dann haben wir keinen Ansatz zum Debuggen... Meine Frage ist nun relativ einfach: Wie geht man in der Softwareentwicklung vor, wenn mehrere Entwickler für die gleiche Zielhardware Software entwicklen? Danke Marius
Saubere Schnittstellen definieren. Statt Hardware Schnittstellen sind das dann Software Schnittstellen. Für Tests und zum Weitermachen bzw. wenn was nicht funktioniert muss man sich dann halt Stubs Also Dummy Module schreiben. Sourceverwaltungssystem, früher z.B. CVS heute Git, etc. Versuchen in den gemeinsamen Meetings sich abzusprechen wer wann!!! was macht und versuchen sich an den Zeitplan zu halten. Leute ihr habt heute mit dem Internet Möglichkeiten euch abzustimmen, davon haben wir früher geträumt. Ich hatte damals das nur das Telefon (Ferngespräch) und das Auto, und maximal Diskette.
Udo Schmitt schrieb: > Sourceverwaltungssystem, früher z.B. CVS heute Git, etc. würde eher SVN empfehlen. Ist auch quasi "Industriestandard". Git ist eher auf der Hobby/Nerd/Bastel Schiene zu sehen.
cyblord ---- schrieb: > würde eher SVN empfehlen. Ist auch quasi "Industriestandard". Git ist > eher auf der Hobby/Nerd/Bastel Schiene zu sehen. Hausgemachter Quatsch. Git ist doch schon längst in der Industrie angekommen. Ansonsten gibt's da noch Perforce. SVN ist in den meisten Fällen nur noch eine Altlast.
Nutze Tools wie z.B. Jira und Redmine oder was sonst so an der Uni en vogue ist. Kostenlose SVNs mit weiteren Tools gibt es z.B. bei assembla.com. Für den Entwicklungsprozess eignet sich die SCRUM-Methode. So, dass waren jetzt viele Stichworte für google & Co. :-)
greg schrieb: > cyblord ---- schrieb: >> würde eher SVN empfehlen. Ist auch quasi "Industriestandard". Git ist >> eher auf der Hobby/Nerd/Bastel Schiene zu sehen. > > Hausgemachter Quatsch. Git ist doch schon längst in der Industrie > angekommen. Ansonsten gibt's da noch Perforce. SVN ist in den meisten > Fällen nur noch eine Altlast. Sicher nicht. Auch dann nicht, wenn ein paar Nerds das gerne anders sehen und ganz doll mit dem Fuss aufstampfen.
Pete K. schrieb: > So, dass waren jetzt viele Stichworte für google & Co. :-) Danke Pete. Welches Tool zum Einsatz kommt ist bisher noch Nebensache. Ich habe halt einfach bedenken, wenn 3 Leute Software für eine Plattform schreiben. Scrum sagt mir etwas, da war mal was in einer Vorlesung ;-)
Marius schrieb: > Da muss man halt an die Disziplin jedes einzelnen appelieren, damit der > eigene Code immer compilierbar ist, dass eine Änderung von Objekten > mitegeteilt wird usw. .. oder man nimmt eine Continous Integration Server der prueft ob dre Code kompilierbar ist und die Tests richtig laufen.
cyblord ---- schrieb: > Ist auch quasi "Industriestandard". Na ja Clearcase und CVS sind/waren auch Industriestandard. Git hat z.B. fast 3 mal so viele Treffer von SVN bei Google. Und bei 3 Personen braucht man ntürlich einen "Industriestandard" der den Bestand von 1000 Entwicklern und hunderten von Projekten verwaltet? :-) Ich würde das nehmen, was schon am besten bekannt ist, am einfachtsten aufzusetzen ist und wo die Einarbeitungszeit am kürzesten ist. Schliesslich haben sie gerade schon die Hardware umgeworfen und endlos soll das Projekt wohl auch nicht dauern.
>Sicher nicht. Auch dann nicht, wenn ein paar Nerds das gerne anders >sehen und ganz doll mit dem Fuss aufstampfen. Bist Du Dir sicher, dass Du wirklich up-to-date bist? Immerhin wird Linux mit Git entwickelt und Github ist wirklich gut gemacht. Da kann SVN nicht mithalten. Manchmal ändern sich die Zeiten, vielleicht gehörst Du schon zum alten Eisen.
Pete K. schrieb: > Für den Entwicklungsprozess eignet sich die SCRUM-Methode. Auch wieder so ein Modewort. Wollen wir noch "extrem programming" dazuwerfen. An Scrum verdienen hauptsächlich Beratungsklitschen, für ein 3 Personen Projekt genauso sinnvoll wie sich einen 60 Tonnen Muldenkipper zu kaufen nur weil man ein Gartenhäuschen bauen will. SCRUM ist nichts anderes als gesunden Menschenverstand in ein Schema zu packen. Ist durchaus in Unternehmen angebracht weil man dort dann ganz einfach mit dem standardisierten Schema den Vertrieblern und Chefs die Sonderlockenflusen austreiben kann. Und die machen dann dafür auch noch Unmengen Kohle für externe SCRUM Berater locker.
markus schrieb: > Bist Du Dir sicher, dass Du wirklich up-to-date bist? Denke schon. > Immerhin wird > Linux mit Git entwickelt Warte mal.... irgendwas klingelt da... ach ja das ist doch das lustige OS mit 3% Marktanteil. Ok ernsthaft: Ich weiß das GIT in der OS-Gemeinde dominiert. Aber was heißt das? > und Github ist wirklich gut ge in diesem Fall? Was brauch ich für ein gemeinsames Projekt? Nen SVN-Server bzw. nen lokales Repo, und nen ordentlichen Client mit am besten guter Integration in die IDE. Das gibts für git auch, ja. Aber ob da nun github nehm oder was anderes. Unbedingt web-basiert brauch ich da nicht.
:
Bearbeitet durch User
cyblord ---- schrieb: > Sicher nicht. Auch dann nicht, wenn ein paar Nerds das gerne anders > sehen und ganz doll mit dem Fuss aufstampfen. Sicher doch. Da gibt es genug Umfragen und andere Indikatoren (z.B. Stellenanzeigen), die das bestätigen. SVN ist seit einigen Jahren auf einem starken Abwärtstrend, bei Git sieht es umgekehrt aus. Microsoft liefert seit einiger Zeit selbst Git-Unterstützung in Visual Studio. Machen die das zum Spaß, oder weil Kunden danach fragten? Rate mal.
cyblord ---- schrieb: > Warte mal.... irgendwas klingelt da... ach ja das ist doch das lustige > OS mit 3% Marktanteil. > Ok ernsthaft: Ich weiß das GIT in der OS-Gemeinde dominiert. Aber was > heißt das? Genau was nichts kostet taugt nix. Also kaufe Clearcase und schmeis das idiotische SVN weit weg. Was ereiferst du dich? Ich habe mich mit einem selbstgeschriebenen System auf einer VAX rumgeschlagen, dann mit Clearcase, im Moment immer noch mit CVS das schon länger tot ist. In Kürze wird es bei uns wohl Git werden. Wenn es statt dessen SVN wäre -auch egal-. Wichtig ist was hinten raus kommt und dass man mit dem Produkt Geld verdient. Wenn du dich so auf ein System versteifst bist du schneller Alteisen als du denkst.
greg schrieb: > Machen die das zum Spaß, oder weil Kunden danach fragten? Rate mal. Hm. Schau ich mir die sonstigen Produkte von denen an z.B. das aktuelle Windows, so fällt die Antwort nicht schwer. Kundenwünsche haben Microsoft überhaupt noch nie interessiert. Oliver
Pete K. schrieb: > Für den Entwicklungsprozess eignet sich die SCRUM-Methode. Für drei Leute, die es nicht schaffen, sich auf ein Bier zu treffen? Dann machen 3 Leute SCRUM jeder für sich zuhause?
Aber zurück zum Thema: ich kann bitbucket empfehlen. Da gibt es Repositories, Mercurial oder Git. Wenn man will auch privat, und das mit Einschränkungen kostenlos. Bei Github muss man für private Repositories zahlen.
Klaus Wachtler schrieb: > Dann machen 3 Leute SCRUM jeder für sich zuhause? Klaus Wachtler schrieb: > Für drei Leute, die es nicht schaffen, sich auf ein Bier zu treffen? > Dann machen 3 Leute SCRUM jeder für sich zuhause? Nee, die müssen deutlich mehr Bier trinken als früher. Bis erst mal die Rollen verteilt sind: Owner, Scrum Master, Management, Customer , User, (gibts noch mehr?). Dann müssen sie User Stories erarbeiten, ihre Ceremonies abhalten, das alles protokollieren und auf die Einhaltung der Verfahren prüfen, .... ach so und ein Entwicklerteam braucht man auch noch, und die müssen zwischen all dem dann auch noch ab und zu entwickeln... Nach soviel Bier, Ohweh! :-)
Udo Schmitt schrieb: > Nee, die müssen deutlich mehr Bier trinken als früher. Bis erst mal die > Rollen verteilt sind: Owner, Scrum Master, Management, Customer , User, > (gibts noch mehr?). Dann müssen sie User Stories erarbeiten, ihre > Ceremonies abhalten, das alles protokollieren und auf die Einhaltung der > Verfahren prüfen, .... > ach so und ein Entwicklerteam braucht man auch noch, und die müssen > zwischen all dem dann auch noch ab und zu entwickeln... > Nach soviel Bier, Ohweh! Wenn man das richtig macht, ist es kein Problem: https://xkcd.com/323/ :)
greg schrieb: > enn man das richtig macht, ist es kein Problem: > > https://xkcd.com/323/ :) Schööön :-) Danke Nachtrag: Bei Windows8 haben sie es mit Scrum probiert. Leider hat der Scrum Master die User Stories aus Versehen mit den Kindergarten Bildern seines Sprösslings vertauscht. Herausgekommen ist die neue Benutzeroberfläche :-)
:
Bearbeitet durch User
cyblord ---- schrieb: > Warte mal.... irgendwas klingelt da... ach ja das ist doch das lustige > OS mit 3% Marktanteil. 3% Marktanteil? Vielleicht auf Sekretaerinnenrechnern ;) Auf Servern sieht das ganze genau umgekehrt aus, da sind weit ueber 90% Linux Maschinen. cyblord ---- schrieb: > Ok ernsthaft: Ich weiß das GIT in der OS-Gemeinde dominiert. Aber was > heißt das? Dass damit schon sehr viel Code verwaltet wird.
Mladen G. schrieb: > > 3% Marktanteil? > Vielleicht auf Sekretaerinnenrechnern ;) > Auf Servern sieht das ganze genau umgekehrt aus, da sind weit ueber 90% > Linux Maschinen. Die Tuxe lassen sich aber auch auf den Punkt provozieren ;-) > > cyblord ---- schrieb: >> Ok ernsthaft: Ich weiß das GIT in der OS-Gemeinde dominiert. Aber was >> heißt das? > > Dass damit schon sehr viel Code verwaltet wird. Das es funktioniert bestreitet ja keiner.
cyblord ---- schrieb: > Die Tuxe lassen sich aber auch auf den Punkt provozieren ;-) Eine falsche Aussage als falsch darzustellen ist vielleicht nicht fuer jeden gleich etwas provokantes ;)
Mladen G. schrieb: > cyblord ---- schrieb: >> Die Tuxe lassen sich aber auch auf den Punkt provozieren ;-) > > Eine falsche Aussage als falsch darzustellen ist vielleicht nicht fuer > jeden gleich etwas provokantes ;) Die Qualität eines Tools damit zu begründen dass es ja gut sein muss da damit Linux entwickelt wird, schreit aber geradezu nach einer ebenso hahnebüchenen Antwort.
cyblord ---- schrieb: > Die Qualität eines Tools damit zu begründen dass es ja gut sein muss da > damit Linux entwickelt wird, schreit aber geradezu nach einer ebenso > hahnebüchenen Antwort. Jetzt hast du wieder recht :)
Hallo, greg schrieb: > cyblord ---- schrieb: >> würde eher SVN empfehlen. Ist auch quasi "Industriestandard". Git ist >> eher auf der Hobby/Nerd/Bastel Schiene zu sehen. > > Hausgemachter Quatsch. Git ist doch schon längst in der Industrie > angekommen. Ansonsten gibt's da noch Perforce. SVN ist in den meisten > Fällen nur noch eine Altlast. Meine Güte. Sowohl Git als auch SVN sind Industriestandards, und ich kenne etliche Unternehmen, die eines oder sogar beide Systeme einsetzen. Welches man benutzt, ist letztendlich egal: beide erfüllen ihre Aufgabe ordentlich und zuverlässig, und unterscheiden sich für den Anwender nur wenig. Beste Grüße, Karl
Karl Käfer schrieb: > Meine Güte. Hast ja recht mit allem. Aber wir hatten hier noch nie einen zünftigen Glaubenskrieg für Versionsverwaltungssysteme. Aber ich sehe Potential... ;-)
cyblord ---- schrieb: > Nen SVN-Server bzw. nen lokales Repo, und nen ordentlichen > Client mit am besten guter Integration in die IDE. IMHO übersiehst du hier einen Punkt, der bei Systemen wie SVN einfach nur riesige Schmerzen bereitet: die Wartung eigener Patchsets auf Basis anderer Software. Um beim gebrachten Linux-Beispiel zu bleiben: du benutzt Linux für ein Projekt, benötigst aber Boardsupport oder andere Sachen, die noch nicht im Mainline-Kernel enthalten sind. Oder du unterhältst aus was für Gründen auch immer lokale Modifikationen, die nicht Teil des "normalen" Linuxkernels sind. Auf jeden Fall musst du ein Patchset pflegen und das idealerweise so, dass Upstream-Änderungen weiterhin in deinen Code einfließen können und du dich nicht für immer und ewig auf eine Uraltversion festlegst, weil die Codebasen immer weiter auseinander driften. Mit Git ist sowas ziemlich angenehm durchzuführen, mit SVN jedoch die Hölle auf Erden.
Hallo markus, markus schrieb: > Bist Du Dir sicher, dass Du wirklich up-to-date bist? Immerhin wird > Linux mit Git entwickelt die Entwicklung des Linux-Kernels ist ein Sonderfall und profitiert darum von dem verteilten Modell von Git. Einem kleineren Projekt von Leuten, die in dieselbe Richtung entwickeln, nutzt das wenig. > Da kann SVN nicht mithalten. Doch, natürlich. Subversion ist immer noch eine äußerst leistungsfähige Software, die wunderbar funktioniert und nur in einigen sehr seltenen Ausnahmefällen hinter Git oder Mercurial zurückstehen muß. Für das, was der TO vorhat, kann er Git oder Subversion oder Mercurial nehmen, wie es ihm gerade beliebt. Jedes dieser Systeme kann alles, was er und seine Mitstreiter brauchen. Liebe Grüße, Karl
Hallo cyblord, cyblord ---- schrieb: > markus schrieb: >> Immerhin wird >> Linux mit Git entwickelt > Warte mal.... irgendwas klingelt da... ach ja das ist doch das lustige > OS mit 3% Marktanteil. Von wegen. Im Serverbereich hat Linux laut Gartner einen Marktanteil von 28%, weiterhin mit steigender Tendenz. Du kannst gern Deinen Phobien und Glaubensdingen fröhnen, aber bei der Wahrheit solltest Du schon bleiben. Liebe Grüße, Karl
Karl Käfer schrieb: > Hallo cyblord, > > cyblord ---- schrieb: >> markus schrieb: >>> Immerhin wird >>> Linux mit Git entwickelt >> Warte mal.... irgendwas klingelt da... ach ja das ist doch das lustige >> OS mit 3% Marktanteil. > > Von wegen. Im Serverbereich hat Linux laut Gartner einen Marktanteil von > 28% laut deinem Kollegen oben, "weit ueber 90%". Bis ihr euch auf irgendeine Phantasiezahl geeinigt habt, bleibe ich mal bei meinen 3%.
Mladen G. schrieb: > Auf Servern sieht das ganze genau umgekehrt aus, da sind weit ueber 90% > Linux Maschinen. Karl Käfer schrieb: > Im Serverbereich hat Linux laut Gartner einen Marktanteil von > 28%, weiterhin mit steigender Tendenz. Der Abstand zwischen gemessenem und gefühltem Marktanteil ist aber doch noch erheblich. Oliver
cyblord ---- schrieb: > Karl Käfer schrieb: >> Hallo cyblord, >> >> cyblord ---- schrieb: >>> markus schrieb: >>>> Immerhin wird >>>> Linux mit Git entwickelt >>> Warte mal.... irgendwas klingelt da... ach ja das ist doch das lustige >>> OS mit 3% Marktanteil. >> >> Von wegen. Im Serverbereich hat Linux laut Gartner einen Marktanteil von >> 28% > > laut deinem Kollegen oben, "weit ueber 90%". Bis ihr euch auf irgendeine > Phantasiezahl geeinigt habt, bleibe ich mal bei meinen 3%. Ich werfe mal den Smartphone-Bereich mit rein, da ist Linux Marktführer.
Karl Käfer schrieb: > Meine Güte. Sowohl Git als auch SVN sind Industriestandards, und ich > kenne etliche Unternehmen, die eines oder sogar beide Systeme einsetzen. > Welches man benutzt, ist letztendlich egal Keineswegs. Git (genauso wie bitkeeper, hq, bzr, ...) ist ein verteiltes System. Das heißt jeder Entwickler hat die Historie lokal auf seinem Rechner und kann auch ohne Internetverbindung alte Revisionen ansehen, Änderungen committen und was noch alles. Bei SVN (und CVS, perforce, ...) braucht man für jede solche Operation Zugriff auf das zentrale Repository. Was bedeutet, daß man ohne Internet auch mal gar nicht weiterarbeiten kann. Noch gravierender sind allerdings die ganz neuen Workflows, die ein DVCS erlaubt. Team-Trees, verteilte Merges usw. Der Entwicklungsprozeß selber skaliert einfach viel besser. Zugegeben, bei 3 Hanseln ist das noch nicht gravierend. Aber wenn ich in die Softwareindustrie in meiner Umgebung schaue (ok, ist sehr open-source-lastig ;) dann sind DVCS die Regel und SVN & Co sind Exoten. Demzufolge kann es nicht schaden, wenn sich angehende Softwareentwickler frühzeitig mit den Möglichkeiten vertraut machen. XL
Oliver schrieb: > Der Abstand zwischen gemessenem und gefühltem Marktanteil ist aber doch > noch erheblich. Das mit der Realität vs. persönlichem Empfinden haben viele (auch und gerade überzeugte Linuxer) auch noch nicht so ganz drauf ;-) Der nächste rechnet Android-Geräte rein und landet bei "weit über 99%". Eventuell sollte die Linux-Gemeinde mal eine Reform der Prozentzahlen denken. Eine Art GNU/%. Linux könnte dann 120 GNU/% Marktanteile haben. Und Windows hätte 0.05 GNU/%.
working directory schrieb: > IMHO übersiehst du hier einen Punkt, der bei Systemen wie SVN einfach > nur riesige Schmerzen bereitet: die Wartung eigener Patchsets auf Basis > anderer Software. Das ist mit vendor branches nicht wirklich schwierig.
Hallo cyblord, cyblord ---- schrieb: >> Von wegen. Im Serverbereich hat Linux laut Gartner einen Marktanteil von >> 28% > > laut deinem Kollegen oben, "weit ueber 90%". Bis ihr euch auf irgendeine > Phantasiezahl geeinigt habt, bleibe ich mal bei meinen 3%. die von mir als Quelle angegebene Gartner Group gilt in diesem Bereich als seriöser Industriestandard. Du willst doch wohl nicht etwa ausgerechnet hier von etablierten Industriestandards abweichen, oder? Abgesehen davon sind wir hier ja in einem Mikrocontroller-Forum, und auf Embedded-Systemen hat Linux sicher den mit Abstand höchsten Marktanteil von allen verbreiteten Betriebssystemen. Bei den Marsrovern hat Linux mit einem Marktanteil von 100% sogar ein Monopol! Und das willst Du einfach leugnen? Tse, Karl
Karl Käfer schrieb: > die von mir als Quelle angegebene Gartner Group gilt in diesem Bereich > als seriöser Industriestandard. Du willst doch wohl nicht etwa > ausgerechnet hier von etablierten Industriestandards abweichen, oder? Niemals! Industriestandards sind meine Bibel. > Bei den Marsrovern hat Linux > mit einem Marktanteil von 100% sogar ein Monopol! Und das willst Du > einfach leugnen? Im Gegentum, ich wäre dafür das Linux Monopol auf fremden Himmelskörpern deutlich auszubauen. Dazu könnte man eine größere Anzahl Linux-Nerds dorthin auslagern.
Marius schrieb: > Da muss man halt an die Disziplin jedes einzelnen appelieren, damit der > eigene Code immer compilierbar ist, dass eine Änderung von Objekten > mitegeteilt wird usw. Immer compilierbar muss der Code nicht sein. Man sollte aus Sicherheitsgründen auch halb fertige Sachen einchecken, dann ist es nicht gar so übel, wenn die lokale Festplatte mal die Grätsche macht. Wenn ein Entwicklungsschritt fertig und kompilierbar ist, wird diese Version nach dem einchecken getaggt. So hat jeder zu jeder Zeit kompilierbaren Code von den anderen Entwicklern. Änderungen an den gemeinsamen Schnittstellen müssen aber natürlich abgestimmt oder mindestens dokumentiert sein und dieses Dokument muss mit dem zugehörigen Code eingecheckt werden. Das ist der Punkt, wo Disziplin nötig ist.
Huch, das ist ja ganz schön explodiert hier. Um mal auf den TE einzugehen, bei einem so kleinen Projekt dürfte die Wahl einer Sourceverwaltung recht leichtfallen. Ich habe SVN einige Jahre genutzt und beim jetzigen Arbeitgeber GIT - solange man kein exzessives Branching/Merge-Orgien vorhat ist das imho gehopst wie gesprungen. Aktuell dürfte das Angebot an GIT-Hosting allerdings größer sein. Und jetzt hier die große SCRUM-Keule auszupacken, halte ich für völlig oversized. Das könnte allerdings auch an meiner persönlichen Abneigung gegen SCRUM liegen ;)
interessant das niemand bisher online live coding vorgeschlagen hat wie z.B. cloud9 (https://c9.io/) oder zumindest sowas wie etherpad dann wäre SVN auch fast hinfällig :) nur dauer online könnte schwierig werden
Hallo Oliver, Oliver schrieb: > Mladen G. schrieb: >> Auf Servern sieht das ganze genau umgekehrt aus, da sind weit ueber 90% >> Linux Maschinen. > > Karl Käfer schrieb: >> Im Serverbereich hat Linux laut Gartner einen Marktanteil von >> 28%, weiterhin mit steigender Tendenz. > > Der Abstand zwischen gemessenem und gefühltem Marktanteil ist aber doch > noch erheblich. Das kommt auf den Markt und die Meßmethode an. Meine Systeme fließen zum Beispiel gar nicht oder sogar falsch in die Messung ein: meine Rechner laufen alle unter Debian- und Ubuntu-Linux, das ich heruntergeladen habe. Trotzdem werden meine Laptops für Windows gezählt, weil es ihnen beilag -- auch wenn ich es gar nicht nutze. Etwas mehr zu den Märkten und Methoden, auch zur Kritik an den Methoden, findest Du hier: http://en.wikipedia.org/wiki/Usage_share_of_operating_systems Du siehst: auf Supercomputern hat Linux einen Marktanteil von 96,4 %. Wenn unser Vorredner also mit "Server" Supercomputer meint, dann hat er damit sogar noch bescheiden tiefgestapelt. HTH, Karl
Ich weiß gar nicht, wie man SVN überhaupt verteidigen kann. Wenn man intensiver mit Branches arbeitet, ist das einfach nur unglaublich schmerzhaft, unübersichtlich und zeitaufwändig. SVN kann doch nicht einmal richtig (d.h. unter Erhaltung der einzelnen Commits) mergen.
benwilliam schrieb: > interessant das niemand bisher online live coding vorgeschlagen hat > > wie z.B. cloud9 (https://c9.io/) > > oder zumindest sowas wie etherpad > > dann wäre SVN auch fast hinfällig :) > nur dauer online könnte schwierig werden Da bellst du aber den völlig falschen Baum an, die Jungs wollen für Software für Mikrocontroller entwickeln, kein jQuery frickeln.
Hallo Axel, Axel Schwenke schrieb: > Keineswegs. Git (genauso wie bitkeeper, hq, bzr, ...) ist ein > verteiltes System. Nein, wirklich? Da wär' ich ja nie drauf gekommen. ;-) > Was bedeutet, daß man ohne Internet auch mal gar nicht weiterarbeiten > kann. Natürlich kann man. Im Zweifelsfall muß man die Änderungen hinterher halt manuell zusammenfügen. Wenn man regelmäßig Kontakt zum Internet hat, ein wenig Disziplin mitbringt und die Aufgaben klar verteilt sind, geht das trotzdem ganz gut. Als wir früher nur CVS, RCS und SCCS hatten, ging es schließlich auch immer, irgendwie. > Noch gravierender sind allerdings die ganz neuen Workflows, die ein DVCS > erlaubt. Team-Trees, verteilte Merges usw. Der Entwicklungsprozeß selber > skaliert einfach viel besser. Für drei Leute mit einer Mikrocontroller-Software... > Zugegeben, bei 3 Hanseln ist das noch nicht gravierend. Puh, Du hast es doch noch gemerkt. ;-) > Aber wenn ich in > die Softwareindustrie in meiner Umgebung schaue (ok, ist sehr > open-source-lastig ;) dann sind DVCS die Regel und SVN & Co sind Exoten. > Demzufolge kann es nicht schaden, wenn sich angehende Softwareentwickler > frühzeitig mit den Möglichkeiten vertraut machen. Tja, das mag bei Dir in der OpenSource-Welt so sein. Ich hingegen komme aus der kommerziellen Softwareentwicklung und kenne sogar noch Firmen, in denen immer noch RCS läuft. Viele vor allem große Firmen lösen etablierte Systeme nicht aufgrund irgendeiner Mode ab, weil irgendein Klugscheißer gerade daher kommt und erzählt wie toll verteilte Systeme sind. Ein paar meiner Kunden haben das Gefühl, daß ihnen die Kontrolle entgleitet, wenn sie auf ein zentrales Repository verzichten. Ganz abgesehen von den Kosten und dem Gemopper, wenn Du 200 Entwickler und 20 Architekten auf ein neues Softwaresystem umziehen willst... Liebe Grüße, Karl
Hallo cyblord, cyblord ---- schrieb: > Niemals! Industriestandards sind meine Bibel. Na also. > Im Gegentum, ich wäre dafür das Linux Monopol auf fremden Himmelskörpern > deutlich auszubauen. Dazu könnte man eine größere Anzahl Linux-Nerds > dorthin auslagern. Bisher schaffen wir das nur mit Linux-Geräten. Liebe Grüße, Karl
Karl Käfer schrieb: > Tja, das mag bei Dir in der OpenSource-Welt so sein. Ich hingegen komme > aus der kommerziellen Softwareentwicklung und kenne sogar noch Firmen, > in denen immer noch RCS läuft. Wie oben gesagt, wir hatten was eigengestricktes für die VAX, dann Clearcase, dann CVS und jetzt wollen wir projektweise auf GIT umstellen. Und unsere Software ist sowas von closed, wie es bei Banken und Versicherungen als Kunden nur sein kann. Karl Käfer schrieb: > Ein paar meiner Kunden haben das Gefühl, daß ihnen die Kontrolle > entgleitet, wenn sie auf ein zentrales Repository verzichten. Ich kenne Git noch nicht besonders, aber ich denke nicht, daß man nicht zentral die offizielle Versionen halten kann. Wir versprechen uns vor allem ein besseres Merge von Git, mal sehen.
Hallo, Danke für die vielen Antworten aber ehrlich gesagt helfen sie mir bei meinem Problem wenig bis gar nicht. Wie gesagt es geht mir darum, wie man mit mehreren Leuten Software für eine Plattform entwickelt. Ob man jetzt SVN oder Git nutzt ist zweitrangig.
Marius schrieb: > Danke für die vielen Antworten aber ehrlich gesagt helfen sie mir bei > meinem Problem wenig bis gar nicht. Du hast meinen ersten Beitrag gelesen?
Marius schrieb: > Danke für die vielen Antworten aber ehrlich gesagt helfen sie mir bei > meinem Problem wenig bis gar nicht. Das Problem liegt (neben der üblichen Schlammschlacht bzgl. "meiner ist länger als deiner") daran, daß es keine einfache Antwort in wenigen Zeilen gibt. Letztlich muß man auf mehreren Ebenen gleichzeitig aufpassen: - das Gesamtproblem muß sinnvoll unterteilt werden - zwischen den Teilen ergeben sich Schnittstellen - diese müssen genau definiert sein - für jeden Einzelteil sollte es sinnvolle Tests geben - es sollte Gesamttests geben - man muß Quelltexte austauschen, z.B. über svn o.ä. - bei größeren Projekten sollte auch jederzeit Lauffähigkeit des Gesamtsystems gewährleistet sein (hier wohl nicht) - ... Das alles will organisiert sein und kontrolliert. Drei gleichberechtigte Leute, die nebeneinander herwursteln, sind keine gute Voraussetzung für Gelingen. Zu jedem dieser Teilschritte kann man ewige Diskussionen (s.o.) anfachen.
:
Bearbeitet durch User
Noch was: selbst bei so einem kleinen Team ist es vielleicht gut, wenn man jemanden auswählt, der die Entscheidungen letztendlich und verbindlich trifft und auch dafür sorgt, dass diese umgesetzt werden. Ein Teamleiter eben. Ich habe es bei Uni-Projekten schon gehabt, dass wir uns zwar locker abgesprochen hatten, einzelne Leute dann aber Dinge ganz anders gemacht haben, weil sie das so für besser hielten. Das geht natürlich gar nicht, und hat zu viel Streit geführt.
cyberlord schrieb: >Hast ja recht mit allem. Aber wir hatten hier noch nie einen zünftigen >Glaubenskrieg für Versionsverwaltungssysteme. Aber ich sehe Potential... >;-) Ja, und sie habe extra für Dich einen Git-Anfängerkurs in der neuen ct. http://www.heise.de/ct/12/13/links/144.shtml
>Ich kenne Git noch nicht besonders, aber ich denke nicht, daß man nicht >zentral die offizielle Versionen halten kann. Wir versprechen uns vor >allem ein besseres Merge von Git, mal sehen. Da gibt es zugegebnermaßen einen kleine Tradeoff bei Git: Es gibt keine Locks, d.h. die Leute können immer gleichzeitig an einem File arbeiten, dass am Schluss "gemerged" werden muss.
greg schrieb: > Noch was: selbst bei so einem kleinen Team ist es vielleicht gut, > wenn > man jemanden auswählt, der die Entscheidungen letztendlich und > verbindlich trifft und auch dafür sorgt, dass diese umgesetzt werden. > Ein Teamleiter eben. Richtig, eine klare (idealerweise vorab und einvernehmlich festgelegte) Organisationsstruktur ist viel wichtiger für den Erfolg als die Wahl irgendeiner konkreten Versionsverwaltung. Was wirklich nötig ist, können die nämlich allesamt. Was einige mehr können, ist bestenfalls ein "nice to have", wird aber niemals einen entscheidenden Einfluß auf den Erfolg des Projektes ausüben können.
@Marius (Gast): SVN hast Du ja schon in Deinem Ursprungspost erwähnt. Gut. Für jeden Bereich des µCs wie z.B. ADC, Display, etc. lassen sich eingene Bibliotheken (adc.h, adc.c, gui.h, gui.c) entwickeln, die von einem Hauptprogramm zusammengehalten werden (main.c). Also, zuwerst werden die Prototypen (*.h) abgestimmt, dann kann jeder einzeln loslegen. Was compilierbar ist wird eingecheckt. So schwierig ist das nicht. Ihr benutzt kein C? Hmm, dann wäre dies eine Überlegung zum Umstieg wert.
markus schrieb: > Da gibt es zugegebnermaßen einen kleine Tradeoff bei Git: Es gibt keine > Locks, d.h. die Leute können immer gleichzeitig an einem File arbeiten LOL. VCS bei denen immer nur einer an einem File ändern darf, sind so 90er. Schon CVS hat dieses schwere Manko beseitigt (das C steht für concurrent). Daß man sich damit potentielle Konflikte einhandelt, wiegt in der Praxis weit weniger schwer als die sonst auftretenden Locking-Konflikte. XL
Axel Schwenke schrieb: > Daß man sich damit potentielle Konflikte einhandelt, > wiegt in der Praxis weit weniger schwer als die sonst auftretenden > Locking-Konflikte. In der Tat, reicht ja schon wenn irgendwer vergisst, einen Lock wieder aufzuheben. Und außerdem zählt dann nicht mehr nur "der kompiliert gerade" als Grund für eine Pause, sondern auch noch "die Datei ist gelockt". :)
> damit der eigene Code immer compilierbar ist Einfache Regel: Was auf den main-Branch geliefert wird (oder wie auch immer sich das bei der jeweiligen Versionsverwaltung nennt) muss compilieren. Kann man mit Selbstdiziplin hinbekommen, oder mit automatischer Prüfung durch das Tool. Wenn man nicht compilierbare Zwischenergebnisse sichern will, hat man dafür einen eigenen Branch. > Wie geht man in der Softwareentwicklung vor, wenn mehrere Entwickler > für die gleiche Zielhardware Software entwicklen? Schnittstellen abstimmen wurde ja schon genannt. Auch wichtig: Traces an den Schnittstellen. Ihr werdet mit hoher Wahrscheinlichkeit Fehler suchen müssen. Und dann ist es gut, wenn man "den Schuldigen" schnell findet, damit der dann in seinem Zuständigkeitsbereich weiter suchen kann.
Diese Buch hier sollte jeder im Team gelesen haben http://www.oreilly.de/catalog/wenschleprogger/ Darin werden einige Fehler in der Team-Zusammenarbeit auf witzige Weise analysiert.
Pete K. schrieb: > Ihr benutzt kein C? Doch wir programmieren in C. sebastian schrieb: > Auch wichtig: Traces an den Schnittstellen. Was genau ist damit gemeint?
sebastian schrieb: >> damit der eigene Code immer compilierbar ist > > Einfache Regel: Was auf den main-Branch geliefert wird (oder wie auch > immer sich das bei der jeweiligen Versionsverwaltung nennt) muss > compilieren. Kann man mit Selbstdiziplin hinbekommen, oder mit > automatischer Prüfung durch das Tool. Naja, bedingt. Wenn ein Make-Lauf eine Stunde oder länger dauert und die Änderungen im Sekundentakt kommen, bleibt nur noch die Selbstdisziplin - und die kann nicht alle Konflikte vorhersehen.
Marius schrieb: >> Auch wichtig: Traces an den Schnittstellen. > > Was genau ist damit gemeint? Das weisst du in dem Moment, in dem irgendwas nicht funktioniert, keine Seite schuld sein will und man wissen will, was zwischen den Teilen übertragen wird um den Schuldigen zu finden.
Klaus Wachtler schrieb: > Wenn ein Make-Lauf eine Stunde oder länger dauert und die Änderungen im > Sekundentakt kommen Das sind 3 Hanselchen die einen µC für ein Uniprojekt neu! programmieren wollen. Da dauert ein Compile genau 2-10 Sekunden. Und die Changes kommen alle paar Stunden mal einer oder 2. Leute, bleibt doch mal am konkreten Problem.
Marius schrieb: > sebastian schrieb: >> Auch wichtig: Traces an den Schnittstellen. > > Was genau ist damit gemeint? Daß API-Funktionsaufrufe mitsamt Parametern und Ergebnissen bei Bedarf geloggt werden können. Vergleichbar strace oder ltrace auf unixoiden Betriebssystemen. Ist allerdings auf µC oft leichter gesagt als getan. In diesem Zusammen- hang auch der (anderswo) immer wieder geäußerte Hinweis, dem µC-System eine Kommunikationsschnittstelle zum Debuggen mitzugeben. XL
Axel Schwenke schrieb: > dem µC-System > eine Kommunikationsschnittstelle zum Debuggen mitzugeben. Die Kommunikation zwischen den Controllern läuft über CAN und wir haben eigene Tools geschrieben, die den CAN "mithören" aber auch CCP ist möglich. Deshalb ist die Variante, dass 2 Leute ihren Code per Lib bereitstellen ja nicht möglich. Bzw weiss ich dann nicht, wie das mit dem Debuggen sauber klappt.
Dann müsst ihr halt statt des CAN-Protokolls eines für die neue Schnittstelle schaffen ...
Ich habe aufhört die Antworten zu lesen nachdem der 20. Post zur Versionskontrolle kam. Das löst euer eigentliches Problem nicht. Grundsätzlich solltet ihr irgendeine Versionskontrolle verwenden. Soweit so gut. Eingecheckt wird nur was sich bauen lässt. Eine Hand voll Sourcefiles ueber ein so kleines Team zu synchronisieren sollte somit geklärt sein. Euer eigentliches Problem droht allerdings im Konzept: Für Timing-Probleme anfälliger Spaghetti-Code, weil das was bisher auf drei Ausführungssträngen lief auf einen zusammengeführt wird. Mit einer Superloop und ausgefallenen Statemachines fallen solche Projekte dann schnell mit sonderbaren Ablaufproblemen auf. Bei der Portierung solltet ihr von vorneherein auf ein kleines pre-emptives RTOS setzen. Wenn jetzt jeder seinen eigenen Aufgabenbereich sauber in Tasks formuliert braucht ihr nur noch einen der bei der Integration die einzelnen Tasks mit ihrer globalen Prioritaet richtig versieht. Der Rest ist gratis.
Dr. M. schrieb: > Der Rest > ist gratis. inclusive Deadlocks, Synchronisierung, jegliche globale Änderungen atomar kapseln, etc. pp. Wer glaubt Multitasking/Multithreading wäre gratis nur weil man ein Betriebssystem benutzt das concurrency zulässt hat noch nie wirkliches Multitasking/Multithrading programmiert. Im ERSTEN Beitrag hättest du lesen können daß sie schon einen µC haben, ob darauf ein RTOS läuft und ob es notwendig/sinnvoll ist wäre erst mal zu klären.
Marius schrieb: > Das klappt soweit auch ganz gut aber nun kam die Idee, alles mit einem > Controller abzudecken. Ich spiele jetzt mal den "devil's advocate": Meistens ist es ja nicht das Ziel einer akademischen Arbeit, möglichst kosteneffizient (hier: mit weniger Controllern) eine Lösung zu finden, sondern vielmehr einen neuen Ansatz für ein Problem als "proof-of-concept" darzustellen. Ich befürchte, dass Ihr mir der Umstellung auf einen einzelnen Controller sehr viel Arbeit in die Koordination der Tätigkeiten stecken müsst, ohne einen wirklichen Vorteil bei der Lösung der grundsätzlichen Aufgabe zu gewinnen. Lehrreich ist es auf jeden Fall, wenn man (das erste Mal?) mit mehreren Leuten zusammen an einer Codebasis arbeitet. Nach meiner Erfahrung gibt dort es aber mehr koordinative und soziale Probleme als technische.
Marcus schrieb: > Nach meiner Erfahrung gibt > dort es aber mehr koordinative und soziale Probleme als technische. Genau darum habe ich ja gefragt, wie man Projekte mit mehreren ( in diesem Fall drei Leuten ) angeht. Ob da nun Git, SVN oder was auch zum Einsatz kommt ist erst einmal egal. Um die Koordination geht es. Aber so wie ich das verstehe muss sich da jeder an die eigene Nase packen und strickt an Absprachen, die gemeinsam getroffen wurden, halten muss. Das mit dem Scrum ist ja alles schön und gut aber wir haben ja gar nicht genug Leute, um jede "Rolle" zu besetzen ;-) Mich würde ja mal interessieren wie ein Bosch, Conti oder wer auch immer sowas händelt. An einem Mototsteuergerät arbeiten ja sicher mehr als drei Leute. Und die bekommen es ja auch gebacken.
Marius schrieb: > Mich würde ja mal interessieren wie ein Bosch, Conti oder wer auch immer > sowas händelt. An einem Mototsteuergerät arbeiten ja sicher mehr als > drei Leute. Man kaufe die teuersten Tools, weil deren Hersteller die glänzendsten Hochglanzprospekte und pomadigsten Vertriebler haben und die Einführung und der Unterhalt solcher Tools einen gewaltigen administrativen Aufwand bedeuten. Dadurch sichert man dann wieder ein paar (oder viele) Konzernbeamtenstellen. In solchen Projekten arbeiten die Entwickler häufig auch nicht kooperativer oder planvoller als anderweitig, sondern die Integrationsverantwortlichen müssen den Entwicklern hinterherrennen, um überhaupt kompilierbare Versionsstände zu finden. In sehr vielen Fällen resignieren irgendwann die Entwickler und synchronisieren ihre eigenen Arbeitskopien nur noch nach massivem Druck durch Projektverantwortliche. Ansonsten arbeiten sie teils monatelang abgekoppelt, so dass deren eingecheckte Versionen zwar in ihren alten Arbeitskopien kompilieren, aber nicht mehr kompatibel sind zu den eingecheckten Entwicklungsständen. All diese Probleme sind auch allen Projektbeteiligten bekannt, und jeder behauptet, darunter zu leiden, aber wer sich wirklich für eine fortwährende Synchronisation einsetzt, wird dafür nicht belohnt, da diese zwar extrem dem Projektfortschritt dient, ihn selbst aber bei der Implementierung der eigenen Arbeitspakete zeitlich zurückwirft. Wer aber in seiner asynchronen Arbeitskopie herumwurschtelt, kommt schneller voran. In meiner langjährigen Erfahrung auch bei Kunden vor Ort bin ich fast immer auf genau die oben beschriebenen Strukturen gestoßen. Je größer das Unternehmen und/oder das Projekt, desto ausgeprägter die mangelnde Synchronisation. > Und die bekommen es ja auch gebacken. Ein steter Tropfen höhlt den Stein. In vielen Fällen betrachte ich es aber eher als Zufall, wenn dort ein verkaufsfähiges Produkt entsteht.
Andreas hat das wunderbar beschrieben, genau so geht es oft in der Großindustrie ab. Und nicht nur in der Implementierung, sondern auch schon in der Planungsphase. Stichworte für ein gutes Gelingen sind: mehr miteinander reden, noch mehr miteinander reden (nicht labern), über den Tellerrand schauen was der Kollege macht Sich nicht zu große, regelmäßige Ziele setzen und dann zusammenwerfen und gemeinsam testen. REGELMÄSSIG! Verantwortliche für Teilgebiete benennen. Nicht Schuldige sondern Lösungen finden. ... Andreas Schweigstill schrieb: > Ein steter Tropfen höhlt den Stein. In vielen Fällen betrachte ich es > aber eher als Zufall, wenn dort ein verkaufsfähiges Produkt entsteht. Ich habe mal (kurz) bei der deutschen Bank gearbeitet und war da in einem Ausschuß in dem es um eine Traceschnittstelle ging. Einheitlich über mehrere Abteilungen hinweg. Da gab es regelmäßige Meetings, alle 14 Tage, schon seit über einem Jahr mit ständig wechselnden Personen. Das Ergebnis waren 2-3 Seiten Spec, die man mit einem guten Kollegen auch abends nach der Arbeit bei einem Bier genausogut hätte schreiben können.
:
Bearbeitet durch User
Udo Schmitt schrieb: > Nicht Schuldige sondern Lösungen finden. Und genau daran hapert es überall. Gerade bei zuzukaufenden Produkten (Tools, Software) wird sofort die Haftungsfrage gestellt. Und wenn es sich um freie Software handelt, kommt der Einwand: "Und wen verklagen wir, wenn die Software doch nicht so tut wie wir es uns erhoffen?" Die tatsächliche technische Eignung tritt vollkommen in der Hintergrund gegenüber solchen Themen.
Was bisher noch gar nicht angesprochen wurde, ist das Thema Anforderungen, also Requirements Management. Die besten Entwickler mit den besten Tools bekommen keine vernünftige Software hin, wenn die Anforderungen qualitativ schlecht, unvollständig, missverständlich, nicht gut trackbar sind. Ihr habt doch ein mit großer Sorgfalt geschriebenes Pflichtenheft, nicht wahr? :-)
Mark Brandis schrieb: > Ihr habt doch ein mit großer Sorgfalt geschriebenes Pflichtenheft, nicht > wahr? :-) Der war gut ;-) Wie gesagt es handelt sich um ein Projekt an der Uni. Daher wird implementiert, was der Prof möchte. Natürlich gibt es kurze schriftliche Beschreibungen und wir besprechen dann mit ihm die Details aber so professionell ist das ganze Projekt auch nicht, warum auch!? Also eine Open issue liste mit Excel führen wir schon, damit man auch einen Überblick hat. Die Software hat auch eine Softwarenummer und beim Umstieg von V1.0 auf V1.1 gibt es auch eine kurze Beschreibung mit den Änderungen. Also ganz so lasch wird das Projekt nicht gehändelt. Vielleicht soll ja gerade mit der Umstellung von drei auf einen Controller mehr Professionalität einhalten. Daher erkunden wir uns ja mit Büchern, Artikeln und auch hier wie die "Profis" so ein Projekt bewältigen.
Marius schrieb: > Mark Brandis schrieb: >> Ihr habt doch ein mit großer Sorgfalt geschriebenes Pflichtenheft, nicht >> wahr? :-) > > Der war gut ;-) > > Wie gesagt es handelt sich um ein Projekt an der Uni. Daher wird > implementiert, was der Prof möchte. Wichtig ist, einmal schriftlich und verbindlich festzuhalten "was der Kunde möchte". Wenn der nämlich immer wieder mit neuen Änderungswünschen kommt, am besten noch sehr spät im Projektverlauf, wird die Software niemals fertig. Aber vielleicht weiß Euer Prof das ja sehr genau und verhält sich intelligent. Das kann man von den echten Kunden in der Berufswelt da draußen leider nicht immer behaupten, und vom eigenen Vertrieb schon zehnmal nicht ;-)
:
Bearbeitet durch User
Mark Brandis schrieb: > Wichtig ist, einmal schriftlich und verbindlich festzuhalten "was der > Kunde möchte". Und genau damit wären wir dann aber wieder bei dem zuvor beschriebenen Problem, dass nicht das erfolgreiche Projekt im Vordergrund steht, sondern die Suche nach dem Schuldigen.
Wie soll Projekt erfolgreich sein, wenn keiner das Ziel kennt? Das Ziel zu formulieren hat doch nichts mit Schuld zu tun.
Klaus Wachtler schrieb: > Das Ziel zu formulieren hat doch nichts mit Schuld zu tun. Viele Projekte scheitern in der Tat daran, dass kein Ziel formuliert wurde und deswegen das Projekt wie Treibsand vor sich hinläuft und niemals fertig wird. Solche Projekte können aber durchaus noch von guten Entwicklern gerettet werden, indem sie selbst sinnvolle Ziele definieren und umsetzen. Genauso falsch ist es aber auch, von vornherein davon auszugehen, dass schon zu Beginn des Projektes alle Anforderungen in Stein gemeißelt werden können. So etwas wird aber durch das o.a. "einmal" impliziert. Dadurch wird solch ein Projekt sowohl an der Überspezifizierung von Details als auch Spezifikationslücken leiden. Und beides darf nicht mehr korrigiert werden, weil man ja beschlossen hat, die Festschreibung nur einmalig durchzuführen. Ganz wichtig ist bei einer guten Anforderungsanalyse, zwischen Problem- und Lösungsraum zu unterscheiden. Im Problemraum müssen Anforderungen möglichst vollständig, aber eng gefasst beschrieben werden, wohingegen die ersten Iterationen im Lösungsraum möglichst weit gefasst werden müssen, um mögliche Lösungswege nicht von vornherein auszuschließen. Und Anforderungen, die schon in den Lösungsraum vorgreifen, sind auch ausdrücklich als Randbedingungen zu definieren und dürfen nur sparsam eingesetzt werden, z.B. bei rechtlichen Anforderungen oder wenn ein Produkt in eine bestehende Landschaft eingefügt werden muss.
Andreas Schweigstill schrieb: > Mark Brandis schrieb: >> Wichtig ist, einmal schriftlich und verbindlich festzuhalten "was der >> Kunde möchte". > > Und genau damit wären wir dann aber wieder bei dem zuvor beschriebenen > Problem, dass nicht das erfolgreiche Projekt im Vordergrund steht, > sondern die Suche nach dem Schuldigen. Nein. Man kann nicht wild mit den Armen rudern, "macht mal irgendwas, aber gefälligst bis gestern" rufen, und sich dann hinterher beschweren wenn die Entwickler nicht das abliefern was der Kunde will. Auch wenn manch ein Projektmanager gerne so vorgeht. Edit: Vielleicht reden wir auch aneinander vorbei. Mit "einmal" habe ich nicht gemeint "exakt einmal, nicht mehr und nicht weniger". Sondern eher "mindestens einmal, aber hoffentlich auch nicht oft". Mit Änderungen an Requirements ist das halt so eine Sache. Wenn sie sinnvoll sind und noch früh genug passieren, meinetwegen. Trotzdem muss man mal begreifen, dass Softwareentwicklung dann gut funktioniert, wenn man mit stabilen und möglichst vollständigen Anforderungen an den Start geht. Dann kann man sich nämlich um die Dinge kümmern, um die man sich eigentlich kümmern sollte: Vernünftige Archtitektur, gutes Design, Code Reviews, ordentliches Testen. Diese Dinge kommen sonst regelmäßig zu kurz, wenn man sich andauernd mit unfertigen bzw. sich ändernden Anforderungen herumschlagen muss.
:
Bearbeitet durch User
Mark Brandis schrieb: > Vielleicht reden wir auch aneinander vorbei. Mit "einmal" habe ich nicht > gemeint "exakt einmal, nicht mehr und nicht weniger". Sondern eher > "mindestens einmal, aber hoffentlich auch nicht oft". Ach so, dann bestand darin das Missverständnis. > Mit Änderungen an Requirements ist das halt so eine Sache. Wenn sie > sinnvoll sind und noch früh genug passieren, meinetwegen. Anforderungsänderungen im Problemraum sind nach Möglichkeit zu vermeiden; ggf. kann später eine Verfeinerung vorgenommen werden, um Missverständnisse zu beseitigen oder festgestellte Lücken zu schließen. Die Spezifikation der daraus abgeleiteten Aufgaben im Lösungsraum sollte man ggf. aber sogar bewusst auf spätere Projektphasen verschieben, wenn man merkt, dass man noch nicht die erforderlichen Kenntnisse besitzt, um sie schon zu erstellen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.