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

Δικαιώματα και ρόλοι

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

Πελάτης

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

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

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

Προγραμματιστής

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

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

Ρόλοι μέσα σε ρόλο

Κάθε ένας από τους βασικούς ρόλους του Extreme Programming μπορεί να βελτιωθεί από μικρότερους ρόλους. Το XP επιτρέπει το συνδυασμό ρόλων μέσα σε ένα άτομο.

Η πλευρά του πελάτη

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

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

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

Προγραμματιστής πλευρά

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

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

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

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

Εξωτερικοί ρόλοι

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

Κανόνες Ακραίου Προγραμματισμού

Σύμβαση κωδικοποίησης

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

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

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

Συλλογική ιδιοκτησία κωδικού

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

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

Συνεδρία CRC

Χρησιμοποιήστε κάρτες Class, Responsibilities, Collaboration (CRC) για να σχεδιάσετε ένα σύστημα ως ομάδα. Η χρήση καρτών διευκολύνει την εκμάθηση της σκέψης με όρους αντικειμένων παρά λειτουργιών και διαδικασιών. Οι κάρτες το επιτρέπουν επίσης περισσότεροάτομα που θα συμμετάσχουν στη διαδικασία σχεδιασμού (ιδανικά ολόκληρη η ομάδα) και όσο περισσότερα άτομα κάνουν το σχεδιασμό, τόσο πιο ενδιαφέρουσες ιδέες θα εισαχθούν.

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

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

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

Πελάτης

Μία από τις απαιτήσεις των XP είναι ο πελάτης να είναι πάντα διαθέσιμος. Δεν πρέπει απλώς να βοηθά την ομάδα ανάπτυξης, αλλά να είναι μέλος της. Όλες οι φάσεις ενός έργου XP απαιτούν επικοινωνία με τον πελάτη, κατά προτίμηση πρόσωπο με πρόσωπο - επί τόπου. Είναι καλύτερο να αναθέσετε απλώς έναν ή περισσότερους πελάτες στην ομάδα ανάπτυξης. Προσοχή, ο πελάτης θα χρειαστεί πολύς καιρός, και το γραφείο του πελάτη μπορεί να προσπαθήσει να σας προσφέρει κάποιον ασκούμενο ως ειδικό. Χρειάζεστε έναν ειδικό.

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

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

Επιλέξτε την απλούστερη λύση

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

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

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

Λειτουργικές δοκιμές

Οι δοκιμές αποδοχής (προηγουμένως ονομάζονταν επίσης Λειτουργικές δοκιμές) συντάσσονται με βάση την Ιστορία χρήστη. Βλέπουν το σύστημα ως ένα μαύρο κουτί. Ο πελάτης είναι υπεύθυνος για την επαλήθευση της ορθότητας των λειτουργικών δοκιμών. Αυτές οι δοκιμές χρησιμοποιούνται για την επαλήθευση της λειτουργικότητας ενός συστήματος πριν από την κυκλοφορία του στην παραγωγή. Οι λειτουργικές δοκιμές είναι αυτοματοποιημένες ώστε να μπορούν να εκτελούνται συχνά. Το αποτέλεσμα αναφέρεται στην ομάδα και η ομάδα είναι υπεύθυνη για τον προγραμματισμό επιδιορθώσεων λειτουργικών δοκιμών.

Συχνή ενσωμάτωση

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

Κάθε ζεύγος προγραμματιστών θα πρέπει να συνεισφέρει τον κώδικά του το συντομότερο δυνατό. Αυτό μπορεί να συμβεί όταν όλα τα UnitTest περάσουν το 100%. Υποβάλλοντας αλλαγές πολλές φορές την ημέρα, μειώνετε τα προβλήματα ενοποίησης σχεδόν στο μηδέν. Η ενσωμάτωση είναι μια δραστηριότητα «πληρωμή τώρα ή πληρώστε περισσότερα αργότερα». Επομένως, ενσωματώνοντας αλλαγές καθημερινά σε μικρές μερίδες, δεν θα χρειαστεί να περάσετε μια εβδομάδα συνδέοντας το σύστημα σε ένα σύνολο ακριβώς πριν από την παράδοση του έργου. Να εργάζεστε πάντα στην πιο πρόσφατη έκδοση του συστήματος.

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

Σχεδιασμός επανάληψης

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

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

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

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

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

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

Επαναλήψεις

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

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

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

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

Ανταλλαγή εργασιών

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

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

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

Όταν ξεκινάτε ένα νέο επαναλήψειςκάθε προγραμματιστής πρέπει να προχωρήσει σε μια νέα εργασία. Ο προγραμματισμός ζευγών βοηθά να ξεπεραστεί το πρόβλημα προσαρμογής (αυτό σημαίνει ότι νέος προγραμματιστήςμπορεί να αρχίσει να εργάζεται παράλληλα με έναν προγραμματιστή με εμπειρία στον τομέα).

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

Αφήστε τη βελτιστοποίηση για αργότερα

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

Κάντε το να λειτουργήσει, μετά κάντε το να λειτουργήσει σωστά και μετά κάντε το να λειτουργήσει γρήγορα.

Προγραμματισμός ζευγών

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

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

Refactor Αδίστακτα!

Εμείς οι προγραμματιστές τείνουμε να παραμένουμε σε ένα σχέδιο πολύ καιρό αφότου γίνει αδέξιο. Συνεχίζουμε να επαναχρησιμοποιούμε κώδικα που δεν μπορεί να συντηρηθεί γιατί εξακολουθεί να λειτουργεί με κάποιο τρόπο και φοβόμαστε μην τον σπάσουμε. Είναι όμως πραγματικά ωφέλιμο; Η XP θεωρεί ότι αυτό δεν είναι επικερδές. Όταν αφαιρούμε τον πλεονασμό, βελτιώνουμε έναν απαρχαιωμένο σχεδιασμό, αφαιρούμε αχρησιμοποίητα κομμάτια - κάνουμε ανακατασκευή. Το Refactoring εξοικονομεί χρόνο και βελτιώνει την ποιότητα του προϊόντος.

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

Σχέδιο έκδοσης

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

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

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

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

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

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

