Μεθοδολογία Agile: Ένας οδηγός για αρχάριους για την ευέλικτη μέθοδο και το Scrum

agile methodology beginner s guide agile method

Δοκιμάστε Το Όργανο Μας Για Την Εξάλειψη Των Προβλημάτων

Επιλέξτε Το Λειτουργικό Σύστημα Επιλέξτε Ένα Πρόγραμμα Προβολής (Προαιρετικά)

Περιγράψτε Το Πρόβλημά Σας

Ένας πλήρης οδηγός για την ευέλικτη μεθοδολογία: (20+ Λεπτομερή μαθήματα μεθοδολογίας Agile Scrum)

Αυτός είναι ο οδηγός για τους προγραμματιστές λογισμικού και τους δοκιμαστές για να κατανοήσουν και να αρχίσουν να εργάζονται για τα πολύ διάσημα Μεθοδολογία Agile SCRUM για ανάπτυξη και δοκιμή λογισμικού . Μάθετε τις βασικές αλλά σημαντικές ορολογίες που χρησιμοποιούνται στη διαδικασία Agile Scrum μαζί με ένα πραγματικό παράδειγμα της πλήρους διαδικασίας.

Έχουμε απαριθμήσει όλα τα Agile Tutorials σε αυτήν τη σειρά για την εξυπηρέτησή σας. Ελπίζω ότι θα σας βοηθήσουν πάρα πολύ.

Θέματα που καλύπτονται: Τι είναι το Agile, Τι είναι το Scrum, Μεθοδολογία Agile στην ανάπτυξη και δοκιμή λογισμικού, Agile Testing, Agile Scrum Process, Scrum Methodology with Scrum Team και Scrum Master.

εισαγωγή στην ευέλικτη ανάπτυξη

Τι θα μάθετε:

Λίστα μαθημάτων ευέλικτης μεθοδολογίας
Εισαγωγή στην ευέλικτη ανάπτυξη
Ευέλικτη μεθοδολογία
Μεθοδολογία Scrum

Λίστα μαθημάτων ευέλικτης μεθοδολογίας

ΠΕΡΙΣΣΟΤΕΡΑ Προτεινόμενα μαθήματα Agile Scrum:

Εκμάθηση # 11: Κορυφαίες τεχνικές εκτίμησης ευκίνητων
Εκμάθηση # 12: Ευκίνητο υβριδικό μοντέλο καταρράκτη
Εκμάθηση # 13: Kanban vs Scrum εναντίον Agile
Εκμάθηση # 14: Εκμάθηση JIRA Agile
Εκμάθηση # 15: Ευέλικτες αναδρομικές συναντήσεις
Εκμάθηση # 16: Ο ρόλος των επιχειρηματικών αναλυτών στο SCRUM
Εκμάθηση # 17: Ο ρόλος της QA στο Scrum

Εργαλεία και ερωτήσεις συνέντευξης:

Εκμάθηση # 18: Εργαλεία ευέλικτης δοκιμής
Εκμάθηση # 19: Τα καλύτερα εργαλεία διαχείρισης έργων Agile
Εκμάθηση # 20: Κορυφαίες ευέλικτες ερωτήσεις συνέντευξης
Εκμάθηση # 21: Κορυφαίες ερωτήσεις συνέντευξης Scrum

Ας ξεκινήσουμε με το πρώτο σεμινάριο της σειράς - Agile Scrum Introduction.

Εισαγωγή στην ευέλικτη ανάπτυξη

Agile στην ανάπτυξη λογισμικού:

Το Agile είναι ένα από τα πιο ευρέως χρησιμοποιούμενα και αναγνωρισμένα πλαίσια ανάπτυξης λογισμικού στον κόσμο.

Οι περισσότεροι από τους οργανισμούς το έχουν υιοθετήσει σε κάποια μορφή ή στην άλλη, αλλά υπάρχει ακόμη πολύς δρόμος για να ωριμάσουν τα προγράμματα υιοθέτησής τους. Ο μοναδικός στόχος αυτής της σειράς σεμιναρίων είναι να ενσωματωθούν επαγγελματίες τεχνολογίας και μη τεχνολογίας στον Agile World.

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

Αυτό το συγκεκριμένο σεμινάριο είναι αφιερωμένο να σας εξηγήσει γιατί υπήρχε ανάγκη για Agile και πώς δημιουργήθηκε. Το βασικό εδώ είναι να σας κάνει να κατανοήσετε την έννοια του Agile Adoption στις Βιομηχανίες Ανάπτυξης Λογισμικού.

Ιστορία του Agile

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

Εκείνη την εποχή, η ανάπτυξη λογισμικού συνέβαινε τόσο πολύ που μέχρι τη στιγμή που τα έργα ήταν έτοιμα να παραδοθούν, η επιχείρηση είχε προχωρήσει και οι απαιτήσεις είχαν αλλάξει. Έτσι, ένα έργο δεν μπόρεσε να καλύψει τις επιχειρηματικές ανάγκες ακόμη και αν ήταν σε θέση να επιτύχει τους καθορισμένους στόχους του.

Έτσι συγκεντρώθηκαν αυτοί οι πρωταθλητές διαφορετικών τεχνικών λογισμικού και το τελικό αποτέλεσμα της συνάντησής τους ήταν αυτό που αποκαλούσαν «ευκίνητο μανιφέστο» το οποίο θα συζητήσουμε λεπτομερώς στο επόμενο σεμινάριο αυτής της σειράς.

Αλλά η ευελιξία που γεννήθηκε εκείνη την ημέρα δεν είναι αυτό που βλέπουμε σήμερα σε οργανισμούς. Η μεθοδολογία που συμφώνησαν οι ειδικοί περιγράφεται ως «ελαφριά» και γρήγορη. Αλλά η κύρια νίκη αυτής της συνάντησης ήταν η σκέψη ότι η ταχύτερη παράδοση ενός προϊόντος και η συνεχής ανατροφοδότηση ήταν τα κλειδιά για την επιτυχία στην ανάπτυξη λογισμικού.

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

Ήθελαν μια λύση που θα είχε περιθώριο για συνεχή ανατροφοδότηση προκειμένου να αποφευχθεί το κόστος της επανεπεξεργασίας σε μεταγενέστερο στάδιο.

Ευέλικτες προκλήσεις

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

Αυτό σήμαινε ότι δεν υπήρχε περιθώριο διόρθωσης των μαθημάτων και ο πελάτης δεν είχε άποψη για την πρόοδο έως ότου ολόκληρο το προϊόν ήταν έτοιμο. Και αυτό ήθελαν να αποφύγουν αυτοί οι ειδικοί. Ήθελαν μια λύση που θα είχε περιθώριο για συνεχή ανατροφοδότηση προκειμένου να αποφευχθεί το κόστος της επανεπεξεργασίας σε μεταγενέστερο στάδιο.

Και αυτός είναι ο λόγος για τον οποίο η ευέλικτη είναι επίσης η προσαρμοστική και συνεχής βελτίωση, όπως και η συνεχής ανατροφοδότηση και η ταχύτητα παράδοσης.

