Daily Stand Up Meetings

Εισαγωγή

Τα Daily Stand-Up Meetings (DSUM) --επιτρέψτε μου να χρησιμοποιώ τους αγγλικούς όρους- αποτελούν ίσως την πιο εύκολη, φαινομενικά, agile πρακτική. Αν και μπορεί να χαρακτηριστεί παράξενη ή ακόμα και εκκεντρική αποτελεί σημαντικό κομμάτι του συνολικότερου agile planning. Ποιος δε θα απορούσε, σε μία εταιρία που όλες οι συναντήσεις παραδοσιακά γίνονται γύρω από ένα τραπέζι, αν έβλεπε μία ομάδα ανθρώπων να στέκονται όρθιοι καθημερινά – όχι στο διάλειμμά τους - και να συζητάνε για την πρόοδο των εργασιών τους; Ακόμα και οι ίδιοι οι συμμετέχοντες σίγουρα τις πρώτες φορές θα νιώσουν εντελώς αμήχανα. Άλλωστε ποιος είναι ο λόγος να είμαστε όρθιοι; Τι κερδίζουμε; Μια χαρά δεν είναι οι συναντήσεις στο τραπέζι; Συνήθως μιλάνε ένα – δύο άτομα και οι υπόλοιποι περιμένουν να περάσει η ώρα χαζεύοντας το ρολόι στον τοίχο ή εξασκώντας το ταλέντο τους στην αφηρημένη ζωγραφική σε όποια επιφάνεια βρεθεί διαθέσιμη.

Χαρακτηριστικά - Κανόνες

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

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

• • Τι έκανα την ημέρα που τελείωσε;
  • Τι θα κάνω την ημέρα που έρχεται;
  • Τι εμπόδια έχω στο δρόμου μου
• Η διάρκειά τους δεν ξεπερνάει τα δεκαπέντε (15’) λεπτά. ( Τεχνικές λεπτομέρειες και αναλύσεις γίνονται μετά τη συνάντηση με τα μέλη που απαιτούνται )
• Ο χώρος στον οποίο γίνονται συνίσταται να είναι ο χώρος εργασίας και πιο συγκεκριμένα γύρω από τον πίνακα εργασιών της ομάδας (Team Board)
•  Και φυσικά, όλοι οι συμμετέχοντες στέκονται όρθιοι, σχηματίζοντας ένα ημικύκλιο ώστε να μπορούν να κοιτάζονται χωρίς εμπόδια.

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

Από την Ομάδα – Για την Ομάδα

          

Ένα κλασσικό «λάθος» που γίνεται σε τέτοιες συναντήσεις (DSUMs) είναι να θεωρηθούν ότι αποτελούν ένα εναλλακτικό είδος αναφοράς προόδου στον Project / Product Manager ή στον Team Leader.

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

Ποιοι συμμετέχουν

                Η πρακτική εφόσον επιθυμούμε να εφαρμοστεί σωστά, απαιτεί τη συμμετοχή όλων των μελών της ομάδας στα DSUMs (developers, testers, designers, πελάτες ή business analysts, agile coaches κτλ. ). Υπάρχουν δύο διαφορετικές απόψεις για το ποιοι έχουν «δικαίωμα» να μιλάνε σε αυτές τις συναντήσεις.

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

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

Τα οφέλη της πρακτικής

Θεωρώντας ότι τα DSUM αντικαθιστούν οποιαδήποτε άλλη μορφή συναντήσεων που έχουν σκοπό αναφορές προόδου παρουσιάζω ενδεικτικά μερικά από τα οφέλη της πρακτικής:

• Λιγότερος «χαμένος» χρόνος σε παρακολούθηση προόδου εργασιών
• Εργασίες που καθυστερούν εντοπίζονται από όλη την ομάδα άμεσα και καθημερινά
• Τα περισσότερα προβλήματα αναφέρονται καθημερινά και επιλύονται άμεσα.
• Τα μέλη της ομάδας σταδιακά γίνονται ολοένα και πιο ενεργά
• Το status του project καθημερινά κοινοποιείται σε όλα τα μέλη της ομάδας.
• Το κάθε μέλος έχει το δικαίωμα να προγραμματίζει την εργασία του (όχι ο PM) και με αυτόν τον τρόπο θυμούνται πιο εύκολα τι έχουν να κάνουν.

Ένα ... click ... πριν την ολοκλήρωση

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

