Μη συμβατικές μεθοδολογίες

Ευέλικτη ανάπτυξη: στοιχεία

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

Ευέλικτη ανάπτυξη: αρχές

1. Η μεγαλύτερή μας προτεραιότητα είναι η ικανοποίηση του πελάτη μέσω της άμεσης και συνεχούς παράδοσης χρήσιμου λογισμικού.
2. Οι αλλαγές στις προδιαγραφές είναι ευπρόσδεκτες, ακόμα και αργά στο στάδιο της ανάπτυξης. Οι ευέλικτες διεργασίες δαμάζουν τις αλλαγές προς όφελος της ανταγωνιστικότητας του πελάτη.
3. Παραδίδουμε λογισμικό τακτικά, σε διαστήματα μερικών εβδομάδων ή μηνών, προτιμώντας τα μικρά διαστήματα.
4. Αυτοί που ασχολούνται με το επιχειρηματικό τμήμα και αυτοί που ασχολούνται με την ανάπτυξη πρέπει να συνεργάζονται καθημερινά σε όλη τη διάρκεια του έργου.
5. Βάση για τα έργα είναι οι άνθρωποι με κίνητρα και το αντίστοιχο ενδιαφέρον. Δώστε τους το περιβάλλον και την υποστήριξη που χρειάζονται και εμπιστευτείτε τους να περατώσουν το έργο.
6. Ο πιο αποδοτικός και αποτελεσματικός τρόπος μεταφοράς πληροφορίας προς την και μέσα στην ομάδα ανάπτυξης είναι η συζήτηση πρόσωπο-με-πρόσωπο.
7. Η κύριος τρόπος μέτρησης της προόδου είναι το λογισμικό που λειτουργεί.
8. Οι εύκαμπτες διεργασίες συμβάλλουν σε μια αειφόρο διεργασία ανάπτυξης. Οι χρηματοδότες, το προσωπικό ανάπτυξης και οι χρήστες θα πρέπει να μπορούν να συνεχίζουν για πάντα με τον ίδιο σταθερό ρυθμό.
9. Συνεχής προσοχή στην τεχνολογική αρτιότητα και το σωστό σχεδιασμό βελτιώνει την ευελιξία.
10. Η απλότητα--η τέχνη της μεγιστοποίησης του ποσού της εργασίας που δεν πραγματοποιείται-- είναι απαραίτητη.
11. Οι καλύτερες αρχιτεκτονικές, απαιτήσεις, και τα καλύτερα σχέδια πηγάζουν από αυτο-οργανωνόμενες ομάδες.
12. Σε τακτά διαστήματα η ομάδα αναλογίζεται πως μπορεί να γίνει πιο αποδοτική. Έτσι συντονίζει και προσαρμόζει ανάλογα τη συμπεριφορά της.

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

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

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

Αξίες του ΑΠ

• Επικοινωνία (έλεγχος, ζεύγη, εκτίμηση κόστους)
• Απλότητα (καλύτερα το απλό σήμερα, και πιθανώς κάποιο πρόσθετο κόστος αύριο, παρά το πρόσθετο κόστος σήμερα για λειτουργικότητα που δε θα απαιτηθεί)
• Ανάδραση (έλεγχοι, γρήγορη παράδοση)
• Θάρρος (για αλλαγή σχεδίου, πέταγμα κώδικα, δοκιμή απλών ιδεών (πχ merge sort μέσω shell script))

Αρχές του ΑΠ

• ´Αμεση ανάδραση
• Υπόθεση της απλότητας
• Επαυξητική αλλαγή (incremental change)
• Ενστέρνιση της αλλαγής
• Ποιοτική εργασία

Ενέργειες του ΑΠ

• Συγγραφή κώδικα
• Έλεγχος
• Ακρόαση
• Σχεδιασμός

Πρακτικές του ΑΠ

Πλάνο της κάθε έκδοσης

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

• το εύρος,
• τις προτεραιότητες,
• τι θα περιέχει η έκδοση,
• ημερομηνίες των εκδόσεων.

Τα στελέχη ανάπτυξης έχουν τον τελικό λόγο για:

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

Μικρές εκδόσεις

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

Μεταφορά (metaphor)

Χρήση μιας μεταφοράς που εκφράζει την αρχιτεκτονική του συστήματος.

Απλό σχέδιο

Το σχέδιο πρέπει να είναι το απλούστερο δυνατό με την προϋπόθεση να:

