Εργασία και εισιτήριο — τι είναι, συστήματα παρακολούθησης και εργασία με εργασίες

Τι είναι η εργασία και το εισιτήριο;

Εργασία (από αγγλ. task) — μονάδα εργασίας καταγεγραμμένη σε σύστημα παρακολούθησης. Περιέχει περιγραφή, προτεραιότητα (Critical, High, Medium, Low), εκτελεστή, προθεσμία και κατάσταση. Στην κινητή ανάπτυξη, μια εργασία μπορεί να είναι “Προσθήκη οθόνης προφίλ με avatar”, “Υλοποίηση σελιδοποίησης ροής” ή “Ενημέρωση έκδοσης targetSdk σε 35”. Κάθε εργασία συνδέεται με ένα έργο, sprint και συγκεκριμένο προγραμματιστή ή ομάδα.

Εισιτήριο (από αγγλ. ticket) — ευρύτερη οντότητα. Ένα εισιτήριο μπορεί να είναι αναφορά σφάλματος (“Η εφαρμογή καταρρέει κατά την περιστροφή οθόνης σε Android 14”), αίτημα λειτουργίας (“Προσθήκη υποστήριξης σκοτεινού θέματος”), αναφορά στην τεχνική υποστήριξη (“Η push ειδοποίηση δεν φτάνει”) ή εργασία από τον διαχειριστή (“Προετοιμασία αναφοράς ποσοστού crash για τον μήνα”). Η διαφορά μεταξύ εργασίας και εισιτηρίου είναι ασαφής: στο Jira και οι δύο έννοιες ενώνονται στο Issue. Κύρια διαφορά: η εργασία είναι πάντα εργασία με εκτελεστή, το εισιτήριο μπορεί να είναι αίτημα χωρίς συγκεκριμένο εκτελεστή μέχρι τη στιγμή του triage.

Στο Scrum και Kanban, οι εργασίες είναι το κύριο στοιχείο του backlog. Κάθε εργασία πρέπει να πληροί το κριτήριο INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Οι ανεξάρτητες εργασίες μπορούν να υλοποιηθούν με οποιαδήποτε σειρά. Εκτιμήσιμες — η ομάδα μπορεί να εκτιμήσει την προσπάθεια. Μικρές — χωράνε σε ένα sprint. Ελέγξιμες — έχουν σαφή κριτήρια αποδοχής. Οι μεγάλες εργασίες (επικές ιστορίες) χωρίζονται σε μικρότερα μέρη έως ότου εκπληρωθούν όλα τα κριτήρια.

Τύποι εργασιών στην κινητή ανάπτυξη

Feature — νέα λειτουργικότητα της εφαρμογής. Παράδειγμα: “Οθόνη εισόδου μέσω βιομετρικών (Face ID / Touch ID)”. Οι Feature εργασίες συνδέονται πάντα με user story και έχουν Κριτήρια Αποδοχής. Εκτίμηση — σε story points (1, 2, 3, 5, 8, 13). Bug — ελάττωμα που βρέθηκε κατά τη διαδικασία ανάπτυξης ή δοκιμής. Η προτεραιότητα ενός bug εισιτηρίου καθορίζεται από το severity (crash → Critical, UI-bug → Medium, τυπογραφικό λάθος → Low). Στην κινητή ανάπτυξη, ποσοστό crash άνω του 0,1% είναι κρίσιμο σφάλμα και απαιτεί άμεση επιδιόρθωση.

Tech Debt / Chore — τεχνικές εργασίες χωρίς ορατό αποτέλεσμα για τον χρήστη: ενημέρωση βιβλιοθηκών (Dependency Bump), αναδιάρθρωση (Μετάβαση από ViewPager σε ViewPager2), ρύθμιση CI/CD, σύνταξη δοκιμών. Οι Tech Debt εργασίες συχνά υποτιμώνται, αν και σύμφωνα με δεδομένα του Stripe 2025, έως και 30% του χρόνου της κινητής ομάδας δαπανάται στη συντήρηση και εξόφληση τεχνικού χρέους. Η αγνόηση του Tech Debt οδηγεί σε αύξηση του αριθμού σφαλμάτων και επιβράδυνση της ανάπτυξης νέων λειτουργιών.

Πρόσθετοι τύποι: Spike (ερευνητική εργασία — μελέτη νέας τεχνολογίας, σύνταξη POC), Task (οποιαδήποτε εργασία που δεν σχετίζεται με κώδικα — τεκμηρίωση, αναθεώρηση σχεδιασμού), Improvement (βελτίωση υπάρχουσας λειτουργικότητας — βελτιστοποίηση χρόνου φόρτωσης οθόνης). Στο Jira, οι τύποι issues διαμορφώνονται ανά έργο. Το τυπικό σύνολο για μια κινητή ομάδα: Story, Bug, Task, Improvement, Epic. Epic — μεγάλο θέμα που ενώνει πολλές ιστορίες. Παράδειγμα: “Ηλεκτρονικό εμπόριο: καλάθι και ολοκλήρωση παραγγελίας”.

Κύκλος ζωής εργασίας: από τη δημιουργία έως το κλείσιμο

Open (To Do) — η εργασία δημιουργήθηκε αλλά δεν ξεκίνησε. Περιέχει περιγραφή, Κριτήρια Αποδοχής, προτεραιότητα. Σε αυτή την κατάσταση, η εργασία πρέπει να περάσει από grooming (αποσαφήνιση και εκτίμηση) πριν μπει στο sprint. In Progress — ο προγραμματιστής ξεκίνησε την εργασία. Στην κινητή ανάπτυξη είναι σημαντικό να συνδέονται τα commits και τα pull requests με την εργασία: στο Jira μέσω Smart Commits (APP-123 #comment επιδιόρθωση σφάλματος), στο GitHub/GitLab μέσω λέξεων-κλειδιών στην περιγραφή PR (Closes APP-123).

In Review — ο κώδικας στάλθηκε για αναθεώρηση. Αυτόματοι έλεγχοι: CI (Gradle build, lint, μοναδιαίες δοκιμές), SonarQube (ποιότητα κώδικα), Danger (changelog, δοκιμές). Ο προγραμματιστής δεν μπορεί να ξεκινήσει την επόμενη εργασία όσο η τρέχουσα είναι σε Review — αυτό αποτρέπει την πολυδιεργασία. QA / Testing — ο δοκιμαστής ελέγχει σε πραγματικές συσκευές (Android — διάφορες εκδόσεις OS και μεγέθη οθόνης, iOS — διάφορα μοντέλα iPhone). Αν βρεθούν σφάλματα, η εργασία επιστρέφει σε In Progress με σχόλιο.

Done (Closed) — η εργασία ολοκληρώθηκε: ο κώδικας συγχωνεύτηκε στο main/master, πέρασε τις δοκιμές, έτοιμος για έκδοση. Ορισμένες ομάδες προσθέτουν την κατάσταση Deployed — η εργασία φτάνει στον χρήστη μόνο μετά τη δημοσίευση του build στα καταστήματα. Είναι σημαντικό να κλείνουν οι εργασίες με σχόλιο για το αποτέλεσμα: ποια έκδοση, ποιο PR, ποιες μετρικές άλλαξαν. Σύμφωνα με δεδομένα του Linear (2025), οι ομάδες που κλείνουν τις εργασίες με περιγραφή αποτελέσματος επιστρέφουν 40% λιγότερο συχνά στις ίδιες εργασίες.

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

Συστήματα παρακολούθησης εργασιών

Jira — βιομηχανικό πρότυπο για ομάδες από 10 άτομα. Υποστηρίζει πίνακες Scrum και Kanban, προηγμένη διαμόρφωση ροής εργασίας, προσαρμοσμένα πεδία, αυτοματοποιήσεις, ενσωμάτωση με Bitbucket/GitHub. Μειονεκτήματα: υπερβολικό για μικρές ομάδες, αργή διεπαφή, περίπλοκη διαμόρφωση. Για κινητά έργα, το Jira διαμορφώνεται με: πρόσθετο Mobile-specific fields (Platform, OS version, Device model), ενσωμάτωση με TestFlight και Firebase Test Lab, αυτοματοποίηση δημιουργίας εκδόσεων. Jira — επιλογή εταιρικών έργων με γραφειοκρατικές διαδικασίες.

Linear — σύγχρονος tracker για ομάδες προϊόντων. Γρήγορη διεπαφή, υποστήριξη πρώτης κατηγορίας για συντομεύσεις πληκτρολογίου, ενσωματωμένο Cycle (ανάλογο sprint), ενσωμάτωση με GitHub και Slack. Πλεονεκτήματα: ταχύτητα δημιουργίας εργασιών μέσω CMD+K, αυτόματη κατανομή σε φάσεις (Triaged → Backlog → Upcoming → Current → Completed), ενσωματωμένη τεκμηρίωση και χάρτες πορείας. Το Linear επιλέγεται από startups και ομάδες προϊόντων που εκτιμούν την ταχύτητα εργασίας. Το 2025, το 40% των νέων κινητών έργων χρησιμοποιεί Linear.

Trello — απλός πίνακας kanban για μικρές ομάδες (2-5 άτομα). Κάρτες με λίστες ελέγχου, ετικέτες, προθεσμίες. Μειονέκτημα: δεν έχει sprints, περιορισμένη ανάλυση, δύσκολη κλιμάκωση. YouGile — το ρωσικό ανάλογο του Trello με πίνακες kanban, συνομιλία και βιντεοκλήσεις. Asana — tracker με εστίαση σε έργα και χρονοδιαγράμματα. Η επιλογή tracker εξαρτάται από το μέγεθος της ομάδας, τον προϋπολογισμό και τις προτιμήσεις: Jira για επιχειρήσεις, Linear για ομάδες προϊόντων, Trello/YouGile για startups. Σημαντικό: το εργαλείο πρέπει να είναι ενιαίο για ολόκληρη την ομάδα — σχεδιαστές, προγραμματιστές, δοκιμαστές, διαχειριστές εργάζονται σε ένα σύστημα.

Βέλτιστες πρακτικές διαχείρισης εργασιών

Γράψτε Κριτήρια Αποδοχής — τα κριτήρια αποδοχής πρέπει να είναι συγκεκριμένα και επαληθεύσιμα. Κακό: “Η οθόνη εισόδου λειτουργεί”. Καλό: “Ο χρήστης εισάγει email και κωδικό, πατά Είσοδος. Αν τα δεδομένα είναι σωστά — μετάβαση στην κύρια οθόνη. Αν είναι λάθος — εμφανίζεται σφάλμα “Λάθος email ή κωδικός””. Τα Κριτήρια Αποδοχής (AC) είναι συμβόλαιο μεταξύ προγραμματιστή, δοκιμαστή και διαχειριστή προϊόντος. Χωρίς AC, η εργασία δεν πληροί τον Definition of Ready (DoR) και δεν πρέπει να μπαίνει στο sprint.

Συνδέστε τα πάντα. Commits, PR, περιπτώσεις δοκιμής, σχέδια σχεδιασμού (Figma), συζητήσεις στο Slack — όλα πρέπει να συνδέονται με την εργασία. Στο Jira αυτό γίνεται μέσω συνδέσμων σε σχόλια, στο Linear — μέσω αυτόματης σύνδεσης PR. Κανόνας ενός κλικ: από την εργασία στον σχεδιασμό/κώδικα/δοκιμές — όχι περισσότερο από ένα κλικ. Ο προγραμματιστής ανοίγει την εργασία και βλέπει αμέσως το σχέδιο στο Figma, τον σύνδεσμο PR και τις περιπτώσεις δοκιμής. Αυτό επιταχύνει την ενσωμάτωση νέων μελών της ομάδας κατά 30% σύμφωνα με δεδομένα του Linear (2025).

Μην δημιουργείτε εργασίες-φαντάσματα. Μια εργασία χωρίς περιγραφή, χωρίς AC και χωρίς προτεραιότητα είναι σκουπίδι. Αν στην καθημερινή standup κανείς δεν θυμάται γιατί δημιουργήθηκε η εργασία — πρέπει να διαγραφεί ή να διευκρινιστεί. Κανόνας 48 ωρών: αν μια εργασία ήταν σε κατάσταση In Progress χωρίς δραστηριότητα για 48 ώρες — ο προγραμματιστής πρέπει να αφήσει σχόλιο για τους λόγους καθυστέρησης. Σύμφωνα με δεδομένα του Jira (2025), το 60% των εργασιών που παραμένουν ανενεργές για περισσότερο από 3 ημέρες τελικά κλείνουν χωρίς εκτέλεση.

Αποσύνθεση εργασιών: επικές ιστορίες, user stories και υποεργασίες

Epic — μεγάλη λειτουργική περιοχή που ενώνει πολλές ιστορίες. Παράδειγμα: “Ενσωμάτωση χρήστη” περιλαμβάνει “Οθόνη υποδοχής”, “Επιλογή ενδιαφερόντων”, “Φόρτωση avatar”, “Ρύθμιση ειδοποιήσεων”. User Story — εργασία από τη σκοπιά του χρήστη. Μορφή: “Ως [ρόλος], θέλω [ενέργεια] για να [αξία]”. Παράδειγμα: “Ως χρήστης, θέλω να συνδέομαι μέσω βιομετρικών για να μην εισάγω κωδικό κάθε φορά”. Το User Story γράφεται από τον διαχειριστή προϊόντος ή τον ιδιοκτήτη προϊόντος.

Υποεργασία (Sub-task) — αποσύνθεση τεχνικής εργασίας εντός Story / Task. Παράδειγμα για Story “Οθόνη προφίλ”: Sub-task 1: Δημιουργία UI οθόνης (XML / SwiftUI), Sub-task 2: Σύνδεση με ViewModel, Sub-task 3: Σύνταξη μοναδιαίων δοκιμών, Sub-task 4: Δοκιμές Snapshot, Sub-task 5: Δοκιμές UI (Espresso / XCUITest). Κανόνας αποσύνθεσης: κάθε υποεργασία ολοκληρώνεται σε 1-2 ημέρες. Αν ο προγραμματιστής εκτιμά την υποεργασία περισσότερο — χωρίζουμε περαιτέρω. Οι υποεργασίες είναι εσωτερική τεχνική της ομάδας, δεν είναι ορατές στο backlog προϊόντος. Το άθροισμα των εκτιμήσεων των υποεργασιών δεν ισούται απαραίτητα με την εκτίμηση της γονικής Story (μέρος της εργασίας — επικοινωνία, αναθεώρηση κώδικα, δοκιμή).

Πυραμίδα αποσύνθεσης: Epic (Τρίμηνο / Εξάμηνο) → Feature / Story (Sprint) → Task (1-3 ημέρες) → Sub-task (Αρκετές ώρες). Τεχνική INVEST βοηθά στον έλεγχο της ποιότητας αποσύνθεσης. Αν η εργασία δεν είναι Independent (εξαρτάται από άλλες) — αυτό είναι σήμα ότι η αποσύνθεση είναι λανθασμένη. Αν η εργασία δεν είναι Small (περισσότερα από 8 story points) — πρέπει να χωριστεί περαιτέρω. Συνηθισμένο μοτίβο: Epic → 5-15 Stories → κάθε Story → 3-8 Sub-task. Η τελική εκτίμηση του epic = άθροισμα εκτιμήσεων Stories, αλλά το πρώτο sprint συνήθως έχει απόκλιση 20-30% στις εκτιμήσεις.

Συνηθισμένα λάθη κατά την εργασία με εργασίες

Λάθος 1: πολύ μεγάλες εργασίες. Μια εργασία 2 εβδομάδων είναι ένα epic που πρέπει να αποσυντεθεί. Οι μεγάλες εργασίες δεν είναι κατάλληλες για καθημερινή παρακολούθηση, μένουν σε In Progress για εβδομάδες. Κανόνας: μέγιστο μέγεθος εργασίας — 2-3 ημέρες εργασίας. Οτιδήποτε μεγαλύτερο — αποσυνθέστε. Παρενέργεια: ο προγραμματιστής αισθάνεται πρόοδο κλείνοντας 2-3 εργασίες την εβδομάδα αντί για μία γιγάντια. Αυτό αυξάνει τα κίνητρα και την προβλεψιμότητα των προθεσμιών.

Λάθος 2: έλλειψη Κριτηρίων Αποδοχής. Ο προγραμματιστής έκανε τη λειτουργία, ο δοκιμαστής έλεγξε — όλα καλά. Διαχειριστής: “Πού είναι το κουμπί επεξεργασίας;” — “Δεν γράφτηκε στην εργασία”. Χωρίς AC κάθε πλευρά κατανοεί την εργασία με τον δικό της τρόπο. Αποτέλεσμα: επανεπεξεργασία, συγκρούσεις, χαμένες προθεσμίες. AC — συμβόλαιο: αν δεν υπάρχουν κριτήρια στην εργασία — δεν είναι έτοιμη για sprint. Στο grooming, πρώτα ελέγχεται η ύπαρξη AC. Αν δεν υπάρχει AC — η εργασία στέλνεται για επεξεργασία στον Product Manager.

Λάθος 3: ξεχνάμε το Tech Debt. Η ομάδα κάνει μόνο Feature εργασίες sprint μετά από sprint. Μετά από έξι μήνες: η μεταγλώττιση διαρκεί 15 λεπτά, το Gradle είναι ξεπερασμένο κατά 3 κύριες εκδόσεις, οι δοκιμές αποτυγχάνουν στο CI λόγω deprecation. Λύση: δεσμεύστε 20% του χρόνου της ομάδας για Tech Debt (πρακτική Google SRE “προϋπολογισμός σφαλμάτων βάσει SLO”). Δημιουργήστε τουλάχιστον μία Tech Debt εργασία για κάθε Feature sprint. Αναλογία: για κάθε 3 Feature εργασίες — 1 Tech Debt ή Bug. Αυτό αποτρέπει τη συσσώρευση τεχνικού χρέους και διατηρεί την ταχύτητα ανάπτυξης.