Ένα έργο, λοιπόν (για να είμαι ακριβής, μία σειρά από έργα), που δεν είναι υπερβολή να το χαρακτηρίσω ισάξιο του TAXIS, είναι η πλήρης, και τονίζω τον όρο πλήρης, μηχανογράφηση του υποθηκοφυλακείου Θεσσαλονίκης και η παροχή υψηλού επιπέδου ηλεκτρονικών υπηρεσιών σε ένα ευρύ φάσμα αποδεκτών. Από το 2004 μέχρι τα τέλη του 2010 έλαβαν χώρα στον παραπάνω φορέα μία σειρά από καινοτόμες προσπάθειες και οι οποίες οδήγησαν στη σημερινή κατάσταση που μπορεί να φαντάζει ξένη στην ελληνική πραγματικότητα. Από τους αμέτρητους φακέλους στις υπερβολικά γεμάτες ντουλάπες, τις ατελείωτες ώρες αναμονής στα γκισέ και τους χώρους αναζήτησης πράξεων, και τους απαράδεκτους χρόνης απόκρισης στις εκδόσεις πιστοποιητικών και εγγραφών φτάσαμε στην ολοκληρωμένη μηχανογράφηση όπου ο καθε ενδιαφερόμενος εξυπηρετείται σε ελάχιστα λεπτά, στην πλήρη ψηφιοποίηση του ιστορικού αρχείου του υποθηκοφυλακείου από τη δεκαετία του '30 μέχρι σήμερα και στην online αναζήτηση πράξεων (μεταγραφές, υποθήκες, κατασχέσεις και αγωγές) από εξουσιοδοτημένους χρήστες (δικηγόροι, δικαστικοί επιμελητές, εφορίες κτλ. )

Κι όμως ένα τέτοιο έργο δεν είναι ακόμα ανακοινώσιμο και ευρέως διαθέσιμο. Η αιτία; Δεν βρίσκονται τα κονδύλια για να καλύψουν την ετήσια δαπάνη για μία αξιοπρεπή τηλεπικοινωνιακή γραμμή που θα είναι ικανή να εξυπηρετήσει τους χιλιάδες δυνητικούς επισκέπτες της μηχανής αναζήτησης του υποθηκοφυλακείου Θεσσαλονίκης. Έτσι ένα τόσο σημαντικό έργο περιορίζεται και βρίσκεται μεταξύ φθοράς και αφθαρσίας επιτρέποντας, δυστυχώς, την πρόσβαση σε περιορισμένο αριθμό χρηστών (μερικές δεκάδες) μέχρι να δοθεί λύσει στο πρόβλημα του τηλεπικοινωνιακού εξοπλισμού. Για το ΣΥΖΕΥΞΙΣ; Ούτε λόγος να γίνεται; Η αίτηση του φορέα σίγουρα βρίσκεται σε κάποιο συρτάρι εδώ και 1 1/2 χρόνο. 

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

Τι περιμένουμε;

Unit Testing με απλά λόγια

Εισαγωγή

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

Τι σημαίνει λοιπόν Unit Testing. Είναι η μέθοδος με την οποία διαπιστώνεται αν οι αυτόνομες μονάδες λογισμικού πληρούν τις τεχνικές και επιχειρησιακές προδιαγραφές που καλούνται να υλοποιήσουν. Με λίγο πιο τεχνικούς όρους είναι τα «σενάρια ελέγχου» που πιστοποιούν ότι όλες οι μέθοδοι μίας κλάσης (άρα και η κλάση) είναι έτοιμες προς ολοκλήρωση με το υπόλοιπο σύστημα.  Πριν αναλυθεί γιατί, πως και πότε πρέπει να αναπτύσσονται τα unit tests, είναι χρήσιμο να αποσαφηνιστούν μερικές έννοιες και να απομυθοποιηθούν καταστάσεις σχετικά με το testing.

Μύθοι και έννοιες

Μία ατέλεια λογισμικού ή αλλιώς ένα σφάλμα, ή αλλιώς ένα bug (δεν έχει σημασία ο όρος) συμβαίνει όταν

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

Είναι αδύνατον να ελεγχθεί πλήρως (100%) ένα σύστημα:

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

To Testing, ειδικότερα το Unit Testing, δεν αποδεικνύει ότι έχουν εξαλειφθεί όλες οι ατέλειες του λογισμικού.

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

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

Η θέση του Unit Testing στα επίπεδα ελέγχου ενός συστήματος.

Όπως φαίνεται στο παρακάτω σχήμα το Unit Testing αποτελεί το πρώτο «ανάχωμα» στη συνεχή μάχη με τις ατέλειες του λογισμικού. Τα Unit Tests γράφονται κατά κανόνα από τους developers που αναπτύσσουν τον αντίστοιχο κώδικα και σε σπάνιες περιπτώσεις από white-box testers.

