Ghid Scrum | 14. Greșeli ale dezvoltatorilor

Publicat: 2022-04-26

Echipa de dezvoltare este un grup de profesioniști independenți. Cu toate acestea, succesul proiectului pe care îl implementează depinde de eforturile lor comune. Și asta necesită multă maturitate și abilități de lucru în echipă. Care sunt cele mai frecvente greșeli ale dezvoltatorilor? Care dintre ele fac ca urmărirea obiectivului de produs să fie dificilă sau chiar imposibilă?

Greșeli frecvente ale dezvoltatorilor – cuprins:

  1. Greșeli frecvente ale dezvoltatorilor
  2. A fi prea atașat de ideile tale
  3. Ocuparea Forței de muncă de sine
  4. Retragerea dezvoltatorului
  5. Independenţă
  6. Limitarea responsabilităților la sfera de autoritate
  7. Sprint Backlog Clutter
  8. rezumat

Greșeli frecvente ale dezvoltatorilor

Multe dintre greșelile dezvoltatorilor care lucrează în Scrum își au originea în abordarea lor față de munca în echipă. Pe de o parte, este greșit înțeles independența și apărarea ideilor cuiva împotriva intereselor echipei. Pe de altă parte, se bazează pe alții și pe lipsa de independență. O altă sursă de probleme poate fi o înțelegere greșită a responsabilității echipei.

The most common mistakes of Developers

A fi prea atașat de ideile tale

Responsabilitățile zilnice ale dezvoltatorilor includ găsirea de soluții inovatoare la probleme complexe. Efortul depus în dezvoltarea soluțiilor îi poate determina să se atașeze excesiv de ideile lor. Acest lucru, la rândul său, îi face să piardă din vedere Obiectivul produsului și să petreacă prea mult timp dezvoltării de soluții secundare care nu sunt utile din perspectiva afacerii. Și sunt, de asemenea, mai puțin dispuși să caute soluții alternative, ceea ce amenință agilitatea echipei.

Ocuparea Forței de muncă de sine

Dacă vreun dezvoltator are dificultăți în a înțelege rolul său în echipă, va încerca să-și separe sarcinile de obiectivul de sprint. Mai rău încă, le vor face fără referire la restul echipei. De asemenea, poate deveni o problemă dacă efectuează în mod arbitrar modificări în Sprint Backlog. Acesta este modul în care independența neînțeleasă a unuia dintre Dezvoltatori poate decurge din probleme de comunicare.

O dorință excesivă de independență poate fi înrădăcinată într-o lipsă de recunoaștere a realizărilor individuale ale unui Dezvoltator . Apare atunci când contribuția sa la munca depusă de echipă este evaluată disproporțional cu efortul depus și cu dificultatea sarcinii.

Lucrul pe cont propriu poate deveni o sursă de conflict serios în cadrul echipei. De aceea este atât de important ca Scrum Master să reacționeze și să rezolve problema de bază cât mai curând posibil. Acest lucru se datorează faptului că se poate dovedi că greșeala nu aparține Dezvoltatorului, ci o evaluare incorectă a implicării lor.

Retragerea dezvoltatorului

Problema rezultată din cele două anterioare – lucrul pe cont propriu și atașarea excesivă a propriilor idei – poate fi o problemă de lipsă de comunicare. Apoi acei Dezvoltatori încep să se izoleze de echipă. Deși își îndeplinesc sarcinile conform Sprint Backlog, se retrag din viața Echipei.

Într-o astfel de situație, Scrum Master ar trebui să acorde o atenție deosebită dezvoltatorilor retrași. Apreciază contribuția lor la echipă și încurajează-i să adopte o atitudine proactivă.

Independenţă

Auto-organizarea este o caracteristică a unei Echipe de Dezvoltare mature, bine compuse, pe care am descris-o într-un articol anterior. Înseamnă că, în ciuda dificultăților, dezvoltatorii nu se bazează pe alți oameni pentru a le spune cum să distribuie sarcinile între ei, cum și când să le finalizeze. Cu toate acestea, auto-organizarea poate da naștere la neînțelegeri interpersonale.

Într-un astfel de caz, este necesar să aveți Scrum Master prezent în orice moment pentru a vă asigura că sarcinile care trebuie făcute pentru a atinge Scopul Sprintului sunt distribuite. Acesta este momentul în care apare problema dependenței dezvoltatorilor .

