Σχετικά με αυτό το πρότυπο
Οι περισσότερες ομάδες σχεδιάζουν τα sprints τους μέσα σε tickets του Jira και ένα backlog, και μετά χάνουν τον έλεγχο του πότε παραδίδεται πραγματικά κάθε κομμάτι. Μια προβολή Gantt ενός μόνο sprint αναδεικνύει το πραγματικό χρονοδιάγραμμα: πότε ο σχεδιασμός παραδίδεται στην ανάπτυξη, πότε κάθε story βρίσκεται σε έλεγχο, πότε το παραλαμβάνει το QA, πότε γίνεται το demo. Αυτό το πρότυπο 2 εβδομάδων μπορεί να αντιγραφεί για κάθε sprint ή να χρησιμοποιηθεί για τον σχεδιασμό ενός μεγαλύτερου release ως αλυσίδα από sprints.
Πώς αναλύεται ένα sprint 2 εβδομάδων
Εκκίνηση του sprint
Συνάντηση sprint planning: αναθεώρηση του backlog, εκτίμηση των story points, σύγκριση χωρητικότητας και velocity, στόχος του sprint. Επιβεβαιώστε ότι όλοι έχουν τα stories τους ανατεθειμένα. Κλείστε με έναν στόχο του sprint σε μία πρόταση που μπορεί να απαγγείλει οποιοσδήποτε στην ομάδα.
- Επεξεργασία του backlog
- Εκτίμηση story points
- Έλεγχος χωρητικότητας έναντι velocity
- Ανάθεση stories
- Στόχος του sprint
Ημέρες 2–4 — Σχεδιασμός και εκκίνηση
Οι σχεδιαστές ολοκληρώνουν τυχόν specs που απομένουν. Οι μηχανικοί ξεκινούν πρώτα από τα μεγαλύτερα stories (μεταφέρουν το ρίσκο νωρίτερα στο sprint). Καθημερινή συνάντηση την ίδια ώρα κάθε μέρα — 15 λεπτά, τρεις ερωτήσεις ανά άτομο.
- Καθημερινή συνάντηση
- Ο σχεδιαστής παραδίδει τα specs
- Οι μηχανικοί ξεκινούν τα μεγαλύτερα stories
- Επιβεβαίωση προτύπου PR και SLA review
Ημέρες 5–8 — Ανάπτυξη
Εντατική ανάπτυξη. Το code review γίνεται συνεχώς (στόχος: το PR να είναι ανοιχτό λιγότερο από 24 ώρες πριν από το πρώτο review). Ενδιάμεση ενημέρωση την ημέρα 7 — επισημάνετε κάθε story που κινδυνεύει να καθυστερήσει.
- Καθημερινή συνάντηση
- Code review (SLA 24 ωρών)
- Ενδιάμεση ενημέρωση (ημέρα 7)
- Επανασχεδιασμός stories υψηλού ρίσκου
Ημέρες 9–11 — QA και merge
Τα stories ολοκληρώνονται και είναι έτοιμα για QA. Οι διορθώσεις σφαλμάτων από το QA επιστρέφουν στους developers. Μέχρι το τέλος της ημέρας 11, κάθε story έτοιμο προς παράδοση έχει γίνει merge. Ό,τι δεν πρόλαβε επιστρέφει στο backlog.
- Έλεγχος QA στα ολοκληρωμένα stories
- Κύκλος διόρθωσης σφαλμάτων
- Merge στο main
- Ενημέρωση release notes
Ημέρες 12–14 — Demo και retro
Ημέρα 12: deploy σε staging, smoke tests. Ημέρα 13: demo του sprint στους stakeholders — κάθε υπεύθυνος story παρουσιάζει τη δουλειά του. Ημέρα 14: αναδρομική ανάλυση — τι πήγε καλά, τι μας καθυστέρησε, τι να δοκιμάσουμε στο επόμενο sprint. Προγραμματίστε την εκκίνηση του επόμενου sprint.
- Deploy σε staging
- Smoke tests
- Demo του sprint
- Αναδρομική ανάλυση
- Εκκίνηση επόμενου sprint
Συμβουλές από ομάδες με ομαλά sprints
- Ξεκινήστε πρώτα από το μεγαλύτερο story. Μεταφέρετε το ρίσκο νωρίτερα στο sprint, όχι αργότερα.
- Ανοίξτε κάθε PR μέσα σε 24 ώρες από τη στιγμή που η δουλειά είναι έτοιμη. Τα PR που παραμένουν χωρίς να ανοιχτούν είναι σιωπηλές καθυστερήσεις.
- Κάντε την ενδιάμεση ενημέρωση την ημέρα 7. Τα stories που κινδυνεύουν την ημέρα 7 είναι ακόμα σώσιμα· την ημέρα 12 δεν είναι.
- Κλείστε κάθε αναδρομική ανάλυση με μία συγκεκριμένη αλλαγή για το επόμενο sprint. Λίστες με 15 ιδέες δεν παράγουν καμία αλλαγή.
- Κάντε το demo ακόμα κι αν τα μισά stories δεν πρόλαβαν. Η παρουσίαση μερικής δουλειάς δημιουργεί πίεση για παράδοση.
Συχνές ερωτήσεις
Είναι χρήσιμο το Gantt για agile sprints;
Ναι — για την προβολή ενός sprint, κάνει ορατή τη σειρά των stories και τις παραδόσεις με τρόπο που ένας πίνακας Kanban δεν καταφέρνει.
Πρέπει να το κάνω αυτό σε κάθε sprint;
Ένα Gantt ενός sprint είναι πιο χρήσιμο στα πρώτα 3–5 sprints μιας νέας ομάδας, ή σε οποιοδήποτε sprint με εξαρτήσεις μεταξύ ομάδων.
Μπορώ να συνδέσω πολλά sprints σε ένα πλάνο release;
Ναι. Ανοίξτε αυτό το πρότυπο και προσθέστε 2–3 ακόμα blocks των 2 εβδομάδων για μια προβολή σε επίπεδο release.