Mozilla beschleunigt Firefox-Entwicklung mit "Sprints"

Browser Mozilla will mit einem neuen, beschleunigten Entwicklungsrhytmus dafür sorgen, dass neue Funktionen bei seinem Browser Firefox schneller für die Anwender verfügbar sind. Die Entwickler bezeichnen das Vorgehen als "Sprint"-Zyklus. mehr...

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Scrum Sprints wenden wir hier in der Firma auch an - macht teilweiße echt schneller. Wissen wird verteilt, klare Ziele gesetzt und somit weiß jeder, was er zu tun hat.
 
@Mister-X: jops, machen wir auch. Am Ende des Sprints steht immer ein Release. Features die noch nicht vollständig sind werden via Pre-Prozessor-Direktiven inaktiviert. Aber Scrum Sprints sind nicht wirklich leicht. Man kann mit unter große Probleme bei der Zeit bekommen.
 
also arbeiten sie nicht schneller, sondern erstellen nur mehr releases. tolle neuerung!!!111
 
@ouzo: Im Text steht ja nur die Hälfte über das Sprint Prinzip
 
@ouzo: FALSCH...nachlesen hilft: http://de.wikipedia.org/wiki/Scrum
 
@Mister-X: geht auch um firefox und nicht direkt ums sprint dingens.. winfuture is ja keine enzyklopädie :P :P
aber eigentlich garnich mal schlecht :P
 
@Mister-X @ DavyJones: Weder hier im Artikel noch in der Quelle steht etwas über Scrum. Ohne den Wikipedia-Artikel komm ich nunmal genau auf diesen o.g. Schluß. Ob der Grund nun darin liegt, dass dieser ominöse Firefox architect nun selbst es nicht ordentlich erklärt hat oder schlecht von Winfuture kopiert wurde ist dabei unwichtig.
 
@ouzo: Selbst ich, der sich nichts unter dem Titel "Sprints" vorstellen kann, außer dass die Entwicklung schneller gehen soll, hat mit Hilfe dieser News herausgelesen, dass verschiedene neue Funktionen jetzt quasi einzeln entwickelt und dann eingebaut werden. Statt also 6 Leute, die zusammensitzen und 2 Funktionen gleichzeitig entwickeln, werden jetzt 2 mal 3 Leute separat hingesetzt, die jeweils nur eine neue Funktion programmieren. Damit fallen von der einen Gruppe jeweils die Probleme der anderen Gruppe weg, die Aufgabenstellugn wird etwas leichter, die Entwicklung geht schneller.
 
@ElDaRoN: das wird sich noch zeigen ob das funktionieren wird, ergo wird nur mehr rlzes geben und diese werden weniger neu Funkionen haben.
 
@ElDaRoN: und da jetzt nur noch die hälfte der leute an einer neuen funktion arbeiten, dauert das ganze doppelt so lange und der code wird von weniger leuten begutachtet, was schlechteren code zur folge haben kann. was kommt also am ende dabei raus? mehr funktionen, weniger umfangreiche/qualitativ schlechtere neuerungen, mehr releases. kommt also am ende genau das raus was ich gesagt habe. dass da noch ein paar andere faktoren hineinspielen ist mir klar, aber im groben kann man es so betrachten. ob es also ein schnelleres arbeiten zur folge hat steht weiter in den sternen.
 
@ouzo: Ach so und mit doppelt so viel Entwicklern geht es dann doppelt so schnell. Das ist eine ziemliche Milchmädchenrechnung, was du dir da zurecht dichtest. Lass die Leute, die Ahnung von Entwicklung haben, mal machen.
 
@Crod: vielleicht solltest du deine vermeintliche ahnung von meinen softwareentwicklungskenntnissen nicht so laut rumposaunen, denn du kannst genauso wenig einschätzen wieviel ahnung ich habe, wie andersherum. nebenbei: "dass da noch ein paar andere faktoren hineinspielen ist mir klar". diese aussage scheinst du überlesen zu haben.
 
@ouzo: Nein, es dauert eben nicht doppelt so lange. Ein einfaches Beispiel: Beide Gruppen á 3 Leute haben den Quellcode der aktuelle Version des Firefox als Basis. Jetzt soll Gruppe 1 zum Beispiel einen Auto-Updater einbauen und Gruppe 2 einen simplen PlugIn-Manager. Da sich beide Gruppen nur auf ihre jeweils eigene Aufgabe (= Ziel) konzentriert, werden alle anderen Probleme, die nicht zu ihrer Aufgabe gehören ignoriert. Ihr kleiner Teil, der ihnen anvertraut wurde, muss halt nur am Ende reibungslos funktionieren. Hätte man sie nicht getrennt müssten sie beide Aufgaben parallel und zusammen lösen. Da kann es vermehrt zu Konflikten kommen, denn: Je mehr Menschen an etwas beteiligt sind, desto fehleranfälliger wird das Ganze. Das liegt daran, dass alle 6 Leute sich um beide Aufgaben kümmern und z.B. die Aufgabenverteilung nicht genau aufgeht, so dass zwei sich um das selbe Problem kümmern, aber verschiedene Ansichten haben. Mozilla macht also eigentlich nichts anderes, als die Programmierergruppen zu verkleinern und gibt jeder Gruppe ein einzelnes Ziel, statt mehrerer Ziele (oder zumindest weniger, aber dafür mehr zusammengehörende). Das ist ungefähr wie beim Programmieren selbst: Du sollst mit Bubble-Sort eine Liste sortieren. Also schreibst du erst, wer in welchem Fall mit wem tauschen soll (Aufgabe 1, if-else-Abfrage) und dann wie oft du das wiederholen musst, um die ganze Liste zu sortieren (Aufgabe 2, for-Schleifen). Das ist jetzt alles sehr stark vereinfacht, aber es dient nur zum Verständnis.
 
@ElDaRoN: und du denkst bisher haben sich die entwickler immer mit anderen als ihren eigenen aufgaben beschäftigt? oder gab es etwa gar keine aufteilung und alle entwickler haben nur stumpf gleichzeitig ohne aufteilung an mehreren themen gleichzeitig gearbeitet und drauf los gecodet? eine aufteilung muss es vorher schon gegeben haben. kann mir keiner erzählen, dass mozilla so unorganisiert gearbeitet hat. es wird nur fehleranfälliger durch schlechte absprachen. und verschiedene ansichten kann man immernoch auch mit nur zwei entwicklern haben.
 
Demnächst können sich Firefox-Nutzer also nicht mehr über Opera-mäßige Versionsnummern beschweren :)
 
@f!R: Ich sag nur Chromium. Da kommen täglich zig neue Builds raus^^ Siehe http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/
 
Mir egal. Google Chrome lässt den lahmen und trägen Firefox jetzt schon ganz alt aussehen! Chrome gehört die Zukunft, dem Fuchs die Vergangenheit.
 
@Bud Seks: solange Chrome nicht ein vergleichbares Plugin wie den FireBug besitzt, ist Chrome für mich keine Alternative, aber schön das er dir gefällt, vllt. tut sich da mal noch was in Richtung Plugins.
 
@Yogort: Chrome bringt eigentlich schon von Haus aus vergleichbare Tools mit. Schau mal auf der Support-Seite von Chrome nach Debugging-Tools...
 
@sibbl: das hört sich interessant an, kannst du mal nen Link posten?
 
Bin auch zu Opera gewechselt und kehre garantiert nicht mehr zum Fx zurück. Tschüssikovski.
 
lauf Forest! Lauf!
Kommentar abgeben Netiquette beachten!