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

Το παιχνίδι του σχεδιασμού

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

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

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

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

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

Μόνιμη συνάντηση

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

Απλότητα

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

Σύστημα μεταφοράς

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

συμπέρασμα

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

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

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

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

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

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

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

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

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

· ζωή σχεδίαση παιχνίδι)

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

Εικ.1

· Συχνάζω αλλαγή εκδόσεις (μικρές εκδόσεις)

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

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

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

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

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

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

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

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

· Ανάπτυξη στο βάση δοκιμές (test-driven ανάπτυξη)

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

Το XP εστιάζει σε δύο τύπους δοκιμών:

ь δοκιμή μονάδων (δοκιμή μονάδων).

ь δοκιμή αποδοχής (δοκιμή αποδοχής).

ακραίο λογισμικό προγραμματισμού

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

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

Για τα XP, μια προσέγγιση που ονομάζεται TDD (Test Driven Development) έχει μεγαλύτερη προτεραιότητα, πρώτα γράφεται μια δοκιμή που δεν περνάει, μετά γράφεται ο κώδικας έτσι ώστε η δοκιμή να περάσει και μετά ο κώδικας ανακατασκευάζεται.

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

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

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

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

· Προγραμματισμός σε ζευγάρια (ζευγ προγραμματισμός)

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

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

· Συλλογικός κατοχή κωδικός (συλλογικό ιδιοκτησία)

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

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

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

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

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

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

· 40 ωρες εργαζόμενος μια εβδομάδα

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

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

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

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

· Συμπερίληψη πελάτης σε εντολή (επί τόπου πελάτης)

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

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

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

· Χρήση κώδικας πως κεφάλαια διαβιβάσεις

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

· Άνοιξε εργαζόμενος χώρο (ανοιχτό χώρος εργασίας)

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

· Αλλαγή κανόνες επί απαραίτητο (απλώς κανόνες)

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

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

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

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

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

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

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

Η ακαδημαϊκή κοινότητα των προγραμματιστών λογισμικού ανέλαβε το πρόβλημα του υψηλού κόστους της αλλαγής και δημιούργησε νέες τεχνολογίες - σχεσιακές βάσεις δεδομένων, αρθρωτό προγραμματισμό, απόκρυψη πληροφοριών. Τι γίνεται όμως αν όλα αυτά τα έργα έχουν ήδη εξαντλήσει τις δυνατότητές τους; Και μπορούμε να βρούμε νέος τρόποςνα μειώσει το κόστος των αλλαγών όχι κόβοντας τον «καταρράκτη» σε κομμάτια, αλλά απλώς ανακατεύοντας όλα τα συστατικά του; Το αποτέλεσμα φαίνεται στο Σχήμα 1γ. Το ονομάσαμε «Extreme Programming» (XP).

Ανατομία XP

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

Κύκλος ανάπτυξης XP

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

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

Ιστορίες

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

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

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

Εκδοχή

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

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

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

Επανάληψη

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

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

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

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

Μια εργασία

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

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

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

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

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

Δοκιμή

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

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

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

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

Έχετε προβλήματα;

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

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

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

Εάν ο πελάτης δεν συνεργαστεί.Φανταστείτε μια κατάσταση όπου ο πελάτης δεν αποδέχεται τους κανόνες του παιχνιδιού σας. Δεν βγάζει τεστ, δεν βάζει προτεραιότητες, δεν διατυπώνει ιστορίες. Πρώτα απ 'όλα, προσπαθήστε να εγκαταστήσετε σχέση εμπιστοσύνηςμε τον πελάτη. Αυξάνοντας τη λειτουργικότητα του συστήματος από επανάληψη σε επανάληψη, δώστε στον πελάτη την ευκαιρία να ελέγξει τη διαδικασία ανάπτυξης. Εάν η αμοιβαία εμπιστοσύνη δεν λειτουργεί, αναλύστε εάν αυτό είναι δικό σας λάθος. Κάνετε τα πάντα για αποτελεσματική αλληλεπίδραση με τον πελάτη;

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

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

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

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

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

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

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

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

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

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