Τι είναι οι ευέλικτες υποσχέσεις;

Ευκίνητες υποσχέσεις

Το Agile δεν αφορά μόνο την εφαρμογή των καθορισμένων πρακτικών στην ανάπτυξη λογισμικού. Επίσης, φέρνει μια αλλαγή στη νοοτροπία της Ομάδας που τους οδηγεί στην οικοδόμηση καλύτερου λογισμικού, σε συνεργασία και τελικά σε έναν ευχαριστημένο πελάτη.

Οι ευέλικτες αξίες και αρχές επιτρέπουν στην ομάδα να αλλάξει την εστίασή της και να αλλάξει τη διαδικασία σκέψης τους για τη δημιουργία καλύτερου λογισμικού.

Τι είναι ακριβώς το Agile;

Το Agile δεν είναι ένα σύνολο κανόνων. Το Agile δεν είναι ένα σύνολο οδηγιών. Το Agile δεν είναι καν μεθοδολογία. Αντίθετα, το Agile είναι ένα σύνολο αρχών που ενθαρρύνουν την ευελιξία, την προσαρμοστικότητα, την επικοινωνία και το λογισμικό εργασίας σε σχέση με σχέδια και διαδικασίες. Καταγράφεται συνοπτικά σε αυτό που ονομάζεται ευκίνητο μανιφέστο.

Η ανάπτυξη λογισμικού Agile επιτρέπει στην ομάδα να συνεργάζεται πιο αποτελεσματικά και αποτελεσματικά στην ανάπτυξη σύνθετων έργων. Αποτελείται από πρακτικές που ασκούν επαναληπτικές και επαυξητικές τεχνικές που υιοθετούνται εύκολα και εμφανίζουν εξαιρετικά αποτελέσματα.

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

Όχι μόνο αυτό, οι μέθοδοι και οι μεθοδολογίες Agile ανοίγουν επίσης περιθώρια βελτίωσης της διαδικασίας ως αναπόσπαστο μέρος κάθε παράδοσης.

Το Agile είναι μια προσέγγιση ανάπτυξης λογισμικού όπου μια αυτόνομη και διαλειτουργική ομάδα εργάζεται για την πραγματοποίηση συνεχών παραδόσεων μέσω επαναλήψεων και εξελίσσεται σε όλη τη διαδικασία συλλέγοντας σχόλια από τους τελικούς χρήστες.

Πώς να εξασκηθείτε ευκίνητα;

Υπάρχουν διάφορες ευέλικτες μεθοδολογίες που είναι στην πράξη σε διάφορες διαφοροποιημένες βιομηχανίες.

ευέλικτες μεθοδολογίες

Ωστόσο, οι πιο δημοφιλείς μεθοδολογίες μεταξύ όλων αυτών είναι:

Scrum
Κανμπάν
Ακραίος προγραμματισμός

Όλες αυτές οι μεθοδολογίες εστιάζονται στην ανάπτυξη λιτού λογισμικού και βοηθούν στην οικοδόμηση καλύτερου λογισμικού αποτελεσματικά και αποδοτικά.

Αυτό είναι όλο με το Agile Εισαγωγή. Το μέρος είναι δομημένο για να σας βοηθήσει να κατανοήσετε τις βασικές αξίες και αρχές που θα υιοθετηθούν για μια ομάδα που εργάζεται σε μια ευέλικτη λειτουργία και νοοτροπία.

Ευκίνητος Μεθοδολογία

Εισαγωγή στα μοντέλα Agile:

Ευέλικτη μεθοδολογία

πώς να κατεβάσετε ολόκληρη τη λίστα αναπαραγωγής από το youtube χωρίς λογισμικό

Όπως όλοι γνωρίζουμε, το Agile είναι μια μεθοδολογία ανάπτυξης λογισμικού.

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

Σε αυτό το σεμινάριο, θα μάθουμε για τα πλεονεκτήματα και τα μειονεκτήματα της ευέλικτης μεθοδολογίας.

Θα δούμε τι είναι το scrum; και πώς είναι διαφορετικό από το ευέλικτο. Τότε θα καταλάβουμε τις διάφορες ευέλικτες μεθοδολογίες που χρησιμοποιούνται από διαφορετικούς οργανισμούς και πώς μπορούμε να εφαρμόσουμε ευέλικτες χρησιμοποιώντας αυτές.

Θα μπορείτε επίσης να εκτιμήσετε τη διαφορά και επίσης τα πλεονεκτήματα / μειονεκτήματα αυτών των μεθοδολογιών.

Πλεονεκτήματα της ευέλικτης μεθοδολογίας

Παρακάτω δίνονται τα διάφορα πλεονεκτήματα της ευέλικτης μεθοδολογίας:

Οι πελάτες παίρνουν συνεχώς μια ματιά και μια αίσθηση της προόδου του έργου στο τέλος κάθε επανάληψης / σπριντ.
Κάθε σπριντ παρέχει στον πελάτη ένα λογισμικό εργασίας το οποίο ανταποκρίνεται στις προσδοκίες του σύμφωνα με τον ορισμό των πράξεων που παρέχονται από αυτούς.
Οι ομάδες ανάπτυξης ανταποκρίνονται αρκετά στις μεταβαλλόμενες απαιτήσεις και μπορούν να δεχθούν αλλαγές ακόμη και στα προχωρημένα στάδια ανάπτυξης.
Υπάρχει συνεχής αμφίδρομη επικοινωνία που διατηρεί τους πελάτες που εμπλέκονται, επομένως όλοι οι ενδιαφερόμενοι - επιχειρηματικοί και τεχνικοί - έχουν σαφή ορατότητα στην πρόοδο του έργου.
Ο σχεδιασμός του προϊόντος είναι αποτελεσματικός και πληροί τις επιχειρηματικές απαιτήσεις.

Μειονεκτήματα της ευέλικτης μεθοδολογίας

Αν και υπάρχουν πολλά πλεονεκτήματα της μεθοδολογίας Agile, υπάρχουν και ορισμένα μειονεκτήματα που εμπλέκονται σε αυτήν.

Αυτοί είναι:

# 1) Δεν προτιμάται η περιεκτική τεκμηρίωση, η οποία μπορεί να οδηγήσει σε λανθασμένες ομάδες να το ερμηνεύσουν εσφαλμένα, καθώς η ευκίνητη δεν απαιτεί τεκμηρίωση. Έτσι, η αυστηρότητα χάνεται στην τεκμηρίωση. Αυτό πρέπει να αποφεύγεται ρωτώντας συνεχώς τον εαυτό σας εάν είναι επαρκείς πληροφορίες για να προχωρήσετε ή όχι.

#δύο) Μερικές φορές, στην αρχή των έργων, οι απαιτήσεις δεν είναι ξεκάθαρες. Οι ομάδες ενδέχεται να προχωρήσουν και να διαπιστώσουν ότι το όραμα των πελατών έγινε ευθυγραμμισμένο και σε τέτοιες περιπτώσεις, οι ομάδες πρέπει να ενσωματώσουν πολλές αλλαγές και είναι δύσκολο να μετρηθεί το τελικό αποτέλεσμα επίσης.