Συχνές εκδόσεις

Οι προγραμματιστές θα πρέπει να εκδίδουν εκδόσεις του συστήματος στους χρήστες (ή σε δοκιμαστές beta) όσο το δυνατόν συχνότερα.

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

Δοκιμαστική λύση

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

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

Συνάντηση όρθια

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

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

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

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

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

Μεταφορά του Συστήματος

Να επιλέγετε πάντα το System Metaphor - μια απλή και ξεκάθαρη ιδέα, ώστε τα μέλη της ομάδας να αποκαλούν τα πάντα με το ίδιο όνομα. Για να κατανοήσετε το σύστημα και να εξαλείψετε τον διπλότυπο κώδικα, είναι εξαιρετικά σημαντικό πώς ονομάζετε αντικείμενα. Εάν μπορείτε να μαντέψετε πώς ονομάζεται ένα αντικείμενο στο σύστημα (αν γνωρίζετε τι κάνει) και όντως ονομάζεται έτσι, θα εξοικονομήσετε πολύ χρόνο και προσπάθεια. Δημιουργήστε ένα σύστημα ονομασίας για τα αντικείμενά σας, ώστε κάθε μέλος της ομάδας να μπορεί να το χρησιμοποιήσει χωρίς ΕΙΔΙΚΕΣ ΓΝΩΣΕΙΣσχετικά με το σύστημα.

Δοκιμές Μονάδων

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

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

Το Unit test για μια κλάση αποθηκεύεται σε ένα κοινό αποθετήριο μαζί με τον κωδικό τάξης. Κανένας κωδικός δεν μπορεί να κυκλοφορήσει χωρίς δοκιμή μονάδας. Πριν απελευθερώσει τον κώδικα, ο προγραμματιστής πρέπει να βεβαιωθεί ότι όλες οι δοκιμές περνούν χωρίς σφάλματα. Κανείς δεν μπορεί να δώσει τον κωδικό αν δεν περάσουν όλοι 100%. Με άλλα λόγια, αφού όλα τα τεστ πέρασαν πριν από τις αλλαγές σας, εάν έχετε σφάλματα, τότε αυτό είναι το αποτέλεσμα των αλλαγών σας. Είναι στο χέρι σας να το διορθώσετε. Μερικές φορές ο κωδικός δοκιμής είναι εσφαλμένος ή ελλιπής. Σε αυτή την περίπτωση, πρέπει να το διορθώσετε.

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

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

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

Η ιστορία χρήστη (κάτι σαν την ιστορία ενός χρήστη) είναι μια περιγραφή του τρόπου λειτουργίας του συστήματος. Κάθε Ιστορία Χρήστη είναι γραμμένο σε μια κάρτα και αντιπροσωπεύει κάποιο κομμάτι της λειτουργικότητας του συστήματος που έχει λογικό νόημα από την άποψη του Πελάτη. Μορφή - μία ή δύο παράγραφοι κειμένου που είναι κατανοητές από τον χρήστη (όχι πολύ τεχνική).

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

Σε κάθε Ιστορία χρήστη δίνεται προτεραιότητα από την πλευρά της επιχείρησης (χρήστης, πελάτης, τμήμα μάρκετινγκ) και μια εκτίμηση του χρόνου εκτέλεσης από τους προγραμματιστές. Κάθε ιστορία χωρίζεται σε εργασίες και ορίζεται μια ώρα που θα αρχίσει να υλοποιείται.

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

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

Ταχύτητα έργου

Η ταχύτητα έργου (ή απλά η ταχύτητα) είναι ένα μέτρο του πόσο γρήγορα ολοκληρώνεται η εργασία στο έργο σας.

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

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

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

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

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

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

Όταν εντοπιστεί σφάλμα

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

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

Δεν θα το χρειαστείτε

Αποφύγετε να γεμίσετε το σύστημα με πράγματα που θα χρειαστείτε στο μέλλον. Μόνο το 10% αυτού που περιμένατε θα χρειαστεί πραγματικά στην αρχική του μορφή, που σημαίνει ότι το 90% του χρόνου σας θα χαθεί.

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

Ο Extreme Programming (XP) είναι μία από τις ευέλικτες μεθοδολογίες ανάπτυξης λογισμικού. Οι συγγραφείς της μεθοδολογίας είναι οι Kent Beck, Ward Cunningham, Martin Fowler και άλλοι.

Παιχνίδι προγραμματισμού

