Agile Vs Waterfall: Ποια είναι η καλύτερη μεθοδολογία για το έργο σας;

agile vs waterfall which is best methodology

βασικές ερωτήσεις συνέντευξης sql και απαντήσεις για τους νεότερους

Μάθετε τα πάντα για τις μεθόδους Agile και Waterfall, Διαφορετικούς τύπους μοντέλων SDLC και τις διαφορές μεταξύ μοντέλων Waterfall vs Agile Development καθώς και δοκιμών:

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

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

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

Τι θα μάθετε:

• Καταρράκτες και ευέλικτες ροές εργασίας
  • Τι είναι ο κύκλος ζωής ανάπτυξης λογισμικού;
  • Τύποι κύκλου ζωής ανάπτυξης λογισμικού
    • # 1) Μοντέλο καταρράκτη
    • # 2) Ευκίνητο μοντέλο
    • # 3) Σπειροειδές μοντέλο
    • # 4) Πρωτότυπο μοντέλο
    • # 5) Μοντέλο V και V
• Μοντέλο καταρράκτη
• Ευέλικτη ροή εργασίας
  • Βασικές ορολογίες που χρησιμοποιούνται στο Agile
  • Βασικοί παράγοντες για την υιοθέτηση ευέλικτης μεθοδολογίας
  • Τύποι ευέλικτων μεθοδολογιών
• Διαφορά μεταξύ μοντέλων καταρράκτη Agile Vs
• Διαφορές μεταξύ ευέλικτης δοκιμής έναντι δοκιμής καταρράκτη
• συμπέρασμα
  • Συνιστώμενη ανάγνωση

Καταρράκτες και ευέλικτες ροές εργασίας

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

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

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

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

(εικόνα πηγή )

Πριν συζητήσουμε τη ροή εργασίας Waterfall και τη ροή εργασίας Agile, ας ρίξουμε μια ματιά στον ορισμό του κύκλου ζωής ανάπτυξης λογισμικού και στις απαιτήσεις του.

Τι είναι ο κύκλος ζωής ανάπτυξης λογισμικού;

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

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

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

(εικόνα πηγή )

Γιατί απαιτείται κύκλος ζωής ανάπτυξης λογισμικού;

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

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

Τύποι κύκλου ζωής ανάπτυξης λογισμικού

Ας δούμε μια σύντομη εισαγωγή στους τύπους SDLC που χρησιμοποιούνται στη διαδικασία ανάπτυξης λογισμικού.

# 1) Μοντέλο καταρράκτη

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

Θα συζητήσουμε περισσότερα για το μοντέλο καταρράκτη σε αυτό το σεμινάριο.

# 2) Ευκίνητο μοντέλο

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

Στις επόμενες ενότητες, μπορούμε να συζητήσουμε περισσότερα σχετικά με τη ροή εργασίας του Agile.

# 3) Σπειροειδές μοντέλο

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

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

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

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

# 4) Πρωτότυπο μοντέλο

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

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

# 5) Μοντέλο V και V

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

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

Τώρα, θα συζητήσουμε λεπτομερώς τους κύκλους ζωής του λογισμικού Waterfall και Agile.

Μοντέλο καταρράκτη

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

(εικόνα πηγή )

Το Waterfall Model περιλαμβάνει τις ακόλουθες φάσεις:

1. Συλλογή απαιτήσεων
2. Μελέτη σκοπιμότητας
3. Σχέδιο
4. Κωδικοποίηση
5. Δοκιμές
6. Συντήρηση

# 1) Ανάλυση απαιτήσεων

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

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

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

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

# 2) Μελέτη σκοπιμότητας

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

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

# 3) Σχεδιασμός συστήματος

Εδώ, ο Project Architect θα προετοιμάσει το σχεδιασμό του συστήματος. Θα καθορίσει το υλικό, τις απαιτήσεις συστήματος και θα σχεδιάσει την αρχιτεκτονική της εφαρμογής. Υπάρχουν 2 μέρη στο σχεδιασμό του συστήματος: σχεδιασμός υψηλού επιπέδου και σχεδιασμός χαμηλού επιπέδου. Στη σχεδίαση υψηλού επιπέδου, σχεδιάζουμε τα διάφορα τμήματα της εφαρμογής. Στη σχεδίαση χαμηλού επιπέδου, γράφουμε τον ψευδοκώδικα.

# 4) Κωδικοποίηση

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

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

# 5) Δοκιμές

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

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

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

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

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

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

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

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

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