Τύποι ευέλικτων μεθοδολογιών

Υπάρχουν πολλές ευέλικτες μεθοδολογίες στην πράξη σε όλο τον κόσμο. Θα μάθουμε λεπτομερέστερα τέσσερα από τα πιο δημοφιλή.

Ευέλικτοι τύποι μεθοδολογιών

# 1) Scrum

Το Scrum μπορεί εύκολα να θεωρηθεί ως το πιο δημοφιλές ευέλικτο πλαίσιο. Ο όρος «scrum» θεωρείται πολύ συνώνυμο του «ευκίνητος» από τους περισσότερους επαγγελματίες. Αλλά αυτό είναι μια λανθασμένη αντίληψη. Το Scrum είναι μόνο ένα από τα πλαίσια με τα οποία μπορείτε να εφαρμόσετε ευέλικτο.

Η λέξη scrum προέρχεται από αθλητικό ράγκμπι. Όπου οι παίκτες συσσωρεύονται σε μια αλληλοσυνδεδεμένη θέση πιέζοντας εναντίον των αντιπάλων. Κάθε παίκτης έχει καθορισμένο ρόλο στη θέση του και μπορεί να παίξει επιθετικό και αμυντικό σύμφωνα με το αίτημα της κατάστασης.

Ομοίως, το scrum in IT πιστεύει σε εξουσιοδοτημένες αυτοδιαχειριζόμενες ομάδες ανάπτυξης με τρεις συγκεκριμένους και σαφώς καθορισμένους ρόλους. Αυτοί οι ρόλοι περιλαμβάνουν - Ιδιοκτήτης προϊόντος (PO), Scrum Master (SM) και η ομάδα ανάπτυξης που αποτελείται από προγραμματιστές και δοκιμαστές . Δουλεύουν μαζί σε επαναλαμβανόμενες χρονικές περιόδους που ονομάζονται σπριντ.

Το πρώτο βήμα είναι η δημιουργία του καθυστερημένου προϊόντος από την PO. Είναι μια λίστα υποχρεώσεων που πρέπει να κάνετε από την ομάδα scrum. Στη συνέχεια, η ομάδα scrum επιλέγει τα στοιχεία κορυφαίας προτεραιότητας και προσπαθεί να τα ολοκληρώσει μέσα στο πλαίσιο χρόνου που ονομάζεται σπριντ.

Ένας ευκολότερος τρόπος να τα θυμάστε όλα αυτά είναι να απομνημονεύσετε το πλαίσιο 3-3-5. Αυτό σημαίνει ότι ένα έργο scrum έχει 3 ρόλους, 3 αντικείμενα και 5 εκδηλώσεις.

Αυτά είναι -

Ρόλοι: PO, Scrum master και ομάδα ανάπτυξης.

Αντικείμενα: Backlog προϊόντος, Sprint BacklogκαιΑύξηση προϊόντος.

Εκδηλώσεις: Sprint, Sprint planning, Daily Scrum, Sprint review και Sprint retrospective.

3-3-5 πλαίσιο

Θα μάθουμε λεπτομερέστερα για καθένα από αυτά στα επόμενα σεμινάρια μας.

# 2) Κανμπάν

Το Kanban είναι ένας ιαπωνικός όρος που σημαίνει μια κάρτα. Αυτές οι κάρτες περιέχουν λεπτομέρειες για την εργασία που πρέπει να γίνει στο λογισμικό. Ο σκοπός είναι η οπτικοποίηση. Κάθε μέλος της ομάδας γνωρίζει το έργο που πρέπει να γίνει μέσω αυτών των οπτικών βοηθημάτων.

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

Υπάρχουν όμως και διαφορές μεταξύ αυτών των δύο - όπως κατά τη διάρκεια ενός σπριντ σπριντ, τα αντικείμενα που εργάζονται από μια ομάδα είναι σταθερά και δεν μπορούμε να προσθέσουμε αντικείμενα στο σπριντ, ενώ στο Kanban μπορούμε να προσθέσουμε αντικείμενα εάν υπάρχει διαθέσιμη χωρητικότητα. Αυτό είναι ιδιαίτερα χρήσιμο όταν οι απαιτήσεις αλλάζουν συχνά.

Ομοίως, μια άλλη διαφορά είναι ότι ενώ το scrum έχει καθορισμένους ρόλους PO, scrum master και ομάδες ανάπτυξης, δεν υπάρχουν τέτοιοι προκαθορισμένοι ρόλοι στο Kanban.

Μια άλλη διαφορά είναι ότι ενώ το scrum προτείνει την ιεράρχηση των καθυστερήσεων προϊόντων, το Kanban δεν έχει τέτοια απαίτηση και είναι εντελώς προαιρετικό. Έτσι, ο Kanban απαιτεί λιγότερη οργάνωση και αποφεύγει δραστηριότητες μη προστιθέμενης αξίας και είναι κατάλληλος για τις διαδικασίες που απαιτούν ανταπόκριση σε αλλαγές.

# 3) Άπαχο

Το Lean είναι μια φιλοσοφία που εστιάζει στη μείωση των αποβλήτων. Πώς το κάνει αυτό;

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

Μια πιο λιτή διαδικασία σημαίνει ταχύτερη παράδοση και λιγότερη προσπάθεια σπατάλη σε εργασίες που δεν βοηθούν στην επίτευξη των στόχων της ομάδας. Αυτό βοηθά στη βελτιστοποίηση κάθε βήματος στον κύκλο ανάπτυξης λογισμικού. Αυτός είναι ο λόγος για τον οποίο οι άπαχες αρχές προσαρμόστηκαν από την αδύνατη κατασκευή στην ανάπτυξη λογισμικού.

Η ανάπτυξη λογισμικού Lean μπορεί να χρησιμοποιηθεί σε οποιοδήποτε έργο πληροφορικής εφαρμόζοντας τις επτά αδύνατες αρχές που παρουσιάζονται παρακάτω:

επτά άπαχες αρχές

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

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

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

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

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

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

Έτσι, βλέπουμε ότι τα λιπαρά και ευκίνητα έχουν πολλά κοινά με μία έντονη διαφορά - ενώ οι άπαχες ομάδες μπορούν να βοηθήσουν στη βελτίωση του προϊόντος, οι ευέλικτες ομάδες είναι αυτές που πραγματικά κατασκευάζουν το προϊόν.

# 4) Extreme Προγραμματισμός (XP)

Ο Extreme προγραμματισμός είναι μια άλλη πιο δημοφιλής ευέλικτη τεχνική. Σύμφωνα με το extremeeprogramming.org, το πρώτο έργο XP ξεκίνησε στις 6 Μαρτίου 1996. Αναφέρουν επίσης ότι το XP επηρεάζει την ανάπτυξη έργων λογισμικού με 5 διαφορετικούς τρόπους - επικοινωνία, απλότητα, σχόλια, σεβασμό και θάρρος. Αυτές ονομάζονται οι τιμές του XP.

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