Ο κόσμος μας είναι πολύ μεταβλητός και απρόβλεπτος για να βασιστούμε στη σταθερότητα της κατάστασης. Το ίδιο συμβαίνει και στην ανάπτυξη λογισμικού: με ένα σπάνιο σύστημα, μπορούμε να πούμε ότι η τελική του μορφή ήταν γνωστή εκ των προτέρων λεπτομερώς στην αρχή της ανάπτυξης. Συνήθως, η όρεξη του πελάτη έρχεται ενώ τρώει: θέλει συνεχώς να αλλάξει κάτι, να βελτιώσει κάτι ή να πετάξει κάτι εντελώς έξω από το σύστημα. Αυτή είναι η μεταβλητότητα των απαιτήσεων που όλοι φοβούνται τόσο πολύ. Ευτυχώς, δίνεται στον άνθρωπο η ικανότητα να προβλέπει πιθανές επιλογέςκαι έτσι να κρατήσει την κατάσταση υπό έλεγχο.
Στον Extreme Programming, ο προγραμματισμός είναι αναπόσπαστο μέρος της ανάπτυξης και το γεγονός ότι τα σχέδια μπορούν να αλλάξουν λαμβάνεται υπόψη από την αρχή. Το υπομόχλιο, η τεχνική που σας επιτρέπει να προβλέψετε την κατάσταση και να υπομένετε ανώδυνα τις αλλαγές, είναι το παιχνίδι προγραμματισμού. Κατά τη διάρκεια ενός τέτοιου παιχνιδιού, οι γνωστές απαιτήσεις συστήματος μπορούν να συλλεχθούν γρήγορα, να αξιολογηθούν και να προγραμματιστούν σύμφωνα με την προτεραιότητα.
Όπως κάθε άλλο παιχνίδι, έτσι και ο σχεδιασμός έχει τους συμμετέχοντες και τον στόχο του. Το βασικό στοιχείο είναι φυσικά ο πελάτης. Είναι αυτός που επικοινωνεί την ανάγκη για αυτήν ή εκείνη τη λειτουργικότητα. Οι προγραμματιστές δίνουν μια κατά προσέγγιση αξιολόγηση κάθε λειτουργικότητας. Η ομορφιά του παιχνιδιού σχεδιασμού έγκειται στην ενότητα του σκοπού και της αλληλεγγύης μεταξύ του προγραμματιστή και του πελάτη: σε περίπτωση νίκης, όλοι κερδίζουν, σε περίπτωση ήττας, όλοι χάνουν. Αλλά ταυτόχρονα, κάθε συμμετέχων πηγαίνει τον δικό του δρόμο προς τη νίκη: ο πελάτης επιλέγει τις πιο σημαντικές εργασίες σύμφωνα με τον προϋπολογισμό και ο προγραμματιστής αξιολογεί τις εργασίες σύμφωνα με την ικανότητά του να τις υλοποιήσει.
Ο ακραίος προγραμματισμός προϋποθέτει ότι οι προγραμματιστές μπορούν να αποφασίσουν μόνοι τους πόσο χρόνο θα τους πάρει για να ολοκληρώσουν τις εργασίες τους και ποιος από αυτούς θα ήταν πιο πρόθυμος να λύσει ένα πρόβλημα και ποιος άλλο.
Σε μια ιδανική κατάσταση, ένα παιχνίδι προγραμματισμού που περιλαμβάνει τον πελάτη και τον προγραμματιστή θα πρέπει να παίζεται κάθε 3-6 εβδομάδες, πριν από την έναρξη της επόμενης επανάληψης ανάπτυξης. Αυτό καθιστά αρκετά εύκολο να κάνετε προσαρμογές με βάση τις επιτυχίες και τις αποτυχίες της προηγούμενης επανάληψης.

Σχέδιο απελευθέρωσης

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

Σχεδιασμός επανάληψης

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

Συνάντηση όρθια

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

Απλότητα

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

Σύστημα μεταφορών

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

Πελάτης στο χώρο εργασίας

Το κύριο πρόβλημα στην ανάπτυξη λογισμικού είναι η έλλειψη γνώσης των προγραμματιστών στο αντικείμενο που αναπτύσσεται. Ο ακραίος προγραμματισμός έχει βρει διέξοδο από αυτήν την κατάσταση. Όχι, δεν πρόκειται για πρακτική άσκηση προγραμματιστή στην επιχείρηση του πελάτη - τότε δεν θα θέλει να προγραμματίσει. Αντίθετα, είναι η συμμετοχή του πελάτη στη διαδικασία ανάπτυξης.
Μπορεί ένας προγραμματιστής, χωρίς να έχει κατανοήσει καλά την ουσία του θέματος και να μην είναι τηλεπαθής, να μαντέψει τι θέλει ο πελάτης; Η απάντηση είναι προφανής. Ο ευκολότερος τρόπος για να ξεπεράσουμε αυτήν την ταλαιπωρία - και ο Extreme Programming μας διδάσκει να βρίσκουμε τις απλούστερες λύσεις - είναι να κάνουμε μια άμεση ερώτηση στον πελάτη. Οι πιο αυστηρές προσεγγίσεις απαιτούν μια ολοκληρωμένη προκαταρκτική ανάλυση της περιοχής που αναπτύσσεται. ΣΕ ορισμένες περιπτώσειςΑυτό είναι δικαιολογημένο, αν και είναι πιο ακριβό. Η πραγματική εμπειρία στην εκτέλεση εγκόσμιων έργων δείχνει ότι είναι αδύνατο να συγκεντρωθούν όλες οι απαιτήσεις εκ των προτέρων. Επιπλέον, ακόμα κι αν υποθέσουμε ότι όλες οι απαιτήσεις έχουν συγκεντρωθεί επί του παρόντος, θα υπάρχει ακόμα ένα σημείο συμφόρησης: τα προγράμματα, όπως όλα στη φύση, δεν δημιουργούνται αμέσως και στο μεταξύ οι επιχειρηματικές διαδικασίες μπορούν να αλλάξουν. Αυτό θα πρέπει να ληφθεί υπόψη.
Πολλοί αμφιβάλλουν για τη δυνατότητα συμμετοχής του πελάτη στη διαδικασία ανάπτυξης. Πράγματι, οι πελάτες είναι διαφορετικοί. Εάν δεν είναι δυνατό να προσελκύσετε τον πελάτη ή τον εκπρόσωπό του, μερικές φορές συνιστάται να προσλάβετε προσωρινά έναν ειδικό στον τομέα που αναπτύσσεται. Αυτό το βήμα θα μειώσει τις ασάφειες στην εργασία, θα αυξήσει την ταχύτητα ανάπτυξης και θα φέρει το έργο πιο κοντά σε αυτό που θέλει να λάβει ο πελάτης. Αυτό μπορεί επίσης να είναι επωφελές από την οικονομική πλευρά: τελικά, ο μισθός ενός προγραμματιστή είναι μερικές φορές σημαντικά υψηλότερος από τον μισθό των ειδικών σε άλλους κλάδους.
Ιστορία χρήστη. Η ιστορία χρήστη (κάτι σαν την ιστορία ενός χρήστη) είναι μια περιγραφή του τρόπου λειτουργίας του συστήματος. Κάθε Ιστορία Χρήστη είναι γραμμένο σε μια κάρτα και αντιπροσωπεύει κάποιο κομμάτι της λειτουργικότητας του συστήματος που έχει λογικό νόημα από την άποψη του Πελάτη. Η φόρμα είναι μία ή δύο παραγράφοι κειμένου που είναι κατανοητές από τον χρήστη (όχι πολύ τεχνική).
Η ιστορία χρήστη γράφεται από τον Πελάτη. Αυτές είναι παρόμοιες με τις περιπτώσεις χρήσης συστήματος, αλλά δεν περιορίζονται στη διεπαφή χρήστη. Για κάθε ιστορία, γράφονται λειτουργικές δοκιμές για να επιβεβαιωθεί ότι αυτή η ιστορία έχει εφαρμοστεί σωστά - ονομάζονται επίσης τεστ αποδοχής.

