Οι προγραμματιστές λατρεύουν να «διορθώνουν» τον κώδικα—Να γιατί αυτό είναι πρόβλημα

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

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

Και εδώ είναι το κόλπο. Γενικά, οι καλοί προγραμματιστές λογισμικού έχουν πολλές ιδέες για βελτιώσεις προϊόντων. "Εντάξει, θα μπορούσαμε να τροποποιήσουμε κάποια πράγματα κατά τη διάρκεια αυτής της λειτουργίας." "Ω, αυτό δεν είναι τόσο σημαντικό, αλλά θα ήταν ωραίο να διορθωθεί αυτό το πράγμα σε αυτήν την πλαϊνή μονάδα". Ωστόσο, είναι σημαντικό να επιτρέψετε στα μέλη της ομάδας σας να έχουν την ευκαιρία να βελτιώσουν τη βάση κώδικα, καθώς βοηθά στη δημιουργία πραγματικών εμπλεκόμενων ομάδων. Ωστόσο, σε αυτό το άρθρο, θα ήθελα να αποκαλύψω τη διαδικασία ανακατασκευής από την οπτική γωνία ενός μάνατζερ. Τα παραπάνω παραδείγματα έχουν ένα πρόβλημα - μπορεί να είναι αδιαφανή για όλη την ομάδα εκτός από τους προγραμματιστές. Ενώ το QA και οι διαχειριστές έχουν το σχέδιό τους να κυκλοφορήσουν κατάλληλο και σταθερό λογισμικό σύμφωνα με το χρονοδιάγραμμα, ορισμένες κρυφές βελτιώσεις μπορεί να δημιουργήσουν απροσδόκητες ανατροπές και νευρικές επαναλήψεις κατά τη διάρκεια της κυκλοφορίας. Ή ακόμη και νέα σφάλματα στην παραγωγή, εάν στο στάδιο της παλινδρόμησης, κάποιες μη τεκμηριωμένες αλλαγές περάσουν απαρατήρητες. Επομένως, οι βελτιώσεις κώδικα είναι απαραίτητες, αλλά θα πρέπει να είναι διαχειρίσιμες.

Πώς να δημιουργήσετε μια διαχειρίσιμη διαδικασία ανακατασκευής στην ομάδα σας

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

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

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

Ας βουτήξουμε σε κάθε θέμα.

Δημιουργία τεχνικού εκκρεμούς χρέους και κανόνα κατανομής πόρων

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

Η καλύτερη εναλλακτική από τη χρήση του "To Do" είναι να δημιουργήσετε μια διαδικασία για τη δημιουργία εργασιών για μελλοντικές αλλαγές. Εάν ο προγραμματιστής βρει κάποιο πιθανό σημείο προβλημάτων ή έχει μια ιδέα για τη βελτίωση της βάσης κωδικών, θα πρέπει να δημιουργήσει ένα αντικείμενο εργασίας στο σύστημα εισιτηρίων (Jira, Azure DevOps ή οποιοδήποτε άλλο σύστημα χρησιμοποιεί η ομάδα). Θα ήταν υπερβολικό να απαιτείται από τους μηχανικούς να παρέχουν μια λεπτομερή περιγραφή της ιδέας τους για κάθε μέλος της ομάδας, αλλά η εξήγηση θα πρέπει να είναι αρκετά σαφής ώστε ο επικεφαλής της ομάδας να κατανοήσει το βασικό σημείο και το εύρος των αλλαγών. Αυτό καλύπτει το πρώτο βήμα - πώς μπορούμε να δημιουργήσουμε μια λίστα πιθανών εργασιών και να παρέχουμε μια περιγραφή υψηλού επιπέδου των μελλοντικών αλλαγών.

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

• Τι κάνουμε; - Μια εξήγηση υψηλού επιπέδου της ιδέας.
• Γιατί το κάνουμε αυτό; - Περιγραφή του τρόπου με τον οποίο αυτές οι αλλαγές θα μπορούσαν να βελτιώσουν την ταχύτητα ανάπτυξης, να μειώσουν τον κίνδυνο αστάθειας που προκαλείται από τον κώδικα σπαγγέτι ή να αυξήσουν την απόδοση του λογισμικού.
• Πόσο σημαντικές είναι αυτές οι αλλαγές για τη μελλοντική ανάπτυξη; - Η προτεραιότητα των αλλαγών. Για παράδειγμα, χωρίς αυτές τις αλλαγές, το κόστος μελλοντικών βελτιώσεων ή επιχειρηματικών λειτουργιών μπορεί να αυξηθεί εκθετικά.
• Τι κινδύνους δημιουργούν αυτές οι αλλαγές; - Μια λίστα λειτουργιών ή λειτουργικών μονάδων που επηρεάζονται για να βοηθήσουν το QA να επαληθεύσει τις αλλαγές.

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

Η σύσταση για τη διαδικασία εκκρεμότητας τεχνολογίας είναι:

1. Σε κάθε επανάληψη, η ομάδα πρέπει να διατηρεί χρόνο για τεχνολογικές βελτιώσεις.

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

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

4. Τα Αντικείμενα Εργασίας θα προγραμματιστούν σε επαναλήψεις Agile σύμφωνα με τις εκτιμήσεις τους.

   
   

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

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

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

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

