Αφηρημένο
Το βιβλίο είναι ένας αφηγημένος αλγόριθμος για τη διεξαγωγή της διαδικασίας ανάπτυξης από την ιδέα έως την υλοποίηση χρησιμοποιώντας ευέλικτες τεχνικές. Η διαδικασία παρουσιάζεται σε βήματα και σε κάθε βήμα υποδεικνύονται οι μέθοδοι για το βήμα της διαδικασίας. Ο συγγραφέας επισημαίνει ότι οι περισσότερες από τις μεθόδους δεν είναι πρωτότυπες, χωρίς να ισχυρίζεται ότι είναι πρωτότυπες. Αλλά το καλό στυλ γραφής και κάποια ακεραιότητα της διαδικασίας κάνουν το βιβλίο πολύ χρήσιμο.
Μια βασική τεχνική της χαρτογράφησης ιστορίας χρήστη είναι η δομή ιδεών και παραστάσεων καθώς ο χρήστης προχωρά στη διαδικασία.
Ταυτόχρονα, η διαδικασία μπορεί να περιγραφεί με διαφορετικούς τρόπους. Μπορείτε να δημιουργήσετε βήματα καθώς επιτυγχάνετε μια βασική τιμή ή μπορείτε απλά να κάνετε και να φανταστείτε την εργάσιμη ημέρα των χρηστών καθώς περνάει χρησιμοποιώντας το σύστημα. Ο συγγραφέας εστιάζει στο γεγονός ότι οι διαδικασίες πρέπει να περιγράφονται, να εκφράζονται με τη μορφή μιας ιστορίας χρήστη σε έναν χάρτη διεργασιών, κάτι που μας έδωσε το όνομα χάρτης ιστορίας χρήστη.
Ποιος το χρειάζεται
Για αναλυτές πληροφορικής και διαχειριστές έργων. Πρέπει να διαβαστεί. Εύκολο και ευχάριστο στην ανάγνωση, το βιβλίο είναι μεσαίου μεγέθους.
Επανεξέταση
Στην απλούστερη μορφή του, έτσι λειτουργεί.
Ένας επισκέπτης έρχεται σε ένα καφέ, επιλέγει πιάτα, παραγγέλνει, λαμβάνει φαγητό, τρώει και πληρώνει.
Μπορούμε να γράψουμε απαιτήσεις για αυτό που θέλουμε από το σύστημα σε κάθε στάδιο.
Το σύστημα θα πρέπει να εμφανίζει μια λίστα με πιάτα, κάθε πιάτο έχει σύνθεση, βάρος και τιμή και να μπορεί να προστεθεί στο καλάθι. Γιατί είμαστε σίγουροι για αυτές τις απαιτήσεις; Αυτό δεν περιγράφεται στην «τυπική» περιγραφή των απαιτήσεων και αυτό δημιουργεί κινδύνους.
Οι ερμηνευτές που δεν καταλαβαίνουν γιατί αυτό είναι απαραίτητο συνήθως κάνουν το λάθος. Οι ερμηνευτές που δεν συμμετέχουν στη διαδικασία δημιουργίας μιας ιδέας δεν εμπλέκονται στο αποτέλεσμα. Η Agile λέει, ας εστιάσουμε κυρίως όχι στο σύστημα, αλλά στους ανθρώπους, στους καταναλωτές, στα καθήκοντα και τους στόχους τους.
Δημιουργούμε περσόνες, τους δίνουμε λεπτομέρειες για ενσυναίσθηση και αρχίζουμε να λέμε ιστορίες από την πλευρά της περσόνας.
Ο υπάλληλος του γραφείου Zakhar πήγε για μεσημεριανό γεύμα και θέλει να έχει ένα γρήγορο σνακ. Τι χρειάζεται; Η ιδέα είναι ότι μάλλον θέλει ένα επαγγελματικό γεύμα. Μια άλλη ιδέα είναι ότι θέλει το σύστημα να θυμάται τις προτιμήσεις του, επειδή κάνει δίαιτα. Μια άλλη ιδέα. Θέλει να του φέρουν καφέ αμέσως γιατί έχει συνηθίσει να πίνει καφέ πριν το μεσημεριανό γεύμα.
Και υπάρχει επίσης μια επιχείρηση (οργανωτικός χαρακτήρας είναι ένας χαρακτήρας που εκπροσωπεί τα συμφέροντα ενός οργανισμού). Οι επιχειρήσεις θέλουν να αυξήσουν τη μέση επιταγή, να αυξήσουν τη συχνότητα των αγορών και να αυξήσουν τα κέρδη. Η ιδέα είναι - ας προσφέρουμε ασυνήθιστα πιάτα κάποιας κουζίνας. Μια άλλη ιδέα - ας παρουσιάσουμε το πρωινό.
Οι ιδέες μπορούν και πρέπει να συγκεκριμενοποιηθούν, να μετασχηματιστούν και να παρουσιαστούν με τη μορφή μιας ιστορίας χρήστη. Ως υπάλληλος του Zakhar Business Center, θέλω το σύστημα να με αναγνωρίζει, ώστε να μπορώ να λαμβάνω ένα μενού με βάση τις προτιμήσεις μου. Ως σερβιτόρος, θέλω το σύστημα να με ειδοποιεί πότε πρέπει να πλησιάσω το τραπέζι, ώστε ο πελάτης να είναι ικανοποιημένος με τη γρήγορη εξυπηρέτηση. Και ούτω καθεξής.
Δεκάδες ιστορίες. Επόμενο είναι η ιεράρχηση και η εκκρεμότητα; Ο Jeff επισημαίνει τα προβλήματα που προκύπτουν: ο εγκλωβισμός σε μικρές λεπτομέρειες και η απώλεια της εννοιολογικής κατανόησης, καθώς και η ιεράρχηση της λειτουργικότητας δημιουργεί μια θολή εικόνα λόγω ασυνέπειας με τους στόχους.
Η διαδρομή του συγγραφέα: Δίνουμε προτεραιότητα όχι στη λειτουργικότητα, αλλά στο αποτέλεσμα = τι παίρνει ο χρήστης στο τέλος.
Ένα προφανές μη προφανές σημείο: η συνεδρία ιεράρχησης δεν πραγματοποιείται από όλη την ομάδα, επειδή είναι αναποτελεσματική, αλλά από τρία άτομα. Το πρώτο είναι υπεύθυνο για τις επιχειρήσεις, το δεύτερο για την εμπειρία χρήστη και το τρίτο για την υλοποίηση.
Ας επιλέξουμε το ελάχιστο για την επίλυση ενός προβλήματος χρήστη (ελάχιστη βιώσιμη λύση).
Αναλύουμε τις ιδέες πρώτης προτεραιότητας χρησιμοποιώντας ιστορίες χρηστών, σκίτσα σχεδίασης, περιορισμούς και επιχειρηματικούς κανόνες στον χάρτη ιστορίας χρήστη, λέγοντας και συζητώντας με την ομάδα τι χρειάζονται οι άνθρωποι και οι ενδιαφερόμενοι σε κάθε βήμα της διαδικασίας. Αφήνουμε τις υπόλοιπες ιδέες ανεξιχνίαστες στο υστέρημα των ευκαιριών.
Η διαδικασία είναι γραμμένη σε κάρτες από αριστερά προς τα δεξιά, με ιδέες σε κάρτες κάτω από τα βήματα της διαδικασίας. Είναι επιτακτική ανάγκη η διαδρομή σε όλη την ιστορία να συζητηθεί μαζί με τα μέλη της ομάδας για να εξασφαλιστεί η αμοιβαία κατανόηση.
Η επεξεργασία με αυτόν τον τρόπο δημιουργεί ακεραιότητα στη συμμόρφωση με τις διαδικασίες.
Οι ιδέες που λαμβάνονται πρέπει να δοκιμαστούν. Ένα μη μέλος της ομάδας βάζει το καπέλο του ατόμου και ζει την ημέρα του ατόμου στο κεφάλι του, λύνοντας το πρόβλημά του. Είναι πιθανό να μην δει τις εξελίξεις, δημιουργώντας ξανά κάρτες και η ομάδα να ανακαλύψει εναλλακτικές για τον εαυτό της.
Στη συνέχεια υπάρχει λεπτομέρεια για αξιολόγηση. Τρία άτομα είναι αρκετά για αυτό. Υπεύθυνος για την εμπειρία χρήστη, προγραμματιστής, δοκιμαστής με μια αγαπημένη ερώτηση: "Τι θα γινόταν αν...".
Σε κάθε στάδιο, η συζήτηση ακολουθεί έναν χάρτη διαδικασίας του ιστορικού του χρήστη, ο οποίος επιτρέπει τη διατήρηση της εργασίας του χρήστη στο μυαλό για τη δημιουργία μιας συνεκτικής κατανόησης.
Είναι απαραίτητη η τεκμηρίωση κατά τη γνώμη του συγγραφέα; Ναι, το χρειάζομαι. Αλλά ως σημειώσεις που σας επιτρέπουν να θυμάστε τι συμφωνήσατε. Το να εμπλακεί ξανά ένας ξένος απαιτεί συζήτηση.
Ο συγγραφέας δεν εμβαθύνει στο θέμα της επάρκειας τεκμηρίωσης, εστιάζοντας στην ανάγκη συζήτησης. (Ναι, χρειάζεται τεκμηρίωση, όσο κι αν το ισχυρίζονται άτομα που δεν έχουν βαθιά κατανόηση του agile). Επίσης, η επεξεργασία μέρους μόνο των δυνατοτήτων μπορεί να οδηγήσει στην ανάγκη για πλήρη επανεπεξεργασία ολόκληρου του συστήματος. Ο συγγραφέας επισημαίνει τον κίνδυνο υπερβολικής επεξεργασίας στην περίπτωση που η ιδέα είναι λανθασμένη.
Για την εξάλειψη των κινδύνων, είναι απαραίτητο να λαμβάνετε γρήγορα σχόλια για το προϊόν που δημιουργείται για να ελαχιστοποιήσετε τη ζημιά από τη δημιουργία του «λάθους» προϊόντος. Κάναμε ένα σκίτσο της ιδέας - την επικυρώσαμε με τον χρήστη, σχεδιάσαμε πρωτότυπα διεπαφής - την επικυρώσαμε με τον χρήστη κ.λπ. (Ξεχωριστά, υπάρχουν λίγες πληροφορίες σχετικά με τον τρόπο επικύρωσης των πρωτοτύπων προγραμμάτων). Οι στόχοι της δημιουργίας λογισμικού, ειδικά στο αρχικό στάδιο, είναι η εκμάθηση μέσω της λήψης γρήγορης ανατροφοδότησης· κατά συνέπεια, το πρώτο προϊόν που δημιουργείται είναι σκίτσα που μπορούν να αποδείξουν ή να διαψεύσουν μια υπόθεση. (Ο συγγραφέας βασίζεται στο έργο του Eric Ries «Startup using Lean methodology»).
Ένας χάρτης ιστορίας βοηθά στη βελτίωση της επικοινωνίας όταν η εφαρμογή πραγματοποιείται σε πολλές ομάδες. Τι πρέπει να υπάρχει στον χάρτη; Τι χρειάζεστε για να συνεχίσετε τη συζήτηση. Όχι μόνο μια ιστορία χρήστη (ποιος, τι, γιατί), αλλά ιδέες, γεγονότα, σκίτσα διεπαφής κ.λπ.
Διαιρώντας τις κάρτες στον χάρτη ιστορικού σε πολλές οριζόντιες γραμμές, μπορείτε να χωρίσετε την εργασία σε εκδόσεις - επισημάνετε το ελάχιστο, ένα επίπεδο αυξανόμενης λειτουργικότητας και τόξα.
Λέμε ιστορίες στον χάρτη διαδικασίας.
Ένας υπάλληλος ήρθε για μεσημεριανό γεύμα.
Τι θελει? Ταχύτητες εξυπηρέτησης. Έτσι ώστε το μεσημεριανό του να τον περιμένει ήδη στο τραπέζι ή τουλάχιστον σε ένα δίσκο. Ωχ - ένα χαμένο βήμα: ο υπάλληλος ήθελε να φάει. Συνδέθηκε και επέλεξε την επιλογή επαγγελματικού γεύματος. Είδε το περιεχόμενο σε θερμίδες και το θρεπτικό περιεχόμενο για να τον βοηθήσει να κάνει δίαιτα και να μην πάρει βάρος. Είδε φωτογραφίες του πιάτου για να αποφασίσει αν θα έτρωγε σε αυτό το μέρος ή όχι.
Στη συνέχεια, θα πάει να πάρει μεσημεριανό και βραδινό; Ή μήπως θα παραδοθεί το γεύμα στο γραφείο του; Στη συνέχεια, το βήμα της διαδικασίας είναι η επιλογή ενός μέρους για φαγητό. Θέλει να δει πότε θα του παραδοθεί και πόσο θα κοστίσει, ώστε να μπορεί να επιλέξει πού θα ξοδέψει τον χρόνο και την ενέργειά του - κατεβαίνοντας κάτω ή πηγαίνοντας στη δουλειά. Θέλει να δει πόσο απασχολημένο είναι το καφενείο για να μην τρέμει σε ουρές.
Τότε ο υπάλληλος ήρθε στο καφενείο. Θέλει να δει το δίσκο του για να τον πάρει και να πάει κατευθείαν για δείπνο. Το καφενείο θέλει να δεχτεί χρήματα για να βγάλει χρήματα από το σέρβις. Ο υπάλληλος θέλει να χάσει ελάχιστο χρόνο σε οικισμούς με το καφενείο, για να μην σπαταλήσει άσκοπα πολύτιμο χρόνο. Πως να το κάνεις? Πληρώστε εκ των προτέρων ή το αντίστροφο μετά την εξ αποστάσεως εξυπηρέτηση. Ή πληρώστε επί τόπου χρησιμοποιώντας ένα περίπτερο. Ποιο είναι το πιο σημαντικό πράγμα σε αυτό; Πόσα άτομα είναι διατεθειμένα να πληρώσουν για μεσημεριανό γεύμα με τραπεζική κάρτα; Πόσα άτομα θα εμπιστεύονταν αυτή την καντίνα για να αποθηκεύσει τον αριθμό της κάρτας τους για επαναλαμβανόμενες πληρωμές; Χωρίς έρευνα πεδίου είναι ασαφές, απαιτείται δοκιμή.
Σε κάθε βήμα της διαδικασίας, πρέπει να παρέχετε με κάποιο τρόπο λειτουργικότητα· για αυτό πρέπει να λάβετε ως βάση κάποιο άτομο και να επιλέξετε αυτό που είναι πιο σημαντικό για αυτόν (οι ίδιοι τρεις επιλογείς). Ακολούθησε την ιστορία μέχρι το τέλος = έφτιαξε μια βιώσιμη λύση.
Ακολουθεί η λεπτομέρεια. Ο πελάτης θέλει να δει πόσο απασχολημένος είναι ο καφές, για να μην τσακωθεί σε ουρές. Τι ακριβώς θέλει;
Δείτε την πρόβλεψη για το πόσα άτομα θα είναι σε 15 λεπτά όταν φτάσει εκεί
Δείτε τον μέσο χρόνο εξυπηρέτησης σε ένα καφέ και τη δυναμική του μισή ώρα νωρίτερα
Δείτε την κατάσταση και τη δυναμική πληρότητας του τραπεζιού
Τι γίνεται αν το σύστημα πρόβλεψης δώσει ένα ασαφές αποτέλεσμα ή σταματήσει να λειτουργεί;
Δείτε μέσα από βίντεο τις ουρές στο καφέ, καθώς και την κατάληψη τραπεζιών. Χμ, γιατί να μην το κάνεις πρώτα;!
Ο συγγραφέας επισημαίνει μια μικρή άσκηση για εξάσκηση: προσπαθήστε να φανταστείτε τι κάνετε το πρωί αφού ξυπνήσετε. Μία κάρτα = μία ενέργεια. Μεγεθύνετε τις κάρτες (αντί να αλέθετε καφέ, πιείτε ένα αναζωογονητικό ρόφημα) για να αφαιρέσετε μεμονωμένες λεπτομέρειες, εστιάζοντας όχι στη μέθοδο υλοποίησης, αλλά στον στόχο.
Σε ποιους απευθύνεται αυτό το βιβλίο: αναλυτές πληροφορικής και διαχειριστές έργων. Πρέπει να διαβαστεί.
Εφαρμογές
Η συζήτηση και η λήψη αποφάσεων είναι αποτελεσματικές σε ομάδες των 3 έως 5 ατόμων.
Γράψτε στην πρώτη κάρτα τι πρέπει να αναπτυχθεί, στη δεύτερη - διορθώστε τι κάνατε στην πρώτη, στην τρίτη - διορθώστε τι έγινε στην πρώτη και τη δεύτερη.
Ετοιμάστε ιστορίες όπως τούρτες - όχι γράφοντας μια συνταγή, αλλά ανακαλύπτοντας ποιον, για ποια περίσταση και για πόσους ανθρώπους είναι το κέικ. Αν αναλύσουμε τις πωλήσεις, τότε δεν θα ήταν στην παραγωγή κέικ, κρέμας κ.λπ., αλλά στην παραγωγή μικρών έτοιμων κέικ.
Η ανάπτυξη λογισμικού είναι παρόμοια με τη δημιουργία μιας ταινίας, όταν πρέπει να αναπτύξετε προσεκτικά και να γυαλίσετε το σενάριο, να οργανώσετε τη σκηνή, τους ηθοποιούς κ.λπ. πριν ξεκινήσουν τα γυρίσματα.
Πάντα θα υπάρχει έλλειψη πόρων.
Το 20% των προσπαθειών παράγει απτά αποτελέσματα, το 60% δίνει ακατανόητα αποτελέσματα, το 20% των προσπαθειών είναι επιβλαβείς - γι' αυτό είναι σημαντικό να εστιάσετε στη μάθηση και να μην απελπίζεστε σε περίπτωση αρνητικού αποτελέσματος.
Επικοινωνήστε απευθείας με τον χρήστη, νιώστε τον εαυτό σας στη θέση του. Επικεντρωθείτε σε κάποια προβλήματα.
Η λεπτομέρεια και η ανάπτυξη της ιστορίας για αξιολόγηση είναι το πιο θλιβερό μέρος του scrum, κάντε τις συζητήσεις να στέκονται σε λειτουργία ενυδρείου (3-4 άτομα συζητούν στον πίνακα, αν κάποιος θέλει να συμμετάσχει, αντικαθιστά κάποιον).
Πηγή: www.habr.com