Δοκιμή πριν ξεκινήσει η ανάπτυξη

Η δοκιμή, με την κλασική της έννοια, είναι μια αρκετά βαρετή διαδικασία. Συνήθως προσλαμβάνουν έναν ελεγκτή που κάνει περιοδικά τις ίδιες ενέργειες και περιμένει την ημέρα που τελικά θα μετατεθεί σε άλλη θέση ή θα παρουσιαστεί η ευκαιρία να αλλάξει δουλειά.
Στον ακραίο προγραμματισμό, ο ρόλος της δοκιμής είναι πιο ενδιαφέρον: τώρα έρχεται πρώτα η δοκιμή και μετά ο κώδικας. Πώς να δοκιμάσετε κάτι που δεν υπάρχει ακόμα; Η απάντηση είναι απλή και μπανάλ: δοκιμάστε τις σκέψεις σας - τι να περιμένετε από ένα μελλοντικό πρόγραμμα ή λειτουργικότητα. Αυτό θα σας επιτρέψει να κατανοήσετε καλύτερα τι πρέπει να κάνουν οι προγραμματιστές και να ελέγξετε τη λειτουργικότητα του κώδικα αμέσως μόλις γραφτεί.
Αλλά και το τεστ μπορεί να μην λειτουργεί. Λοιπόν, γράψτε ένα τεστ για ένα τεστ; Και μετά δοκιμή για δοκιμή και ούτω καθεξής ad infinitum; Καθόλου. Η δοκιμή για τη δοκιμή θα αντικαταστήσει τον κωδικό. Πως και έτσι? Αλλά κοίτα: φανταστείτε ότι πρέπει να στερεώσετε το παξιμάδι στη μέση του μπουλονιού για να μην γυρίζει. Τι κάνουν για αυτό; Βιδώστε το δεύτερο παξιμάδι κοντά στο πρώτο, έτσι ώστε κάθε παξιμάδι να εμποδίζει το διπλανό να γυρίσει. Είναι το ίδιο στον προγραμματισμό: η δοκιμή ελέγχει τον κώδικα και ο κώδικας δοκιμάζει τη δοκιμή.
Η εμπειρία δείχνει ότι αυτή η προσέγγιση όχι μόνο δεν επιβραδύνει, αλλά και επιταχύνει την ανάπτυξη. Εξάλλου, γνωρίζοντας τι πρέπει να γίνει και την απαιτούμενη ποσότητα εργασίας θα εξοικονομήσετε χρόνο αρνούμενοι να πουλήσετε αζήτητα αντικείμενα. αυτή τη στιγμήΛεπτομέριες.

Προγραμματισμός ζευγών

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

Αλλαγή θέσεων

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

Συλλογική ιδιοκτησία κωδικού

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

Σύμβαση κωδικοποίησης

Είστε μέρος μιας ομάδας που εργάζεται σε αυτό το έργο για μεγάλο χρονικό διάστημα. Οι άνθρωποι έρχονται και φεύγουν. Κανείς δεν κωδικοποιεί μόνος του και ο κωδικός ανήκει σε όλους. Πάντα θα υπάρχουν στιγμές που θα πρέπει να κατανοήσετε και να προσαρμόσετε τον κώδικα κάποιου άλλου. Οι προγραμματιστές θα αφαιρέσουν ή θα αλλάξουν διπλότυπο κώδικα, θα αναλύσουν και θα βελτιώσουν τις κατηγορίες άλλων ατόμων κ.λπ. Με τον καιρό, θα είναι αδύνατο να πούμε ποιος είναι ο συγγραφέας μιας συγκεκριμένης τάξης.
Επομένως, όλοι πρέπει να υπακούουν σε κοινά πρότυπα κωδικοποίησης - μορφοποίηση κώδικα, ονομασία κλάσεων, μεταβλητές, σταθερές, στυλ σχολίων. Έτσι, θα είμαστε σίγουροι ότι όταν κάνουμε αλλαγές στον κώδικα κάποιου άλλου (που είναι απαραίτητος για επιθετική και ακραία πρόοδο προς τα εμπρός), δεν θα τον μετατρέψουμε σε Babel Pandemonium.
Τα παραπάνω σημαίνουν ότι όλα τα μέλη της ομάδας πρέπει να συμφωνήσουν σε κοινά πρότυπα κωδικοποίησης. Δεν έχει σημασία ποιες. Ο κανόνας είναι ότι όλοι τους υπακούουν. Όσοι δεν θέλουν να συμμορφωθούν με αυτά φεύγουν από την ομάδα.

Συχνή ενσωμάτωση

Οι προγραμματιστές θα πρέπει να ενσωματώνουν και να κυκλοφορούν τον κώδικά τους κάθε λίγες ώρες, αν είναι δυνατόν. Σε κάθε περίπτωση, δεν πρέπει ποτέ να κρατάτε τις αλλαγές για περισσότερο από μία ημέρα. Η συχνή ενσωμάτωση αποφεύγει την αποξένωση και τον κατακερματισμό στην ανάπτυξη, όπου οι προγραμματιστές δεν μπορούν να επικοινωνήσουν με την έννοια της κοινής χρήσης ιδεών ή της επαναχρησιμοποίησης κώδικα. Όλοι θα πρέπει να εκτελούν την πιο πρόσφατη έκδοση.
Κάθε ζεύγος προγραμματιστών θα πρέπει να συνεισφέρει τον κώδικά του το συντομότερο δυνατό. Αυτό μπορεί να συμβεί όταν όλα τα UnitTest περάσουν το 100%. Υποβάλλοντας αλλαγές πολλές φορές την ημέρα, μειώνετε τα προβλήματα ενοποίησης σχεδόν στο μηδέν. Η ενσωμάτωση είναι μια δραστηριότητα «πληρωμή τώρα ή πληρώστε περισσότερα αργότερα». Επομένως, με την ενσωμάτωση αλλαγών σε μικρές αυξήσεις κάθε μέρα, δεν θα χρειαστεί να περάσετε μια εβδομάδα προσπαθώντας να συνδέσετε το σύστημα λίγο πριν την παράδοση του έργου. Να εργάζεστε πάντα στην πιο πρόσφατη έκδοση του συστήματος.