Οι Extreme προγραμματιστές δημιουργούν επίσης έναν απλό κώδικα και αρχίζουν να λαμβάνουν σχόλια για αυτό από την πρώτη μέρα. Το επίκεντρο είναι να μην υπερβείτε ή να προβλέψετε απαιτήσεις που δεν έχουν κοινοποιηθεί. Αυτό διατηρεί τον σχεδιασμό απλό και παράγει μόνο το ελάχιστο προϊόν που θα εξυπηρετεί τις απαιτήσεις.

Τα σχόλια βοηθούν την ομάδα να βελτιώσει και να παράγει καλύτερη ποιότητα εργασίας. Αυτό τους βοηθά να χτίζουν σεβασμό ο ένας τον άλλο καθώς μαθαίνουν ο ένας από τον άλλον και μαθαίνουν πώς να μοιράζονται τις απόψεις τους.

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

Αυτό είναι ιδιαίτερα χρήσιμο σε έργα όπου οι απαιτήσεις θα αλλάζουν συχνά. Η συνεχής ανατροφοδότηση θα βοηθήσει τις ομάδες να συμπεριλάβουν αυτές τις αλλαγές με θάρρος.

Έτσι, έχουμε δει τις διαφορετικές ευέλικτες μεθοδολογίες όπως Scrum, XP, Kanban και Lean μαζί με τα αντίστοιχα πλεονεκτήματα και μειονεκτήματά τους.

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

Στο επόμενο μέρος, ας καταλάβουμε τα πάντα για το Scrum.

Μεθοδολογία Scrum

Το SCRUM είναι μια διαδικασία ευέλικτης μεθοδολογίας που είναι ένας συνδυασμός του επαναληπτικού μοντέλου και του στοιχειώδους μοντέλου.

Ένα από τα σημαντικότερα μειονεκτήματα του παραδοσιακού Μοντέλο καταρράκτη ήταν ότι - έως ότου ολοκληρωθεί η πρώτη φάση, η εφαρμογή δεν μετακινείται στην άλλη φάση. Και κατά τύχη, εάν υπάρχουν κάποιες αλλαγές στο μεταγενέστερο στάδιο του κύκλου, τότε καθίσταται πολύ δύσκολο να εφαρμοστούν αυτές οι αλλαγές, καθώς θα συνεπαγόταν επανεξέταση των προηγούμενων φάσεων και επανάληψη των αλλαγών.

Έλεγχος ευέλικτου scrum

Μερικά από τα βασικά χαρακτηριστικά του SCRUM περιλαμβάνουν:

Αυτο-οργανωμένη και επικεντρωμένη ομάδα.
Δεν υπάρχουν τεράστια έγγραφα απαιτήσεων, αλλά έχουν πολύ ακριβείς και επίκαιρες ιστορίες.
Οι διαλειτουργικές ομάδες συνεργάζονται ως ενιαία μονάδα.
Κλείστε την επικοινωνία με τον εκπρόσωπο χρήστη για να κατανοήσετε τις δυνατότητες.
Έχει καθορισμένο χρονοδιάγραμμα το πολύ ένα μήνα.
Αντί να κάνει ολόκληρο το «πράγμα» κάθε φορά, το Scrum κάνει τα πάντα σε ένα δεδομένο διάστημα.
Η ικανότητα και η διαθεσιμότητα των πόρων λαμβάνονται υπόψη πριν από τη διάπραξη οτιδήποτε.

Για να κατανοήσετε καλά αυτήν τη μεθοδολογία, είναι σημαντικό να κατανοήσετε τις βασικές ορολογίες στο SCRUM.

Διαβάστε επίσης => Πώς να παρέχετε δυνατότητες λογισμικού υψηλής αξίας σε σύντομο χρονικό διάστημα χρησιμοποιώντας τη διαδικασία Agile Scrum

Σημαντικές ορολογίες SCRUM

1) Ομάδα Scrum

Η ομάδα scrum είναι μια ομάδα που αποτελείται από 7 με + ή - δύο μέλη. Αυτά τα μέλη είναι ένα μείγμα ικανοτήτων και αποτελούνται από προγραμματιστές, υπεύθυνους δοκιμών, άτομα βάσεων δεδομένων, άτομα υποστήριξης κ.λπ., μαζί με τον ιδιοκτήτη του προϊόντος και έναν κύριο scrum.

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

Ομάδα Scrum

2) Σπριντ

Το Sprint είναι ένα προκαθορισμένο διάστημα ή χρονικό πλαίσιο στο οποίο η εργασία πρέπει να ολοκληρωθεί και να είναι έτοιμη για αναθεώρηση ή έτοιμη για ανάπτυξη παραγωγής. Αυτό το χρονικό πλαίσιο συνήθως κυμαίνεται από 2 εβδομάδες έως 1 μήνα.

Τι είναι το λειτουργικό σύστημα linux και unix

Στην καθημερινή μας ζωή, όταν λέμε ότι ακολουθούμε τον κύκλο Sprint 1 μηνός, αυτό σημαίνει απλώς ότι εργαζόμαστε για ένα μήνα στις εργασίες και το κάνουμε έτοιμο για έλεγχο μέχρι το τέλος αυτού του μήνα.

3) Κάτοχος προϊόντος

Ο κάτοχος του προϊόντος είναι ο βασικός ενδιαφερόμενος ή ο κύριος χρήστης της εφαρμογής που θα αναπτυχθεί. Ο ιδιοκτήτης του προϊόντος είναι το πρόσωπο που αντιπροσωπεύει την πλευρά του πελάτη. Έχει την τελική εξουσία και πρέπει να είναι πάντα διαθέσιμος για την ομάδα.

Πρέπει να είναι προσβάσιμος όταν κάποιος έχει αμφιβολίες που χρειάζονται διευκρίνιση. Είναι σημαντικό για τον ιδιοκτήτη του προϊόντος να κατανοήσει και να μην εκχωρήσει νέα απαίτηση στη μέση του σπριντ ή όταν το σπριντ έχει ήδη ξεκινήσει.

4) Master Scrum

Το Scrum Master είναι ο διαμεσολαβητής της ομάδας scrum. Διασφαλίζει ότι η ομάδα του scrum είναι παραγωγική και προοδευτική. Σε περίπτωση οποιωνδήποτε εμποδίων, το master scrum παρακολουθεί και τα επιλύει για την ομάδα. Το SCRUM Master είναι ο μεσολαβητής μεταξύ του PO και της ομάδας.

Διατηρεί την PO ενήμερη για την πρόοδο του Sprint. Εάν υπάρχουν οδοφράγματα ή ανησυχίες για την ομάδα, συζητήστε με την ΟΠ και επιλύστε τα. Όπως και το Daily Standup της ομάδας, συμβαίνει καθημερινά μια στάση του SCRUM Master με το PO.

Συνιστώμενη ανάγνωση => Πώς να είσαι καλός μέντορας ομάδας, προπονητής και αληθινός αμυντικός ομάδας σε έναν ευέλικτο κόσμο δοκιμών;

5) Επιχειρηματικός αναλυτής (BA)

