Τεχνικές εκτίμησης Agile: Μια πραγματική εκτίμηση σε ένα έργο Agile

agile estimation techniques

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

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

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

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

Τι θα μάθετε:

• Εισαγωγή
• Εκτιμήσεις σημείων ιστορίας σε ευκίνητο
• Προτεινόμενο εργαλείο
• Διαφορετικές τεχνικές εκτίμησης ευκίνητων
  • # 1) Σχεδιασμός πόκερ
  • # 2) Μεγέθη μπλουζών
  • # 3) Ψηφοφορία με κουκκίδες
  • # 4) Το σύστημα κάδων
  • # 5) Μεγάλο / Αβέβαιο / Μικρό
  • # 6) Χαρτογράφηση συγγένειας
  • # 7) Μέθοδος παραγγελίας
• Υπολογισμός προϋπολογισμού σε ευκίνητο
• Πρότυπα εκτίμησης στο έργο Agile Development
  • 1) Πρότυπο σχεδίου έργου Agile:
  • 2) Πρότυπο προγράμματος απελευθέρωσης Agile:
  • 3) Πρότυπο καθυστέρησης προϊόντων ευέλικτου προϊόντος:
  • 4) Πρότυπο καθυστέρησης Agile Sprint:
  • 5) Πρότυπο σχεδίου ευκίνητων δοκιμών:
  • 6) Πρότυπο ιστορίας χρηστών Agile:
  • 7) Πρότυπο χάρτη ευκίνητων οδών:
• Στάδια εκτίμησης στο Agile Project
  • # 1) Εκτίμηση προτάσεων ή επιπέδου έργου
  • # 2) Εκτίμηση επιπέδου έκδοσης
  • # 3) Εκτίμηση επιπέδου σπριντ
• συμπέρασμα
• Συνιστώμενη ανάγνωση

Εισαγωγή

Παρακάτω αναφέρονται τα 3 κύρια επίπεδα της ευέλικτης εκτίμησης.

# 1) Επίπεδο έργου ή πρότασης είναι αυτή που χρησιμοποιεί τη Γρήγορη ανάλυση σημείων λειτουργίας κατά τις αρχικές φάσεις της ανάπτυξης του Έργου.

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

# 3) Επίπεδο σπριντ είναι αυτό όπου οι ιστορίες των χρηστών χωρίζονται στις εργασίες και οι εκτιμώμενες ώρες ανατίθενται στις εργασίες ανάλογα με την πολυπλοκότητά τους. Εδώ, ορίζουμε επίσης τον υπεύθυνο για την εργασία μαζί με την κατάσταση των εργασιών.

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

Εκτιμήσεις σημείων ιστορίας σε ευκίνητο

Οι εκτιμήσεις Story Points είναι μια συγκριτική ανάλυση για την εκτίμηση περίπου των στοιχείων καθυστέρησης προϊόντων με σχετικό μέγεθος. Τα μέλη της ομάδας για την εκτίμηση ιστοριών χρηστών περιλαμβάνουν: Ιδιοκτήτης προϊόντος, Scrum Master, Developers, Testers και Stake.

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

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

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

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

# 4) Παρακάτω αναφέρονται μερικές κοινές ερωτήσεις μεταξύ των συμμετεχόντων:

• Σχέδιο: Ποια είναι η προηγούμενη και υποχρεωτική γνώση που πρέπει να έχουμε πριν αρχίσουμε να δουλεύουμε πάνω της;
• Κωδικοποίηση: Πόσο κωδικοποίηση απαιτείται για την εφαρμογή αυτής της ιστορίας χρήστη. Έχουμε συναντήσει κάποια παρόμοια ιστορία χρήστη στο παρελθόν;
• Δοκιμή μονάδων: Απαιτούνται ψεύτικα αντικείμενα για τη δοκιμή μονάδας για αυτήν την ιστορία χρήστη;
• Δοκιμή ενοποίησης: Επηρεάζει αυτή η ιστορία τις άλλες λειτουργίες της ίδιας ενότητας και άλλες ενότητες;
• Δοκιμή αποδοχής: Ποια είναι τα σημεία που πρέπει να προσέξετε για την παράδοση του επιθυμητού προϊόντος όπως επιθυμείτε από τους Πελάτες;
• Εξειδίκευση: Κάποιος από τους συμμετέχοντες έχει κάνει παρόμοια ιστορία στο παρελθόν και είναι ειδικός σε αυτήν;

# 5) Κάντε σχετικό μέγεθος για την επιλεγμένη ιστορία. Εάν απαιτεί την ίδια δουλειά και προσπάθεια, τότε εκχωρήστε το ίδιο όχι. πόντων, όπως έχουν ανατεθεί στην ιστορία αναφοράς. Εάν απαιτεί περισσότερη προσπάθεια, εκχωρήστε την υψηλότερη αξία. Εάν απαιτεί λιγότερη προσπάθεια, εκχωρήστε την σε χαμηλότερη τιμή.