Σαράντα ώρες εργασίας την εβδομάδα

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

συμπέρασμα

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

Βιβλιογραφία:

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

Ο συγγραφέας της μεθόδου είναι ο Αμερικανός προγραμματιστής Kent Beck. Στα τέλη της δεκαετίας του '90, ηγήθηκε του έργου Chrysler Comprehensive Compensation System και εκεί πρωτοστάτησε στην πρακτική του ακραίου προγραμματισμού. Περιέγραψε την εμπειρία του και την ιδέα που δημιούργησε στο βιβλίο Extreme Programming Explained, που δημοσιεύτηκε το 1999. Ακολούθησαν άλλα βιβλία που περιγράφουν λεπτομερώς τις πρακτικές XP. Οι Ward Cunningham, Martin Fowler και άλλοι συμμετείχαν επίσης στην ανάπτυξη της μεθοδολογίας.

Το XP διαφέρει από άλλες ευέλικτες μεθοδολογίες στο ότι εφαρμόζεται μόνο στον τομέα της ανάπτυξης λογισμικού.Δεν μπορεί να χρησιμοποιηθεί σε άλλη επιχείρηση ή καθημερινή ζωή όπως το scrum, το kanban ή το lean.

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

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

1. Όλη η ομάδα

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

2. Παιχνίδι προγραμματισμού

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

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

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

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

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

3. Συχνές εκδόσεις

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

4. Δοκιμές χρήστη

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

5. Συλλογική ιδιοκτησία

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

6. Συνεχής Ενσωμάτωση Κώδικα

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

7. Πρότυπα Κωδικοποίησης

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

8. Μεταφορά συστήματος

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

9. Σταθερός ρυθμός

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

10. Δοκιμαστική ανάπτυξη

Μια από τις πιο δύσκολες πρακτικές της μεθοδολογίας. Στα XP, τα τεστ γράφονται από τους ίδιους τους προγραμματιστές, ΠΡΙΝ γράψουν τον κώδικα που πρέπει να ελεγχθεί. Με αυτήν την προσέγγιση, κάθε κομμάτι λειτουργικότητας θα καλύπτεται 100% με δοκιμές. Όταν μερικοί προγραμματιστές ανεβάζουν κώδικα στο αποθετήριο, εκτελούνται αμέσως οι δοκιμές μονάδας. Και πρέπει ΟΛΟΙ να δουλεύουν. Τότε οι προγραμματιστές θα είναι σίγουροι ότι κινούνται προς τη σωστή κατεύθυνση.

11. Προγραμματισμός ζευγών

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

12. Απλός σχεδιασμός

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

13. Refactoring

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

XP Πλεονεκτήματα και μειονεκτήματα

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

Τα οφέλη του Extreme Programming έχουν νόημα όταν η ομάδα χρησιμοποιεί πλήρως τουλάχιστον μία από τις πρακτικές XP. Λοιπόν, τι αξίζει να δοκιμάσετε:

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

Παρά όλα τα πλεονεκτήματα, το XP δεν λειτουργεί πάντα και έχει μια σειρά από αδυναμίες. Άρα, ακραίος προγραμματισμός - μειονεκτήματα:

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

Αρχές XP

Στο πρώτο του βιβλίο, ο Kent Beck διατύπωσε τις αρχές του Extreme Programming: απλότητα, επικοινωνία, ανατροφοδότηση και θάρρος. Στη νέα έκδοση του βιβλίου, πρόσθεσε μια πέμπτη αρχή - τον σεβασμό.

1. Απλότητα

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

2. Επικοινωνία

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

3. Ανατροφοδότηση

Η ανατροφοδότηση στα XP υλοποιείται σε τρεις κατευθύνσεις ταυτόχρονα:

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

4. Θάρρος

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

5. Σεβασμός

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

Αλγόριθμος για την υλοποίηση της μεθοδολογίας XP και της διαδικασίας εργασίας

Ο Beck Kent συνιστά την εφαρμογή XP για την επίλυση προβλημάτων σε ένα έργο. Η ομάδα επιλέγει το πιο πιεστικό πρόβλημα και το λύνει χρησιμοποιώντας μία από τις πρακτικές Extreme Programming. Στη συνέχεια προχωρά σε επόμενο πρόβλημαχρησιμοποιώντας άλλη πρακτική. Με αυτήν την προσέγγιση, τα προβλήματα λειτουργούν ως κίνητρο για τη χρήση XP και η ομάδα σταδιακά κατακτά όλα τα εργαλεία της μεθοδολογίας.

Για να εφαρμόσετε το XP σε ένα υπάρχον έργο, πρέπει σταδιακά να κατακτήσετε τις τεχνικές του στους ακόλουθους τομείς:

• δοκιμές
• σχέδιο
• σχεδίαση
• διαχείριση
• ανάπτυξη

Δοκιμές.

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

Σχέδιο.

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

Σχεδίαση.

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

Διαχείριση.

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

Ανάπτυξη.

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

Σε ένα έργο που λειτουργεί σύμφωνα με τη μεθοδολογία XP, η διαδικασία είναι δομημένη ως εξής:

Ποιος χρησιμοποιεί XP

Σύμφωνα με μια μελέτη του 2016 της Versionone, μόνο το 1% των ευέλικτων εταιρειών χρησιμοποιεί ακραίο προγραμματισμό στην καθαρή του μορφή. Ένα άλλο 10% λειτουργεί χρησιμοποιώντας μια υβριδική μεθοδολογία scrum και XP.

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

Δεν είναι εύκολο να βρεις πληροφορίες για ομάδες που χρησιμοποιούν XP, αλλά υπάρχουν και εκείνοι που διαφημίζουν ότι αυτή η μεθοδολογία είναι ο λόγος της επιτυχίας τους. Ένα παράδειγμα Extreme Programming είναι η Pivotal Software, Inc.

