Πώς να εφαρμόσετε αποτελεσματικά τα έργα λογισμικού σας

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

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

  1. Η φάση σχεδιασμού: τα πρώτα στάδια καθορισμού του έργου και των στόχων του
  2. Η φάση του scoping: ο χρόνος που οι περισσότεροι άνθρωποι σκέφτονται για το scoping. Εδώ προσπαθείτε να απαριθμήσετε τη δουλειά που πρέπει να γίνει με δεδομένους τους στόχους του έργου και να εκτιμήσετε πόσος χρόνος θα χρειαστεί για να τους κάνετε.
  3. Η φάση εκτέλεσης: όταν εφαρμόζετε πραγματικά το έργο.

Η φάση προγραμματισμού

Ένα από τα πιο σημαντικά πράγματα που πρέπει να κάνετε κατά τη διάρκεια αυτής της περιόδου είναι να ορίσετε πολύ συγκεκριμένους στόχους για το έργο . Για παράδειγμα, αντί να "βελτιώσετε το X ώστε να είναι πιο επεκτάσιμο και με απόδοση", ένας καλύτερος και πιο συγκεκριμένος στόχος μπορεί να είναι η "βελτίωση του Χ προσθέτοντας δοκιμές μονάδας, υποστηρίζοντας 20K ερωτήματα ανά δευτερόλεπτο και μειώνοντας τον περιορισμένο μέσο όρο καθυστέρησης χρήστη σε <= 200ms "

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

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

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

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

Εδώ είναι ένας τρόπος να το σκεφτείτε: σχεδιάστε την επίδραση ενός έργου με την πάροδο του χρόνου, όπου ο άξονας Υ είναι αντίκτυπος και ο άξονας Χ είναι ο χρόνος. Στην αρχή του έργου, ο αντίκτυπος είναι 0% και στο τέλος του έργου, ο αντίκτυπος είναι 100%. Θέλετε να μεγιστοποιήσετε την περιοχή κάτω από την καμπύλη κάνοντας υψηλές εργασίες ROI πρώτα.

Προσπαθήστε να αποφύγετε την επανεγγραφή μεγάλων συστημάτων από το μηδέν όσο το δυνατόν περισσότερο . Όταν κάνουμε μια επανεγγραφή, τείνουμε (1) να υποτιμούμε πόση δουλειά θα ήταν, (2) να μπαίνουμε στον πειρασμό να προσθέσουμε νέες δυνατότητες και βελτιώσεις και (3) να δημιουργήσουμε ένα υπερβολικά περίπλοκο σύστημα επειδή είμαστε πολύ εστιασμένοι σε όλες τις αδυναμίες του το πρώτο σύστημα.

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