• Τρέχει όλους τους ελέγχους
• Να μην περιέχει διπλά στοιχεία
• Να εκφράζει κάθε σκοπό που έχει σημασία για τους προγραμματιστές
• Να έχει τις λιγότερες δυνατές κλάσεις και μεθόδους

Έλεγχος

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

Αναπαραγοντοθέτηση (refactoring)

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

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

Ένα ζευγάρι μοιράζεται τον υπολογιστή. Όταν το ένα μέλος πληκτρολογεί, το άλλο ελέγχει:

• Θα δουλέψει το σύνολο της προσέγγισης;
• Υπάρχουν έλεγχοι που δεν έχουν υλοποιηθεί;
• Μήπως μπορεί το σύστημα να απλοποιηθεί;

Τα ζευγάρια αλλάζουν δυναμικά.

Συλλογική ιδιοκτησία (collective ownership)

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

Συνεχής ολοκλήρωση

Τα τμήματα του κώδικα ενώνονται τακτικά μεταξύ τους.

Εβδομάδα 40 ωρών

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

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

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

Πρότυπα κώδικα

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

Σημείωση

Ανάπτυξη λογισμικού στη Microsoft

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

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

• Kent Beck. Extreme Programming Explained: Embrace Change. Addison Wesley Longman, 2000.

• William J. Brown, Raphael C. Malveau, Hays W. McCormick III, and Thomas J. Mowbray. AntiPatterns Refactoring Software, Architectures, and Projects in Crisis. Wiley, 1998.

• Alistair Cockburn. Agile Software Development. Addison-Wesley, 2001.

• Michael A. Cusumano and Richard W. Selby. Microsoft Secrets. The Free Press, 1995.

• Institute of Electrical and Electronics Engineers, Inc., New York, NY, USA. Information Technology—Software Life Cycle Processes—Software Development Acquirer-Supplier Agreement, 1995. EIA/IEEE Interim Standard J-Std-016-1995 (Issued for Trial Use).

• Watts S. Humphrey. Managing the Software Process, pages 411–428. Addison-Wesley, 1989.

• Institute of Electrical and Electronics Engineers, Inc., New York, NY, USA. IEEE Recommended Practice for Software Acquisition (includes IEEE 1062a), 1998. IEEE Standard 1062-1998.

• P. J. Plauger. Programming on Purpose II: Essays on Software People, pages 123–129. Prentice-Hall, 1993.

• M Poppendieck and T. Poppendieck. Lean Software Development. Addison-Wesley, 2003.

• Diomidis Spinellis. Taking common sense to the extreme (http://www.dmst.aueb.gr/dds/pubs/Breview/2000-IEEE-XP/html/review.html). IEEE Software, 17(4):113–114, July/August 2000. Book review: eXtreme Programming Explained: Embrace Change.

• Diomidis Spinellis. Fear of coding, and how to reduce it (http://www.dmst.aueb.gr/dds/pubs/jrnl/2001-05-Computer-Fear-of-Coding/html/foc.html). IEEE Computer, 34(8):98–100, August 2001.

• Laurie Williams and Alistair Cockburn. Agile software development: It's about feedback and change. IEEE Computer, 36(6):39–43, July 2003. Feature issue on Agile Methods.

• Laurie Williams. The XP programmer: The few-minutes programmer. IEEE Software, 20(3):16–20, May/June 2003. Extreme programming theme issue.

Ασκήσεις

1. Θα μπορούσατε να υιοθετήσετε ΑΠ για την υλοποίηση της άσκηση του μαθήματος; Ποιες πρακτικές του ΑΠ δε θα μπορούσαν να εφαρμοστούν;
2. Εντοπίστε και σχολιάστε διαφορές ανάμεσα στον τρόπο που υλοποιείται λογισμικό στη Microsoft και το μοντέλο διεργασίας ανάπτυξης του καταρράκτη.

• Περιεχόμενα

 Τελευταία αλλαγή: Τρίτη, 5 Φεβρουαρίου 2008 9:41 μμ
 Εκτός αν αναφέρεται κάτι διαφορετικό, όλο το πρωτότυπο υλικό της σελίδας αυτής του οποίου δημιουργός είναι ο Διομήδης Σπινέλλης παρέχεται σύμφωνα με τους όρους της άδειας «Creative Commons Attribution-Share Alike 3.0 Greece License».