Pivotal Software, Inc.

Μια αμερικανική εταιρεία λογισμικού που αναπτύσσει λογισμικό για επιχειρηματική ανάλυση με βάση μεγάλα δεδομένα και παρέχει συμβουλευτικές υπηρεσίες. Τα βασικά προϊόντα χρησιμοποιούνται από εταιρείες Ford, Mercedes, BMW, GAP, Humana, μεγάλες τράπεζες, κυβερνητικές υπηρεσίες, ασφαλιστικές εταιρείες κ.λπ.

Η Pivotal είναι υπέρμαχος των ευέλικτων μεθοδολογιών ως των μόνων δυνατών στη σύγχρονη ανάπτυξη. Από όλες τις επιλογές για ευέλικτες μεθοδολογίες, η εταιρεία επέλεξε το XP ως προσέγγιση win-win για πελάτες και ομάδες προγραμματισμού. Κάθε εργάσιμη ημέρα ξεκινά με μια συνάντηση εν κινήσει και τελειώνει ακριβώς στις 18:00 - χωρίς υπερωρίες. Το Pivotal χρησιμοποιεί σχεδιασμό παιχνιδιών, προγραμματισμό ζευγών, συνεχείς δοκιμές, συνεχή ενοποίηση και άλλες πρακτικές XP. Για πολλές πρακτικές, έχουν το δικό τους λογισμικό.

Ακραίος προγραμματισμός,
Extreme Programming: Σχεδιασμός,
Extreme Programming: Test Driven Development / Kent Beck

Σχετικά με τον ακραίο προγραμματισμό από τον δημιουργό της μεθοδολογίας, Kent Beck. Ξεκινήστε με το πρώτο, το οποίο περιγράφει την ιδέα XP με παραδείγματα και αιτιολογεί τα πλεονεκτήματά της. Αργότερα, ο συγγραφέας δημοσίευσε αρκετά ακόμη βιβλία, όπου περιέγραψε λεπτομερώς μεμονωμένες πρακτικές XP.

Refactoring: Improving Existing Code / Martin Fowler

Ακραίος προγραμματισμός: διατύπωση διαδικασίας. Από τα πρώτα βήματα στο πικρό τέλος / Ken Auer, Roy Miller

Εφόσον το Extreme Programming προσπαθεί για καθαρό και εύκολα συντηρήσιμο κώδικα, η λίστα των βιβλίων περιλαμβάνει όλες τις εκδόσεις που σας διδάσκουν πώς να προγραμματίζετε καλύτερα.

Εφαρμογές για την εφαρμογή XP σε μια ομάδα

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

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

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

Jira

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

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

Ετυμηγορία

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

Αυτή η μεθοδολογία προορίζεται αποκλειστικά για το πεδίο ανάπτυξη προϊόντα λογισμικού και δεν μπορεί να προσαρμοστεί για άλλη επιχείρηση.

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

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

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

Extreme Programming: Test Driven Development

Αφιερωμένο στη Σίντι: τα φτερά της ψυχής μου

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

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

ISBN 978-0321146533 Αγγλικά

ISBN 978-5-496-02570-6

© 2003 από την Pearson Education, Inc.

© Μετάφραση στα Russian LLC Publishing House "Piter", 2017

© Έκδοση στα ρωσικά, σχεδιασμένο από τον Peter Publishing House LLC, 2017

© Σειρά "Programmer's Library", 2017

Πρόλογος

Καθαρίστε τον κώδικα που λειτουργεί«Καθαρός κώδικας που λειτουργεί», αυτή η σύντομη αλλά ουσιαστική φράση, που επινοήθηκε από τον Ρον Τζέφρις, ενσωματώνει ολόκληρη την έννοια της Ανάπτυξης με γνώμονα τη δοκιμή (TDD). Ο καθαρός κώδικας που λειτουργεί είναι ένας στόχος που αξίζει να επιδιώξετε επειδή

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

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

Βελτιώνει τη ζωή των χρηστών των προγραμμάτων σας.

Επιτρέπει στους συναδέλφους σας να βασίζονται σε εσάς και σε εσάς να βασίζεστε σε αυτούς.

Είναι πιο ευχάριστο να γράφεις κώδικα σαν αυτό.

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

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

Οποιαδήποτε επικάλυψη εξαλείφεται.

Δύο απλοί κανόνες, σωστά; Ωστόσο, δημιουργούν πολύπλοκη ατομική και ομαδική συμπεριφορά με πολλές τεχνικές συνέπειες:

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

Γράφουμε τα δικά μας τεστ γιατί ανυπομονούμε να μας γράψει κάποιος άλλος.

Το περιβάλλον ανάπτυξης μας πρέπει να ανταποκρίνεται γρήγορα σε μικρές τροποποιήσεις κώδικα.

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

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

1. Κόκκινο - Γράψτε ένα μικρό τεστ που δεν λειτουργεί και ίσως δεν γίνεται καν μεταγλώττιση.

2. Πράσινο - κάντε τη δοκιμή να εκτελεστεί όσο το δυνατόν γρηγορότερα, χωρίς να ανησυχείτε για την ορθότητα του σχεδιασμού και την καθαρότητα του κώδικα. Γράψτε μόνο αρκετό κώδικα για να δουλέψει η δοκιμή.

3. Refactoring – εξάλειψη τυχόν αντιγραφής από τον γραπτό κώδικα.

Το κόκκινο – πράσινο – το refactoring είναι το μάντρα του TDD.

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

Εάν η πυκνότητα του ελαττώματος είναι αρκετά χαμηλή, η ομάδα Διασφάλισης Ποιότητας (QA) θα μπορεί να μετακινηθεί από την αντίδραση στα σφάλματα στην αποτροπή τους.

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

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

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

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

Γενναιότητα