1. Το ανεκτέλεστο πρόγραμμα περιποίησης θα πρέπει να περιέχει εργασίες με σαφείς και εφικτές απαιτήσεις.
2. Οι εκκρεμότητες περιποίησης θα πρέπει να μοιραστούν με τα μέλη της ομάδας πριν από τη συζήτηση και την εκτίμηση.
3. Όλα τα μέλη της ομάδας πρέπει να είναι προετοιμασμένα και εξοικειωμένα με τις εργασίες πριν από την περιποίηση.
4. Εάν οποιοδήποτε συσσωρευμένο στοιχείο απαιτεί πρόσθετη διερεύνηση ή εκ νέου εφαρμογή, η ανησυχία θα πρέπει να συζητηθεί.
5. Οι απαιτήσεις για προβληματικά εκκρεμή στοιχεία θα πρέπει να οριστικοποιηθούν με βάση τις αποκαλυπτόμενες ιδιαιτερότητες. Όλες οι πιθανές προβληματικές περιοχές πρέπει να τεκμηριώνονται.
6. Κάθε ανεκτέλεστο στοιχείο θα πρέπει να εκτιμάται.

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

Καθιέρωση διαδικασίας σε περίπτωση απροσδόκητων προβλημάτων κατά την επανάληψη

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

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

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

Κριτική της πρόσθετης γραφειοκρατίας και πώς να απαντηθεί σε αυτήν

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

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

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

• Η δημιουργία ενός συστήματος προτύπων στο σύστημα εισιτηρίων μπορεί να είναι χρήσιμη. Επιτρέπει τη γρήγορη προσθήκη εργασιών και τη συμπλήρωση με τις σωστές παραμέτρους και συνδέσμους.
• Είναι υπέροχο να έχετε ορισμένες πολιτικές εισιτηρίων στο εταιρικό wiki, όπως Confluence / Notion / SharePoint ή οποιαδήποτε άλλη πλατφόρμα τεκμηρίωσης ομάδας. Αυτές οι σελίδες μπορούν να παρέχουν καλά παραδείγματα εργασιών που έχουν δημιουργηθεί σωστά. Είναι προς το συμφέρον του επικεφαλής της ομάδας να διατηρεί την τεχνική τεκμηρίωση και τα πρότυπα στίλβωσης για να βοηθά οποιοδήποτε άλλο μέλος της ομάδας να υποβάλλει σαφή και κατανοητά εισιτήρια.
• Στο βασικό επίπεδο, αρκεί να υποχρεωθούν οι μηχανικοί να δημιουργήσουν εργασίες με περιγραφές υψηλού επιπέδου χωρίς εκτενή άρθρα σχετικά με το στρατηγικό όραμα ή τις δυνατότητες των προτάσεών τους. Η περιγραφή θα πρέπει να βοηθά τον κριτικό (συνήθως τον επικεφαλής της ομάδας) να πάρει την κύρια ιδέα των αλλαγών. Αργότερα, ο επικεφαλής της ομάδας μπορεί να επικυρώσει την πρόταση και να τη συμπληρώσει με πρόσθετες λεπτομέρειες σύμφωνα με τη διαδικασία. Αυτό βοηθά επίσης να κατανοήσουμε εάν αυτές οι αλλαγές είναι ακόμη απαραίτητες και παρέχει κάποιο φίλτρο ποιότητας.
• Εάν ο προγραμματιστής έχει χρόνο να εφαρμόσει την πρόταση, η πολιτική κλάδου χαρακτηριστικών μπορεί να είναι πολύ χρήσιμη. Ωστόσο, είναι απαραίτητο να δημιουργήσετε μια εργασία, επειδή είναι χρήσιμο να υπάρχει ένας κανόνας για τη δημιουργία κλάδων χαρακτηριστικών που ονομάζονται ανά εισιτήριο. Ως αποτέλεσμα, όμως, έχουμε έναν ικανοποιημένο μηχανικό, ο οποίος έχει εφαρμόσει κάποιο τμήμα τεχνολογικού χρέους, εισιτηρίου και συνδεδεμένης υλοποίησης που μπορούν να καλυφθούν και να προγραμματιστούν για επαλήθευση σε μια κατάλληλη επανάληψη, χωρίς τον κίνδυνο απροσδόκητης αποσταθεροποίησης.

Όλες αυτές οι αλλαγές είναι εξαιρετικά τεχνικές και η περιγραφή δεν βοηθάει γιατί κανείς δεν θα καταλάβει την ιδέα

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

Απλά γράψε κάτι σαν:

"Η μέθοδος "XXX" καταναλώνει υπερβολική RAM σε κάθε κλήση. Η δημιουργία μιας πρόσθετης κρυφής μνήμης για αυτήν τη μέθοδο συμβάλλει στη μείωση της κατανάλωσης RAM και στην επιτάχυνση όλων των API. Η μέθοδος χρησιμοποιεί δεδομένα που αλλάζουν σπάνια, αρκεί να πέσει η προσωρινή μνήμη κατά την επανεκκίνηση. Οι αλλαγές είναι ασφαλείς, αλλά ενδέχεται να επηρεάσουν τις ακόλουθες λειτουργίες: XXX, XXX, XXX…”.

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

Όλες αυτές οι πολιτικές εμποδίζουν μόνο τους χρήστες να λαμβάνουν νέες βελτιώσεις

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

Χρειαζόμαστε όλη αυτή τη γραφειοκρατία για ένα απλό στυλ κώδικα που δεν θα κάνει ποτέ κακό στο 99,99% των περιπτώσεων;

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

Σύναψη

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

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