בהתמקדות בתהליך הפיתוח, הדבר
הראשון שיקפוץ לנו כאשר נחשוב על 'יחידה אחת של מוצר' הוא כמובן התוצר הסופי.
אך הדבר אינו מסתיים רק בזה.
(הערה - מאמר זה מתייחס לעולם התוכנה. מאמר מעודכן ומקיף יותר ניתן למצוא כאן.)
באבני הבסיס של תהליך הפיתוח קיימים מוצרים קטנים וחלקיים יותר אשר גם עליהם ניתן להגדיר 'יחידה אחת של מוצר'. כגון - כתיבת הדרישות, פיתוח הדרישות, בדיקת הדרישות, והעלאת הדרישות המוגמרות לאוויר.
בראייה רחבה של הגרסה אין מחלוקת שקיצור זמן Lead time (בכל רמה שהיא) תוך שמירה על רמת האיכות, יקצר את לוחות הזמנים של זמן התהליך כולו, ויאפשר חסכון בעלויות, כמו גם הוצאה לשוק מהירה יותר (Time To Market)
אז איך
עושים את זה ?
1. מציאת זמן ה Lead time
טעות נפוצה בחישוב זמן זה היא תחילת המדידה בנקודה בה החל הפיתוח,
וסיום המדידה בנקודה בה הסתיימו הבדיקות. נקודות אלו הן מצומצמות מדי
ואינן כוללות את הזמן הכולל הנדרש עבור הדרישה.
את המדידה יש להתחיל מרגע שהדרישה אושרה להכנס לגרסה, ולסיים בנקודה
בה הדרישה עלתה לאוויר.
2. צמצום זמן ה Lead time
את צמצום זמן ה Lead time ניתן לבצע בדרכים רבות, אני אזכיר רק חלק מהן,
הפשוטות יותר למימוש.
העלאת רמת האיכות – איכות
נמוכה של תוצר היא המובילה בקטגוריית זמן lead time ארוך.
בחישוב פשוט ניתן לגלות כי הזמן המושקע בכתיבה ולאחר תיקון הקוד הוא
כפול מזה שהיינו כותבים אותו נכון מלכתחילה (הן מצד הפיתוח והן מצד הבדיקות)
כיצד עושים זאת - הגדרת מדיניות שאינה מתפשרת בנושא האיכות, ואכיפתה
ע"י הגדרת זמן design, תהליכי הפקות לקחים, תכנון נכון, וכלי ניתור מתאימים ישפרו רבות תחום זה.
יצירת תוצרים בתדירות גבוהה – לתחום זה שני הבטים עיקריים. האחד – קשור ליעילות התהליך. ככל
שאשחרר תוצרים בתדירות גבוהה יותר, כך אוכל לבדוק אותם מהר יותר ולהחזיר פידבק
מהיר לפיתוח.
אין דין בעיות המתגלות בשלבים מוקדמים כדין אלו המתגלות בשלבים
מאוחרים בתהליך.
השני – קשור ליכולת לשחרר תוצרים בשלב מוקדם בתהליך אשר יכולים לקדם
את ה TTM.
אם ניקח לדוגמא גרסה של חצי שנה, ייתכן שתוך חודש נוכל לשחרר feature לשוק אשר כבר נוכל למכור אותו ללקוחות, מבלי
לחכות חצי שנה עד שהגרסה תסתיים.
כיצד עושים זאת – בעזרת שיטות האג'יליות
עבודה טורית ברמה הצוותית – אחת הפרדיגמות הנפוצות בתחום הפיתוח קשורה ליכולת המפתח לעבוד
ביעילות רבה יותר אם יעבוד במקביל על מספר משימות פיתוח. פרדיגמה זו הופרכה
לחלוטין בשנים האחרונות, אך ננצל אותה להתייחסות לעבודת צוות. בהתייחסנו לפן זה - ככל שנעמיס יותר על צוות הפיתוח, כך ההתקדמות שלו תהיה פחות ממוקדת, הוא
יגיע לפחות תוצרים בפרק זמן נתון, וה lead time יתארך. צמצום מספר המשימות עליהן
עובד הצוות בכל רגע נתון (לרמה המתאימה) יאפשר עבודה יעילה ואפקטיבית הן ברמת
התוצר, הן ברמת האיכות, והן ברמת תדירות הייצור.
גם כאן השיטות
האג'יליות מתאימות מאד.
שורת סיכום
על מנת לסגור מעגל עם הגדרת ה lead time בתחילת המאמר, צמצום הזמן אינו מתייחס רק לשלב הפיתוח. אלא לכל שלב בתהליך.
ניקח לדוגמא את שלב כתיבת הדרישות - כתיבה איכותית, הוצאת תוצרי דרישות בתדירות גבוהה, ועבודה טורית יספקו גם הם תמורה נאה לקיצור זמן ה lead time.
יוגב טל, PMP
בחזרה לעמוד הבית - מרעננים
את הפיתוח
אין תגובות:
הוסף רשומת תגובה