Πώς μπορεί η Agile IT να μεταμορφώσει τον τομέα της πληροφορικής;

Περιεχόμενο

• Γιατί Agile IT;
• Πώς Αντιμετωπίζει η Μελέτη Μεθοδολογίας τα Προβλήματα του Μοντέλου Καταρράκτη;
• Πώς έχει επηρεάσει η Agile τη βιομηχανία πληροφορικής;
• No Bugs, No Stress - Ο οδηγός σας βήμα προς βήμα για τη δημιουργία λογισμικού που αλλάζει τη ζωή χωρίς να καταστρέφει τη ζωή σας
• Λόγοι BT μετατοπίστηκαν σε ευέλικτες πρακτικές
• Κακή διαχείριση των απαιτήσεων
  
• Κακό σχεδιασμό λογισμικού
• Περιορισμοί ανάπτυξης
• Τι έκανε η BT για να αντιμετωπίσει τα παραπάνω προβλήματα;
• συμπέρασμα

Πηγή: Darkovujic / Dreamstime.com

Πάρε μακριά:

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

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

Γιατί Agile IT;

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

Με απλά λόγια, το μοντέλο καταρράκτη είναι ένα μοντέλο ανάπτυξης λογισμικού όπου η εργασία γίνεται διαδοχικά - μία φάση μετά την άλλη. Υπάρχουν πέντε φάσεις αυτού του μοντέλου: απαιτήσεις, σχεδιασμός, υλοποίηση, επαλήθευση και συντήρηση. Συνήθως, μετά από μια φάση έχει ολοκληρωθεί, είναι δύσκολο, αν όχι αδύνατο, να γίνουν αλλαγές σε μια προηγούμενη φάση. Έτσι, η υπόθεση είναι ότι οι απαιτήσεις είναι λίγο πολύ σταθερές. Η κύρια διαφορά με το μοντέλο Agile είναι στην υπόθεση ότι δεν θα υπάρξουν αλλαγές στις απαιτήσεις. Ο Agilex υποθέτει ότι οι επιχειρηματικές καταστάσεις θα αλλάξουν και οι απαιτήσεις. Έτσι, το λογισμικό παραδίδεται σε μικρότερα κομμάτια πάνω από το ss, ενώ στο μοντέλο του καταρράκτη, η πρώτη παράδοση ή απελευθέρωση γίνεται μετά από πολύ καιρό. (Για περισσότερες πληροφορίες σχετικά με την ανάπτυξη, ανατρέξτε στο θέμα Πώς Apache Spark βοηθά στην ταχεία ανάπτυξη εφαρμογών.)

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

Σε ένα άλλο παράδειγμα, ο Craig Larman, ο συγγραφέας του βιβλίου "Agile and Iterative Development: A Guide's Guide", επεσήμανε πώς ορισμένα έργα που εκτελούνται από το Υπουργείο Άμυνας (DoD) χρησιμοποιώντας το μοντέλο καταρράκτη στις Η.Π.Α. να επιτύχουν τους στόχους τους. Καθ 'όλη τη δεκαετία του 1980 και του 1990, το DoD έπρεπε να χρησιμοποιήσει το μοντέλο καταρράκτη για τα έργα ανάπτυξης λογισμικού σύμφωνα με τα πρότυπα που δημοσιεύθηκαν στο DoD STD 2167. Τα στατιστικά στοιχεία που έδειξαν σοκαριστικά αποκάλυψαν ότι το 75% αυτών των προγραμμάτων λογισμικού δεν χρησιμοποιήθηκαν ποτέ. Μετά από αυτή την έκθεση ξεκίνησε μια ομάδα εργασίας υπό τον Dr. Frederick Brooks, έναν πολύ γνωστό εμπειρογνώμονα στον τομέα της τεχνολογίας λογισμικού. Η ειδική ομάδα εξέθεσε μια έκθεση που σχολίασε ότι "το DoD STD 2167 χρειάζεται επίσης μια ριζική αναμόρφωση για να αντικατοπτρίζει τη σύγχρονη βέλτιστη πρακτική. Η εξέλιξη της ανάπτυξης είναι καλύτερη από τεχνική άποψη, εξοικονομώντας χρόνο και χρήματα. "

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

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

Πώς Αντιμετωπίζει η Μελέτη Μεθοδολογίας τα Προβλήματα του Μοντέλου Καταρράκτη;

Η μεθοδολογία Agile διαφέρει θεμελιωδώς από το μοντέλο του καταρράκτη και αυτό είναι ξεκάθαρο από τις παραδοχές του:

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

Πώς έχει επηρεάσει η Agile τη βιομηχανία πληροφορικής;

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

No Bugs, No Stress - Ο οδηγός σας βήμα προς βήμα για τη δημιουργία λογισμικού που αλλάζει τη ζωή χωρίς να καταστρέφει τη ζωή σας

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

Λόγοι BT μετατοπίστηκαν σε ευέλικτες πρακτικές

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

Κακή διαχείριση των απαιτήσεων

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

Κακό σχεδιασμό λογισμικού

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

Περιορισμοί ανάπτυξης

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

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

Τι έκανε η BT για να αντιμετωπίσει τα παραπάνω προβλήματα;

Η ΒΤ συνειδητοποίησε ότι η ενίσχυση του μοντέλου καταρράκτη δεν ήταν η απάντηση στα προβλήματα. Χρειάστηκε μια νέα προσέγγιση. Έτσι, αποφάσισε να εφαρμόσει την προσέγγιση Agile. Σύμφωνα με τη νέα προσέγγιση, αποφασίστηκαν τα εξής:

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

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

συμπέρασμα

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