Η φάση κάλυψης

  • Μόνο οι μηχανικοί που γράφουν τον κώδικα πρέπει να είναι αυτοί που καλύπτουν τις εργασίες. Όχι οι διευθυντές τους, ούτε ο πρωθυπουργός, ούτε τα βασικά ενδιαφερόμενα μέρη της εταιρείας.
  • Αντισταθείτε στον πειρασμό να υποβαθμιστεί . Να είστε ειλικρινείς σχετικά με το πόσο καιρό θα διαρκέσουν τα καθήκοντα, όχι πόσο καιρό εσείς ή κάποιος άλλος (όπως ο διευθυντής σας ή η ομάδα Go To Market) θέλει να πάρει.
  • Χωρίστε το έργο σε μικρές εργασίες, το καθένα διαρκεί δύο ημέρες ή λιγότερο . Όταν έχετε εργασίες που καλύπτονται από " περίπου 1 εβδομάδα ", συχνά καταλήγουν περισσότερο χρόνο επειδή δεν απαριθμήσατε όλες τις δευτερεύουσες εργασίες που ίσως χρειαστεί να κάνετε.
  • Ορίστε μετρήσιμα ορόσημα για να φτάσετε στον στόχο του έργου. Προγραμματίστε το καθένα με μια συγκεκριμένη ημερομηνία ημερολογίου που αντιπροσωπεύει πότε αναμένετε να επιτευχθεί αυτό το ορόσημο. Στη συνέχεια, δημιουργήστε ένα είδος εξωτερικής λογοδοσίας σε αυτά τα ορόσημα, για παράδειγμα, δεσμεύοντάς τα στον διαχειριστή σας και ρυθμίζοντας ορόσημα checkins.
  • Σκεφτείτε τις εκτιμήσεις χρόνου έργου ως κατανομές πιθανότητας , όχι σενάρια με τις καλύτερες περιπτώσεις. Αντί να πείτε σε κάποιον ότι μια λειτουργία θα ολοκληρωθεί σε 6 εβδομάδες, πείτε του κάτι σαν "υπάρχει πιθανότητα 50% να ολοκληρώσετε τη λειτουργία σε 4 εβδομάδες και 90% πιθανότητα να την ολοκληρώσουμε σε 8 εβδομάδες . Αυτό τείνει να αναγκάσει τους ανθρώπους να είναι πιο ρεαλιστικοί.
  • Προσθέστε buffer για να λάβετε υπόψη: (1) Χρόνος προγραμματισμού! = Ώρα ημερολογίου, λόγω συναντήσεων, συνεντεύξεων και αργιών. Συνήθως πολλαπλασιάζω τον χρόνο dev με 1,5 για να φτάσω στην ώρα ημερολογίου. (2) Χρόνος απροσδόκητων εργασιών έργου, καθώς υπάρχουν πάντα εργασίες που δεν συνειδητοποιήσατε ότι πρέπει να κάνετε μέχρι αργότερα, όπως η αναδιαμόρφωση παλιού κώδικα, ο εντοπισμός σφαλμάτων φαινομενικά ανεξήγητων συμπεριφορών, η προσθήκη δοκιμών. Όσο πιο έμπειροι είστε στο scoping, τόσο μικρότερος θα είναι αυτός ο πολλαπλασιαστής.
  • Χρησιμοποιήστε ιστορικά δεδομένα. Παρακολουθήστε εάν έχετε τείνει να υπερβείτε ή να υπογραμμίζετε έργα στο παρελθόν (οι περισσότεροι τείνουν να υπογραμμίζουν). Προσαρμόστε ανάλογα το πεδίο εφαρμογής σας.
  • Λάβετε υπόψη ότι το 2X του αριθμού των ατόμων δεν σημαίνει 1 / 2X το χρόνο dev , ως αποτέλεσμα των γενικών εξόδων επικοινωνίας, του χρόνου αύξησης κ.λπ.
  • Σκεφτείτε timeboxing αορίστου τμήματα του έργου . Αντί να "βρείτε το καλύτερο πλαίσιο επεξεργασίας ροής για αυτό το σύστημα", το οποίο μπορεί να χρειαστεί μήνες έρευνας και πρωτοτύπων, κάντε timebox για να "βρείτε ένα κατάλληλο πλαίσιο επεξεργασίας ροής σε μια εβδομάδα". Χρησιμοποιήστε την κρίση σας εδώ για να το εξισορροπήσετε από την εμφάνιση μακροπρόθεσμων λειτουργικών γενικών εξόδων.

Η φάση εκτέλεσης

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

Χρησιμοποιήστε ορόσημα για να απαντήσετε "πώς πηγαίνει το έργο;" Ως μηχανικοί, είναι δελεαστικό να απαντήσετε «θα γίνει μέχρι την επόμενη εβδομάδα» ή «μέχρι το τέλος αυτού του μήνα». Αλλά αυτοί οι τύποι ασαφών απαντήσεων τείνουν να δημιουργούν έργα που απέχουν πάντα 2 εβδομάδες από την ολοκλήρωσή τους. Αντ 'αυτού, χρησιμοποιήστε τα ορόσημα (re-scoped) για να δώσετε μια συγκεκριμένη απάντηση με βάση το πόση δουλειά απομένει.

Εάν το έργο γλιστρήσει, βεβαιωθείτε ότι όλοι καταλαβαίνουν γιατί το έργο έχει πέσει. Στη συνέχεια, αναπτύξτε μια ρεαλιστική και αναθεωρημένη έκδοση του σχεδίου έργου . Η διακοπή του έργου ή η περικοπή του είναι μια πιθανή επιλογή που πρέπει να εξεταστεί. Διαβάστε περισσότερα για το The Sunk Cost Fallacy εάν ​​είστε περίεργοι γιατί οι άνθρωποι τείνουν να προκαλούν προκατάληψη κατά της περικοπής ενός έργου στη μέση.

Δίνοντας πίστωση όπου οφείλεται η πίστωση, πολλές πληροφορίες εδώ προέρχονται από συνομιλίες με μηχανικούς και διευθυντές όπως ο Spencer Chan και ο Nikhil Garg, η ανάγνωση βιβλίων όπως το The Effective Engineer του Edmond Lau και η προσωπική κάλυψη πολλών έργων με διαφορετικούς βαθμούς ακρίβειας.

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

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