Din nou, Scrum Master ar trebui să vină în ajutor, încurajând membrii echipei de dezvoltare să fie autodeterminați și să își asume responsabilitatea pentru sarcinile lor.

Limitarea responsabilităților la sfera de autoritate

O altă problemă cu care trebuie să se confrunte Dezvoltatorii, în special în cadrul echipei de formare, este lipsa de dorință de a îndeplini alte sarcini decât cele care aparțin competențelor de bază ale Dezvoltatorului.

Această greșeală poate duce la o reducere semnificativă a eficienței echipei de dezvoltare. Nu toate Sprinturile folosesc competențele de bază ale fiecărui membru al echipei. Prin urmare, trebuie să fie deschiși să îndeplinească alte sarcini auxiliare sau de organizare care sunt la fel de relevante pentru Scopul Sprintului.

common mistakes

Sprint Backlog Clutter

O astfel de sarcină este menținerea în ordine a Sprint Backlog. Este o sarcină cheie pentru buna funcționare a echipei de dezvoltare. Cu toate acestea, o greșeală comună este schimbarea responsabilității pentru păstrarea acesteia între Dezvoltatori. Acest lucru împiedică nu numai munca la obiectivul Sprintului, ci și dezvoltarea echipei și îmbunătățirea continuă a acesteia.

Greșeli frecvente ale dezvoltatorilor -rezumat

În rezumat, cele mai frecvente greșeli ale dezvoltatorilor includ încercările de a se separa de echipă în ansamblu: lucrul pe cont propriu, împingerea propriilor idei și devenirea retrasă. Integritatea echipei de dezvoltare este, de asemenea, amenințată de problemele legate de dezvoltarea independenței, dezordinea în Sprint Backlog și lipsa de dorință a dezvoltatorilor de a îndeplini sarcini în afara competențelor lor de bază.

Dacă vă place conținutul nostru, alăturați-vă comunității noastre de albine ocupate pe Facebook, Twitter, LinkedIn, Instagram, YouTube.

Scrum Guide | 14. Mistakes of Developers caroline becker avatar 1background

Autor: Caroline Becker

În calitate de manager de proiect, Caroline este expertă în găsirea de noi metode de a proiecta cele mai bune fluxuri de lucru și de a optimiza procesele. Abilitățile ei de organizare și capacitatea de a lucra sub presiunea timpului o fac cea mai bună persoană pentru a transforma proiectele complicate în realitate.

Vizualizați toate postările

Ghid Scrum:

  1. Glosar de termeni de bază, roluri și noțiuni
  2. Ce este Scrum?
  3. Valorile Scrum
  4. Cum implementezi Scrum în compania ta?
  5. Echipa Scrum - ce este și cum funcționează?
  6. Cine este un proprietar de produs?
  7. Cele mai frecvente greșeli ale Product Ownerului
  8. Cine este Scrum Master?
  9. Caracteristicile unui bun Scrum Master
  10. Cele mai frecvente greșeli ale Scrum Master
  11. Ce statistici și valori ar trebui să urmărească Scrum Master?
  12. Cooperare între Product Owner și Scrum Master
  13. Echipa de dezvoltare în Scrum
  14. Cele mai frecvente greșeli ale dezvoltatorilor
  15. Artefacte Scrum
  16. Scaling Scrum
  17. Sprint Backlog
  18. Ce este Product Backlog?
  19. Ce sunt User Stories?
  20. Crearea celei mai bune povești de utilizator cu INVEST
  21. Cele mai frecvente greșeli ale User Story
  22. Criterii de acceptare a poveștii utilizatorului
  23. Estimare și Story Points în Scrum
  24. Planificarea Pokerului
  25. Joc de estimare a echipei
  26. Definirea creșterii
  27. Evenimente Scrum
  28. Ce este Sprint în Scrum?
  29. Angajamentele echipei Scrum - Obiectiv de produs, obiectiv de sprint și definiția finalizării
  30. Ce este un grafic Burndown?
  31. Cum se creează și se interpretează un grafic de ardere?
  32. Avantajele și dezavantajele diagramei de ardere
  33. Panouri Kanban în Scrum și Scrumban
  34. Viteza în Scrum - Viteza echipei de dezvoltare
  35. Scrum zilnic
  36. Planificarea sprintului
  37. Sprint Review
  38. Ce este o retrospectivă Sprint?
  39. Greșeli frecvente în timpul unei retrospective de sprint
  40. Creșterea backlog-ului de produse