Διαχείριση έργων στο SCRUM

Πώς λειτουργεί;

Στην πράξη, αυτό σημαίνει ότι ολόκληρη η διαδικασία βελτιστοποιείται συνεχώς και προσαρμόζεται στις ανάγκες του ομάδα και το προϊόν καθ' όλη τη διάρκεια των εργασιών για το έργο. Ευθύνη για τη διαχείριση ανάπτυξη προϊόντων κατανέμεται μεταξύ του ιδιοκτήτη του προϊόντος (PO) και της ομάδας σχεδιασμού. Ο PO είναι το πρόσωπο που είναι υπεύθυνο για τη λήψη αποφάσεων σχετικά με την κατεύθυνση της ανάπτυξης του προϊόντος και έχει ένα ολιστικό "όραμα" για το τι πρόκειται να γίνει το προϊόν. Η διαχείριση των εργασιών βασίζεται στον πίνακα Kanban (σε συνδυασμό με το σπριντ λειτουργικότητα που ονομάζεται συμβούλιο SCRUM). Κάθε συμμετέχων στη διαδικασία μπορεί να προσθέσει εργασίες στο backlog, αλλά ο OP είναι υπεύθυνος για τον καθορισμό των προτεραιοτήτων. Η ομάδα έργου είναι υπεύθυνη για τη "μετατροπή" των ιδεών του ΟΠ σε συγκεκριμένες εργασίες και τον προγραμματισμό της υλοποίησής τους.

Πορεία του κύκλου

Η διαδικασία χωρίζεται σε επαναλήψεις (sprints). Στο πλαίσιο ενός sprint διάρκειας περίπου 2 εβδομάδων, η ομάδα έργου υλοποιεί και δοκιμάζει το προηγουμένως προγραμματισμένο μέρος της λειτουργικότητας.

Το σπριντ ξεκινά με τον "προγραμματισμό", όπου η ομάδα συζητά και προετοιμάζει τις εργασίες που έχουν προηγουμένως προετοιμαστεί και οριστεί από τον PO στην κορυφή του backlog. Στη συνέχεια, εκτιμάται η δυσκολία αυτών των εργασιών και δίνονται πόντοι ανάλογα με τη δυσκολία. Με σχετικά σταθερή σύνθεση της ομάδας και συνθήκες εργασίας, ο αριθμός των πόντων που εκτελούνται σε κάθε sprint είναι επαναλαμβανόμενος και επιτρέπει τον προγραμματισμό των μελλοντικών εργασιών. Στο τέλος της συνάντησης σχεδιασμού, επιλέγονται εργασίες με συνολικό αριθμό πόντων που πρέπει να ολοκληρωθούν εντός ενός sprint και ξεκινά ένα νέο sprint.

Στη μέση του σπριντ, γίνεται η προετοιμασία. Πρόκειται για μια συνάντηση κατά την οποία ο OP παρουσιάζει στην ομάδα περαιτέρω προσδοκίες και ιδέες, ενώ η ομάδα έργου τις αναλύει, τις αναλύει σε μικρότερες εργασίες και παρουσιάζει πιθανές προτάσεις στον OP. Κατά τον σχεδιασμό των μελλοντικών εργασιών, ο OP συμβουλεύεται τους αναλυτές, τους χρήστες, τους σχεδιαστές UX και τους γραφίστες. Πρόσθετες αναλύσεις (αγορά έρευνα και επιστήμη των δεδομένων) συχνά απαιτούνται σε αυτό το στάδιο. Μόνο μετά την ανάλυση και τη διατύπωση της λεγόμενης Ιστορίας Χρήστη ο PO θα δημοσιεύσει αυτές τις Ιστορίες σε ένα backlog. Το User Story θα πρέπει να περιέχει πληροφορίες σχετικά με το τι περιμένει ο ΕΠ από μια συγκεκριμένη εργασία ή ομάδα εργασιών και σχετικά με τα κριτήρια που θα πρέπει να χρησιμοποιηθούν για να αναγνωριστεί αν η εργασία έχει ολοκληρωθεί.

Κατά τη διάρκεια του σπριντ, οι λεγόμενες "καθημερινές συναντήσεις" πραγματοποιούνται σε καθημερινή βάση. Σε αυτές τις συναντήσεις, κάθε προγραμματιστής ενημερώνει την υπόλοιπη ομάδα για το τι έκανε την τελευταία ημέρα και ενδεχομένως ενημερώνει για τυχόν προβλήματα ή μπλοκαρίσματα που εμποδίζουν την περαιτέρω εργασία του. Χάρη σε αυτή την ανταλλαγή της τρέχουσας κατάστασης, είναι δυνατόν να εντοπιστούν πολύ πιο γρήγορα πιθανές συγκρούσεις μεταξύ διαφόρων εργασιών και να αποφευχθεί η κατάσταση όπου ο προγραμματιστής κολλάει σε ένα πρόβλημα και δεν μπορεί να προχωρήσει σε αυτό. Η υπόθεση της καθημερινής συνάντησης εργασίας πρέπει να είναι όσο το δυνατόν πιο σύντομη, αλλά ταυτόχρονα να εκπληρώνει το ρόλο της. Η μόνιμη φόρμουλα της συνάντησης ενθαρρύνει την ομάδα να τη διατηρεί σύντομη.