Το TDD είναι ένας τρόπος διαχείρισης του φόβου στη διαδικασία προγραμματισμού. Δεν εννοώ τον φόβο να πέσεις από την καρέκλα ή τον φόβο να βρεθείς μπροστά στο αφεντικό σου. Εννοώ τον φόβο να αντιμετωπίσω ένα πρόβλημα «τόσο δύσκολο που δεν έχω ιδέα πώς να το λύσω ακόμα». Πόνος είναι όταν η φύση μας λέει: «Σταμάτα!», και φόβος είναι όταν η φύση μας λέει: «Πρόσεχε!» Η προσοχή δεν είναι καθόλου κακό, αλλά εκτός από τα οφέλη του, ο φόβος έχει και ορισμένες αρνητικές επιπτώσεις σε εμάς:

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

Ο φόβος μας κάνει να επικοινωνούμε λιγότερο.

Ο φόβος μας κάνει να φοβόμαστε τις κριτικές της δουλειάς μας.

Ο φόβος μας κάνει οξύθυμους.

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

Μην προσπαθήσετε να προβλέψετε το μέλλον, αλλά ξεκινήστε αμέσως μια πρακτική μελέτη του προβλήματος.

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

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

(Πρέπει να αντιμετωπίσετε μόνοι σας τον ερεθισμό).

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

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

Αναγνώστες του βιβλίου Extreme Programming ΕξηγήστεΊσως έχετε παρατηρήσει τη διαφορά στον τόνο μεταξύ του Extreme Programming (XP) και του Test-Driven Development (TDD). Σε αντίθεση με το XP, η τεχνική TDD δεν είναι απόλυτη. Το XP λέει, "για να προχωρήσεις, πρέπει να κυριαρχήσεις αυτό και αυτό." Το TDD είναι μια λιγότερο συγκεκριμένη τεχνική. Το TDD υποθέτει ότι υπάρχει ένα διάστημα μεταξύ της λήψης αποφάσεων και των αποτελεσμάτων και παρέχει εργαλεία για τη διαχείριση του μήκους αυτού του διαστήματος. «Τι θα γινόταν αν περνούσα μια εβδομάδα σχεδιάζοντας έναν αλγόριθμο σε χαρτί και στη συνέχεια γράφοντας κώδικα χρησιμοποιώντας μια προσέγγιση πρώτα δοκιμής; Θα είναι συμβατό με το TDD;» Φυσικά και θα είναι. Γνωρίζετε το μέγεθος του διαστήματος μεταξύ της λήψης μιας απόφασης και της αξιολόγησης των αποτελεσμάτων και ελέγχετε συνειδητά αυτό το διάστημα.

Οι περισσότεροι άνθρωποι που έχουν κατακτήσει το TDD λένε ότι οι πρακτικές προγραμματισμού τους έχουν αλλάξει προς το καλύτερο. Μολυνθεί από εξετάσεις(μολυσμένο τεστ) - αυτός είναι ο ορισμός που βρήκε ο Erich Gamma για να περιγράψει αυτήν την αλλαγή. Μόλις κατακτήσετε το TDD, πιάνετε τον εαυτό σας να γράφει πολύ περισσότερα τεστ από πριν και να προχωράτε με μικρά βήματα που προηγουμένως θα σας φαινόταν άσκοπα. Από την άλλη, ορισμένοι προγραμματιστές, έχοντας εξοικειωθεί με το TDD, αποφασίζουν να επιστρέψουν στις παλιές πρακτικές, επιφυλάσσοντας το TDD για ειδικές περιπτώσεις που ο συμβατικός προγραμματισμός δεν οδηγεί στην επιθυμητή πρόοδο.

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

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

Διαμόρφωση της βασικής αρχιτεκτονικής όσο το δυνατόν νωρίτερα.

Χρήση αρχιτεκτονικής στοιχείων.

Δημιουργία πρωτοτύπων, σταδιακή ανάπτυξη και δοκιμή.

Τακτικές αξιολογήσεις της τρέχουσας κατάστασης.

Διαχείριση αλλαγών, συνεχής ανάπτυξη αλλαγών εκτός έργου.

Εστιάστε στη δημιουργία ενός προϊόντος που λειτουργεί σε πραγματικό περιβάλλον.

Εστίαση στην ποιότητα.

Προσαρμογή της διαδικασίας στις ανάγκες του έργου.

Ακραίος προγραμματισμός

Extreme Programming (XP) εμφανίστηκε ως μια εξελικτική μέθοδος ανάπτυξης λογισμικού«κάτω πάνω». Αυτή η προσέγγιση είναι ένα παράδειγμα της λεγόμενης μεθόδου"ζωντανή" ανάπτυξη (Agile Development Method) . Η ομάδα των «ζωντανών» μεθόδων περιλαμβάνει, εκτός από τον ακραίο προγραμματισμό, τις μεθόδους SCRUM, DSDM (Dynamic Systems Development Method, μέθοδος ανάπτυξης δυναμικών συστημάτων),Με γνώμονα τα χαρακτηριστικά Ανάπτυξη (ανάπτυξη με γνώμονα τις λειτουργίες του συστήματος) κ.λπ.

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

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

Ένα πρόγραμμα εργασίας είναι πιο σημαντικό από την ολοκληρωμένη τεκμηρίωση.

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

Η επεξεργασία αλλαγών είναι πιο σημαντική από την τήρηση των σχεδίων.

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

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

Ωστόσο, το XP έχει το δικό του διάγραμμα διαδικασίας ανάπτυξης (αν και, σε γενικές γραμμές, η ευρέως διαδεδομένη κατανόηση της «διαδικασίας ανάπτυξης» ως ένα αρκετά άκαμπτο σχέδιο ενεργειών έρχεται σε αντίθεση με την ίδια την ιδέα της «ζωντανής» ανάπτυξης), που φαίνεται στο Σχ. 15.

Σύμφωνα με τους συγγραφείς του XP, αυτή η τεχνική δεν ακολουθεί τόσο κάποια γενικά πρότυπα δράσης όσο η χρήση ενός συνδυασμού των παρακάτω τεχνικών. Ωστόσο, κάθε τεχνική είναι σημαντική και χωρίς τη χρήση της, η ανάπτυξη θεωρείται ότι δεν είναι XP, σύμφωνα με τον Kent Beck, έναν από τους συγγραφείς αυτής της προσέγγισης, μαζί με τους Ward Cunningham και Ron Jeffries.