Ένας Αναλυτής Επιχειρήσεων παίζει πολύ σημαντικό ρόλο στο SCRUM. Αυτό το άτομο είναι υπεύθυνο για την ολοκλήρωση και τη σύνταξη της απαίτησης στα έγγραφα απαιτήσεων (βάσει των οποίων δημιουργούνται οι ιστορίες χρηστών).

Εάν υπάρχουν αμφισημίες στα κριτήρια Ιστοριών χρηστών / Αποδοχής, αυτός / αυτή είναι αυτός που προσεγγίζεται από την τεχνική ομάδα (SCRUM) και στη συνέχεια το παίρνει στο PO ή αλλιώς, εάν είναι δυνατόν, επιλύει μόνος του. Σε έργα μεγάλης κλίμακας, μπορεί να υπάρχουν περισσότερα από 1 BA, αλλά σε έργα μικρής κλίμακας, το SCRUM Master μπορεί να ενεργεί και ως BA.

Είναι πάντα καλή πρακτική να έχετε πτυχίο κατά την έναρξη του έργου.

6) Ιστορία χρήστη

Οι ιστορίες χρηστών δεν είναι παρά οι απαιτήσεις ή το χαρακτηριστικό που πρέπει να εφαρμοστεί.

Στο άχρηστο, δεν έχουμε αυτά τα τεράστια έγγραφα απαιτήσεων, αλλά οι απαιτήσεις ορίζονται σε μία μόνο παράγραφο, συνήθως έχουν τη μορφή ως:

Σαν
θέλω να
Να επιτύχω

Για παράδειγμα :

Ως Διαχειριστής θέλω να έχω κλειδωμένο κωδικό πρόσβασης σε περίπτωση που ο χρήστης εισάγει λανθασμένο κωδικό πρόσβασης για 3 συνεχόμενες φορές για να περιορίσει τη μη εξουσιοδοτημένη πρόσβαση.

Υπάρχουν ορισμένα χαρακτηριστικά των ιστοριών χρηστών που πρέπει να τηρηθούν. Οι ιστορίες χρηστών πρέπει να είναι σύντομες, ρεαλιστικές, να εκτιμηθούν, να είναι πλήρεις, διαπραγματεύσιμες και δοκιμαστικές. Μια ιστορία χρήστη δεν αλλάζει ούτε αλλάζει ποτέ στη μέση του Sprint.

Είναι ευθύνη του SCRUM Master και του BA (εάν ισχύει) να βεβαιωθείτε ότι η ΔΠ έχει συντάξει σωστά τις Ιστορίες χρηστών με ένα κατάλληλο σύνολο Κριτηρίων Αποδοχής ». Εάν πρέπει να γίνουν αλλαγές που θα επηρεάσουν την απελευθέρωση σπριντ, τότε τέτοιες ιστορίες βγαίνουν από το σπριντ ή γίνονται σύμφωνα με τις διαθέσιμες ώρες.

Κάθε ιστορία χρήστη έχει ένα κριτήριο αποδοχής, το οποίο θα πρέπει να ορίζεται καλά και να γίνεται κατανοητό από την ομάδα.

Τα κριτήρια αποδοχής περιγράφουν λεπτομερώς την ιστορία του χρήστη που παρέχει τα δικαιολογητικά έγγραφα. Βοηθά στην περαιτέρω βελτίωση της ιστορίας του χρήστη. Οποιοσδήποτε από την ομάδα μπορεί να γράψει τα κριτήρια αποδοχής. Η εξεταστική ομάδα βασίζει τις δοκιμαστικές περιπτώσεις / προϋποθέσεις σε αυτά τα κριτήρια αποδοχής.

7) Έπη

Τα Epics είναι διφορούμενες ιστορίες χρηστών ή μπορούμε να πούμε ότι αυτές είναι οι ιστορίες χρηστών που δεν έχουν οριστεί και διατηρούνται για μελλοντικά σπριντ.

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

Το Epic είναι ακριβώς όπως εσείς το σχέδιο διακοπών του επόμενου έτους, όπου απλά ξέρετε ότι ίσως θέλετε να πάτε, αλλά πού, πότε, με ποιον, όλες αυτές οι λεπτομέρειες δεν έχετε ιδέα αυτή τη στιγμή.

Με παρόμοιο τρόπο, υπάρχουν δυνατότητες που πρέπει να εφαρμοστούν στο μέλλον των οποίων οι λεπτομέρειες δεν είναι ακόμη γνωστές. Κυρίως ένα χαρακτηριστικό ξεκινά με ένα Epic και στη συνέχεια κατανέμεται σε ιστορίες που θα μπορούσαν να εφαρμοστούν.

8) Καθυστέρηση προϊόντος

Το καθυστερημένο προϊόν είναι ένα είδος κάδου ή πηγής όπου διατηρούνται όλες οι ιστορίες χρηστών. Αυτό διατηρείται από τον Κάτοχο προϊόντος. Το καθυστερημένο προϊόν μπορεί να φανταστεί ως λίστα επιθυμιών του ιδιοκτήτη του προϊόντος που το δίνει προτεραιότητα σύμφωνα με τις ανάγκες της επιχείρησης.

Κατά τη διάρκεια της συνάντησης προγραμματισμού (βλ. Επόμενη ενότητα), μια ιστορία χρήστη λαμβάνεται από την καθυστέρηση του προϊόντος και, στη συνέχεια, η ομάδα κάνει την ανταλλαγή ιδεών, την κατανοεί και την τελειοποιεί και αποφασίζει συλλογικά ποιες ιστορίες χρηστών να λάβει, με την παρέμβαση του ιδιοκτήτη του προϊόντος.

9) Σπριντ καθυστέρηση

Με βάση την προτεραιότητα, οι ιστορίες χρηστών λαμβάνονται από το Product Backlog ως ένα κάθε φορά. Η ομάδα του Scrum καταιγισμού ιδεών καθορίζει τη σκοπιμότητα και αποφασίζει για τις ιστορίες που θα εργαστούν σε ένα συγκεκριμένο σπριντ. Η συλλογική λίστα όλων των ιστοριών χρηστών που η ομάδα scrum λειτουργεί σε ένα συγκεκριμένο σπριντ είναι γνωστή ως Sprint backlog.

Σπριντ καθυστέρηση

10) Σημεία ιστορίας

Τα σημεία ιστορίας είναι μια ποσοτική ένδειξη της πολυπλοκότητας μιας ιστορίας χρήστη. Με βάση το σημείο της ιστορίας, καθορίζονται εκτιμήσεις και προσπάθειες για μια ιστορία.

Ένα σημείο ιστορίας είναι σχετικό και όχι απόλυτο. Για να βεβαιωθείτε ότι οι εκτιμήσεις και οι προσπάθειές μας είναι σωστές, είναι σημαντικό να ελέγξετε ότι οι ιστορίες χρηστών δεν είναι μεγάλες. Όσο πιο ακριβής και μικρότερη είναι η ιστορία του χρήστη, τόσο ακριβέστερη θα είναι η εκτίμηση.

Κάθε ιστορία χρήστη αντιστοιχίζεται σε ένα σημείο ιστορίας με βάση τη σειρά Fibonacci (1, 2, 3, 5, 8, 13 & 21). Όσο υψηλότερος είναι ο αριθμός, το συγκρότημα είναι η ιστορία.