Κατά τη διάρκεια του σπριντ, οι εργασίες μετακινούνται στον πίνακα SCRUM ανάλογα με την τρέχουσα κατάστασή τους. Η επιλογή των στηλών αντιστοιχεί συνήθως στο σύστημα εργασίας των εταιρειών ή της ομάδας και συνδέεται με το σύστημα ελέγχου εκδόσεων και τη συχνότητα των εκδόσεων. Για εμάς έχει ως εξής:

• To do - εργασίες που περιμένουν να ολοκληρωθούν
• Σε εξέλιξη - εργασίες σε εξέλιξη
• Κωδικός αναθεώρηση - εργασίες που περιμένουν να ελεγχθούν από άλλον προγραμματιστή
• Προετοιμασία - εργασίες που ελέγχονται και γίνονται αποδεκτές από τους προγραμματιστές
• Σταδιακά - εργασίες που βρίσκονται σε μια περίπτωση σταδιακής επεξεργασίας και περιμένουν έγκριση PO
• Αποδεκτές - εργασίες που έγιναν δεκτές από τον PO
• Έτοιμο - έτοιμες εργασίες που βρίσκονται στην παράσταση παραγωγής

Μετά το σπριντ, πραγματοποιείται μια αναδρομή. Πρόκειται για μια συνάντηση αφιερωμένη στη βελτιστοποίηση της εργασίας. Όλη η ομάδα συζητά τι πήγε καλά στο τελευταίο σπριντ και τι χρειάζεται βελτίωση. Συχνά αναφερόμαστε επίσης στην προηγούμενη αναδρομή και ελέγχουμε αν καταφέραμε να εφαρμόσουμε όλες τις ιδέες για τη βελτίωση της εργασίας. Τα προβλήματα που συζητούνται στην αναδρομή μπορεί να είναι οτιδήποτε, από εργαλεία ανάπτυξης, μέσω της πίεσης, της δυσκολίας των εργασιών, μέχρι προβλήματα επικοινωνίας (τόσο μεταξύ των προγραμματιστών και της ομάδας όσο και του PO).

Αρμοδιότητες του SCRUM master

Ο υπεύθυνος για την ορθή διεξαγωγή της διαδικασίας SCRUM είναι ο SCRUM master. Αυτός είναι συχνά ο πιο ακατανόητος ρόλος στην ομάδα. Ο SCRUM master δεν έχει καμία εξουσία λήψης αποφάσεων. Οι αποφάσεις λαμβάνονται από κοινού από την ομάδα και τον PO, ενώ ο ρόλος του SCRUM master είναι να απομακρύνει τα εμπόδια στην ορθή πορεία της διαδικασίας.

Τα καθήκοντα του SCRUM master περιλαμβάνουν τα εξής:

• Διεξαγωγή συναντήσεων SCRUM, συμπεριλαμβανομένου του σχεδιασμού, της προετοιμασίας, της καθημερινής συνάντησης standup και της αναδρομής
• Διασφάλιση ότι οι εργασίες στον πίνακα SCRUM φροντίζονται τακτικά από την ομάδα και ιεραρχούνται από τον PO.
• Λειτουργεί ως συνδετικός κρίκος μεταξύ της ομάδας και της PO- ως εκ τούτου, συχνά ο SCRUM master είναι αυτός που έχει δύσκολο ρόλο στη μετάφραση της γλώσσας των προγραμματιστών στη γλώσσα των επιχειρήσεων και αντίστροφα. Αυτό οφείλεται στο γεγονός ότι, στην εταιρεία μας, ο SCRUM master είναι προγραμματιστής, άρα τεχνικός. Το γενικό πλαίσιο της εργασίας του SCRUM master δεν απαιτεί κάτι τέτοιο.
• Σταμάτημα της ομάδας από το να ξεφεύγει από το θέμα και φύλαξη της ημερήσιας διάταξης στις συνεδριάσεις
• Μέριμνα για την ατμόσφαιρα στην ομάδα - κυρίως στις συναντήσεις.
• Επίλυση συγκρούσεων εάν προκύψουν.

Διαβάστε επίσης:

• Οι καλές πρακτικές της Codest για την κατασκευή λογισμικού. Η προσέγγισή μας στο ταξίδι του πελάτη
• Οι καλές πρακτικές της Codest για την κατασκευή λογισμικού: GitFlow
• Οι καλές πρακτικές της Codest για την κατασκευή λογισμικού. Πώς υλοποιούμε την ανάλυση απαιτήσεων;