איך מפרקים פיצ'ר למיקרו-משימות - המדריך המעשי

למה פירוק נכון משנה הכל

יש פיצ'ר שנראה פשוט בפגישה. "נוסיף התראות למשתמש." כולם מנהנים. מוסיפים לתכנון ה-Sprint. שבוע אחר כך, המפתח חוזר עם שאלות שאיש לא חשב עליהן: התראות push או in-app? מה קורה כשהמשתמש לא מחובר? האם ההתראה נשמרת? מי יכול לשלוח אותה? כמה זמן היא תקפה?

הפיצ'ר ה"פשוט" הפך לשלושה סיפורים, חמישה edge cases, ותלות לא מזוהה בשרת ה-notifications שאף אחד לא בדק שהוא מוכן.

זה לא תרחיש נדיר. זה מה שקורה כשפיצ'ר נכנס לפיתוח לפני שפירקו אותו נכון!

מה זו מיקרו-משימה ומה היא לא

מיקרו-משימה היא יחידת עבודה שמפתח יכול להשלים בלי להיתקע ובלי לחכות למישהו אחר. לא ביום, לא בשבוע - ברוב המקרים, בין שעתיים לחצי יום.
מה שהיא לא: פיצ'ר שחולק לחלקים שרירותיים. "חלק ראשון מהמסך" הוא לא מיקרו-משימה. "בניית ה-UI של טופס ההתחברות ללא לוגיקה" - כן.

הבחינה הפשוטה: האם המפתח יכול לסגור את המשימה הזאת בלי לחכות לאף אחד? אם התשובה היא לא, המשימה עדיין לא פורקה מספיק.

התהליך בפועל - שלב אחרי שלב

שלב 1: להבין את הפיצ'ר לפני שמפרקים אותו
לפני שמתחילים לפרק, צריך להבין. מה המשתמש מנסה לעשות? מה קורה כשמשהו נכשל? האם יש תלות במערכת חיצונית?

שאלות שכדאי לשאול בשלב הזה: מי המשתמש של הפיצ'ר הזה? מה ה-Happy Path? מה ה-Edge Cases הצפויים? האם יש תלות ב-API חיצוני, ב-SDK, או בתשתית שצריך לוודא שהיא מוכנה?

בשלב הזה, User Story טוב עוזר מאוד! "כמשתמש שמחובר, אני רוצה לקבל התראה כשמצב ההזמנה שלי משתנה, כדי שלא אצטרך לבדוק ידנית." זו מסגרת. עכשיו אפשר להתחיל לפרק.

שלב 2: לזהות את התלויות לפני שמחלקים
זו הטעות הנפוצה ביותר שאנחנו רואים בשטח: מפרקים פיצ'ר למשימות, מחלקים למפתחים - ואז מגלים באמצע ה-Sprint שמשימה B לא יכולה להתחיל כי משימה A עוד לא הסתיימה.

תלויות לא מזוהות מראש עוצרות ספרינטים. הן לא תמיד ברורות, אבל כמה שאלות עוזרות לחשוף אותן:
האם המשימה הזו צריכה נתונים ממשימה אחרת? האם היא מחכה ל-API שעוד לא מוכן? האם שני מפתחים נוגעים באותו קובץ או אותה רכיב? האם יש תלות בצד הלקוח, למשל החלטת עיצוב שעוד לא אושרה?

כל תלות שמזוהים כאן - הופכת למשימה נפרדת שנכנסת לפני, או לחסימה (Blocker) שמתועדת בגלוי.

שלב 3: לפרק לשכבות
דרך אפקטיבית לפרק פיצ'ר היא לחשוב לפי שכבות. לרוב הפיצ'רים יש שלוש:

Backend / Logic - לוגיקת השרת, ה-API, בסיס הנתונים. "בניית endpoint שמחזיר רשימת התראות למשתמש לפי ID."
Frontend / UI - הממשק שמציג את הנתונים. "בניית קומפוננטת רשימת התראות עם מצב ריק ומצב טעינה."
Integration - החיבור בין השכבות, בדיקות end-to-end, טיפול בשגיאות. "חיבור קומפוננטת ההתראות ל-API, כולל טיפול בשגיאת רשת."
פירוק לפי שכבות מאפשר לשני מפתחים לעבוד במקביל, אחד על Backend ואחד על ה-UI עם mock data ולחבר בסוף.

שלב 4: לכתוב כל משימה כך שמפתח שלא היה בפגישה יבין אותה
משימה טובה כוללת: מה צריך לבנות, מה קריטריון הסיום (Definition of Done), ומה לא כלול בה.

"בניית UI לרשימת התראות" היא לא משימה טובה. "בניית קומפוננטת רשימת התראות ב-React Native עם שלושה מצבים: loading, empty state, ורשימה פעילה. עיצוב לפי Figma frame #42. ללא חיבור ל-API בשלב זה" - זו מיקרו משימה!

הסימן שהפיצ'ר לא פורק מספיק

יש כמה תסמינים שמסגירים פירוק לקוי:

משימה שנמשכת יותר מיומיים ברציפות בלי לסגור. מפתח שמחכה למפתח אחר כדי להמשיך. שאלות שעולות באמצע הפיתוח על דברים שהיו צריכים להיות מוגדרים מראש. משימה ש"כמעט גמורה" נשארת כמעט גמורה לאורך כל ה-Sprint.

כל אחד מהתסמינים האלה מצביע על משימה שנכנסה לפיתוח לפני שהיה ברור מה בדיוק מסמנים כ-Done.

כמה מיקרו-משימות זה יותר מדי?

שאלה שעולה הרבה: האם פירוק יתר יוצר overhead מיותר?

כן, אם מגזימים. משימה של עשרים דקות שמתועדת, מוקצית, מעדכנת סטטוס ונסגרת - עולה יותר ממה שהיא שווה. הכלל שעובד: משימה שקצרה מחצי שעה לא צריכה להיות פריט נפרד במערכת. אפשר לאגד כמה פעולות קטנות למשימה אחת, כל עוד הן שייכות לאותה שכבה ואותו מפתח.

הגודל הנכון הוא כזה שמאפשר לראות התקדמות אמיתית כל יום, בלי לשקוע בניהול המשימות עצמן.

עבודה עם כלים שונים - מה שנשאר קבוע

ב-Bit-Gem אנחנו עובדים עם כלי ניהול משימות שונים בהתאם לדרישת הלקוח. Jira, Monday, Azure DevOps, GoodDay ואחרים. הכלי משתנה, מה שלא משתנה הוא העקרונות: משימה ברת-סגירה, תלויות מזוהות מראש, ו-Definition of Done כתוב.

כלי טוב עם פירוק רע - יוצר Backlog מבולגן.
כלי בינוני עם פירוק טוב - עובד!