Ανάπτυξή feature λίγο πριν το release

[PC_MAGAS]

Παίδες σας έχεi τύχει ποτέ να αναπτύσετε κώδικα κυριολεκτικά τελευταία στιγμη πριν το release. Εννοώ ότι η εφαρμογή να σκάει και να μην παίζει όπως πρέπει σε πολλαπλά σημεία 1 μέρα πριν το release. Εαν ναι σας συμβαίνει συχνά και τι κάνετε προκειμένου να μην επαναλαμβάνετε σε περίπτωση που είστε team leader/manager;

Επεξ/σία 3 Οκτωβρίου 2017 από PC_MAGAS

[tsofras]

Unit testing με όσο το μεγαλύτερο code coverage γίνεται και γενικά σουίτες με τεστς αυτόματα που τρέχουν το βράδυ σε nightly builds.

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

[Alithinos]

Πιστεύω πως κανείς δε μπορεί να κάνει μια απόλυτα σωστή εκτίμηση για την ολοκλήρωση, αλλά η ακρίβεια της εκτίμησης είναι ανάλογη της εμπειρίας.Δεν είμαι μάνατζερ, παρά μόνο έχω ασχοληθεί με κάποια προσωπικά πρότζεκτ, μόνος. Αυτο που έχω διαπιστώσει είναι πως δε μπορώ να κάνω καμία εκτίμηση για τον απαιτούμενο χρόνο ολοκλήρωσης, αν δεν έχω φτιάξει ξανά στο παρελθόν ένα συγκεκριμένο χαρακτηριστικό. Σπας το πρότζεκτ σε μέρη, και κανείς έναν υπολογισμό για το κάθε μέρος. Αν όμως δεν έχεις φτιάξει ξανά παρόμοιο μέρος, είσαι στο σκοτάδι. Πχ στο παιχνίδι που φτιάχνω αυτό το καιρό, έχω ξεχωρίσει κάποια συστήματα τύπου player inventory, combat system, quest system, κτλπ. Συνειδητοποίησα πως κάποια συστήματα μου πήραν λιγότερο απ ότι περίμενα, και άλλα περισσότερο. Με διαφορά περισσότερο εκτός βγήκα στον υπολογισμό του ψευδο-ΑΙ που θα χρησιμοποιούν διάφοροι χαρακτήρες. Περίμενα πως θα μου πάρει 3-5 ημέρες, και μου έχει πάρει ηδη 2 βδομάδες ο σχεδιασμός και η συγγραφή κώδικα, και ακόμα δεν έχω ξεκινήσει unit & integration testing. Βγήκα τόσο εκτός πλάνου επειδή δεν είχα φτιάξει παρόμοιο σύστημα στο παρελθόν. Σε άλλα συστήματα έγινε και το αντίθετο όμως, και τα ολοκλήρωσα νωρίτερα απ ότι περίμενα.

 

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

 

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

 

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

 

Απ οτι έχω διαβάσει η συχνότητα και ο βαθμός των κακών εκτιμήσεων υλοποίησης ήταν ο κύριος λόγος που άρχισε ο κόσμος να απομακρύνεται απ το μοντέλο καταρράκτη αναζητώντας εναλλακτικά υποδείγματα.Αυτό μας δηλώνει πως ΔΕΝ μπορεί κανείς να προβλέψει με απόλυτη ακρίβεια. Το iterative development λύνει κάποια προβλήματα του καταρράκτη, αλλά προϋποθέτει συμμετοχή του πελάτη στη διαδικασία ανάπτυξης.

[masteripper]

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

Βασίζεται στην πανάρχαια τεχνική της χρήσης αρνητικής ανάδρασης...μα πολύ αρνητικής

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

Οπότε πολύ απλά όταν φτιάχναμε μια εφαρμογή στην δουλειά ....κάναμε τις αρχικές δοκιμές μεταξύ μας και μετά την περνάγαμε στον "tester"....πάντα αθόρυβα και πάντα για "καλύτερα"....το τηλέφωνο πάντα χτυπούσε για οτι πιο φανταστικό μπορούσαμε και δεν μπορούσαμε να φανταστούμε....το φτιάχναμε και περιμέναμε....μετά απο κανα 1-2 μέρες το πρόγραμμα φτιαχνόταν και πήγαινε τρένο...αν δεν άλλαζε τίποτε ήταν εγγύηση ότι θα ήταν αθάνατο....

[alou]

Λογικά, σε κάποιο σημείο, αυθαίρετα ή με οποιοδήποτε κριτήριο, λες τη μαγική φράση Feature lock και ασχολείσαι μόνο με debug, βελτιώσεις, tests και οτιδήποτε είναι απαραίτητο για το release. Οποιοδήποτε feature έχει προκύψει στο μεσοδιάστημα, μπαίνει σε ένα πλάνο με την προτεραιότητα που του αξίζει για μετά. 

[tsofras]

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

......

 

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

[Alithinos]

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

 

Αν όμως φτάσουμε 1 ημέρα πριν το deadline και η εφαρμογή "δεν παίζει σε πολλά σημεία όπως πρέπει", κάπου δεν κάναμε και κακή εκτίμηση για το χρόνο που θα χρειαστεί για την ολοκλήρωση ?

 

Αυτό είπα και εγώ στο 2. Να διαχωρίσουμε το project σε συστήματα (features, ή modules αν προτιμάς) και να υπολογίσουμε το χρόνο για το καθένα, και στο τέλος να κάνουμε τη πρόσθεση. Άμα έχουμε φτιάξει παρόμοια features στο παρελθόν όμως, μπορούμε να κάνουμε μια εκτίμηση με μεγαλύτερη ακρίβεια. Μου έχει γίνει συνήθεια εμένα τουλάχιστον κάθε καινούριο module κτλπ που φτιάχνω, να γράφω κάπου πόσο χρόνο μου πήρε, ώστε να έχω κάπου συγκεντρωμένες αυτές τις πληροφορίες.

 

Τώρα για bugs κτλπ, ήδη έχουν υπωθεί αρκετά πράγματα στο thread, και έχουν γραφτεί ακόμα περισσότερα σε διάφορα βιβλία και sites. Θα σημειώσω κάτι σε αυτό που ανέφερε ο alou, ότι κάποια στιγμή πρέπει να κάνουμε το feature lock και να πούμε "ως εδώ η προσθήκη νέων στοιχείων" και ύστερα να επικεντρωθούμε σε bug fixing, optimization, λίγο καθάρισμα, και να κάνουμε το gui πιο όμορφο ίσως.. Αν δεν κάνουμε το feature lock, κινδυνεύουμε να πάθουμε και feature creep.

[ZauZ]

Αν η ανάπτυξη είναι σε πολύ βασικό κομμάτι (ή κομμάτια) του κώδικα που θα επηρεάσει ενδεχομένως και σημαντικές λειτουργίες που αποδεδειγμένα λειτουργούν αξιόπιστα τότε θα προσπαθήσω να καθυστερήσω το realease ώστε να γίνει testing ενώ σε αντίθετη περίπτωση θα προσπαθήσω να κάνω τμηματικό release σε ορισμένους μόνο χρήστες.

 

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

[Επισκέπτης]

 Εαν ναι σας συμβαίνει συχνά και τι κάνετε προκειμένου να μην επαναλαμβάνετε σε περίπτωση που είστε team leader/manager;

 

Φροντίζουμε να μην το κωλοβαράμε μέχρι την τελευταία στιγμή.