Για να είμαι ακριβής

Εάν δώσετε 1/2/3 σημείο ιστορίας, σημαίνει ότι η ιστορία είναι μικρή και χαμηλής πολυπλοκότητας.
Εάν δώσετε πόντους ως 5/8, είναι ένα μεσαίο σύνθετο και
Τα 13 και 21 είναι πολύ περίπλοκα.

Εδώ η πολυπλοκότητα συνίσταται τόσο στην ανάπτυξη όσο και στην προσπάθεια δοκιμών.

Για να αποφασίσει ένα σημείο ιστορίας, ο καταιγισμός ιδεών συμβαίνει μέσα στην ομάδα του scrum και η ομάδα αποφασίζει συλλογικά ένα σημείο ιστορίας.

Μπορεί να συμβεί ότι η ομάδα ανάπτυξης δίνει ένα σημείο ιστορίας 3 σε μια συγκεκριμένη ιστορία, επειδή για αυτούς μπορεί να είναι 3 γραμμές αλλαγής κώδικα, αλλά η ομάδα δοκιμών δίνει 8 σημεία ιστορίας επειδή πιστεύουν ότι αυτή η αλλαγή κώδικα θα επηρεάσει μεγαλύτερες ενότητες, έτσι η δοκιμαστική προσπάθεια θα ήταν μεγαλύτερη. Οποιοδήποτε σημείο ιστορίας δίνετε, πρέπει να το αιτιολογήσετε.

Έτσι σε αυτήν την περίπτωση, συμβαίνει καταιγισμός ιδεών και η ομάδα συμφωνεί συλλογικά σε ένα σημείο ιστορίας.

Όποτε αποφασίζετε για ένα σημείο ιστορίας, λάβετε υπόψη τους παρακάτω παράγοντες:

Η εξάρτηση της ιστορίας με άλλη εφαρμογή / ενότητα.
Το σύνολο δεξιοτήτων του πόρου.
Η πολυπλοκότητα της ιστορίας.
Ιστορική εκμάθηση.
Κριτήρια αποδοχής της ιστορίας χρήστη.

Εάν δεν γνωρίζετε μια συγκεκριμένη ιστορία, μην την μετρήσετε.

Κάθε φορά που μια ιστορία είναι = ή> 8 βαθμοί, χωρίζεται σε 2 ή περισσότερες ιστορίες.

11) Κάτω γράφημα

Το γράφημα Burn down είναι ένα γράφημα που δείχνει την εκτιμώμενη πραγματική προσπάθεια v / s των εργασιών scrum.

Είναι ένας μηχανισμός παρακολούθησης με τον οποίο για ένα συγκεκριμένο σπριντ οι καθημερινές εργασίες παρακολουθούνται για να ελέγξουν αν οι ιστορίες προχωρούν προς την ολοκλήρωση των δεσμευμένων σημείων ιστορίας ή όχι.

Παράδειγμα : Για να το καταλάβετε, ελέγξτε το παρακάτω σχήμα:

Κάτω γράφημα 1

Έχω υποθέσει:

2 εβδομάδες σπριντ (10 ημέρες)
2 πόροι πραγματικοί που εργάζονται στο σπριντ.

'Ιστορία' -> Σε αυτήν τη στήλη εμφανίζονται οι ιστορίες χρηστών που έχουν ληφθεί για το σπριντ.

'Εργο' -> Αυτή η στήλη εμφανίζει τη λίστα της εργασίας που σχετίζεται με την ιστορία του χρήστη.

'Προσπάθεια' -> Αυτή η στήλη δείχνει την προσπάθεια. Τώρα, αυτό το μέτρο είναι η συνολική προσπάθεια για την ολοκλήρωση της εργασίας. Δεν απεικονίζει την προσπάθεια που καταβάλλεται από συγκεκριμένο άτομο.

«Ημέρα 1 - Ημέρα 10» -> Αυτή η στήλη (ες) δείχνει τις ώρες που απομένουν για την ολοκλήρωση της ιστορίας. Παρακαλώ δείτε ότι η ώρα ΔΕΝ είναι η ώρα που έχει ήδη γίνει ΑΛΛΑ οι ώρες που απομένουν.

«Εκτιμώμενη προσπάθεια» -> Είναι το σύνολο της προσπάθειας. Για το 'Έναρξη' είναι απλώς το άθροισμα ολόκληρης της μεμονωμένης εργασίας: SUM (C5: C15)

Ο συνολικός αριθμός προσπαθειών που πρέπει να ολοκληρωθεί σε 1 ημέρα είναι 70/10 = 7. Έτσι, στο τέλος της ημέρας 1, η προσπάθεια πρέπει να μειωθεί σε 70 - 7 = 63. Με παρόμοιο τρόπο, υπολογίζεται για όλες τις ημέρες έως την ημέρα 10, όταν η εκτιμώμενη προσπάθεια πρέπει να είναι 0 (Σειρά 16)

'Πραγματική προσπάθεια αριστερά' -> Όπως υποδηλώνει το όνομα, απομένει η προσπάθεια για την ολοκλήρωση της ιστορίας. Μπορεί επίσης να συμβεί ότι η πραγματική προσπάθεια αυξάνεται ή μειώνεται από την εκτιμώμενη.

Μπορείτε να χρησιμοποιήσετε τις ενσωματωμένες συναρτήσεις και το Διάγραμμα στο Excel για να δημιουργήσετε αυτό το γράφημα καύσης.

Τα βήματα Burn Down Chart θα ήταν:

Εισαγάγετε όλες τις ιστορίες (Στήλη A5 - A15).
Εισαγάγετε όλες τις εργασίες (στήλη B5 - B15).
Εισαγάγετε τις Ημέρες (Ημέρα 1 - Ημέρα 10).
Εισαγάγετε τις αρχικές προσπάθειες (Συνοψίστε τις εργασίες C5 - C15).
Εφαρμόστε τον τύπο για να υπολογίσετε τις 'Εκτιμώμενες προσπάθειες' για κάθε ημέρα (Ημέρα 1 έως Ημέρα 10). Εισαγάγετε τον τύπο στο D15 (C16- $ C $ 16/10) και σύρετέ το για όλες τις ημέρες.
Για κάθε μέρα, εισαγάγετε τις πραγματικές προσπάθειες. Εισαγάγετε τον τύπο στο D17 (SUM (D5: D15)) για να συνοψίσετε τις πραγματικές προσπάθειες που απομένουν και σύρετέ τον για όλες τις άλλες ημέρες.
Επιλέξτε το και δημιουργήστε το γράφημα ως εξής:

Κάτω γράφημα 2

12) Ταχύτητα

Ο συνολικός αριθμός του σημείου ιστορίας που μια ομάδα scrum αρχειοθετεί σε ένα σπριντ, ονομάζεται Velocity. Η ομάδα Scrum κρίνεται ή αναφέρεται από την ταχύτητά της. Τούτου λεχθέντος, πρέπει να θυμόμαστε ότι ο στόχος εδώ ΔΕΝ είναι η επίτευξη των μέγιστων πόντων ιστορίας, αλλά η ποιότητα που μπορεί να παραδοθεί, σεβόμενος το επίπεδο άνεσης της ομάδας scrum.