# 6) Συντήρηση

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

Σε ποιες περιπτώσεις μπορούμε να επιλέξουμε το μοντέλο καταρράκτη;

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

Πλεονεκτήματα καταρράκτη:

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

Μειονεκτήματα καταρράκτη:

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

Ευέλικτη ροή εργασίας

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

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

(εικόνα πηγή )

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

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

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

Αρχικά, ο κάτοχος του προϊόντος θα προσθέσει όλες τις απαιτήσεις στο καθυστερημένο προϊόν. Το καθυστερημένο προϊόν περιέχει όλες τις ιστορίες χρηστών. Ας πούμε, 100 έως 150 ιστορίες χρηστών σχετίζονται με το πλήρες έργο. Τώρα προσθέστε τις συγκεκριμένες ιστορίες χρηστών στο σπριντ καθυστέρησης που πρέπει να εφαρμοστεί. Στη συνέχεια, όλοι οι προγραμματιστές, QA, BA θα δουλέψουν στα σπριντ. Έτσι λειτουργεί η ροή Agile.

Βασικές ορολογίες που χρησιμοποιούνται στο Agile

Τι είναι η καθυστέρηση σπριντ;

πώς να κάνετε χειροκίνητη δοκιμή μεταξύ προγραμμάτων περιήγησης

Είναι η λίστα των ιστοριών χρηστών που πρέπει να εφαρμόσουμε στην τρέχουσα επανάληψη ή σπριντ.

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

(εικόνα πηγή )

Τι είναι το Sprint;

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

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

Ημερήσια συνάντηση Standup Scrum

Business Analyst, Developer, Tester, the Project Manager είναι μέρος των καθημερινών stand up scrum meeting. Γίνεται καθημερινά. Δεν πρέπει να επεκτείνεται περισσότερο από 15 έως 30 λεπτά.

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

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

Διάγραμμα καύσης

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

(εικόνα πηγή )

Γράφημα Kanban

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

(εικόνα πηγή )

τι μπορεί να ανοίξει ένα αρχείο eps

Προγραμματισμός δραστηριότητας πόκερ

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

Για παράδειγμα , ένα μέλος της ομάδας ιστοριών χρηστών θα δώσει μια εκτίμηση όπως 3, 5, 8, 3, 1, 3. Στη συνέχεια, η ομάδα θα επιλέξει 3 ως εκτίμηση. Η κάρτα δραστηριότητας πόκερ περιέχει 0, 1, 3, 5, 8, 13, 20, 100, διάλειμμα, αμφιβολίες; καρτέλλες. Με βάση αυτήν την ομάδα τα μέλη θα προτείνουν οποιαδήποτε κάρτα εκτίμησης. Έτσι, θα εκτιμήσουμε όλες τις ιστορίες χρηστών που σχετίζονται με το συγκεκριμένο σπριντ.

(εικόνα πηγή )

• 0 αριθμός πόκερ αντιπροσωπεύει: καμία εργασία σε αυτό το αντικείμενο / ιστορία χρήστη
• Οι αριθμοί 1, 3 αντιπροσωπεύουν: η εργασία είναι λιγότερο
• 5, 8 αριθμοί αντιπροσωπεύουν: εργασίες μεσαίου επιπέδου
• Ο αριθμός 13, 20 αντιπροσωπεύει: εργασίες μεγάλου επιπέδου
• 100 αριθμός αντιπροσωπεύει: πολύ μεγάλα καθήκοντα
• Το άπειρο αντιπροσωπεύει: Η εργασία είναι τεράστια, πρέπει να χωριστεί σε πολλές εργασίες και ιστορίες χρηστών
• Το διάλειμμα αντιπροσωπεύει: Χρειάζομαι ένα διάλειμμα
• ; Αντιπροσωπεύει: Αμφιβολίες

Master Scrum

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

Το Scrum master λειτουργεί ως γέφυρα σε όλα τα μέλη της ομάδας για την επίλυση των προκλήσεων και των εξαρτήσεων που συναντά το έργο. Θα παρακολουθεί την πρόοδο του έργου για κάθε σπριντ.

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

Ιδιοκτήτης προιόντος

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

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

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

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

Καθήκοντα

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

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

Καλλωπισμός

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

Επανάληψη

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

Βασικοί παράγοντες για την υιοθέτηση ευέλικτης μεθοδολογίας

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

Τύποι ευέλικτων μεθοδολογιών