Η ισχυρή διάκριση της XP μεταξύ επιχειρηματικών και τεχνικών αποφάσεων ανάγεται στο έργο του αρχιτέκτονα Christopher Alexander. Το βιβλίο του The Timeless Way of Building σημειώνει ότι όσοι διαχειρίζονται ένα κτίριο πρέπει να έχουν τη δυνατότητα να λαμβάνουν σημαντικές αποφάσεις κατά την κατασκευή του.

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

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

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

Το Spiral Model του Barry Boehm ήταν η πρώτη αντίδραση στην απαρχαιότητα του μοντέλου του καταρράκτη. Για πολύ καιρόστην κυριαρχία ισχυρών τεχνολογιών, κανείς δεν θα μπορούσε να ξεπεράσει τον Dave Thomas και τους συναδέλφους του στο Object Technology International, που δημιούργησαν τη μέθοδο JIT.

Οι ρίζες της αρχής της μεταφοράς που χρησιμοποιείται στα XP βρίσκονται στα βιβλία των George Lakoff και Mark Johnson, ιδιαίτερα στο τελευταίο τους έργο Philoslphy in the Flesh. Αυτή η αρχή προτάθηκε επίσης από τον Richard Coine, ο οποίος συνέδεσε τη μεταφορά και την ανάπτυξη λογισμικού με όρους μεταμοντέρνας φιλοσοφίας.

Τέλος, μεγάλο μέρος της έμφασης της XP στην οργάνωση του γραφείου προέρχεται από το έργο των Jim Coplien, Tom DeMarco και Tim Lister, οι οποίοι παρατήρησαν την επίδραση των περιβαλλοντικών συνθηκών στο έργο των προγραμματιστών.

Παραδείγματα εκτέλεσης έργων με χρήση XP

Αξίωμα: στον δρόμο για την επίτευξη ενός κοινού στόχου

Τζι Χανούλα

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

Εφαρμογή:βάση δεδομένων διαχείρισης καμπάνιας

Περίοδος υλοποίησης: 3 χρόνια

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

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

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

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

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

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

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

DaimlerChrysler: η καλύτερη ομάδα στον κόσμο

Τσετ Χέντρικσεν

Ομάδα: 15 άτομα, συμπεριλαμβανομένων 10 προγραμματιστών

Εφαρμογή:αυτοματοποίηση πλήρους κλίμακας υπολογισμού μισθοδοσίας

Περίοδος υλοποίησης: 4 χρόνια

Οι εργασίες για το έργο C3 ξεκίνησαν τον Ιανουάριο του 1995. Η Chrysler Corporation σύναψε σύμβαση με μια συνεργαζόμενη εταιρεία, σύμφωνα με την οποία μια κοινή ομάδα ανάπτυξης και από τους δύο οργανισμούς ανέλαβε το έργο. Οι συνεργάτες μας ακολούθησαν μια μεθοδολογία ανάπτυξης που επικεντρώθηκε στη χρήση GUIκαι αγνόησε τον αυτοματισμό δοκιμής. Το αποτέλεσμα ήταν ένα σύστημα που ήταν γεμάτο με μη εντυπωσιακά γραφικά και υπολόγιζε λανθασμένα τον μισθό για τους περισσότερους υπαλλήλους. Θα χρειαστούν περίπου 100 ημέρες για να δημιουργήσει ένα τέτοιο σύστημα μια μηνιαία μισθοδοσία. Συνειδητοποιήσαμε ότι το πρόγραμμα που γράψαμε δεν θα χρησιμοποιηθεί ποτέ πραγματικά.

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

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