Η χρονική στιγμή που πρέπει να γράφονται τα unit tests έχει άμεση εξάρτηση με το αν εφαρμόζεται η πρακτική του test-driven development, για την οποία θα αναφερθώ σε μελλοντικό blog. Αν λοιπόν μία ομάδα ανάπτυξης ακολουθεί test-driven development τότε τα tests γράφονται πριν από τον κώδικα, διαφορετικά αναπτύσσονται συνήθως παράλληλα με τον κώδικα ή στο τέλος. Η σύγκριση, ωστόσο, των παραπάνω τεχνικών δεν αποτελεί αντικείμενο του παρόντος Blog. Όποτε λοιπόν έχουμε αμφιβολία για το πώς ο κώδικάς μας συμπεριφέρεται ή όποτε θέλουμε να πιστοποιήσουμε ότι κάνει αυτό που περιμένουμε, γράφουμε ένα unit test. Η αξία των Unit Tests είναι ανεκτίμητη επειδή άπαξ και αυτοματοποιηθούν μπορούμε να τα εκτελούμε κάθε φορά που κάνουμε μία αλλαγή στον κώδικα ώστε να ξέρουμε άμεσα και αξιόπιστα αν έχουμε χαλάσει κάτι που ήδη «έπαιζε σωστά». Ένα Agile project, θα έχει εκατοντάδες, αν όχι χιλιάδες unit tests, τα οποία διατρέχουν όλο το λογισμικό ελέγχοντας ότι αφορά την επιχειρησιακή λογική του (business logic).

Χαρακτηριστικά ενός καλού Unit Test

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

Τα οφέλη της εφαρμογής της πρακτικής του Unit Testing

• Άμεση ανατροφοδότηση (feedback)
  • Μόλις γίνονται αλλαγές στον κώδικα κι ένα unit test «χαλάει» (σταματάει δηλαδή να είναι επιτυχές), ο developer το μαθαίνει αμέσως και όχι μετά από μερικές εβδομάδες, όταν έχει φτάσει η έκδοση στην ομάδα ελέγχου, ομάδα υποστήριξης ή ακόμα χειρότερα στον πελάτη.
• Δραματική μείωση του κόστους ελέγχου μίας έκδοσης
  • Αντί να χρειάζεται να γίνει χειροκίνητος έλεγχος όλων των λειτουργιών κάθε φορά που είναι έτοιμη μία έκδοση, σώζουμε δεκάδες ώρες, αυτοματοποιώντας τουλάχιστον τους ελέγχους για τις «εύκολες» λειτουργίες και αφιερώνουμε τον υπόλοιπο χρόνο στις πιο περίπλοκες.
• Δραματική μείωση του χρόνου αποσφαλμάτωσης
  • Όταν αποτυγχάνει ένα Unit Test ο developer ξέρει ΑΚΡΙΒΩΣ σε ποιο σημείο του κώδικα υπάρχει η ατέλεια, χωρίς να χρειάζεται να διατρέψει εκατοντάδες γραμμές κώδικα αναζητώντας αυτή που το έχει προκαλέσει.
• Αύξηση αξιοπιστίας και άνεση στη διανομή σε ομάδες ελέγχου και υποστήριξης
  • Η ύπαρξη μίας πλειάδας αυτοματοποιημένων ελέγχων παρέχει ένα επίπεδο ασφάλειας σε όλους τους εμπλεκόμενους σε ένα project. Αυτό δε σημαίνει, φυσικά, ότι κάθε έκδοση γίνεται αποδεκτή, μόνο και μόνο επειδή υπάρχουν τα unit tests, αλλά μας «απελευθερώνει» ώστε να αφοσιωθούμε στον λεπτομερή έλεγχο κρίσιμων και περίπλοκων λειτουργιών του λογισμικού.

Continuous Integration – Συνεχής Ολοκλήρωση

