Κάθε τεχνολογικός οργανισμός σήμερα φαίνεται να ασκεί την ευέλικτη μεθοδολογία για την ανάπτυξη λογισμικού ή μια έκδοση αυτής. Ή τουλάχιστον πιστεύουν ότι το κάνουν. Είτε είστε νέοι στην ευέλικτη ανάπτυξη εφαρμογών είτε έχετε μάθει την ανάπτυξη λογισμικού πριν από δεκαετίες χρησιμοποιώντας τη μεθοδολογία ανάπτυξης λογισμικού καταρράκτη, σήμερα η εργασία σας επηρεάζεται τουλάχιστον από την ευέλικτη μεθοδολογία.
Αλλά τι είναι ευέλικτη μεθοδολογία, και πώς πρέπει να εφαρμόζεται στην ανάπτυξη λογισμικού; Σε τι διαφέρει η ευέλικτη ανάπτυξη από τον καταρράκτη στην πράξη; Τι είναι ο ευέλικτος κύκλος ζωής ανάπτυξης λογισμικού ή ευκίνητος SDLC; Και τι είναι το scrum agile έναντι του Kanban και άλλων ευέλικτων μοντέλων;
Το Agile κυκλοφόρησε επίσημα το 2001, όταν 17 τεχνολόγοι συνέταξαν το μανιφέστο του Agile. Έγραψαν τέσσερις βασικές αρχές για ευέλικτη διαχείριση έργων, με στόχο την ανάπτυξη καλύτερου λογισμικού:
- Άτομα και αλληλεπιδράσεις για διαδικασίες και εργαλεία
- Λειτουργικό λογισμικό για ολοκληρωμένη τεκμηρίωση
- Συνεργασία πελατών για διαπραγμάτευση συμβολαίου
- Απαντώντας σε αλλαγή μετά από ένα σχέδιο
Πριν ευκίνητο: Η εποχή της μεθοδολογίας καταρράκτη
Παλιά χέρια σαν εμένα θυμούνται τις μέρες που η μεθοδολογία καταρράκτη ήταν το χρυσό πρότυπο για την ανάπτυξη λογισμικού. Η διαδικασία ανάπτυξης λογισμικού απαιτούσε έναν τόνο τεκμηρίωσης εκ των προτέρων πριν ξεκινήσει οποιαδήποτε κωδικοποίηση. Κάποιος, συνήθως ο αναλυτής της επιχείρησης, έγραψε πρώτα ένα έγγραφο απαιτήσεων επιχείρησης που καταγράφει ό, τι χρειάζεται η επιχείρηση στην εφαρμογή. Αυτά τα επιχειρησιακά έγγραφα απαιτήσεων ήταν μακρά, με λεπτομέρειες όλων: συνολική στρατηγική, ολοκληρωμένες λειτουργικές προδιαγραφές και οπτικά σχέδια διεπαφής χρήστη.
Οι τεχνολόγοι έλαβαν το έγγραφο των επιχειρησιακών απαιτήσεων και ανέπτυξαν το δικό τους έγγραφο τεχνικών απαιτήσεων. Αυτό το έγγραφο καθόρισε την αρχιτεκτονική της εφαρμογής, τις δομές δεδομένων, τα αντικειμενοστραφή λειτουργικά σχέδια, τις διεπαφές χρήστη και άλλες μη λειτουργικές απαιτήσεις.
Αυτή η διαδικασία ανάπτυξης λογισμικού καταρράκτη θα ξεκινούσε τελικά την κωδικοποίηση, στη συνέχεια την ολοκλήρωση και τελικά τον έλεγχο πριν από μια εφαρμογή θεωρηθεί έτοιμη για παραγωγή. Η όλη διαδικασία θα μπορούσε εύκολα να διαρκέσει μερικά χρόνια.
Εμείς οι προγραμματιστές αναμενόταν να γνωρίζουμε «την προδιαγραφή», όπως κλήθηκε η πλήρης τεκμηρίωση, όπως και οι συγγραφείς των εγγράφων, και συχνά τιμωρήσαμε εάν ξεχάσαμε να εφαρμόσουμε σωστά μια βασική λεπτομέρεια που περιγράφεται στη σελίδα 77 των 200- έγγραφο σελίδας.
Τότε, η ίδια η ανάπτυξη λογισμικού δεν ήταν εύκολη. Πολλά εργαλεία ανάπτυξης απαιτούσαν εξειδικευμένη εκπαίδευση και δεν υπήρχε πουθενά κοντά στον ανοιχτό κώδικα ή στα εμπορικά στοιχεία λογισμικού, API και υπηρεσίες ιστού που υπάρχουν σήμερα. Έπρεπε να αναπτύξουμε πράγματα χαμηλού επιπέδου, όπως το άνοιγμα συνδέσεων βάσης δεδομένων και το multithreading την επεξεργασία δεδομένων μας.
Για ακόμη και βασικές εφαρμογές, οι ομάδες ήταν μεγάλες και τα εργαλεία επικοινωνίας ήταν περιορισμένα. Οι τεχνικές μας προδιαγραφές ήταν αυτές που μας ευθυγραμμίζουν και τις αξιοποιήσαμε όπως η Αγία Γραφή. Εάν αλλάξει μια απαίτηση, θα θέλαμε τους ηγέτες των επιχειρήσεων να περάσουν από μια μακρά διαδικασία ελέγχου και να αποσυνδεθούμε επειδή η επικοινωνία των αλλαγών σε όλη την ομάδα και η διόρθωση του κώδικα ήταν δαπανηρή.
Επειδή το λογισμικό αναπτύχθηκε με βάση την τεχνική αρχιτεκτονική, αναπτύχθηκαν πρώτα αντικείμενα χαμηλού επιπέδου και στη συνέχεια εξαρτημένα αντικείμενα. Οι εργασίες ανατέθηκαν βάσει δεξιοτήτων, και ήταν σύνηθες για τους μηχανικούς βάσης δεδομένων να κατασκευάζουν πρώτα πίνακες και άλλα αντικείμενα βάσης δεδομένων, ακολουθούμενο από τους προγραμματιστές εφαρμογών που κωδικοποιούν τη λειτουργικότητα και την επιχειρηματική λογική, και τελικά επικαλύφθηκε το περιβάλλον εργασίας χρήστη. Χρειάστηκαν μήνες πριν κανείς δει την εφαρμογή να λειτουργεί και μέχρι τότε, οι ενδιαφερόμενοι γίνονταν άγχος και συχνά πιο έξυπνοι για αυτό που πραγματικά ήθελαν. Δεν υπάρχει αμφιβολία ότι η εφαρμογή αλλαγών ήταν τόσο ακριβή!
Δεν λειτούργησαν όλα όσα βάζετε μπροστά στους χρήστες όπως αναμενόταν. Μερικές φορές, οι χρήστες δεν θα χρησιμοποιούν καθόλου μια λειτουργία. Άλλες φορές, μια ικανότητα ήταν ευρέως επιτυχημένη, αλλά απαιτούσε ανασχεδιασμό για να υποστηρίξει την απαραίτητη επεκτασιμότητα και απόδοση. Στον κόσμο του καταρράκτη, μάθατε αυτά τα πράγματα μόνο μετά την ανάπτυξη του λογισμικού, μετά από έναν μακρύ κύκλο ανάπτυξης.
Σχετικό βίντεο: Πώς λειτουργεί η ευέλικτη μεθοδολογία
Όλοι φαίνεται να μιλάνε για ευέλικτη ανάπτυξη λογισμικού, αλλά πολλοί οργανισμοί δεν έχουν σταθερή αντίληψη για το πώς λειτουργεί η διαδικασία. Παρακολουθήστε αυτό το βίντεο πέντε λεπτών για να φτάσετε γρήγορα στην ταχύτητα.
Ο άξονας για την ευέλικτη ανάπτυξη λογισμικού
Εφευρέθηκε το 1970, η μεθοδολογία καταρράκτη ήταν επαναστατική, διότι έφερε πειθαρχία στην ανάπτυξη λογισμικού για να διασφαλίσει ότι υπήρχε μια σαφής προδιαγραφή που πρέπει να ακολουθηθεί. Βασίστηκε στη μέθοδο κατασκευής καταρράκτη που προήλθε από τις καινοτομίες της σειράς συναρμολόγησης του Henry Ford το 1913, οι οποίες παρείχαν βεβαιότητα ως προς κάθε βήμα στη διαδικασία παραγωγής για να εγγυηθεί ότι το τελικό προϊόν ταιριάζει με αυτό που ήταν πρώτο.
Όταν η μεθοδολογία καταρράκτη ήρθε στον κόσμο του λογισμικού, τα υπολογιστικά συστήματα και οι εφαρμογές τους ήταν συνήθως περίπλοκα και μονολιθικά, απαιτώντας πειθαρχία και σαφές αποτέλεσμα. Οι απαιτήσεις άλλαξαν επίσης αργά σε σύγκριση με σήμερα, έτσι οι προσπάθειες μεγάλης κλίμακας ήταν λιγότερο προβληματικές. Στην πραγματικότητα, τα συστήματα κατασκευάστηκαν με την υπόθεση ότι δεν θα άλλαζαν αλλά θα ήταν διαρκή θωρηκτά. Τα πολυετή χρονοδιαγράμματα ήταν κοινά όχι μόνο στην ανάπτυξη λογισμικού αλλά και στη μεταποιητική και άλλες επιχειρηματικές δραστηριότητες. Όμως, η ακαμψία του καταρράκτη έγινε πτέρνα του Αχιλλέα στην εποχή του Διαδικτύου, όπου απαιτείται ταχύτητα και ευελιξία.
Η μεθοδολογία ανάπτυξης λογισμικού άρχισε να αλλάζει όταν οι προγραμματιστές άρχισαν να εργάζονται σε εφαρμογές Διαδικτύου. Πολλές από τις πρώτες εργασίες έγιναν στις νεοσύστατες επιχειρήσεις όπου οι ομάδες ήταν μικρότερες, είχαν τοποθετηθεί σε ταξίδια και συχνά δεν είχαν παραδοσιακό υπόβαθρο της επιστήμης των υπολογιστών. Υπήρχαν οικονομικές και ανταγωνιστικές πιέσεις για την ταχύτερη προώθηση ιστότοπων, εφαρμογών και νέων δυνατοτήτων στην αγορά. Τα εργαλεία και οι πλατφόρμες ανάπτυξης άλλαξαν γρήγορα ως απόκριση.
Αυτό οδήγησε πολλούς από εμάς να δουλεύουμε σε νεοσύστατες επιχειρήσεις να αμφισβητούν τη μεθοδολογία καταρράκτη και να αναζητούν τρόπους για να είναι πιο αποτελεσματικοί. Δεν μπορούσαμε να κάνουμε όλη τη λεπτομερή τεκμηρίωση εκ των προτέρων και χρειαζόμασταν μια πιο επαναληπτική και συνεργατική διαδικασία. Συζητήσαμε ακόμα τις αλλαγές στις απαιτήσεις, αλλά ήμασταν πιο ανοιχτοί στον πειραματισμό και στην προσαρμογή στις ανάγκες των τελικών χρηστών. Οι οργανισμοί μας ήταν λιγότερο δομημένοι και οι εφαρμογές μας ήταν λιγότερο περίπλοκες από τα συστήματα κληρονομιάς της επιχείρησης, οπότε ήμασταν πολύ πιο ανοιχτοί στην κατασκευή εφαρμογών έναντι αγοράς. Το πιο σημαντικό, προσπαθούσαμε να αναπτύξουμε επιχειρήσεις, οπότε όταν οι χρήστες μας μας έλεγαν ότι κάτι δεν λειτούργησε, συχνότερα απλώς δεν επιλέξαμε να τα ακούσουμε.
Οι δεξιότητές μας και οι ικανότητές μας για καινοτομία έγιναν στρατηγικά σημαντικές. Θα μπορούσατε να συγκεντρώσετε όλα τα χρήματα που θέλετε, αλλά δεν θα μπορούσατε να προσελκύσετε ταλαντούχους προγραμματιστές λογισμικού που θα μπορούσαν να συνεργαστούν με ταχέως μεταβαλλόμενες τεχνολογίες Διαδικτύου εάν επρόκειτο να τους αντιμετωπίζετε ως συνδρομητές κωδικοποιητές που δουλεύουν με υποταγή ακολουθώντας το "spec" Απορρίψαμε τους διαχειριστές έργων που έρχονται με χρονοδιαγράμματα από άκρο σε άκρο που περιγράφουν τι πρέπει να αναπτύξουμε, πότε πρέπει να αποστέλλονται οι εφαρμογές και μερικές φορές ακόμη και πώς να δομήσουμε τον κώδικα. Ήμασταν τρομεροί στο να χτυπήσουμε τα προγράμματα τριών μηνών και έξι μηνών που συνέταξαν οι διαχειριστές του έργου καταρράκτη και ενημερώθηκαν συνεχώς.
Αντ 'αυτού, αρχίσαμε να τους λέμε πώς έπρεπε να κατασκευαστούν οι εφαρμογές Διαδικτύου και παραδώσαμε αποτελέσματα σε ένα πρόγραμμα που καταρτίσαμε επαναληπτικά. Αποδεικνύεται ότι δεν ήμασταν τόσο άσχημα στο να παραδώσουμε ό, τι είπαμε ότι θα κάναμε όταν δεσμευόμαστε σε αυτό σε μικρά διαστήματα μιας εβδομάδας έως τεσσάρων εβδομάδων.
Το 2001, μια ομάδα έμπειρων προγραμματιστών λογισμικού συγκεντρώθηκαν και συνειδητοποίησαν ότι ασκούσαν συλλογικά την ανάπτυξη λογισμικού διαφορετικά από την κλασική μεθοδολογία καταρράκτη. Και δεν ήταν όλοι στις νεοσύστατες επιχειρήσεις. Αυτή η ομάδα, η οποία περιελάμβανε φωτιστικά τεχνολογίας Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber και Jeff Sutherland, ήρθε με το Agile Manifesto που τεκμηριώνει τις κοινές πεποιθήσεις τους για το πώς πρέπει να λειτουργεί μια σύγχρονη διαδικασία ανάπτυξης λογισμικού. Τόνισαν τη συνεργασία σχετικά με την τεκμηρίωση, την αυτοοργάνωση παρά τις άκαμπτες πρακτικές διαχείρισης και την ικανότητα να διαχειρίζεσαι σε συνεχείς αλλαγές αντί να κλειδώνεις σε μια αυστηρή διαδικασία ανάπτυξης καταρράκτη.
Από αυτές τις αρχές γεννήθηκε η ευέλικτη μεθοδολογία για την ανάπτυξη λογισμικού.
Οι ρόλοι στην ευέλικτη μεθοδολογία
Μια ευέλικτη διαδικασία ανάπτυξης λογισμικού ξεκινά πάντα καθορίζοντας τους χρήστες και τεκμηριώνοντας μια δήλωση οράματος σχετικά με ένα εύρος προβλημάτων, ευκαιριών και αξιών που πρέπει να αντιμετωπιστούν. Ο ιδιοκτήτης του προϊόντος αποτυπώνει αυτό το όραμα και συνεργάζεται με μια διεπιστημονική ομάδα (ή ομάδες) για την υλοποίηση αυτού του οράματος. Εδώ είναι οι ρόλοι σε αυτήν τη διαδικασία.
Χρήστης
Οι ευέλικτες διαδικασίες ξεκινούν πάντα με γνώμονα τον χρήστη ή τον πελάτη. Σήμερα, τα ορίζουμε συχνά με προσωπικότητες χρήστη για να δείξουμε διαφορετικούς ρόλους σε μια ροή εργασίας που υποστηρίζει το λογισμικό ή διαφορετικούς τύπους αναγκών και συμπεριφορών πελατών.
Ιδιοκτήτης προιόντος
Η ίδια η ευέλικτη διαδικασία ανάπτυξης ξεκινά με κάποιον που απαιτείται να είναι η φωνή του πελάτη, συμπεριλαμβανομένων τυχόν εσωτερικών ενδιαφερομένων. Αυτό το άτομο αποστάζει όλες τις ιδέες, τις ιδέες και τα σχόλια για να δημιουργήσει ένα όραμα προϊόντος. Αυτά τα οράματα προϊόντων είναι συχνά σύντομα και απλά, αλλά παρόλα αυτά ζωγραφίζουν μια εικόνα για το ποιος είναι ο πελάτης, ποιες αξίες αντιμετωπίζονται και μια στρατηγική για τον τρόπο αντιμετώπισής τους. Μπορώ να φανταστώ ότι το αρχικό όραμα της Google έμοιαζε σαν "Ας διευκολύνουμε σε οποιονδήποτε έχει πρόσβαση στο Διαδίκτυο να βρει σχετικούς ιστότοπους και ιστοσελίδες με μια απλή διεπαφή που βασίζεται σε λέξεις-κλειδιά και έναν αλγόριθμο που κατατάσσει υψηλότερες αξιόπιστες πηγές στα αποτελέσματα αναζήτησης".
Το ονομάζουμε αυτό το άτομο ιδιοκτήτης προιόντος. Η ευθύνη του είναι να καθορίσει αυτό το όραμα και στη συνέχεια να συνεργαστεί με μια ομάδα ανάπτυξης για να το κάνει πραγματικότητα.
Για να συνεργαστεί με την ομάδα ανάπτυξης, ο ιδιοκτήτης του προϊόντος χωρίζει το όραμα του προϊόντος σε μια σειρά από ιστορίες χρηστών που εξηγούν λεπτομερέστερα ποιος είναι ο χρήστης στόχος, ποιο πρόβλημα επιλύεται γι 'αυτούς, γιατί η λύση είναι σημαντική για αυτούς και ποιοι περιορισμοί και κριτήρια αποδοχής καθορίζουν τη λύση. Αυτές οι ιστορίες χρηστών έχουν προτεραιότητα από τον κάτοχο του προϊόντος, ελέγχονται από την ομάδα για να διασφαλιστεί ότι έχουν κοινή κατανόηση σχετικά με το τι τους ζητείται.
Ομάδα ανάπτυξης λογισμικού
Ευέλικτα, η ομάδα ανάπτυξης και οι ευθύνες των μελών της διαφέρουν από εκείνες στην παραδοσιακή ανάπτυξη λογισμικού.
Οι ομάδες είναι διεπιστημονικές, αποτελούμενες από μια διαφορετική ομάδα ατόμων με τις δεξιότητες για να ολοκληρώσουν τη δουλειά. Επειδή η εστίαση είναι στην παράδοση λογισμικού εργασίας, η ομάδα πρέπει να ολοκληρώσει εφαρμογές που λειτουργούν από άκρο σε άκρο. Έτσι, η βάση δεδομένων, η επιχειρηματική λογική και το περιβάλλον εργασίας χρήστη του μέρος της εφαρμογής αναπτύσσεται και στη συνέχεια γίνεται επίδειξη - όχι ολόκληρη η εφαρμογή. Για να γίνει αυτό, τα μέλη της ομάδας πρέπει να συνεργαστούν. Συναντιούνται συχνά για να βεβαιωθούν ότι όλοι είναι ευθυγραμμισμένοι με αυτό που χτίζουν, για το ποιος κάνει τι και για τον ακριβώς τρόπο ανάπτυξης του λογισμικού.
Εκτός από τους προγραμματιστές, οι ομάδες ανάπτυξης λογισμικού μπορούν να περιλαμβάνουν μηχανικούς διασφάλισης ποιότητας (QA), άλλους μηχανικούς (όπως για βάσεις δεδομένων και συστήματα back-end), σχεδιαστές και αναλυτές, ανάλογα με τον τύπο του έργου λογισμικού.
Scrum, Kanban και άλλα ευέλικτα πλαίσια
Πολλά ευέλικτα πλαίσια που παρέχουν λεπτομέρειες σχετικά με τις διαδικασίες ανάπτυξης και τις πρακτικές ευέλικτης ανάπτυξης, που ευθυγραμμίζονται με έναν κύκλο ζωής ανάπτυξης λογισμικού.
Το πιο δημοφιλές ευκίνητο πλαίσιο ονομάζεται άρωμα. Επικεντρώνεται σε ρυθμό παράδοσης που ονομάζεται α τρέχω και δομές συσκέψεων που περιλαμβάνουν τα ακόλουθα:
- Σχεδιασμός - όπου προσδιορίζονται οι προτεραιότητες σπριντ
- Δέσμευση - όπου η ομάδα εξετάζει μια λίστα ή καθυστερήσεις ιστοριών χρηστών και αποφασίζει πόση δουλειά μπορεί να γίνει κατά τη διάρκεια του σπριντ
- Καθημερινές συναντήσεις - έτσι ώστε οι ομάδες να μπορούν να κοινοποιούν ενημερώσεις σχετικά με την κατάσταση και τις στρατηγικές ανάπτυξης τους)
Τα Sprints τελειώνουν με μια επίδειξη συνάντησης όπου η λειτουργικότητα εμφανίζεται στον κάτοχο του προϊόντος, ακολουθούμενη από μια αναδρομική συνάντηση όπου η ομάδα συζητά τι πήγε καλά και τι χρειάζεται βελτίωση στη διαδικασία του.
Πολλοί οργανισμοί απασχολούν master scrum ή προπονητές για να βοηθήσουν τις ομάδες να διαχειριστούν τη διαδικασία scrum.
Αν και το scrum κυριαρχεί, υπάρχουν και άλλα ευέλικτα πλαίσια:
- Το Kanban λειτουργεί ως διαδικασία fan-in και fan-out όπου η ομάδα αντλεί ιστορίες χρηστών από έναν πίνακα εισαγωγής και τις διοχετεύει μέσω μιας σταδιακής διαδικασίας ανάπτυξης έως ότου ολοκληρωθούν.
- Ορισμένοι οργανισμοί υιοθετούν μια υβριδική ευέλικτη και καταρράκτη προσέγγιση, χρησιμοποιώντας ευέλικτες διαδικασίες για νέες εφαρμογές και καταρράκτη για παλαιότερες.
- Υπάρχουν επίσης πολλά πλαίσια που επιτρέπουν στους οργανισμούς να κλιμακώσουν την πρακτική σε πολλές ομάδες.
Ενώ τα ευέλικτα πλαίσια καθορίζουν τη διαδικασία και τη συνεργασία, οι πρακτικές ευέλικτης ανάπτυξης είναι συγκεκριμένες για την αντιμετώπιση εργασιών ανάπτυξης λογισμικού που εκτελούνται σε ευθυγράμμιση με ένα ευέλικτο πλαίσιο.
Έτσι, για παράδειγμα:
- Ορισμένες ομάδες υιοθετούν ζεύγη προγραμματισμού, όπου δύο προγραμματιστές κωδικοποιούν μαζί για να προωθήσουν κώδικα υψηλότερης ποιότητας και να επιτρέψουν σε περισσότερους ανώτερους προγραμματιστές να καθοδηγούν νέους.
- Οι πιο προηγμένες ομάδες υιοθετούν δοκιμαστική ανάπτυξη και αυτοματοποίηση για να διασφαλίσουν ότι η υποκείμενη λειτουργικότητα προσφέρει τα αναμενόμενα αποτελέσματα.
- Πολλές ομάδες υιοθετούν επίσης τεχνικά πρότυπα, έτσι ώστε η ερμηνεία του προγραμματιστή για την ιστορία ενός χρήστη να μην οδηγεί μόνο στην επιθυμητή λειτουργικότητα, αλλά επίσης πληροί την ασφάλεια, την ποιότητα κώδικα, τις συμβάσεις ονοματολογίας και άλλα τεχνικά πρότυπα.