Αυτή η φάση της εφαρμογής του C3 ξεκίνησε τον Μάιο του 1997, αν και είχαμε προβλέψει μια προγενέστερη ημερομηνία. Η αποτυχία των σχεδίων μας οφειλόταν σε δύο παράγοντες. Αρχικά, αποφασίσαμε να αντικαταστήσουμε μόνο τα εσωτερικά εξαρτήματα σύστημα πληρωμής. Όλες οι εξωτερικές διεπαφές παρέμειναν ανέγγιχτες. Έξοδος αγώνα νέο σύστημαστοιχεία του παλιού αποδείχθηκαν πολύ περισσότερα δύσκολη εργασίααπ' όσο περιμέναμε. Δεύτερον, αποφασίσαμε να μην ξεκινήσουμε ειδικές απαιτήσεις κατά τη διάρκεια οποιασδήποτε περιόδου πληρωμής, όπως επεξεργασία W-2, κατανομή κερδών ή γενική αύξηση. μισθοί. Ως αποτέλεσμα, αυτό που έπρεπε να είχε γίνει τον Νοέμβριο μετατέθηκε για τον Απρίλιο.

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

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

Ford Motor: ένας μοναδικός συνδυασμός απόδοσης και ποιότητας

Ντον Γουέλς

Ομάδα: 17 άτομα, συμπεριλαμβανομένων 12 προγραμματιστών

Εφαρμογή:σύστημα ανάλυσης κόστους

Περίοδος υλοποίησης: 6 χρόνια

Το τμήμα χρηματοοικονομικών συστημάτων της Ford Motor Company αναπτύσσει το σύστημα ανάλυσης Vehicle Costing and Profit System (VCAPS), το οποίο δημιουργεί αναφορές για τα έσοδα παραγωγής, τα έξοδα, τα καθαρά έσοδα και τα κέρδη. Οι εισροές στο σύστημα είναι οι προδιαγραφές προϊόντων μηχανικής, τα πάγια κόστη και έξοδα και μεταβλητό κόστος όπως οι ώρες εργασίας. Το VCAPS συγκεντρώνει όλα αυτά τα δεδομένα και συντάσσει λεπτομερείς αναφορές με ανάλυση κόστους που επιτρέπουν την αποτελεσματική πρόβλεψη και τη λήψη εταιρικών αποφάσεων. Οι εργασίες για το έργο VCAPS ξεκίνησαν το 1993. Αναπτύχθηκε με χρήση VisualWorks και GemStone Smalltalk. Το VCAPS αυτή τη στιγμή διατηρείται από μια μικρή ομάδα ανθρώπων και σύντομα θα αντικατασταθεί από μια πιο σύγχρονη εφαρμογή.

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

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

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

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

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

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

Σύστημα τιμολόγησης: δοκιμές που μπορείτε να διαβάσετε

Ρομπ Μι

Ομάδα:τρεις προγραμματιστές

Εφαρμογή:σύστημα υπολογισμού τιμολογίων μεταφοράς

Περίοδος υλοποίησης: 3 μήνες

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

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

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

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

Αγκαλιάζοντας την αλλαγή με τον ακραίο προγραμματισμό, Kent Beck. Computer, Οκτώβριος, 1999, σσ. 70-77, Ανατύπωση με άδεια, Πνευματικά δικαιώματα IEEE, 1999, Με την επιφύλαξη παντός δικαιώματος.

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

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

Αρχές XP

Οι βασικές αρχές είναι:

• Επανάληψη.Η ανάπτυξη πραγματοποιείται σε σύντομες επαναλήψεις παρουσία ενεργούς σχέσης με τον πελάτη. Οι επαναλήψεις ως τέτοιες προτείνονται να είναι σύντομες, η συνιστώμενη διάρκεια είναι 2-3 εβδομάδες και όχι περισσότερο από 1 μήνα. Σε μία επανάληψη, μια ομάδα προγραμματιστών πρέπει να εφαρμόσει πολλά χαρακτηριστικά του συστήματος, καθένα από τα οποία περιγράφεται σε μια ιστορία χρήστη. Οι ιστορίες χρήστη (UI) σε αυτήν την περίπτωση είναι οι αρχικές πληροφορίες βάσει των οποίων δημιουργείται η ενότητα. Διαφέρουν από τις περιπτώσεις χρήσης (UTs). Η περιγραφή του PI είναι σύντομη - 1-2 παραγράφων, ενώ το PI περιγράφεται συνήθως με επαρκή λεπτομέρεια, με τις κύριες και εναλλακτικές ροές, και συμπληρώνεται από ένα μοντέλο. Τα UI γράφονται από τους ίδιους τους χρήστες, οι οποίοι στα XP αποτελούν μέρος της ομάδας, σε αντίθεση με τα UI που περιγράφει ο αναλυτής συστήματος. Η έλλειψη επισημοποίησης της περιγραφής των δεδομένων εισόδου του έργου σε XP επιδιώκεται να αντισταθμιστεί με την ενεργή ένταξη του πελάτη στη διαδικασία ανάπτυξης ως πλήρες μέλος της ομάδας.
• Η απλότητα των λύσεων.Υιοθετείται η πρώτη απλούστερη λύση εργασίας. Η ακραία φύση της μεθόδου συνδέεται με υψηλό βαθμόο κίνδυνος μιας απόφασης λόγω της επιπολαιότητας της ανάλυσης και του άκαμπτου χρονοδιαγράμματος. Το ελάχιστο σύνολο των κύριων λειτουργιών του συστήματος υλοποιείται στην πρώτη και σε κάθε επόμενη επανάληψη. η λειτουργικότητα επεκτείνεται σε κάθε επανάληψη.
• Εντατική ανάπτυξη από μικρές ομάδες(όχι περισσότερα από 10 άτομα) και προγραμματισμός ζευγών(όταν δύο προγραμματιστές δημιουργούν κώδικα μαζί σε έναν κοινό χώρο εργασίας), ενεργή επικοινωνία εντός της ομάδας και μεταξύ ομάδων. Όλα αυτά στοχεύουν στον εντοπισμό προβλημάτων όσο το δυνατόν νωρίτερα (τόσο λάθη όσο και χαμένες προθεσμίες). Ο προγραμματισμός ζευγών στοχεύει στην επίλυση του προβλήματος της σταθεροποίησης του έργου. Όταν χρησιμοποιείτε τη μεθοδολογία XP, υπάρχει μεγάλος κίνδυνος απώλειας κώδικα λόγω της αποχώρησης ενός προγραμματιστή που δεν άντεξε ένα έντονο πρόγραμμα εργασίας. Σε αυτή την περίπτωση, ο δεύτερος προγραμματιστής από το ζεύγος παίζει το ρόλο του "κληρονόμου" του κώδικα. Είναι επίσης σημαντικό πώς κατανέμονται οι ομάδες στον χώρο εργασίας - το XP χρησιμοποιεί έναν ανοιχτό χώρο εργασίας, που συνεπάγεται γρήγορη και δωρεάν πρόσβαση για όλους σε όλους.
• Σχόλια πελατών, ο εκπρόσωπος του οποίου εμπλέκεται ουσιαστικά στη διαδικασία ανάπτυξης.
• Επαρκής βαθμός θάρρουςκαι προθυμία για ανάληψη κινδύνων.

Κόλπα XP (πρακτικές)

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