Θα μπορούσα να αναφέρω δεκάδες τεχνικούς και επιστημονικούς ορισμούς για τη σημασία της συνεχής ολοκλήρωσης και τη θέση που κατέχει ανάμεσα στις agile πρακτικές. Για παράδειγμα, ένας αρκετά απλουστευμένος όρος, είναι: «Οι ενέργειες που γίνονται από τους developers σε καθημερινά τακτά χρονικά διαστήματα ώστε οι αλλαγές που κάνουν στο λογισμικό να ενοποιούνται / ολοκληρώνονται με το υπόλοιπο λογισμικό αυτοματοποιημένα και γρήγορα». Θεωρώ, ωστόσο, ότι πέρα από τους τεχνικούς όρους, η εφαρμογή μιας τέτοιας πρακτικής από μία ομάδα ανάπτυξης λογισμικού στηρίζεται στην κουλτούρα ότι από την πρώτη (1^η) ημέρα ενός project  / προϊόντος αυτό θεωρείται ένα ζωντανό και παραγωγικό σύστημα το οποίο βρίσκεται σε πλήρη χρήση από τους τελικούς χειριστές. Αντί, δηλαδή να αντιμετωπίζεται η εγκατάσταση του συστήματος ως ένα γεγονός στο μακρινό και αβέβαιο μέλλον, υιοθετείται η αντίληψη ότι είναι ήδη σε παραγωγική λειτουργία και οι συμπεριφορές της ομάδας προσαρμόζονται ανάλογα.

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

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

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

Τι χρειάζεται όμως για να εφαρμοστεί ένα σύστημα συνεχής ολοκλήρωσης; Δεν αρκούν μόνο τα εργαλεία ή μόνο οι άνθρωποι. Είναι από τις agile πρακτικές που και τα δύο πρέπει να δέσουν αρμονικά για το βέλτιστο αποτέλεσμα. Συνοπτικά παρουσιάζονται τα απαραίτητα συστατικά για να «δέσει το γλυκό».

• Ένα Source Code Repository : Ένα κεντρικό σημείο (μία μεγάλη δεξαμενή) στο οποίο τηρείται ο κώδικας μαζί με όλο το ιστορικό του, τις αλλαγές που έχουν γίνει, πότε και από ποιον, και φυσικά ποιο project αφορούν. 
• Μία σωστά ορισμένη διαδικασία check-in (commit) : Είναι η διαδικασία που πρέπει να τηρείται πριν την οριστικοποίηση των αλλαγών από κάθε developer. Ένα τυπικό παράδειγμα φαίνεται στο παρακάτω σχήμα 

• Μία αυτοματοποιημένη διαδικασία build (αυτόματη δημιουργία δηλαδή εκτελέσιμου συστήματος – αυτό που θα πάρουν οι τελικοί χειριστές) : Αποτελεί τη ραχοκοκαλιά της συνεχούς ολοκλήρωσης. Ένα σωστά ορισμένο αυτοματοποιημένο build πρέπει να μεταγλωττίζει τον κώδικα (compile), να εκτελεί όλα τα tests και βασικά να κάνει ότι θα έκανε χειροκίνητα ο αρμόδιος developer για να παράγει το τελικό εκτελέσιμο. Το κλειδί είναι η ελαχιστοποίηση της εμπλοκής του ανθρώπινου παράγοντα. Όσο λιγότερο εμπλέκονται οι άνθρωποι σε αυτή τη διαδικασία τόσο το καλύτερο. Εξίσου σημαντική είναι η ταχύτητα. Δεδομένου ότι το αυτοματοποιημένο build θα «τρέχει» πολλές φορές την ημέρα θα πρέπει να μη διαρκεί πάνω από δέκα (10) λεπτά ή πάνω από πέντε(5) για μικρά projects.

• H προθυμία και η δέσμευση της ομάδας να δουλεύει σε μικρά κομμάτια: Αποτελεί τον πιο κρίσιμο παράγοντα για την επιτυχημένη εφαρμογή της συνεχής ολοκλήρωσης και χωρίς αυτή όλα τα παραπάνω είναι ανούσια. Αυτό σημαίνει με απλά λόγια ότι ο κάθε developer δεν περιμένει να οριστικοποιήσει τις αλλαγές του στο τέλος κάθε ημέρας ή ακόμα χειρότερα στο τέλος της εβδομάδας. Κάθε μικρή, αξιοποιήσιμη και ελεγμένη αλλαγή χρειάζεται να οριστικοποιείται (commit) άμεσα για να απολαμβάνει η ομάδα όλα τα θετικά της συνεχής ολοκλήρωσης.

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

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

Σε επόμενα Blog θα αναφερθώ στις πολλές δυνατότητες επέκτασης της συνεχής ολοκλήρωσης αλλά και σε άλλες agile πρακτικές.

Μια μέρα... στον ΟΠΑΔ...

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