# 6) Προσεγγίστε τη συναίνεση με όλους τους συμμετέχοντες για να οριστικοποιήσετε το σχετικό μέγεθος για την επιλεγμένη ιστορία χρήστη σύμφωνα με τον ορισμό του ολοκληρωμένου.

Τι είναι η δοκιμή beta στις δοκιμές λογισμικού

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

Προτεινόμενο εργαλείο

# 1) Agile Poker

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

Το ξεκίνημα με το Agile Poker είναι απλό και εύκολο, καθώς εμπνεύστηκε από τρεις μεθοδολογίες εκτίμησης βιομηχανικού προτύπου: Planning Poker®, Wideband Delphi και Magic Estimation (επίσης γνωστή ως Silent Grouping, Affinity Estimation, Swimlanes Sizing ή Relative Estimations).

Διαφορετικές τεχνικές εκτίμησης ευκίνητων

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

Υπάρχουν κυρίως 7 τεχνικές εκτίμησης έργου Agile:

# 1) Σχεδιασμός πόκερ

• Σε αυτήν την τεχνική Εκτίμησης, όλοι οι άνθρωποι που υποτίθεται ότι πρέπει να κάνουν τις εκτιμήσεις, κάθονται σε έναν γύρο κύκλο για τη συνεδρία προγραμματισμού πόκερ.
• Κάθε εκτιμητής έχει μια σειρά από κάρτες προγραμματισμού πόκερ: 0,1,2,3,5,8,13,20,40 και 100. Αυτές οι τιμές αντιπροσωπεύουν σημεία ιστορίας ή μέτρο στα οποία η ομάδα εκτιμά.
• Στην αρχή της περιόδου λειτουργίας, ο ιδιοκτήτης του προϊόντος ή ο πελάτης διαβάζει την ιστορία του χρήστη, περιγράφοντας όλα τα χαρακτηριστικά και τις απαιτήσεις του.
• Μετά την ανάγνωση της ιστορίας, πραγματοποιούνται συζητήσεις μεταξύ των εκτιμητών και με τον ιδιοκτήτη / πελάτη του προϊόντος. Οι εκτιμητές μπορούν να κάνουν ερωτήσεις ή να διευκρινίσουν τις αμφιβολίες τους με τον ιδιοκτήτη του προϊόντος.
• Μετά τις συζητήσεις, όλοι οι εκτιμητές καλούνται να επιλέξουν μία κάρτα για να εκτιμήσουν την ιστορία ενός χρήστη. Εάν όλοι οι εκτιμητές δίνουν την ίδια τιμή, τότε γίνεται η τελική εκτίμηση.
• Εάν οι τιμές είναι διαφορετικές, τότε οι εκτιμητές που δίνουν τις υψηλότερες και τις χαμηλότερες τιμές εξηγούν τις απόψεις τους και γιατί επέλεξαν αυτήν την τιμή, έως ότου επιτευχθεί συναίνεση.
• Μια καλή τεχνική όταν είναι μικρό όχι. των αντικειμένων πρέπει να εκτιμηθεί σε μια μικρή ομάδα.

=> Περαιτέρω λεπτομερής ανάγνωση στις Τεχνική προγραμματισμού πόκερ προγραμματισμού .

# 2) Μεγέθη μπλουζών

• Όπως και στην περίπτωση των μπλουζών, βλέπουμε μεγέθη: XS (Extra Small), S (Small), M (Medium), L (Large), XL (Extra Large). Μια παρόμοια προσέγγιση ακολουθείται εδώ. Τα στοιχεία υπολογίζονται σε μεγέθη μπλουζών.
• Αυτή είναι μια τέλεια τεχνική για να δώσει μια γενική εκτίμηση του μεγάλου ανεκτέλεστου αντικειμένου.
• Χρήσιμο όταν πρέπει να γίνει γρήγορη και σκληρή εκτίμηση. Αργότερα αυτά τα μεγέθη μπορούν να μετατραπούν σε όχι σύμφωνα με την απαίτηση.
• Ένα σχετικό μέγεθος (κυρίως μεσαίο) αποφασίζεται μετά από αμοιβαία συζήτηση και συμφωνία των μελών της ομάδας ή των εκτιμητών. Στη συνέχεια, οι αριθμοί αντιστοιχίζονται στα στοιχεία ανάλογα με το σχετικό μέγεθος που αντιστοιχεί στο Μεσαίο μέγεθος.
• Μειονέκτημα: Αυτό που φαίνεται L σε κάποιον μπορεί να φαίνεται XL για κάποιον.
• Όλοι οι εκτιμητές αποδίδουν το δικό τους μέγεθος στα αντικείμενα. Μετά από συζητήσεις και επίλυση των αναντιστοιχιών, επιτυγχάνεται συναίνεση για να ληφθεί η τελική εκτίμηση.