1. Σχεδιασμός διαδικασίας.Όλη η ομάδα ανάπτυξης συγκεντρώνεται, λαμβάνεται μια συλλογική απόφαση σχετικά με το ποια χαρακτηριστικά του συστήματος θα εφαρμοστούν στην επόμενη επανάληψη. Η πολυπλοκότητα της υλοποίησης κάθε ιδιότητας καθορίζεται από τους ίδιους τους προγραμματιστές.
2. Στενή αλληλεπίδραση με τον πελάτη.Ο εκπρόσωπος πελάτη πρέπει να είναι μέλος της ομάδας XP. Γράφει το UI, επιλέγει τις ιστορίες που θα εφαρμοστούν σε μια συγκεκριμένη επανάληψη και απαντά σε ερωτήσεις που σχετίζονται με τις επιχειρήσεις. Ο εκπρόσωπος του πελάτη πρέπει να είναι ειδικός στην αυτοματοποιημένη θεματική περιοχή. Είναι απαραίτητο να υπάρχει συνεχής ανατροφοδότηση από τον εκπρόσωπο του πελάτη.
3. Γενικοί κανόνες ονομασίας συστήματος.Καλές συμβάσεις ονομασίας συστήματος ευκολία ονομασίας κλάσεις και μεταβλητές. Η ομάδα ανάπτυξης θα πρέπει να έχει ενιαίες συμβάσεις ονομασίας.
4. Απλή αρχιτεκτονική.Οποιαδήποτε ιδιότητα του συστήματος θα πρέπει να υλοποιείται όσο πιο απλά γίνεται. Οι προγραμματιστές στην ομάδα XP εργάζονται με το σύνθημα: "Τίποτα περισσότερο!". Υιοθετείται η πρώτη απλή λύση εργασίας, το απαιτούμενο επίπεδο λειτουργικότητας υλοποιείται αυτή τη στιγμή. Αυτό εξοικονομεί χρόνο στον προγραμματιστή.
5. Ανακατασκευή.Πρόκειται για μια βελτιστοποίηση του υπάρχοντος κώδικα για την απλούστευση του, η οποία θα πρέπει να εκτελείται συνεχώς. Διατηρώντας τον κώδικα διαφανή και ορίζοντας τα στοιχεία του μόνο μία φορά, οι προγραμματιστές μειώνουν τον αριθμό των σφαλμάτων που πρέπει να διορθωθούν αργότερα. Κατά την υλοποίηση κάθε νέας ιδιότητας του συστήματος, ο προγραμματιστής πρέπει να εξετάσει εάν ο υπάρχων κώδικας μπορεί να απλοποιηθεί και πώς αυτό θα βοηθήσει στην υλοποίηση της νέας ιδιότητας. Επιπλέον, δεν μπορείτε να συνδυάσετε το refactoring με το design: εάν δημιουργείτε νέο κωδικό, η ανακατασκευή θα πρέπει να αναβληθεί.
6. Προγραμματισμός ζευγών.Όλοι οι προγραμματιστές πρέπει να δουλεύουν σε ζευγάρια: ο ένας γράφει τον κώδικα, ο άλλος κοιτάζει. Έτσι, είναι απαραίτητο να τοποθετήσετε μια ομάδα προγραμματιστών σε ένα μέρος. Το XP λειτουργεί καλύτερα σε μη κατανεμημένες ομάδες προγραμματιστών και χρηστών.
7. 40 ώρες εργασίας την εβδομάδα.Ο προγραμματιστής δεν πρέπει να εργάζεται πάνω από 8 ώρες την ημέρα. Η ανάγκη για υπερωρίες είναι σαφής ένδειξη ενός προβλήματος στον συγκεκριμένο τομέα ανάπτυξης. Η εύρεση των αιτιών των υπερωριών και η έγκαιρη εξάλειψή τους είναι ένας από τους βασικούς κανόνες.
8. Συλλογική ιδιοκτησία κωδικού.Κάθε προγραμματιστής στην ομάδα πρέπει να έχει πρόσβαση στον κωδικό οποιουδήποτε τμήματος του συστήματος και το δικαίωμα να κάνει αλλαγές σε οποιονδήποτε κώδικα. Υποχρεωτικός κανόνας: εάν ένας προγραμματιστής έχει κάνει αλλαγές και το σύστημα δεν λειτουργεί σωστά μετά από αυτό, τότε είναι αυτός ο προγραμματιστής που πρέπει να διορθώσει τα σφάλματα.
9. Ενιαία πρότυπα κωδικοποίησης.Απαιτούνται πρότυπα κωδικοποίησης για την υποστήριξη άλλων πρακτικών: κοινή χρήση κώδικα, προγραμματισμός ζευγών και ανακατασκευή. Χωρίς ένα ενιαίο πρότυπο, είναι τουλάχιστον πιο δύσκολο να πραγματοποιηθούν αυτές οι πρακτικές, αλλά στην πραγματικότητα είναι γενικά αδύνατο: η ομάδα θα εργάζεται σε έναν τρόπο συνεχούς έλλειψης χρόνου. Η ομάδα εργάζεται στο έργο εδώ και πολύ καιρό. Οι άνθρωποι έρχονται και φεύγουν. Κανείς δεν κωδικοποιεί μόνος του και ο κωδικός ανήκει σε όλους. Πάντα θα υπάρχουν στιγμές που θα είναι απαραίτητο να κατανοήσετε και να διορθώσετε τον κώδικα κάποιου άλλου. Οι προγραμματιστές θα αφαιρέσουν τον διπλότυπο κώδικα, θα αναλύσουν και θα βελτιώσουν τις κατηγορίες άλλων ατόμων κ.λπ. Επομένως, όλοι πρέπει να υπακούουν σε κοινά πρότυπα κωδικοποίησης - μορφοποίηση κώδικα, ονομασία κλάσης, μεταβλητή, σταθερή ονομασία, στυλ σχολίου. Τα παραπάνω σημαίνουν ότι όλα τα μέλη της ομάδας πρέπει να συμφωνήσουν σε κοινά πρότυπα κωδικοποίησης. Δεν έχει σημασία, αλλά όλοι είναι υποχρεωμένοι να τους υπακούουν.
10. Μικρές εκδόσεις.Η ελάχιστη επανάληψη είναι μία ημέρα, η μέγιστη μία είναι ένας μήνας. Όσο πιο συχνά γίνονται εκδόσεις, τόσο περισσότερα ελαττώματα στο σύστημα θα αποκαλύπτονται. Οι πρώτες εκδόσεις βοηθούν στον εντοπισμό ελλείψεων στα πρώτα στάδια και, στη συνέχεια, η λειτουργικότητα του συστήματος επεκτείνεται με βάση τη διεπαφή χρήστη. Εφόσον ο χρήστης περιλαμβάνεται στη διαδικασία ανάπτυξης από την πρώτη κυκλοφορία, αξιολογεί το σύστημα και εκδίδει μια ιστορία χρήστη και σχόλια. Με βάση αυτό καθορίζεται η επόμενη επανάληψη, ποια θα είναι δηλαδή η νέα κυκλοφορία. Τα πάντα σχετικά με τα XP αφορούν την παροχή συνεχών σχολίων στους χρήστες.
11. Συνεχής ενσωμάτωση.Η ενσωμάτωση νέων τμημάτων του συστήματος θα πρέπει να γίνεται όσο το δυνατόν συχνότερα, τουλάχιστον μία φορά κάθε λίγες ώρες. Ο βασικός κανόνας της ολοκλήρωσης είναι ο εξής: η ενσωμάτωση μπορεί να πραγματοποιηθεί εάν όλα τα τεστ περάσουν με επιτυχία. Εάν τα τεστ δεν περάσουν, τότε ο προγραμματιστής πρέπει είτε να κάνει διορθώσεις και στη συνέχεια να ενσωματώσει τα στοιχεία του συστήματος ή να μην τα ενσωματώσει καθόλου. Αυτός ο κανόνας είναι άκαμπτος και ξεκάθαρος. Εάν υπάρχει τουλάχιστον ένα σφάλμα στο δημιουργημένο τμήμα του συστήματος, τότε η ενοποίηση δεν μπορεί να πραγματοποιηθεί. Η συχνή ενσωμάτωση σάς επιτρέπει να αποκτάτε ένα έτοιμο σύστημα πιο γρήγορα, αντί να ξοδεύετε μια εβδομάδα στη συναρμολόγηση.
12. Δοκιμές.Σε αντίθεση με τις περισσότερες άλλες μεθοδολογίες, η δοκιμή σε XP είναι ένα από τα πιο σημαντικά στοιχεία. Η ακραία προσέγγιση υποθέτει ότι Οι δοκιμές γράφονται πριν γραφτεί ο κώδικας . Κάθε ενότητα πρέπει να έχει μια δοκιμή μονάδας - μια δοκιμή για αυτήν την ενότητα. Έτσι, το XP εκτελεί δοκιμές παλινδρόμησης, "μη υποβαθμισμένη ποιότητα" όταν προσθέτει λειτουργικότητα. Τα περισσότερα σφάλματα διορθώνονται στο στάδιο της κωδικοποίησης. Τα τεστ γράφονται από τους ίδιους τους προγραμματιστές, οποιοσδήποτε από αυτούς έχει το δικαίωμα να γράψει ένα τεστ για οποιαδήποτε ενότητα. Μια άλλη σημαντική αρχή: το τεστ καθορίζει τον κώδικα και όχι το αντίστροφο (ανάπτυξη βάσει δοκιμής), δηλαδή, ένα κομμάτι κώδικα τοποθετείται στο αποθετήριο εάν και μόνο εάν όλα τα τεστ έχουν περάσει με επιτυχία, διαφορετικά αυτή η αλλαγή κώδικα απορρίπτεται.

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