Ο ΟΠΑΔ ανοίγει για το κοινό στις 08:00 π.μ. κι ως σωστός επαγγελματίας είπα να πάω λίγο νωρίτερα για να μην αργήσω στην εργασία μου. Έφτασα εκεί στις 07:40 και ανέβηκα γρήγορα - γρήγορα τα σκαλιά του κτιρίου. "Θα μαι μόνος μου", σκέφτηκα, "άντε άλλοι 2-3 κακόμοιροι που μέσα στη βροχή ξύπνησαν νωρίς"!!! Με το που έφτασα στην αιθουσα συνάντησα ένα αρκετά μεγάλο πλήθος συμπολιτών μου να κοιτάζουν ένα πρόχειρο χαρτί κι άλλον έναν να προσπαθεί να διαβάσει τα ονόματα που ήταν γραμμένα σε αυτό. Για να μην πολυλογώ, τελικά δεν ήμουν από τους πρώτους! Το χαρτί / η λίστα περιλάμβανε τα ονόματα αυτών που είχαν έρθει πρίν από μένα και την ώρα που είχα φτάσει έπαιρναν αριθμό προτεραιότητας. Αφού έκανα το ίδιο - έγραψα το όνομά μου - μετά από 15' πήρα κι εγώ τον αριθμό μου... πενηντα οκτώ (58). Πριν προλάβω να καθήσω σε μία καρέκλα ένας μαινόμενος κύριος άρχισε να τα βάζει με αυτόν που διάβαζε τα ονόματα, ο οποίος ήταν απλός πολίτης. Αφού πέρασαν 10' και λύθηκαν οι όποιος παρεξηγήσεις τα πνεύματα ηρέμησαν. Οι πρώτοι υπάλληλοι εμφανιστηκα και αρχισαν να εξυπηρετούν το κοινό. Σε ένα άλλο γκισέ ο υπολογιστής που συνδέεται με την οθόνη των αριθμών εξυπηρέτησης boot-άρει. Windows 98 βλέπω στην οθόνη και νομίζω ότι έχω γυρίσει καμιά 10άριά χρόνια πίσω!! Μετά από λίγο μήνυμα του CheckDisk!! Βγαίνει ο υπάλληλος από το γραφείο, ξαναμπαίνει.. τα ίδια. Τελικά μετά από 3 επανεκιννήσεις τα νούμερα εμφανίστηκαν. Ουφ... πάει και αυτό...

Τα νούμερα άρχισαν να κυλούν... βασανιστικά αργά... 

08:30πμ: Είμαστε ακόμα στο 13... Αναρωτιέμαι αν τελικά θα προλάβω να εξυπηρετηθώ μέχρι τις 13:30 που λειτουργεί η υπηρεσία. 

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

09:10πμ: Εμφανίζεται ένας μικρο-πωλητής με χαρτομάντηλα. 3 πακέτα - 1 Ευρώ. Πάει σε έναν πάτερ. Τον αγνοεί επιδεικτικά. Ένας άλλος τον ρωτάει :"Πόσα έχεις μέσα? Μου τα δίνεις για 5Ευρώ όλα;", "Έγινε", απαντάει και το deal κλεινει!!

09:30πμ: Μία υπάλληλος από άλλο γραφείο εμφανίζεται και παίρνει μαζί της καμιά 10αριά από τους αναμένοντες για μία συγκεκριμένη διαδικασία. "Όπα, πάνε 10 νουμεράκια μάνι - μάνι", αναθάρρησα.

09:50πμ: Όσοι πρόλαβαν να πάρουν αριθμό προτεραιτότητας πρόλαβαν. Αύριο πάλι!!! Η συσκευή εξαφανίζεται με διακριτικό τρόπο...

09:55πμ: "Ντιν... 58", επιτέλους ήρθε η σειρά μου... πάω με χαρά στο γκισέ, για να εξυπηρετηθώ. Η υπάλληλος μου δίνει 3-4 έντυπα να συμπληρώσω και μου εξηγεί τη διαδικασία. Συνειδητοποιώ ότι δεν θα πάρω το βιβλιάριο σήμερα. Πρέπει να τα πάω σε μία άλλη υπηρεσία και μετά να φέρω πάλι τα συμπληρωμένα, σφραγισμένα , υπογεγραμμένα έντυπα ( άλλη μέρα φυσικά ). Σαστίζω, "πλάκα θα μου κάνουν..", σκέφτομαι. Ώσπου να το καταλάβω, έρχεται ο επόμενος πολίτης και το πρώτο επεισόδιο του παραμυθιού κάπου εδώ τελειώνει!!

10:05μμ: Φτάνω στο αμάξι και ξεκινάω για την εργασία μου προβληματισμένος... παρόλα αυτά όχι εκνευρισμένος (βοήθησε τελικά η απουσία καφέ).

2 1/2 ώρες αναμονή για να πάρω 3 έντυπα σε 2'. Η παραγωγικότητα στο μεγαλείο της!!!

Καλό μας κουράγιο!