Για παράδειγμα : Για ένα συγκεκριμένο σπριντ: ο συνολικός αριθμός ιστοριών χρηστών είναι 8 με σημεία ιστορίας όπως φαίνεται παρακάτω.

Ταχύτητα Scrum

Εδώ λοιπόν η ταχύτητα θα είναι το άθροισμα των πόντων ιστορίας = 30

Ορισμός του Τέλους:

Ένα Sprint επισημαίνεται ως Τέλος όταν όλες οι ιστορίες έχουν ολοκληρωθεί, όλες οι εργασίες dev, έρευνας, QA επισημαίνονται ως 'Ολοκληρώθηκε', όλα τα σφάλματα είναι σταθερά κλειστά, διαφορετικά αυτά που μπορούν να γίνουν αργότερα (όπως δεν σχετίζονται πλήρως ή είναι λιγότερο σημαντικά) αφαιρούνται και προστίθενται στο καθυστερημένο αρχείο, η αναθεώρηση κώδικα και η δοκιμή μονάδας ολοκληρώνονται, οι εκτιμώμενες ώρες έχουν ανταποκριθεί στις πραγματικές ώρες που έχουν τεθεί στα καθήκοντα και το σημαντικότερο έχει δοθεί μια επιτυχημένη επίδειξη στην PO και τους ενδιαφερόμενους.

Δραστηριότητες που έγιναν στη μεθοδολογία SCRUM

# 1) Συνάντηση προγραμματισμού

Μια συνάντηση προγραμματισμού είναι το σημείο εκκίνησης του Sprint. Είναι η συνάντηση όπου συγκεντρώνεται ολόκληρη η ομάδα scrum, το SCRUM Master επιλέγει μια ιστορία χρήστη βάσει της προτεραιότητας από το καθυστερημένο προϊόν και τις ιδέες της ομάδας.

Με βάση τη συζήτηση, η ομάδα scrum αποφασίζει την πολυπλοκότητα της ιστορίας και το μέγεθος της σύμφωνα με τη σειρά Fibonacci. Η ομάδα προσδιορίζει τις εργασίες μαζί με τις προσπάθειες (σε ώρες) που θα γίνουν για την ολοκλήρωση της υλοποίησης της ιστορίας των χρηστών.

Πολλές φορές, προηγείται η συνάντηση προγραμματισμού από μια «συνάντηση προ-προγραμματισμού». Είναι σαν την εργασία που κάνει η ομάδα scrum προτού καθίσει για την επίσημη συνάντηση προγραμματισμού. Η ομάδα προσπαθεί να καταγράψει τις εξαρτήσεις ή άλλους παράγοντες που θα ήθελαν να συζητήσουν στη συνάντηση προγραμματισμού.

# 2) Εκτέλεση εργασιών Sprint

Όπως υποδηλώνει το όνομα, αυτά είναι η πραγματική δουλειά που έκανε η ομάδα scrum για να ολοκληρώσει το έργο τους και να μεταφέρει την ιστορία του χρήστη στην κατάσταση 'Τέλος'.

# 3) Καθημερινή αναμονή

Κατά τη διάρκεια του κύκλου σπριντ, κάθε μέρα η ομάδα scrum συναντά, όχι περισσότερο από 15 λεπτά (θα μπορούσε να είναι μια κλήση stand-up, συνιστάται να έχει κατά την έναρξη της ημέρας) και να δηλώσετε 3 πόντους:

Τι έκανε χθες το μέλος της ομάδας;
Τι σχεδίασε το μέλος της ομάδας σήμερα;
Υπάρχουν εμπόδια (οδοφράγματα);

Ο διευθυντής του Scrum είναι αυτός που διευκολύνει αυτήν τη συνάντηση. Σε περίπτωση που οποιοδήποτε μέλος της ομάδας αντιμετωπίζει κάθε είδους δυσκολίες, το master scrum ακολουθεί για να το επιλύσει. Στο Stand ups, το διοικητικό συμβούλιο εξετάζεται επίσης και από μόνο του δείχνει την πρόοδο της ομάδας.

# 4) Επισκόπηση σύσκεψης

Στο τέλος κάθε κύκλου σπριντ, η ομάδα SCRUM συναντά ξανά και δείχνει τις ιστορίες χρηστών που εφαρμόστηκαν στον κάτοχο του προϊόντος. Ο κάτοχος του προϊόντος μπορεί να επαληθεύσει τις ιστορίες σύμφωνα με τα κριτήρια αποδοχής του. Είναι και πάλι ευθύνη του πλοιάρχου Scrum να προεδρεύει αυτής της συνάντησης.

Επίσης στο εργαλείο SCRUM, το Sprint είναι κλειστό και οι εργασίες επισημαίνονται ότι έχουν ολοκληρωθεί.

# 5) Αναδρομική συνάντηση

Η αναδρομική σύσκεψη πραγματοποιείται μετά τη σύσκεψη αναθεώρησης.

Η ομάδα SCRUM συναντά, συζητά και τεκμηριώνει τα ακόλουθα σημεία:

Τι πήγε καλά κατά τη διάρκεια του Sprint (Βέλτιστες πρακτικές);
Τι δεν πήγε καλά στο Sprint;
Διδάγματα
Στοιχεία δράσης.

Η ομάδα του Scrum θα πρέπει να συνεχίσει να ακολουθεί τις βέλτιστες πρακτικές, να αγνοεί τις «μη βέλτιστες πρακτικές» και να εφαρμόζει τα μαθήματα που αντλήθηκαν κατά τη διάρκεια των συνακόλουθων σπριντ. Η αναδρομική συνάντηση βοηθά στην εφαρμογή της συνεχούς βελτίωσης της διαδικασίας SCRUM.

Πώς γίνεται η διαδικασία; Ενα παράδειγμα!

Έχοντας διαβάσει τις τεχνικές ορολογίες του SCRUM. επιτρέψτε μου να δείξω ολόκληρη τη διαδικασία με ένα παράδειγμα.

Παράδειγμα:

Βήμα 1 : Ας έχουμε μια ομάδα SCRUM 9 ατόμων που αποτελείται από 1 κάτοχο προϊόντος, 1 κύριο Scrum, 2 δοκιμαστές, 4 προγραμματιστές και 1 DBA.

Βήμα 2 : Το Sprint αποφασίζεται να ακολουθήσει έναν κύκλο 4 εβδομάδων. Έχουμε λοιπόν 1 μήνα Sprint από τις 5 έως τις 4 Ιουνίου^ουτου Ιουλίου.

Βήμα # 3 : Ο Κάτοχος προϊόντος έχει κατά προτεραιότητα λίστα ιστοριών χρηστών στο καθυστερημένο προϊόν.

Βήμα # 4: Η ομάδα αποφασίζει να συναντηθεί στις 4^ουΙούνιος για τη συνάντηση «Προγραμματισμός».