• Μεθοδολογία Agile Scrum
• Ανάπτυξη λογισμικού Lean
• Κανμπάν
• Extreme Προγραμματισμός (XP)
• Κρύσταλλο
• Μέθοδος Δυναμικής Ανάπτυξης Συστημάτων (DSDM)
• Ανάπτυξη βάσει λειτουργιών (FDD)

Agile Pros:

• Ένα από τα μεγαλύτερα πλεονεκτήματα του ευέλικτου μοντέλου είναι το μεγάλη προσαρμοστικότητα . Η προσαρμοστικότητα σημαίνει «ανταπόκριση στην αλλαγή». Η Agile είναι πολύ ευέλικτη στην αντιμετώπιση των αλλαγών στις ανάγκες και τις προτεραιότητες των πελατών.
• Επιτρέπει να βελτιώνει συνεχώς και δίνει προτεραιότητα στο συνολικό καθυστερημένο προϊόν χωρίς να επηρεαστεί η τρέχουσα επανάληψη στην οποία η ομάδα επικεντρώνεται στην παράδοση του MVP. Οι αλλαγές μπορούν να προγραμματιστούν για την επόμενη επανάληψη, προσφέροντας έτσι την ευκαιρία να φέρουν τις αλλαγές μόνο μέσα σε λίγες εβδομάδες.
• Η ευέλικτη μεθοδολογία προσφέρει ένα μεγάλο βαθμό δέσμευση ενδιαφερομένων . Ο πελάτης και η ομάδα του έργου συναντιούνται πριν, κατά τη διάρκεια και μετά από κάθε σπριντ. Καθώς ο πελάτης συμμετέχει συνεχώς σε όλο το έργο, υπάρχουν περισσότερες ευκαιρίες για την ομάδα να κατανοήσει με σαφήνεια το όραμα του πελάτη.
• Το λογισμικό εργασίας παραδίδεται νωρίς και συχνά. Αυτό αυξάνει το εμπιστοσύνη των ενδιαφερομένων στην ομάδα και ενθαρρύνει την ομάδα να μείνετε εξαιρετικά αφοσιωμένοι στο έργο.
• Αυτό το μοντέλο δίνει διαφάνεια . Τόσο οι ενδιαφερόμενοι όσο και η ομάδα γνωρίζουν καλά για το τι συμβαίνει. Ο πελάτης μπορεί να δει την εργασία σε εξέλιξη.
• Το σταθερό σπριντ προγράμματος διάρκειας μιας έως τεσσάρων εβδομάδων το επιτρέπει πρόωρη και προβλέψιμη παράδοση . Οι νέες δυνατότητες κυκλοφορούν γρήγορα και συχνά με χρονοδιάγραμμα.
• Ευκίνητος είναι πελατοκεντρική . Δεν παρέχει απλώς τη λειτουργικότητα αλλά εστιάζει επίσης στην παράδοση της δυνατότητας που έχει κάποια αξία στον χρήστη. Κάθε ιστορία χρήστη έχει ένα κριτήριο αποδοχής επικεντρωμένο στην επιχείρηση.
• Πολύτιμος σχόλια πελατών κερδίζεται νωρίς στο έργο και αλλαγές στο προϊόν μπορούν να γίνουν όπως απαιτείται.
• Η εστίαση είναι στην επιχειρηματική αξία . Πρώτα παρέχει αυτό που είναι πιο σημαντικό για τον πελάτη.
• Βελτιώνει την ποιότητα των παραδοτέων . Σε αντίθεση με τον καταρράκτη, οι δοκιμές γίνονται συνεχώς και συχνά σε ένα έργο Agile και αυτό, με τη σειρά του, βοηθά στον εντοπισμό και την επίλυση των προβλημάτων νωρίς.
• Ευκίνητος υποστηρίζει την προσέγγιση TDD (Test Driven Development) που παρέχει αρκετό χρόνο για τη δημιουργία δοκιμών μονάδας για τις λειτουργίες που πρόκειται να κυκλοφορήσουν μέσω του MVP.
• Επίσης, με την παραγωγή συχνές κατασκευές , τυχόν εσφαλμένη ευθυγράμμιση με τις απαιτήσεις των πελατών μπορεί επίσης να εντοπιστεί και να διορθωθεί νωρίς.
• Καθώς παίρνουμε άμεσα σχόλια χρηστών μετά από κάθε κυκλοφορία MVP, το ο κίνδυνος αποτυχίας του έργου είναι χαμηλός, όταν εργάζεστε με ευέλικτο τρόπο.
• Ευκίνητος προωθεί την ομαδική εργασία . Υπάρχει μεγάλη συνεργασία, αλληλεπίδραση, αρμονία και ενθουσιασμός μεταξύ των μελών της ομάδας Agile.
• Οι εκτιμήσεις κόστους και προγράμματος κάθε σπριντ κοινοποιούνται στον πελάτη πριν από την έναρξη του σπριντ. Αυτό βελτιώνει τη λήψη αποφάσεων καθώς ο χρήστης μπορεί να κατανοήσει το κόστος κάθε δυνατότητας και να δώσει προτεραιότητα ανάλογα.
• Σε ένα ευκίνητο έργο, υπάρχει χώρος για συνεχής βελτίωση . Διδάγματα από τα προηγούμενα σπριντ μπορούν να εφαρμοστούν στα επερχόμενα σπριντ.
• Επικεντρώνεται στο συγκεκριμένο έργο σε κάθε στάδιο του έργου.

