FF Pro-Q 3 kommt....

  • Ersteller Gast92251
  • Erstellt am
Scrum hat nicht viel mit Produktentwicklung und -pflege zu tun

Oh doch, auch. Habe 3 Jahre in einem Unternehmen gearbeitet, in der die R&D Abteilung Scrum eingeführt hat - weg von monströsen Pflichtenheften, die nach 2 Wochen obsolet sind hin zu agiler Entwicklung - coden, testen, fixen, testen, releasen.
Hab ich auch schon oft in der Software Entwicklung gesehen.
 
So, auch mal getestet das Ding, und fliegt gleich wieder von der Platte. Der hat neben kein Attack und kein Release ja auch noch nicht mal eine Ratio, oder hab ich das übersehen?

Ich bleibe beim TB V4, ist für mich wesentlich intuitiver zu bedienen und bietet auch im Dynamic-Bereich den vollen Parameterumfang.
Was ich beim tbv4 vermisse ist eine undo Funktion und das man mehrere Bänder selektieren kann. Und die Ansicht aller EQs im Analyser
Wie im proq3 wäre schön nice. Aber ich bleib auch beim tbv4
 
  • Danke
Reaktionen: gyn
Ich habe mit dem Ding gestern ne PT Session unter Win10 gekillt. So hart, dass ich den Resetknopf drücken musste. Mal schauen, ob ich das reproduzieren kann.

Ich konnte es reproduzieren - der Q3 ist rehabilitiert. Es war die Waves Chamber, die Probleme gemacht hat.
 
Vielleicht sind diese ganzen SCRUM-Methoden/Vorgehensweisen in der IT doch nicht das gelbe vom Ei?

Scrum bedeutet anscheinend komplette Verblödung.
Nach dem Motto: da ich Teil eines ausgeklügelten Prozesses bin, kann ich mein Hirn einfach ausschalten.

Die nächste Totalverblödung heißt offenbar DevOps.
 
Scrum bedeutet anscheinend komplette Verblödung.
Nach dem Motto: da ich Teil eines ausgeklügelten Prozesses bin, kann ich mein Hirn einfach ausschalten.
Nö.

Ich sehs doch in meiner Firma hier. Scrum und alles andere BRINGT NICHTS.
Schaud Dir doch die ganzen Outputs von NI, Steinberg und Co an. Was bringt es? NICHTS.

Menschliche "Kurzsichtigkeit" läßt sich nicht überlisten. Die sollen lieber in einen Schachverein eintreten. Dann werden "normale" unerfahrene Programmierer regelmäßig so böse zusammengeschoben, bis sie endlich kapieren, daß ein Fehler der letzte sein kann. Dann denken die Leute mal ein paar Schritte voraus bei ihrem Treiben und können Implikationen hoffentlich besser abschätzen, außerdem muss man lernen, den Gesamtüberblick nie auf dem Auge zu verlieren, sehr nützlich. :)
 
Zuletzt bearbeitet:
Na bei dem Bug hofft man wenigstens auf einen anständigen Boxtone :)

Ich hab ProMB ... muss da mal horchen, was mit dem DynQ3 so viel anders klingt bevor ich überhaupt über ein Öpdeit nachthinke.
 
i han halt getried mal wieder ein wenig deutscher beim writen am been zu sein, weil's mich gesplasht han immer englisch zu posten... big sorry for that... ist ehrlich gesayt auch shice vong feeling her wenn dich k1 understanded in so 1 forum... never again, i promise!!!!!!einself
 
Ich sehs doch in meiner Firma hier. Scrum und alles andere BRINGT NICHTS.
Schaud Dir doch die ganzen Outputs von NI, Steinberg und Co an. Was bringt es? NICHTS.
Nun ja, das ist etwas anderes, wenn es nichts bringt. Aber das hat nichts mit dem Vorgehensmodell zu tun. Bei uns klappt das wunderbar und ich als Entwickler arbeite meine Jira-Tickets ab, die alle zwei Wochen mit uns besprochen und priorisiert werden.
Das hilft natürlich nicht, und da muss ich dir Recht geben, nicht gegen die menschlichen Eigenarten, bzw. kann diese grade ziehen. Das ist aber nicht der Anspruch eines Vorgehenmodells. Ich kann z.B. total schrottigen Code schreiben, Sonar ignorieren (da ich die Regeln dort selber festlege) trotzdem funktioniert alles für den User einwandfrei. Das Vorgehensmodell sollte schon an die Prozesse in einer Firma angepasst sein, sonst geht das nach hinten los "das haben wir schon immer so gemacht, das ändern wir nicht" sind die Mauern gegen die man mit agiler Entwicklung läuft. Außerdem sagt man, dass Scrum nur Sinn macht, wenn die Teamgröße 5 und mehr hat.
Wie jetzt hier bei FF scheint wohl ein QS-Problem vorzuliegen, es fehlten Testfälle, die gerne mal in die Definition of ready als Akzeptanzkriterium aufgenommen werden, aber das kann man auch anders gestalten, wichtig ist nur, DASS man es macht.
FF hat aber flott reagiert und ich kann mir vorstellen, dass die beiden rot angelaufen sind ;)
 