Ο ιδιοκτήτης του προϊόντος παίρνει 1 ιστορία από την καθυστέρηση του προϊόντος, την περιγράφει και την αφήνει στην ομάδα να προβληματιστεί.
Όλη η ομάδα συζητά και επικοινωνεί απευθείας με τον ιδιοκτήτη του προϊόντος για να έχει κατανοήσει με σαφήνεια την ιστορία του χρήστη.
Με παρόμοιο τρόπο, λαμβάνονται διάφορες άλλες ιστορίες χρηστών. Εάν είναι δυνατόν, η ομάδα μπορεί να προχωρήσει και να μετρήσει τις ιστορίες επίσης.

Μετά από όλη τη συζήτηση, τα μεμονωμένα μέλη της ομάδας επιστρέφουν στους σταθμούς εργασίας τους και

Προσδιορίστε τις μεμονωμένες εργασίες τους για κάθε ιστορία.
Υπολογίστε τον ακριβή αριθμό ωρών στις οποίες θα λειτουργούν. Ας δούμε πώς τελειώνει το μέλος αυτές τις ώρες.

Συνολικός αριθμός ωρών εργασίας = 9
Μείον 1 ώρα για διάλειμμα, μείον 1 ώρα για συναντήσεις, μείον 1 ώρα για email, συζητήσεις, αντιμετώπιση προβλημάτων κ.λπ.
Έτσι, οι πραγματικές ώρες εργασίας = 6.
Συνολικός αριθμός εργάσιμων ημερών κατά τη διάρκεια του Sprint = 21 ημέρες.
Συνολικός αριθμός διαθέσιμων ωρών = 21 * 6 = 126.
Το μέλος είναι σε άδεια για 2 ημέρες = 12 ώρες (Αυτό ποικίλλει για κάθε μέλος, μερικά μπορεί να πάρουν άδεια και κάποια όχι.)
Αριθμός πραγματικών ωρών = 126 - 12 = 114 ώρες.

Αυτό σημαίνει ότι το μέλος θα είναι πραγματικά διαθέσιμο για 114 ώρες για αυτό το σπριντ. Έτσι θα καταρρεύσει την ατομική του σπριντ δουλειά με τέτοιο τρόπο ώστε να φτάσουν συνολικά 114 ώρες.

Βήμα # 5 : Στις 5^ουτον Ιούνιο ολόκληρη η ομάδα Scrum συναντιέται για τη «Συνάντηση Σχεδιασμού».

Η τελική ετυμηγορία της ιστορίας χρήστη από το καθυστερημένο προϊόν ολοκληρώνεται και η ιστορία μεταφέρεται στο Sprint Backlog.
Για κάθε ιστορία, κάθε μέλος της ομάδας δηλώνει τα προσδιορισμένα καθήκοντά του, εάν απαιτείται, μπορεί να συζητήσει σχετικά με αυτά τα καθήκοντα, μπορεί να το μέγεθος ή να αλλάξει το μέγεθός του (θυμηθείτε τη σειρά Fibonacci !!).
Ο κύριος του Scrum ή η ομάδα εισάγουν τις ατομικές τους εργασίες μαζί με τις ώρες τους για κάθε ιστορία σε ένα εργαλείο.
Αφού ολοκληρωθούν όλες οι ιστορίες, ο κύριος Scrum σημειώνει την αρχική ταχύτητα και ξεκινά επίσημα το Sprint.

Βήμα # 6 : Μόλις ξεκινήσει το Sprint, με βάση τις εργασίες που έχουν ανατεθεί, κάθε μέλος της ομάδας αρχίζει να εργάζεται σε αυτές τις εργασίες.

Βήμα # 7 : Η ομάδα συναντάται καθημερινά για 15 λεπτά και συζητά 3 πράγματα:

Τι έκαναν χθες;
Τι σκοπεύουν να κάνουν σήμερα;
Υπάρχουν εμπόδια (οδοφράγματα);

Βήμα # 8 : Το scrum master παρακολουθεί την πρόοδο σε καθημερινή βάση με τη βοήθεια του 'Burn down chart'.

Βήμα # 9 : Σε περίπτωση οποιουδήποτε εμποδίου, το Master Scrum παρακολουθεί για να τα επιλύσει.

Βήμα # 10 : Στις 4^ουΙούλιο, η ομάδα συναντά ξανά για τη συνάντηση αξιολόγησης. Ένα μέλος επιδεικνύει την υλοποίηση της ιστορίας χρήστη στον κάτοχο του προϊόντος.

Βήμα # 11 : Στις 5^ουΙούλιο, η Ομάδα συναντά ξανά για την Αναδρομική, όπου συζητούν

Τι πήγε καλά;
Τι δεν πήγε καλά;
Στοιχεία δράσης.

Βήμα # 12 : Στις 6^ουΤον Ιούλιο, η Ομάδα συναντιέται ξανά για μια συνάντηση προγραμματισμού για το επόμενο σπριντ και ο κύκλος συνεχίζεται.

διαδικασία μεθοδολογίας scrum agile

Εργαλεία δραστηριότητας SCRUM

Υπάρχουν πολλά εργαλεία που μπορούν να χρησιμοποιηθούν εκτενώς για την παρακολούθηση των δραστηριοτήτων scrum.

Μερικά από αυτά περιλαμβάνουν:

Στο επερχόμενο σεμινάριο, θα ρίξουμε φως στο μανιφέστο Agile που είναι μια ιδέα που οδηγεί αποτελεσματικές ομάδες Agile.

Επόμενο σεμινάριο

Σχετικά με τους συγγραφείς: Αυτή η σειρά γράφτηκε από τα ακόλουθα μέλη της ομάδας STH: Shruti Shrivastava - Ένας επαγγελματίας Master Scrum με 9 χρόνια εμπειρίας σε τομείς BFSI, E-commerce και B2B. Ο Shruti είναι ειδικός στις δοκιμές αυτοματισμού και στις κορυφαίες ομάδες scrum.

Anshul Kumar Srivastava - Επαγγελματίας διαχείρισης προϊόντων και επαγγελματίας Agile με γνώμονα τα αποτελέσματα με 7 χρόνια εμπειρίας στους τομείς BFSI και Telecom.

Συνιστώμενη ανάγνωση

Agile Scrum Online κουίζ: Δοκιμάστε τις γνώσεις σας για το Agile Scrum
Kanban vs Scrum vs Agile: Μια λεπτομερής σύγκριση για την εύρεση διαφορών
Πώς να παρέχετε δυνατότητες λογισμικού υψηλής αξίας σε σύντομο χρονικό διάστημα χρησιμοποιώντας τη διαδικασία Agile Scrum
Agile Manifesto: Κατανόηση των ευέλικτων αξιών και αρχών
SAFe Agile Tutorial: Τι είναι το Scale Agile Framework
30+ Κορυφαίες ερωτήσεις και απαντήσεις συνέντευξης Scrum (2021 LIST)
Agile Vs Waterfall: Ποια είναι η καλύτερη μεθοδολογία για το έργο σας;
Κορυφαίες ερωτήσεις και απαντήσεις για 31 ευέλικτες συνεντεύξεις