Ευκίνητα μειονεκτήματα:

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

Διαφορά μεταξύ μοντέλων καταρράκτη Agile Vs

Οι διαφορές μεταξύ των κύκλων ζωής ανάπτυξης λογισμικού Waterfall και Agile αναφέρονται παρακάτω.

Υδατόπτωση	Ευκίνητος
Η διαδικασία αντιμετωπίζεται ως ένα ενιαίο έργο το οποίο χωρίζεται περαιτέρω σε διαφορετικές φάσεις.	Η διαδικασία χωρίζεται σε πολλαπλά έργα και κάθε έργο έχει μια επανάληψη διαφορετικών σταδίων.
Η μεθοδολογία καταρράκτη είναι ένα μοντέλο στο οποίο κάθε στάδιο του κύκλου ζωής του προϊόντος λαμβάνει χώρα σε μια σειρά. Η πρόοδος του έργου ρέει σταδιακά προς τα κάτω μέσω αυτών των φάσεων που μοιάζουν με καταρράκτη.	Η ευέλικτη μεθοδολογία είναι ένα μοντέλο που ακολουθεί μια επαναληπτική προσέγγιση.
Αυτό το μοντέλο πιστεύει σε μια μαζική ολική παράδοση. Το προϊόν παραδίδεται στο τέλος της SDLC.	Αυτό το μοντέλο πιστεύει σε πολλά μικρά κομμάτια παράδοσης σε καθορισμένα χρονικά διαστήματα. Ένα MVP (Ελάχιστο βιώσιμο προϊόν) παραδίδεται στο τέλος κάθε σπριντ.
Είναι μια παραδοσιακή και ντεμοντέ προσέγγιση.	Είναι μια νέα και σύγχρονη προσέγγιση.
Ένας κύκλος και μία κυκλοφορία.	Επαναλαμβανόμενος αριθμός επαναλήψεων και πολλαπλών εκδόσεων.
Χωρίζει τον κύκλο ζωής ανάπτυξης λογισμικού σε διαφορετικές φάσεις.	Χωρίζει τον κύκλο ζωής ανάπτυξης λογισμικού σε σπριντ.
Δομημένο και άκαμπτο μοντέλο. Είναι δύσκολο να αλλάξει η περιγραφή, η προδιαγραφή και ο σχεδιασμός του έργου.	Αυτό το μοντέλο είναι γνωστό για την ευελιξία του. Μπορούμε να κάνουμε αλλαγές σε οποιαδήποτε φάση του έργου ανά πάσα στιγμή.
Μακροπρόθεσμη κλίμακα προγραμματισμού.	Βραχυπρόθεσμη κλίμακα προγραμματισμού.
Υπάρχει μεγάλη απόσταση μεταξύ του πελάτη και του προγραμματιστή.	Υπάρχει μικρή απόσταση μεταξύ του πελάτη και του προγραμματιστή.
Μεγάλος χρόνος μεταξύ προδιαγραφών και υλοποίησης. Ο επιχειρηματικός αναλυτής συλλέγει και προετοιμάζει την απαίτηση πριν από την έναρξη του έργου.	Σύντομος χρόνος μεταξύ προδιαγραφών και υλοποίησης. Ο ιδιοκτήτης του προϊόντος προετοιμάζει τις απαιτήσεις και τις ενημερώσεις για την ομάδα σε κάθε σπριντ.
Χρειάζεται πολύς χρόνος για να ανακαλύψετε προβλήματα.	Τα προβλήματα ανακαλύπτονται γρήγορα.
Υψηλός κίνδυνος προγράμματος.	Χαμηλός κίνδυνος προγράμματος.
Λιγότερη ικανότητα γρήγορης απόκρισης σε αλλαγές.	Υψηλή ικανότητα γρήγορης απόκρισης σε αλλαγές.
Η δοκιμαστική φάση πραγματοποιείται μόνο μετά την ολοκλήρωση της φάσης ανάπτυξης.	Η δοκιμή πραγματοποιείται γενικά παράλληλα με την ανάπτυξη για να διασφαλιστεί η ποιότητα συνεχώς.
Ο πελάτης εμπλέκεται μόνο στη φάση συγκέντρωσης απαιτήσεων και μετά από αυτό δεν υπάρχει συμμετοχή του πελάτη. Έρχεται στην εικόνα μόνο κατά την παράδοση του προϊόντος.	Ο πελάτης συμμετέχει καθ 'όλη τη διάρκεια του έργου και η ανατροφοδότηση λαμβάνεται από τον πελάτη κατά καιρούς για να εξασφαλιστεί η ικανοποίηση των πελατών.
Κατάλληλο για έργα που έχουν σαφώς καθορισμένες απαιτήσεις και εκείνα που δεν αναμένουν αλλαγές.	Κατάλληλο για έργα που πρέπει να εξελιχθούν και για έργα που απαιτούν μεταβαλλόμενες απαιτήσεις.
Αυστηρά διαδοχική διαδικασία.	Η πολύ συνεργατική διαδικασία ανάπτυξης λογισμικού οδηγεί σε καλύτερες ομαδικές προσπάθειες και γρήγορη επίλυση προβλημάτων.
Εμφανίζει μια νοοτροπία έργου.	Εισάγει μια νοοτροπία προϊόντων και έτσι εστιάζει περισσότερο στον πελάτη. Οι απαιτήσεις και οι αλλαγές είναι το μέρος της διαδικασίας
Τυπική και ιεραρχική. Ο διαχειριστής του έργου είναι ο υπεύθυνος λήψης αποφάσεων.	Είναι άτυπο. Όλη η ομάδα είναι υπεύθυνη για τη λήψη αποφάσεων.
Αυτό το μοντέλο προβλέπει ότι δεν θα υπάρξουν αλλαγές στις απαιτήσεις σε όλο το έργο.	Αυτό το μοντέλο βασίζεται στην προσαρμογή και περιλαμβάνει αλλαγές.
Πρέπει να δημιουργήσετε μη αυτόματα έγγραφα για να επαληθεύσετε την κατάσταση της εργασίας και της προόδου του έργου.	Ακολουθεί το γράφημα Kanban και το γράφημα Burn Down για να επαληθεύσετε την πρόοδο του έργου και την κατάσταση εργασίας του ατόμου.

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