Nun ja, das ist etwas anderes, wenn es nichts bringt. Aber das hat nichts mit dem Vorgehensmodell zu tun. Bei uns klappt das wunderbar und ich als Entwickler arbeite meine Jira-Tickets ab, die alle zwei Wochen mit uns besprochen und priorisiert werden.

Wenn du alle zwei Wochen ein "Ticket" bekommst und abarbeitest, machst du nichts anderes als was ein Teil der Entwickler schon immer gemacht hat, Aufgaben festlegen, Aufgaben abarbeiten, nach dem Prinzip, was gerade am dringensten ansteht. Leider hat auch dieser Ansatz seine Grenzen, je nachdem, wie intelligent und demokratisch der Chef ist und offen für Vorschläge ist. Da hapert es oft.

Nur daß neumodische Spinner die Ticket-Methode jetzt so nennen, wie sie meinen, daß es aktuell klingt (oho wir sind aber ein "modernes" Unternehmen). Der beste Ansatz ist der, daß möglichst viele Entwickler gut darüber informiert sind und ein gutes Verständnis haben, wie das Gesamtsystem funktioniert und mit wem sie bei Bedarf was zu besprechen hätten und sich gegenseitig beflügeln (ganz selten!), dann funktionert nämlich auch die Qualitätskontrolle besser, wenn die eigene Intuition Alarm schlägt. Das gilt aber unabhängig von Scrum. Ich war mal in einem angesehenen Forschungslab, und dort funktionerte die einfachste Methode am besten (nämlich gar keine). Scrum usw. brauchten die nicht. Es wurde dynamisch entschieden, wer was macht, je nachdem, wer sich wie profiliert hat, und sei es nur tendentiell. Maximale Flexibilität sozusagen.

Statt also auf natürliche Weise zusammenzuarbeiten mit einem gewissen Instinkt für vernunftbegabtes Arbeiten, denkt man sich so einen gekünstelten Bullshit aus. Und du wirst sehen, die Halbwertszeit von Scrum beträgt höchstens 5 Jahre, das ist mal so meine Behauptung.
 
Zuletzt bearbeitet:
Well said @synthpark
 
Scrum hat sich in unserer Firma seit Jahren extrem gut bewährt. Man darf nur nicht den Fehler machen, es über einen Kamm zu scheren und für jedes Team zur Vorgabe zu machen. Ich selbst arbeite in einer Querschnittsabteilung, d.h. wir erstellen technische Basiskomponenten, die von den Projekt-Teams genutzt werden. Ich bin nicht an der Produktentwicklung beteiligt sondern arbeite den entsprechenden Teams zu und stehe darüber hinaus als Consultant zur Verfügung. Folglich ist für mich Scrum ein völlig ungeeignetes Modell, und daher praktizieren wir das auch in unserem Team nicht. In den Projekt-Teams läuft aber die Entwicklung wesentlich strukturierter und vernünftiger ab, seit Scrum Einzug gehalten hat.
 

Ähnliche Themen

BasementBluesBoy
Antworten
0
Aufrufe
406
BasementBluesBoy
BasementBluesBoy
pieffa
Antworten
6
Aufrufe
337
pieffa
pieffa
ollo123
Antworten
4
Aufrufe
325
ollo123
ollo123
mkzwoo
Antworten
0
Aufrufe
322
mkzwoo
mkzwoo
BasementBluesBoy
Antworten
22
Aufrufe
1K
BasementBluesBoy
BasementBluesBoy

Neue Antworten


Oft gelesene Themen

Zurück
Oben