# 3) Ψηφοφορία με κουκκίδες

• Αυτή είναι βασικά μια μέθοδος κατάταξης για να αποφασίσετε τη σειρά του Product Backlog από τις ιστορίες υψηλότερης προτεραιότητας έως τις ιστορίες χαμηλότερης προτεραιότητας. Αυτό γίνεται για να επιλέξετε τις πιο σημαντικές ιστορίες που πρέπει να προωθηθούν.
• Αρχικά, δημοσιεύστε όλες τις ιστορίες των χρηστών μαζί με την περιγραφή τους στον τοίχο ή στον πίνακα χρησιμοποιώντας κίτρινα αυτοκόλλητα ή με τρόπο που τους ξεχωρίζει για τη λήψη των ψήφων.
• Σε όλους τους ενδιαφερόμενους παρέχονται 4 έως 5 κουκκίδες (κυρίως με τη μορφή αυτοκόλλητων ετικεττών, στυλό ή μαρκαδόροι μπορούν επίσης να χρησιμοποιηθούν για την τελεία).
• Όλα τα ενδιαφερόμενα μέρη καλούνται να δώσουν τις ψήφους τους στις ιστορίες χρηστών που προτιμούν.
• Ο Κάτοχος προϊόντος παραγγέλνει τα στοιχεία καθυστέρησης προϊόντος από τα πιο προτιμώμενα (ένα με τις περισσότερες από τελείες) έως τα λιγότερο προτιμώμενα (ένα με τουλάχιστον όχι τελείες).
• Ίσως να συμβαίνει, όπου λίγοι ενδιαφερόμενοι είναι δυσαρεστημένοι με την απόφαση που αποφασίστηκε. Σε αυτήν την περίπτωση, οι ιστορίες χρηστών χωρίζονται σε 3 ομάδες μετά τις συζητήσεις: υψηλή προτεραιότητα, χαμηλή προτεραιότητα και μεσαία προτεραιότητα. Οι ιστορίες χρηστών υψηλής προτεραιότητας δημοσιεύονται στον τοίχο για να λάβουν τις ψήφους. Αυτό γίνεται έως ότου επιτευχθεί η τελική παραγγελία με τη συμφωνία όλων των ενδιαφερομένων.

# 4) Το σύστημα κάδων

• Είναι μια καλή τεχνική όταν ένα μεγάλο όχι. των αντικειμένων πρέπει να εκτιμηθούν κατά μεγάλο αριθμό. των συμμετεχόντων. Είναι πιο γρήγορο και πιο λογικό από το σχεδιασμό πόκερ.
• Δημιουργούνται διαφορετικοί κάδοι με τιμές: 0,1,2,3,4,5,8,13,20,30,50,100, 200. Αυτό μπορεί να επεκταθεί εάν απαιτείται. Αυτοί οι κάδοι δεν είναι τίποτα άλλο από κάρτες που αντιπροσωπεύουν τιμές τοποθετημένες διαδοχικά σε ένα τραπέζι.
• Οι ιστορίες πρέπει να τοποθετηθούν μέσα σε αυτές όπου ο εκτιμητής τις θεωρεί κατάλληλες. Όλα τα προς εκτίμηση στοιχεία είναι γραμμένα στις κάρτες.
• Διαλέξτε ένα στοιχείο τυχαία και τοποθετήστε το στον κάδο 8. Χρησιμοποιείται μόνο για αναφορά. Διαλέξτε μια άλλη ιστορία τυχαία, συζητήστε όλα τα χαρακτηριστικά και τις απαιτήσεις της με την ομάδα και κατόπιν συναίνεσης, τοποθετήστε την στον κατάλληλο κάδο. Παρομοίως, το τρίτο αντικείμενο συλλέγεται και τοποθετείται σε κατάλληλο κουβά.
• Η ακολουθία κάδου μπορεί επίσης να αλλάξει, σε περίπτωση που η ομάδα αισθανθεί το πρώτο στοιχείο που επιλέχθηκε, πρέπει να ανήκει στον κάδο 1 αντί στον κάδο 8.
• Ακολουθείται η προσέγγιση Divide and Conquer. Όλα τα υπόλοιπα στοιχεία κατανέμονται μεταξύ όλων των συμμετεχόντων. Όλοι οι συμμετέχοντες μπορούν να τοποθετήσουν το αντικείμενο χωρίς την έγκριση άλλων συμμετεχόντων.
• Τα αντικείμενα πρέπει να τοποθετηθούν σωστά. Δεν υπάρχει δυνατότητα τοποθέτησης αντικειμένων μεταξύ των κάδων.
• Εάν ένας συμμετέχων δεν καταλαβαίνει το στοιχείο καθυστέρησης προϊόντος ή εάν οι άλλοι συμμετέχοντες έχουν ολοκληρώσει την τοποθέτηση των ιστοριών χρηστών τους, οι ιστορίες χρηστών μπορούν να μεταφερθούν στους άλλους συμμετέχοντες.
• Επιτέλους, ο έλεγχος Sanity πραγματοποιείται από όλους τους συμμετέχοντες. Εάν κάποιος συμμετέχων εντοπίσει λάθος κάδο που έχει εκχωρηθεί σε ένα στοιχείο, τότε μπορεί να το ενημερώσει για άλλους συμμετέχοντες και να συζητήσει μαζί τους. Αυτό γίνεται έως ότου επιτευχθεί συναίνεση για το σύνολο των καθυστερήσεων προϊόντων.
• Ο διαμεσολαβητής πρέπει να ελέγξει ότι κανείς δεν μετακινεί τα αντικείμενα, εκτός εάν γίνει έλεγχος λογικής.
• Αυτό γίνεται επίσης για να επιτευχθεί η σειρά προτεραιότητας των στοιχείων καθυστέρησης προϊόντος.