Διαφορές μεταξύ ευέλικτης δοκιμής έναντι δοκιμής καταρράκτη

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

συμπέρασμα

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

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

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

Σε ορισμένες περιπτώσεις, επιλέγουμε επίσης άλλες προσεγγίσεις που ονομάζονται Spiral, V και V και Prototype, με βάση τις ανάγκες.

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

Συνιστώμενη ανάγνωση

• Μελέτη περίπτωσης: Πώς να εξαλείψετε τις ατέλειες των καταρρακτών και των ευέλικτων διαδικασιών ανάπτυξης χρησιμοποιώντας ένα υβριδικό μοντέλο
• Τι είναι το μοντέλο SDLC Waterfall;
• Επανεξέταση εργαλείου διαχείρισης δοκιμών Zephyr Enterprise - Πώς να χρησιμοποιήσετε περιουσιακά στοιχεία μοντέλου καταρράκτη στο εργαλείο Agile
• VersionOne Tutorial: All-in-one Agile Project Management Tool Οδηγός
• Jira Portfolio Tutorial: Agile Project Portfolio Management Plug-in για το JIRA (Κριτική)
• Κορυφαία 10 καλύτερα εργαλεία διαχείρισης έργων Agile το 2021
• Τεχνικές εκτίμησης ευκίνητων: μια πραγματική εκτίμηση σε ένα έργο ευκίνητο
• 4 βήματα προς την ανάπτυξη της ευέλικτης νοοτροπίας δοκιμών για επιτυχημένη μετάβαση σε ευέλικτη διαδικασία