Ζωντανό παιχνίδι προγραμματισμού

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

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

				Δοκιμή
		χρήση		σενάρια
			Νέα ιστορία
	Απαιτήσεις		χρήση
			Ταχύτητα έργου
	Μεταφορική έννοια		Σχέδιο έκδοσης
		Σχεδίαση		Επανάληψη	Αποδοχή	Μικρό
αρχιτεκτονική				τελευταίος
						Εντάξει
						χρήστες
Αναξιόπιστος			Βέβαιος	Νέα επανάληψη

«Πετώντας» λύσεις

Εικόνα 15. Διάγραμμα ροής εργασίας σε XP.

Συχνές αλλαγές έκδοσης (μικρές εκδόσεις)

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

Μεταφορά του συστήματος

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

Απλός σχεδιαστικές λύσεις(απλό σχέδιο)

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

Δοκιμαστική Ανάπτυξη(ανάπτυξη βάσει δοκιμής)

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

Συνεχής ανακατασκευή

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

Προγραμματισμός ζευγών

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

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

Συλλογική ιδιοκτησία του κώδικα

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

Συνεχής ενσωμάτωση

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

40 ώρες εργασίας την εβδομάδα

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

Ένταξη του πελάτη στην ομάδα(πελάτης επιτόπου)

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

Χρήση κώδικα ως μέσο επικοινωνίας

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

Ανοιχτός χώρος εργασίας

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

Αλλαγή των κανόνων όπως απαιτείται (απλώς κανόνες)

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

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

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

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

Το XP ως σύνολο περιγραφόμενων τεχνικών χρησιμοποιήθηκε για πρώτη φορά κατά τη διάρκεια της εργασίας στο έργο C3 (Chrysler Comprehensive Compensation System, ανάπτυξη ενός συστήματος λογιστικής πληρωμών

υπάλληλοι της Daimler Chrysler). Από τους 20 συμμετέχοντες σε αυτό το έργο, 5 (συμπεριλαμβανομένων των προαναφερθέντων 3 βασικών συγγραφέων του XP) δημοσίευσαν 3 βιβλία και έναν τεράστιο αριθμό άρθρων αφιερωμένα στο XP κατά τη διάρκεια του ίδιου του έργου και στη συνέχεια. Αυτό το έργο αναφέρεται πολλές φορές στο διάφορες πηγέςως παράδειγμα χρήσης αυτής της τεχνικής. Τα ακόλουθα δεδομένα συγκεντρώνονται από τα άρθρα που αναφέρονται, μείον ανέκδοτα στοιχεία, και απεικονίζουν τα προβλήματα με ορισμένες τεχνικές XP όταν εφαρμόζονται σε αρκετά πολύπλοκα έργα.

Το έργο ξεκίνησε τον Ιανουάριο του 1995. Από τον Μάρτιο του 1996, μετά την ένταξη του Kent Beck, εκτελείται με χρήση XP. Μέχρι εκείνη τη στιγμή, είχε ήδη υπερβεί τον προϋπολογισμό και τα σχέδια για σταδιακή υλοποίηση των λειτουργιών. Η ομάδα ανάπτυξης κόπηκε και για περίπου έξι μήνες μετά το έργο εξελίχθηκε με μεγάλη επιτυχία. Τον Αύγουστο του 1998, εμφανίστηκε ένα πρωτότυπο που θα μπορούσε να εξυπηρετήσει περίπου 10.000 εργαζόμενους. Το έργο αναμενόταν αρχικά να ολοκληρωθεί στα μέσα του 1999 και το λογισμικό που θα προέκυπτε θα χρησιμοποιηθεί για τη διαχείριση των οφελών για τους 87.000 υπαλλήλους της εταιρείας. Σταμάτησε τον Φεβρουάριο του 2000 μετά από 4 χρόνια λειτουργίας XP λόγω πλήρους αποτυχίας τήρησης χρονικών πλαισίων και προϋπολογισμού. Το λογισμικό που δημιουργήθηκε δεν έχει χρησιμοποιηθεί ποτέ για να εργαστεί με δεδομένα για περισσότερους από 10.000 υπαλλήλους, αν και έχει αποδειχθεί ότι μπορεί να χειριστεί δεδομένα για 30.000 υπαλλήλους της εταιρείας. Το άτομο που έπαιξε το ρόλο του πελάτη που συμπεριλήφθηκε στην ομάδα έργου παραιτήθηκε μετά από μερικούς μήνες τέτοιας εργασίας, μη μπορώντας να αντέξει τον φόρτο εργασίας και δεν έλαβε ποτέ επαρκή αντικατάσταση μέχρι το τέλος του έργου.

Λογοτεχνία για τη διάλεξη 3

W. Royce. Διαχείριση έργων λογισμικού. Μ.: Λόρι, 2002.

Α. Jacobson, G. Butch, J. Rambo. Ενιαία διαδικασία ανάπτυξης λογισμικού. Αγία Πετρούπολη: Peter, 2002.

Kroll, The Spirit of the RUP. www-106.ibm.com/developerworks/rational/library/ content/RationalEdge/dec01/TheSpiritoftheRUPDec01.pdf

Κ. Μπεκ. Ακραίος Προγραμματισμός. Αγία Πετρούπολη: Peter, 2002.

http://www.agilemanifesto.org/

K. Beck, et. al. Η Chrysler πηγαίνει στο "Extremes". Κατανεμημένη Υπολογιστική, 10/1998.

Α. Κόκμπερν. Επιλογή Μεθοδολογίας Έργου. Λογισμικό IEEE, 04/2000.

L. Williams, R. R. Kessler, W. Cunningham, R. Jeffries. Ενίσχυση του Case for Pair Programming. Λογισμικό IEEE 4/2000.

G. Keefer. Ο ακραίος προγραμματισμός θεωρείται επιβλαβής για αξιόπιστη ανάπτυξη λογισμικού. Τεχνική Έκθεση AVOCA, 2002.

Διατίθεται ως http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf.