שבועות 3 עד 6: ספרינטים ראשונים וקצב עבודה
מה קורה
הצוות מתחיל לבנות. הספרינט הראשון או השני מספקים תוצרים קטנים יותר, של יסודות. אל תצפו עדיין למוצר עובד. צפו לראות התקדמות שאפשר לבדוק.
תוצרים טיפוסיים של הספרינט הראשון:
- תשתית בסיסית ו-Pipeline לפריסה
- הזדהות והרשאות משתמש בסיסיות
- סכמת מסד הנתונים ושלד ה-API
- מסכי UI ראשונים (עובדים, עוד לא מלוטשים)
קצב העבודה צריך להתייצב כך:
- תכנון ספרינט בתחילת כל מחזור של שבועיים
- ישיבות בוקר יומיות (15 דקות, בכתב או בשיחה)
- נקודת בדיקה באמצע הספרינט, אם צריך
- דמו ורטרוספקטיבה בסוף כל מחזור
התפקיד שלכם
כאן ה-Product Owner שלכם מצדיק את המשכורת. בית התוכנה צריך מכם:
- החלטות תוך 24 עד 48 שעות. לא תוך שבועיים. החלטות הן צוואר הבקבוק של הכול. כשמפתח צריך הבהרה על פיצ׳ר ולא מקבל תשובה עשרה ימים, בזבזתם עשרה ימים מהספרינט שלו.
- בדיקה של תוצרי הספרינט. באמת ללחוץ על כל מה שמוצג בדמו, ולתת משוב ספציפי. "הטופס צריך לבדוק שכתובת המייל תקינה" עוזר. "תעשו את זה יותר אינטואיטיבי" לא עוזר.
- תיעדוף שוטף של ה-Backlog. דרישות חדשות צצות, באגים מתגלים, פיצ׳רים צריכים תיעדוף מחדש. זה נורמלי. התפקיד שלכם הוא לנהל את סדרי העדיפויות, ולא להגדיר הכול מראש.
למה לשים לב
נורה אדומה: אין דמו בסוף כל ספרינט. אם הם לא מראים תוכנה עובדת כל שבועיים, משהו בתהליך שלהם לא עובד.
נורה אדומה: בין הדמואים אתם לא שומעים מהצוות. בית תוכנה טוב מעדכן ביוזמתו, בעיקר כשהוא מגלה חסמים או סיכונים.
נורה ירוקה: הקצב עולה בין הספרינט הראשון לשני. הצוות לומד את הקוד ואת התחום שלכם מהר יותר ממה שציפה.
נורה ירוקה: בית התוכנה מציע לוותר על פיצ׳ר, כי המורכבות שלו לא שווה את זה. הוא בונה את המוצר שלכם, ולא מנפח שעות.
מה צריך להיות אצלכם בסוף שבוע 6
- אב טיפוס עובד, או תוספת פונקציונלית ראשונה (בסביבת Staging)
- לוח זמנים והערכות מעודכנים, לפי הקצב בפועל
- סיכונים או שינויי היקף שזוהו
- החלטות טכניות מתועדות, עם השיקולים שמאחוריהן
שבועות 7 עד 12: קצב מלא ואבן הדרך הראשונה
מה קורה
עד שבוע 7 הצוות צריך להגיע לשיא הקצב. מה שלמדו באפיון כבר מיושם, בסיס הקוד עומד, וקצב העבודה יציב.
צפו לדברים האלה:
- הקצב מתייצב, ואפשר לחזות כמה ייעשה בכל ספרינט
- פחות שאלות הבהרה מבית התוכנה, כי הם כבר מבינים את התחום
- יותר הצעות יזומות מהצוות לפיצ׳רים ולשיפורים
- אבן הדרך הראשונה שאפשר לפרוס: MVP, בטא פנימית או POC
סקירת אבן הדרך
בין שבוע 10 לשבוע 12, קבעו סקירה רשמית של אבן הדרך. זה לא עוד דמו של ספרינט. זו הערכה ברמה העסקית:
- הפרויקט עומד ביעדים ובתקציב המקוריים?
- יש שינויי היקף שצריך להעריך מחדש?
- צריך לשנות את הרכב הצוות (למשל יותר פרונטאנד, פחות בקאנד)?
- מה לוח הזמנים המציאותי לאבן הדרך הבאה?
הסקירה צריכה להרגיש כמו עבודה משותפת, ולא כמו עימות. שני הצדדים מביאים נתונים, מדברים על מה עבד ומה לא, ומסכמים על ההמשך.
למה לשים לב
נורה אדומה: בית התוכנה עוד לא פרס שום דבר שאפשר לבדוק. אחרי 12 שבועות צריכה להיות לכם סביבת Staging עם תוכנה עובדת. לא גמורה, אבל עובדת.
נורה אדומה: הרכב הצוות השתנה בלי שדיברו איתכם. אם המפתח שפגשתם בתהליך המכירה כבר לא בפרויקט, שאלו למה.
נורה ירוקה: בית התוכנה מזהה חוב טכני ומציע תוכנית לטפל בו. הוא בונה לטווח ארוך, ולא רק רץ לדמו הבא.
תקשורת: מה שמכריע הכול
סגרו בשבועיים הראשונים את הערוצים, את תדירות הפגישות ואת מסלולי ההסלמה. כשיש הפרשי שעות, העדיפו עדכונים בכתב, ושמרו את השיחות החיות לתכנון, לדמואים ולהחלטות גדולות. בית התוכנה צריך להתאים את עצמו אליכם. במדריך שלנו להקמת ערוצי התקשורת עם בית תוכנה תמצאו את כל הכלים, את טבלת הפגישות ואת רמות ההסלמה.
מה אפשר להספיק ב-90 יום
Check2Fly, מערכת הגבולות הלאומית של ישראל בתקופת הקורונה, עברה מהפגישה הראשונה לפריסה ארצית תוך 90 יום. התוכנית עברה באותם שלבים שבמדריך הזה, רק דחוסים בגלל מועד יעד של חירום. בשבועיים של ארכיטקטורה מיפינו את אפליקציית הנוסעים, את מערכת המפעילים, את ה-API של המעבדות ואת צינורות הנתונים הממשלתיים. בשמונה שבועות של פיתוח הרצנו ארבעה מסלולי עבודה במקביל, עם אבטחה בכל ספרינט. בשבועיים של פריסה העלינו את המערכת בכל שדות התעופה ומעברי הגבול בבת אחת. רוב הפרויקטים לא צריכים קצב כזה. הם כן צריכים את אותה משמעת: ארכיטקטורה מוגדרת לפני הבנייה, תוכנה עובדת בכל ספרינט ואבן דרך ראשונה ברורה.
בדיקת מצב אחרי 90 יום
בסוף 90 הימים, בדקו את ההתקשרות מול הקריטריונים האלה:
| קריטריון | תקין | סימן אזהרה |
|---|
| יש קוד שאפשר לפרוס ב-Staging? | כן, מכמה ספרינטים | אין פריסה עובדת |
| מגמת הקצב | יציבה או עולה | יורדת או קופצת |
| זמן קבלת החלטות | פחות מ-48 שעות | יותר משבוע |
| יציבות הצוות | אותו צוות ליבה משבוע 2 | כמה החלפות בצוות |
| איכות התקשורת | יזומה ושקופה | רק בתגובה, ומעורפלת |
| ניהול ההיקף | שינויים נדונים ומוערכים מחדש | ההיקף מתרחב בלי שאף אחד רואה |
אם שלושה סעיפים או יותר נופלים בעמודת "סימן אזהרה", הגיע הזמן לשיחה ישירה על מה שצריך להשתנות.
שאלות נפוצות
כמה אנחנו צריכים להיות מעורבים?
תכננו 5 עד 10 שעות בשבוע של ה-Product Owner שלכם ב-90 הימים הראשונים: תכנון ספרינטים, דמואים, סידור ה-Backlog והחלטות שוטפות. אחרי שהצוות מתייצב, זה יורד ל-3 עד 5 שעות. אם אין לכם Product Owner שיכול להתחייב לזה, הפרויקט ייסחף.
ההצעה של בית התוכנה אחרי האפיון שונה ממה שציפינו. זה סימן רע?
להפך. זה אומר שהאפיון עבד. בית התוכנה מבין עכשיו את הבעיה שלכם טוב יותר ממה שתיארתם אותה במסמך הדרישות (RFP). שפטו את ההצעה לגופה. אם השינויים מוצדקים ומוסברים היטב, זה סימן לבית תוכנה חזק.
איך מתמודדים עם מחלוקות מול בית התוכנה בחודשים הראשונים?
מעלים אותן מוקדם וישירות. ב-90 הימים הראשונים נקבעים יחסי העבודה, ותסכול שבולעים רק מצטבר. בית תוכנה טוב שמח לקבל משוב ישיר, כי כך הוא מבין מה אתם מצפים ממנו.
איך נראית תחילת העבודה עם Globalbit?
כל התקשרות אצלנו מתחילה בשלב אפיון מובנה של 2 עד 4 שבועות. מהיום הראשון, ה-Product Owner שלכם עובד מול מנהל פרויקט וראש צוות טכני קבועים, בשם. ישיבות הבוקר מתחילות בשבוע הראשון, ובסוף הספרינט הראשון תראו קוד פרוס בסביבת Staging. אחרי יותר מ-200 פרויקטים, ליטשנו את התהליך הזה כדי לחסום את הכשלים הנפוצים של תחילת הדרך.
רוצים לראות איך זה נראה אצלנו? דברו איתנו.