Και άλλοι.

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

Εγκυκλοπαιδικό YouTube

1 / 5

Extreme Programming (XP) - Βασικές Τεχνικές

Hexlet Webinar #6: Extreme Programming

συμβουλές ζωής. Γιατί να συμμετέχω σε διαγωνισμούς προγραμματισμού;

032. Προγραμματισμός ζευγών - Sergey Berezhnoy

Extreme Programming Channel v. 2.0

Υπότιτλοι

XP βασικά κόλπα

The Twelve Basic Techniques of Extreme Programming (σύμφωνα με την πρώτη έκδοση του βιβλίου Εξήγησε τον ακραίο προγραμματισμό) μπορούν να ομαδοποιηθούν σε τέσσερις ομάδες:

• Σύντομος κύκλος ανατροφοδότησης (Ανατροφοδότηση λεπτής κλίμακας)
  • Ανάπτυξη μέσω δοκιμών (Ανάπτυξη βάσει δοκιμής)
  • Παιχνίδι προγραμματισμού
  • Ο πελάτης είναι πάντα εκεί (Ολόκληρη η ομάδα, πελάτης επιτόπου)
  • Προγραμματισμός ζευγών
• Συνεχής, όχι κατά παρτίδες διαδικασία
  • Συνεχής ενσωμάτωση
  • Refactoring (Βελτίωση σχεδίασης, Refactoring)
  • Συχνές μικρές απελευθερώσεις
• Μια κατανόηση που μοιράζονται όλοι
  • Απλότητα
  • Μεταφορά συστήματος
  • Συλλογική ιδιοκτησία κωδικού ή επιλεγμένα μοτίβα σχεδίασης (Συλλογική ιδιοκτησία μοτίβων)
  • Πρότυπο κωδικοποίησης ή συμβάσεις κωδικοποίησης
• Κοινωνική ασφάλιση του προγραμματιστή (Programmer welfare):
  • Εβδομάδα εργασίας 40 ωρών (βιώσιμος ρυθμός, σαράντα ώρες εβδομάδα)

Δοκιμές

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

• δοκιμή μονάδων μονάδων.

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

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

Για τα XP, μια προσέγγιση που ονομάζεται TDD (από το αγγλικό test-driven development - development through testing) είναι υψηλότερη προτεραιότητα. Σύμφωνα με αυτή την προσέγγιση, αρχικά γράφεται ένα τεστ που αρχικά αποτυγχάνει (επειδή η λογική που πρέπει να ελέγξει απλώς δεν υπάρχει ακόμα), στη συνέχεια εφαρμόζεται η λογική που απαιτείται για να περάσει το τεστ. Το TDD, κατά μία έννοια, σας επιτρέπει να γράψετε κώδικα που είναι πιο βολικό στη χρήση - γιατί όταν γράφετε μια δοκιμή, όταν δεν υπάρχει ακόμα λογική, είναι πιο εύκολο να φροντίσετε για την ευκολία του μελλοντικού συστήματος.

Το παιχνίδι του σχεδιασμού

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

Ο πελάτης είναι πάντα εκεί

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

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

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

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

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

Ανακατασκευή

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

Συχνές μικρές απελευθερώσεις

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

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

Ευκολία Σχεδιασμού

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

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

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

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

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

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

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

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

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

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

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