# 5) Μεγάλο / Αβέβαιο / Μικρό

• Αυτή είναι μια τραχιά έκδοση και είναι η απλοποίηση του συστήματος κουβά όπου υπάρχουν μόνο τρία μεγέθη: Μεγάλο, Μικρό και Αβέβαιο.
• Οι συμμετέχοντες ή οι εκτιμητές καλούνται να τοποθετήσουν τα αντικείμενα σε μία από τις κατηγορίες. Πρώτον, οι απλές ιστορίες χρηστών επιλέγονται και τοποθετούνται στις μεγάλες και μικρές κατηγορίες. Στη συνέχεια, τα σύνθετα αντικείμενα λαμβάνονται.
• Είναι μια καλή τεχνική όταν υπάρχουν συγκρίσιμα στοιχεία στο Product Backlog.

# 6) Χαρτογράφηση συγγένειας

• Μια καλή τεχνική όταν η ομάδα είναι μικρή και όχι. των αντικειμένων καθυστέρησης είναι λιγότερο.
• Το πρώτο βήμα είναι το Silent Relative Sizing: Στον τοίχο, μια κάρτα με την ένδειξη 'Μικρότερη' είναι τοποθετημένη στην αριστερή πλευρά και η κάρτα με την ένδειξη 'Μεγαλύτερη' γραμμένη σε αυτήν τοποθετείται στη δεξιά πλευρά. Ο Κάτοχος προϊόντος παρέχει ένα υποσύνολο των στοιχείων σε όλους τους συμμετέχοντες. Όλοι οι συμμετέχοντες καλούνται να κάνουν μέγεθος κάθε αντικειμένου σε σχέση με τα μεγέθη στις κάρτες στον τοίχο, λαμβάνοντας υπόψη την προσπάθεια που απαιτείται για την υλοποίησή τους. Είναι η ατομική απόφαση του συμμετέχοντα χωρίς συζήτηση με τα άλλα μέλη της ομάδας. Ο Κάτοχος προϊόντος ή ο ενδιαφερόμενος είναι παρών για να ξεκαθαρίσει τις αμφιβολίες του συμμετέχοντα. Τα στοιχεία καθυστέρησης προϊόντων που είναι πολύ ασαφή για να κατανοηθούν από τα μέλη της ομάδας για εκτίμηση τοποθετούνται ξεχωριστά. Χρειάζονται 5-20 λεπτά.
• Επεξεργασία τοίχου: Τα μέλη της ομάδας μπορούν να αλλάξουν τη θέση των αντικειμένων στον τοίχο. Μπορούν να συζητήσουν τις απαιτήσεις σχεδιασμού και εφαρμογής με τα άλλα μέλη της ομάδας. Αυτή η δραστηριότητα μπορεί να κλείσει όταν συμβαίνει μικρή αλλαγή στον τοίχο. Χρειάζονται περίπου 20-60 λεπτά .
• Τοποθέτηση αντικειμένων σε σωστές τοποθεσίες: Μετά τις συζητήσεις, η ομάδα τοποθετεί τα στοιχεία καθυστέρησης του προϊόντος στις σχετικές και κατάλληλες θέσεις τους. Μπορούμε να χρησιμοποιήσουμε το μέγεθος των μπλουζών, τη σειρά Fibonacci κ.λπ. εδώ για να εκτιμήσουμε σχετικά το μέγεθος των αντικειμένων.
• Πρόκληση κατόχου προϊόντος: Ο Κάτοχος προϊόντος μπορεί να βρει κάποια ασυμφωνία στις εκτιμήσεις που έγιναν από την ομάδα και πρέπει να συζητήσει περισσότερα χαρακτηριστικά ή τις απαιτήσεις για ένα στοιχείο με την ομάδα. Μετά από συζητήσεις, γίνονται τελικές εκτιμήσεις.
• Εξαγωγή στο Εργαλείο διαχείρισης καθυστέρησης έργου: Για να βεβαιωθείτε ότι οι πληροφορίες σχετικά με τις τελικές εκτιμήσεις δεν έχουν χαθεί, εξαγάγετε τις σε ένα εργαλείο διαχείρισης καθυστερημένων προϊόντων.

# 7) Μέθοδος παραγγελίας

• Μια καλή τεχνική όταν το μεγάλο όχι. αντικειμένων και μικρό αριθ. των ανθρώπων είναι εκεί.
• Δίνει ακριβή σχετικά μεγέθη για τα είδη καθυστερημένων προϊόντων.
• Μια κλίμακα προετοιμάζεται από χαμηλή έως υψηλή. Όλα τα αντικείμενα τοποθετούνται τυχαία πάνω του. Κάθε συμμετέχων καλείται να μετακινήσει οποιοδήποτε στοιχείο στην κλίμακα, ταυτόχρονα. Η κίνηση μπορεί να είναι μία προς τα πάνω, μία προς τα κάτω ή να περάσει τη στροφή σε άλλο μέλος.
• Αυτό συνεχίζεται έως ότου όλοι οι συμμετέχοντες είναι ικανοποιημένοι και δεν θέλουν να μετακινήσουν κανένα στοιχείο στην κλίμακα.
• Αυτό δίνει επίσης τη σειρά προτεραιότητας των στοιχείων Product Backlog.

Υπολογισμός προϋπολογισμού σε ευκίνητο

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

Χρησιμοποιεί τα δεδομένα που συλλέχθηκαν από τα προηγούμενα έργα και χρησιμοποιεί τον μαθηματικό τύπο για να πάρει τον εκτιμώμενο προϋπολογισμό για το τρέχον έργο.

Ακολουθεί η ακολουθία των βημάτων, για τον υπολογισμό του προϋπολογισμού σε ένα έργο Agile:

# 1) Καταγράψτε όλες τις απαιτήσεις του έργου και κάντε το υπολογίζει για αυτούς χρησιμοποιώντας το πόκερ προγραμματισμού, το σύστημα Bucket, τη σειρά Fibonacci κ.λπ. Όλα τα μέλη της ομάδας θα πρέπει να συμφωνήσουν για τις εκτιμήσεις που έγιναν για τις αναφερόμενες απαιτήσεις μετά από σαφή ανάλυση και κατανόηση των ιστοριών των χρηστών. Οι εκτιμήσεις γίνονται με βάση τις δυνατότητες που θα εφαρμοστούν σε μια ιστορία χρήστη.

#δύο) Προσδιορίστε τη διάρκεια των επαναλήψεων που ονομάζονται Sprints και τα στοιχεία καθυστέρησης προϊόντων που έχουν εκχωρηθεί σε αυτό. Συνήθως διαρκεί 2 έως 3 εβδομάδες. Οι ιστορίες χρηστών επιλέγονται με μια ακολουθία ξεκινώντας από την ιστορία χρηστών της μέγιστης προτεραιότητας, μεταβαίνοντας σε μικρότερη προτεραιότητα και με την ιστορία με τη λιγότερη προτεραιότητα χρήστη στο τέλος. Αυτό βοηθά να αποφασίσετε ποιες ιστορίες χρηστών πρέπει να ληφθούν στο πρώτο Sprint και ποιες ιστορίες μπορούν να ληφθούν αργότερα.

# 3) Προετοιμάστε το καμένο γράφημα για να δώσετε μια σαφή εικόνα για το πόση δουλειά μένει να γίνει σε σχέση με τον χρόνο που απομένει για εφαρμογή. Βασικά δίνει το ρυθμό προόδου μιας ευέλικτης ομάδας. Δίνει μια σαφή εικόνα για το πώς συμπεριφέρεται η ομάδα και πώς αναμένεται να συμπεριφερθεί.

Η πρόοδος της ομάδας μετριέται από την άποψη των Ολοκληρωμένων εργασιών, της Υπολειπόμενης προσπάθειας, της Ιδανικής καταστροφής και των Υπολειπόμενων εργασιών όπως φαίνεται παρακάτω:

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

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

# 6) Παρακολουθώντας τους κρυμμένους κινδύνους. Οι κίνδυνοι στο έργο Agile περιλαμβάνουν: Κίνδυνος υπερβολικού προϋπολογισμού του έργου, Απουσία μελών της ομάδας, Μέλη δεν έχουν σαφή ή πλήρη γνώση, Μέλη δεν έχουν τις απαιτούμενες δεξιότητες, έχουν περάσει οι προθεσμίες κ.λπ.

Πρότυπα εκτίμησης στο έργο Agile Development

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

Τα κύρια πρότυπα είναι όπως αναφέρονται παρακάτω:

1) Πρότυπο σχεδίου έργου Agile:

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

(Σημείωση: Κάντε κλικ σε οποιαδήποτε εικόνα για μεγέθυνση)

2) Πρότυπο προγράμματος απελευθέρωσης Agile:

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

3) Πρότυπο καθυστέρησης προϊόντων ευέλικτου προϊόντος:

Περιγράφει το πλήρες καθυστερημένο προϊόν που ορίζεται για το έργο. Δίνει λεπτομέρεια των εργασιών των Sprints μαζί με την κατάσταση, την προτεραιότητα, τα σημεία ιστορίας και εάν έχουν ανατεθεί σε ένα Sprint ή εάν υπάρχουν κάποια πρόσθετα καθήκοντα όπως ελαττώματα κ.λπ.

4) Πρότυπο καθυστέρησης Agile Sprint:

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

5) Πρότυπο σχεδίου ευκίνητων δοκιμών:

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

Αναφέρει επίσης το Όνομα Έργου, Συμβατό πρόγραμμα περιήγησης, Έκδοση της υπό δοκιμή Εφαρμογής, Αναγνωριστικό περίπτωσης δοκιμής για ένα επιλεγμένο σενάριο, Γραμμένο από, Δοκιμασμένο από, Περιγραφή κ.λπ.

6) Πρότυπο ιστορίας χρηστών Agile:

Δίνει τις λεπτομέρειες συγκεκριμένες για την ανάλυση της ιστορίας του χρήστη όπως Ποιοι είναι οι ρόλοι που απαιτούνται για να δοκιμαστεί μια συγκεκριμένη λειτουργικότητα, ποια είναι η προϋπόθεση (ρύθμιση περιβάλλοντος και ενεργοποιημένοι σύνδεσμοι) και ποιο είναι το αναμενόμενο αποτέλεσμα;

7) Πρότυπο χάρτη ευκίνητων οδών:

Δίνει μια κατεύθυνση στο έργο της εταιρείας, σε βραχυπρόθεσμη και μακροπρόθεσμη βάση. Βοηθά στον καθορισμό προσδοκιών εντός της εταιρείας. Και η επισκόπηση του προορισμού του έργου.

Στάδια εκτίμησης στο Agile Project

Σε ένα Agile Project, οι εκτιμήσεις γίνονται σε 3 επίπεδα όπως αναφέρονται παρακάτω:

• Επίπεδο έργου / πρότασης: Το συνολικό λειτουργικό μέγεθος ολόκληρης της εφαρμογής εκτιμάται χρησιμοποιώντας τη μέθοδο Quick Function Point Analysis (QFPA) όταν είναι διαθέσιμες μόνο απαιτήσεις υψηλού επιπέδου.
• Επίπεδο έκδοσης: Τα σημεία ιστορίας αντιστοιχίζονται στις ιστορίες χρηστών που βοηθούν στον προσδιορισμό του αριθ. των κυκλοφοριών που έχουν προγραμματιστεί στο πλαίσιο ενός έργου και του αριθ. ιστοριών χρηστών που θα ληφθούν σε μια κυκλοφορία και σπριντ.
• Επίπεδο σπριντ: Οι εκτιμώμενες ώρες αντιστοιχίζονται στα καθήκοντα των ιστοριών χρηστών σε ένα σπριντ. Αυτό γίνεται για να εξασφαλιστεί η δέσμευση της ανάπτυξης για την παράδοση ιστοριών χρηστών σε ένα σπριντ.

Τα S1, S2, S3, S4, S5, S6 είναι σπριντ.

# 1) Εκτίμηση προτάσεων ή επιπέδου έργου

Είναι μια εκτίμηση πολύ υψηλού επιπέδου για το έργο. Επικεντρώνεται στο συνολικό αριθμό των απαιτήσεων στο στοιχείο Product Backlog. Τα Function Points χρησιμοποιούνται για την εκτίμηση του μεγέθους του λογισμικού / έργου πριν τεκμηριωθεί μια λεπτομερής περιγραφή των λειτουργικών απαιτήσεων.

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

Κατά τη διάρκεια των αρχικών σταδίων του έργου, συνιστάται να υιοθετηθεί η μέθοδος Quick Function Point Analysis (QFPA).

Η μέθοδος Quick Function Point Analysis είναι μια μοναδική προσέγγιση για την εκτίμηση του FP όταν διατίθενται μόνο υψηλού επιπέδου απαιτήσεις.

Πώς να υπολογίσετε το συνολικό λειτουργικό μέγεθος;

• Κατανοήστε όλες τις λειτουργίες μιας εφαρμογής με τη βοήθεια ειδικών τομέα.
• Προσδιορίστε και απαριθμήστε όλες τις πιθανές λειτουργίες μιας εφαρμογής.
• Οι λειτουργίες αποθήκευσης δεδομένων ταξινομούνται σε αρχεία εσωτερικής λογικής (δεδομένα αποθηκευμένα εσωτερικά εντός της εφαρμογής) και αρχεία εξωτερικής διεπαφής (δεδομένα που χρησιμοποιούνται μόνο για σκοπούς αναφοράς).
• Οι συναρτήσεις συναλλαγής ταξινομούνται σε εξωτερικές εισόδους (δεδομένα που προέρχονται από εξωτερικές πηγές στην εφαρμογή), εξωτερικές εξόδους (τα παράγωγα δεδομένα πηγαίνουν από εφαρμογή σε εξωτερικό) και εξωτερικές έρευνες (δεδομένα ανακτώνται από μία ή περισσότερες εξωτερικές εισόδους και εξωτερικές εξόδους).
• Υπολογίστε το μέγεθος FP για κάθε συνάρτηση υπολογίζοντας τη μέση πολυπλοκότητά της.
• Συνοψίστε το μέγεθος FP όλων των λειτουργιών, για να λάβετε το συνολικό λειτουργικό μέγεθος της εφαρμογής.
• Τουλάχιστον δύο άτομα με εμπειρία στην ανάλυση FP, θα πρέπει να υπολογίζουν ανεξάρτητα, να ταιριάζουν με τα αποτελέσματα και να επιλύουν τις διαφορές.

Παράδειγμα εκτίμησης επιπέδου έργου:

Παρακάτω είναι η λίστα των απαιτήσεων για ένα έργο, όπως στο Product Backlog:

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

Η ομάδα χρησιμοποιεί μια γρήγορη εκτίμηση FP για να εκτιμήσει το μέγεθος του έργου.

Ακολουθεί η ανάλυση που έγινε:

• Η λειτουργία αποθήκευσης δεδομένων εδώ αποθηκεύει τα διαπιστευτήρια χρήστη για να συνδεθείτε και να αλλάξετε τον κωδικό πρόσβασης.
• Δεδομένου ότι τα διαπιστευτήρια αποθηκεύονται εντός του ορίου της εφαρμογής, αποθηκεύονται σε ILF (Εσωτερικά λογικά αρχεία).
• Οι συναρτήσεις συναλλαγής περιλαμβάνουν:
  • Είσοδος χρήστη και εμφάνιση της κύριας σελίδας.
  • Αποσύνδεση χρήστη και εμφάνιση της οθόνης αποσύνδεσης.
  • Δυνατότητα αλλαγής του κωδικού πρόσβασης.

Ακολουθούν τα βήματα που εκτελούνται για την εκτίμηση του μεγέθους του έργου χρησιμοποιώντας την Ανάλυση Quick Function Point:

ΒΗΜΑ # 1: Καταγράψτε όλες τις συναρτήσεις δεδομένων

Το UFP (Unjjusted Function Point) λαμβάνεται από τον πίνακα Caper Jones.

ΒΗΜΑ # 2: Καταγράψτε όλες τις Λειτουργίες Συναλλαγών

Το UFP (Unjjusted Function Point) λαμβάνεται από τον πίνακα Caper Jones.

ΒΗΜΑ # 3: Απόκτηση του εκτιμώμενου μεγέθους του έργου στα Function Points

UFP = FP δεδομένων + FP συναλλαγής

UFP = 10 + 12 = 22 UFP

FP = UFP * VFP = 22 * ​​1 = 22 FP (Υποθέτοντας VFP (Συντελεστής προσαρμογής τιμής = 1)

Παραγωγικότητα = 16 FP / μήνα (Κανονικό πρότυπο)

Προσπάθεια = FP / Παραγωγικότητα = 22/16-άτομο μήνας = 1,37 άτομο μήνας

Ερωτήσεις και απαντήσεις συνέντευξης προγραμματιστή salesforce για έμπειρους

# 2) Εκτίμηση επιπέδου έκδοσης

Οι εκτιμήσεις επιπέδου έκδοσης γίνονται κατά τη διάρκεια του προγραμματισμού κυκλοφορίας. Είναι η επόμενη δραστηριότητα μετά από εκτίμηση επιπέδου έργου. Οι απαιτήσεις προτεραιότητας λαμβάνονται από το Product Backlog που έχει τη μορφή Ιστοριών χρηστών.

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

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

Η εκτίμηση του ιστορικού γίνεται με βάση:

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

Τα S1, S2, S3, S4, S5 είναι σπριντ.

Βήματα για την ανάθεση σημείων ιστορίας σε μια ιστορία χρήστη:

• Όλα τα μέλη της ομάδας συγκεντρώνονται γύρω από ένα τραπέζι που περνά από τις ιστορίες χρηστών που υπάρχουν στο Sprint Backlog.
• Αποφασίζεται η έννοια ενός σημείου ιστορίας και η αντίστοιχη προσπάθεια.
• Ένα από τα μέλη της ομάδας διαβάζει μια ιστορία χρήστη και στη συνέχεια ζητά από τα μέλη της ομάδας να αναθέσουν τα σχετικά σημεία ιστορίας.
• Εάν υπάρχει σημαντική διαφορά μεταξύ των σημείων ιστορίας που έχουν ανατεθεί από τα μέλη της ομάδας, τότε δίνουν μια εξήγηση για τα σημεία ιστορίας που έχουν εκχωρήσει, επιτυγχάνοντας έτσι μια συναίνεση στο τέλος.
• Η διαδικασία επαναλαμβάνεται 3-4 φορές έως ότου δεν υπάρχει σημαντική διαφορά μεταξύ των εκτιμήσεων που δίνονται από τα μέλη της ομάδας.
• Το μέγεθος των ιστοριών βοηθά στον καθορισμό πόσων ιστοριών θα ληφθούν σε ένα σπριντ και κυκλοφορία.

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

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

Μπορούμε να χρησιμοποιήσουμε τις παρακάτω μεθόδους για εκτιμήσεις πόντων ιστορίας:

• Αριθμητικό μέγεθος: 1 έως 10
• Μέγεθος μπλουζών: Κάθε απαίτηση ταξινομείται ως Extra Small (XS), Small (S), Medium (M), Large (L), Extra Large (XL).
• Σειρά Fibonacci: Η εκτίμηση έγινε μέσω της ακολουθίας Fibonacci (1,2,3,5,8,13,21,34,….)

Εκτίμηση των παραπάνω ιστοριών χρηστών μέσω της ακολουθίας Fibonacci:

# 3) Εκτίμηση επιπέδου σπριντ

Οι εκτιμήσεις επιπέδου Sprint γίνονται κατά τη διάρκεια του Sprint Planning. Τα στοιχεία καθυστέρησης προϊόντων υψηλής προτεραιότητας λαμβάνονται και χωρίζονται σε διαφορετικές εργασίες, όπως Λεπτομέρειες, Σχεδιασμός, Ανάλυση, Ανάπτυξη, Δημιουργία δοκιμαστικών περιπτώσεων, Εκτέλεση δοκιμαστικών περιπτώσεων, Δοκιμή αποδοχής χρηστών κ.λπ.

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

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

μικρό για την εκχώρηση εκτιμώμενων ωρών στις εργασίες:

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

Παράδειγμα εκτίμησης επιπέδων σπριντ:

Υπάρχουν δύο μέρη της συνάντησης Sprint Planning:

• Πρώτο μέρος: Εστίαση στην αποσαφήνιση των απαιτήσεων για Ιστορίες χρηστών, που επιλέγονται από το Product Backlog.
• Δεύτερο μέρος: Το επίκεντρο είναι να σπάσουμε τις απαιτήσεις σε εργασίες και να εκτιμήσουμε τις ώρες που απαιτούνται για την ολοκλήρωσή τους. Θα πρέπει να περιλαμβάνονται όλες οι εργασίες που είναι απαραίτητες για να παραδοθεί το αντικείμενο του Product Backlog. Οι εργασίες θα πρέπει να είναι μικρές. Στην ιδανική περίπτωση, μια προσπάθεια εργασίας δεν πρέπει να υπερβαίνει τις έξι ώρες.

συμπέρασμα

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

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

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

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

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

• Πώς να κάνετε τη διαδικασία ευέλικτης εκτίμησης εύκολη με το σχεδιασμό πόκερ
• Agile Vs Waterfall: Ποια είναι η καλύτερη μεθοδολογία για το έργο σας;
• Τεχνικές εκτίμησης δοκιμής λογισμικού (Πλήρης οδηγός εκτίμησης προσπάθειας δοκιμής)
• VersionOne Tutorial: All-in-one Agile Project Management Tool Οδηγός
• Jira Portfolio Tutorial: Agile Project Portfolio Management Plug-in για JIRA (Κριτική)
• Κορυφαία 10 καλύτερα εργαλεία διαχείρισης έργων Agile το 2021
• Βασικές εργασίες για ένα επιτυχημένο ευκίνητο ταξίδι: Πώς να επιλέξετε τη σωστή μέθοδο, εργαλεία και τεχνικές
• 4 βήματα προς την ανάπτυξη της ευέλικτης δοκιμαστικής νοοτροπίας για επιτυχημένη μετάβαση στην ευέλικτη διαδικασία