דפים

יום שישי, 8 ביולי 2016

Make it Lean – Build Quality In

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

"ניהול רזה" או בשמה הלועזי 'Lean', הינה מתודולוגיה אשר פותחה במקור בשנות ה 40 ע"י חברת טויוטה במטרה לייעל את תהליך הייצור.
Lean אינה מתודולוגיה טרנדית. על אף שעברו מעל 70 שנה, היא ממשיכה להיות אקטואלית ובסיס איתן לתעשיות שונות, ואף למתודולוגיות חדשות (כגון Agile).
(הרחבה בנושא עקרונות המתודולוגיה ניתן למצוא כאן).
מכאן קיימת החשיבות הרבה לדעתי, להכרת הנושא ומשמעויות המימוש שלו.

במאמר זה השתמשתי בתובנות מתוך הספר Implementing Lean Software Development אשר נכתב ע"י Mary & Tom Poppendieck

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

תחנה 1:תפיסת האיכות
נניח כי נוכל להתנתק לרגע מהאילוצים הקיימים בכל פרויקט, ולייצר מוצר ללא תקלות כבר בפעם הראשונה (דבר הנקרא במינוח מקצועי First Time Right). בעולם הדמיוני המופשט הזה, טיפלנו למעשה בצורה הטובה ביותר בנושא האיכות.
במילים אחרות השיטה הטובה ביותר לטיפול בתקלות הינה - לא ליצור אותן מלכתחילה.
כנראה שפרויקט ללא אילוצים יהיה קשה מאד למצוא, אך התובנה הינה מציאותית מאד.
במקרים רבים כאשר מדברים על שיפור האיכות מתמקדים במנגנוני ניטור, זיהוי, והגנה מפני תקלות, וממעטים להתייחס ל"מקור" של הבעיה.
בתפיסת Lean יש להקדים ולהתייחס לאיכות כבר בשלבים הראשונים של תהליך הייצור.
השקעה באיכות כתיבת קוד לדוגמא, או בשלבי design נכונים, היא רווח נקי בכל הקשור להשקעה באיכות. חשוב לזכור כי ככל שנדחה את הטיפול בבעיה לשלבים מאוחרים יותר של תהליך הייצור, כך העלות והזמן אשר נידרש להשקיע בפתרון הבעיה יגדלו במידה רבה. (כגון תיקוני קוד, סבבי בדיקות, בדיקות מאמץ, רגרסיה, וכיו"ב)
בנוסף לכך, בשל שטיפלנו רק בסימפטומים של הבעיה (דהיינו תקלות), הריי שהסבירות שבעיות דומות יתגלו בעתיד נשארה גבוהה.

תחנה 2: תוצר הפיתוח
בתחנה השנייה בתהליך איכות המוצר נמצא גוף הפיתוח.
טיפול באיכות הקוד כפי שציינתי בפתיח מתחיל בראש ובראשונה בתכנון נכון, כתיבת קוד איכותית, וכיוב', אך מעבר לכך קיימים כלים אשר נוכל לשלב אותם בתוך התהליך ואשר יעלו את אמת האיכות של המוצר כבר בשלב זה -
Code Review  הוספת "זוג עיניים" נוסף אשר יעבור על הקוד ויספק הערות בשלב הראשוני, הינו קריטי להצלחה. בין אם אדם זה הוא ראש הצוות, או מתכנת עמית – הערך המוסף של זיהוי תקלות, תשאול מקרי קצה, בקרת איכות הקוד, בשלב כה מוקדם תחזיר את עצמה פי כמה בעתיד
Unit Testing – הגדרת בדיקות המוצר בצורה מוטמעת בתוך הקוד ע"י המפתחים.
סט בדיקות אלו יכולים לתת חיווי ראשוני למפתחים על תקינות ואיכות המוצר שפיתחו עוד לפני שהגיע לשלב הבדיקות. מעבר לכך – ישמש סט בדיקות אלו חלק מהכיסוי האוטומטי (Automatic Testing) של הבדיקות (בהמשך).
אין לי ספק שמרבית קוראי מאמר זה מכירים כלים אלו, ואולי אף השתמשו בהם במקרים כאלו או אחרים.
אז מה החידוש כאן?
הרווח המשמעותי כאן הוא הטמעה של כלים אלו "כחלק מתהליך הייצור" ולא כפעילות מזדמנת. 
פעילות מזדמנת נדחקת במרבית המקרים לפינה בטענות שונות כגון: אם ישאר זמן למפתח, זמינות לראש הצוות, הספק של התכולה, וכיו"ב. פעילות קבועה, מושתתת בתהליך תספק את הרווח אותו אנחנו מחפשים.

תחנה 3: תוצר בדיקות
אחת התפיסות השגויות בכל הקשור לגוף הבדיקות הינה כי "גוף הבדיקות אחראי לאיכות המוצר".
למעשה הדבר הנכון הוא שגוף הפיתוח הוא זה שאחראי לאיכות המוצר, בעוד שייעודו העיקרי של מרבית גופי הבדיקות הינו בקרת איכות (Quality Assurance).
כיצד ניתן לשלב את האיכות בתוך תהליך הבדיקות?
בקרת איכות בשלב הראשוני והמהותי ניתן לממש בעזרת כלי בשם TDR.
בשימוש בכלי זה, אנשי הבדיקות מנתחים את דרישות המוצר, ויוצרים מסמך בדיקות (Test Design Review) אשר מכסה את הדרישות. המסמך מוצג הן לגוף הפיתוח, והן לגוף האחראי לכתיבת הדרישות (Product).
לתהליך זה שני יתרונות עיקריים:
1. היכולת לזהות פערים בדרישות (חוסר בהירות, חוסר הגדרה, וכיו"ב) בשלב מוקדם מאד בתהליך הייצור
2. היכולת להראות למפתחים תמונת מראה של כיסוי הבדיקות בשלב מוקדם, ימקד את המפתחים בפתרון נכון ומלא של הדרישות עוד בשלב הראשוני של עבודתם.
Automatic Testing – בדיקות אוטומטיות.
אין בכוונתי לפרט כאן על היתרונות הברורים של שימוש בבדיקות אוטומטיות. יחד עם זאת על מנת שעבודה עם כלי זה תהיה נכונה, היא דורשת השקעה תמידית הן בהגדלת כיסוי הבדיקות, והן בתחזוקה של הבדיקות הקיימות. תנאי מקדים לכך הינו שלנושא האוטומציה יהיה חלק בדיון הקשור לתהליך הייצור. מספר דוגמאות המחשה –
- בעת פיתוח מוצר (feature) חדש, יש לקחת בחשבון יצירת תשתית אשר תאפשר הרצה בעתיד של אוטומציה. השקעה בתכנון ומימוש של תשתית נכונה בשלב זה ייצר רווח נקי בסיום כתיבת המוצר.
- בעת שינוי מוצר (feature) יש להעלות לדיון את המשמעות של "שבירת" האוטומציה. איזו פגיעה בתשתית בדיקות האוטומטיות צפויה? האם ניתן "להקטין את הנזק?" וכיו"ב

תחנה 4: תהליך הייצור
תהליך הייצור הינו אחד המנועים המרכזיים ל"אכיפת האיכות" במוצר.
כיצד דבר זה בא לידי ביטוי?
שימת דגש לדוגמא של ההנהלה בקידום תכולות, תגרום לכך שנושא האיכות יקבל עדיפות שנייה.
הארגון "ירוץ קדימה" עם תכולות מרובות, אך למעשה ישלם על כך כאשר רמת האיכות לא תאפשר שחרור של הגרסה. דבר זה יגרור במרבית המקרים דחייה של שחרור הגרסה עד אשר המוצר יגיע לרמת איכות מספקת.
כיצד ניתן לשלב את האיכות בתוך תהליך הייצור?
אציין מספר כלים מהותיים בנושא -
High Quality Bar – הגדרת KPI של איכות ברמת Sprint. (לדוגמא - # התקלות המותרות, חומרת התקלות, וכיו"ב) התפיסה כאן היא כי בקרה עקבית בתדירות נכונה בנושא האיכות תגרור רמת איכות גבוהה במוצר הסופי ללא "השקעה נוספת" הנדרשת בסוף תהליך הייצור.
"Stop the line" - מנגנון ה -"עצירת חרום" ברכבת עוצר מידית את נסיעת הרכבת.
באותו אופן נוכל להגדיר מנגנונים הכרחיים בתהליך הייצור אשר אם הם "נשברים", הם מחייבים התנהלות אחרת, עצירה מוחלטת של תהליך הייצור עד להבנת הבעיה, והטיפול/משאבים הנדרשים לטפל בה.
היכן ניתן להגדיר מנגנונים כאלו ברמת החברה – עניין סובייקטיבי.
דוגמא בולטת ואופיינית למרבית החברות הינה "שבירת build" – קוד תקול אשר נכנס לגרסת המוצר ואשר מונע ממנה להיבנות.
במצב זה יש לבצע "עצירת חרום" לזהות את הבעיה, ולהגדיר את הטיפול והאחריות לתיקונה לפני שממשיכים ב"נסיעה".
Frequent Integration - הכוונה כאן הינה קיצור עד כמה שאפשר את משך הזמן שאנחנו עובדים בנפרד מעץ המוצר. לעבודה בנפרד מ"עץ המוצר" יש את היתרונות שלה – היכולת לא להיות מושפע / ולא להשפיע על עץ המוצר עצמו במהלך שינויים. יחד עם זאת ככל שזמן זה יתארך, כך יהפוך ה "חיבור" לעץ המוצר להיות מורכב וידרוש משאבים נוספים (מפתחים, בודקים, זמן, וכיוב')
בתפיסת Lean יש לשים דגש על אינטגרציות תכופות כמה שניתן על מנת לצמצם תופעה זו.

דילמות
כמה צריך להשקיע בנושא האיכות? ב- שלביDesign  נכונים? ב Automation?
השקעה מוגברת מדי של משאבים – תביא במרבית המקרים לצמצום מרחב ההתקדמות של תהליך הייצור, או לחלופין לתהליכי ייצור ארוכים ומורכבים אשר יפגעו ביכולת התמודדות של החברה בשוק. מאידך, השקעה מינימלית מדי – תביא גם היא לאותן תופעות בדיוק, אך מצד שונה. כאשר השוק לא יקבל את המוצר או לחלופין ידרוש תיקונים רבים על המוצר שקנה
התשובה הנכונה לדעתי הינה - על בסיס הצורך, יש לבחון כל מקרה לגופו ברמת ROI. (Return Of Investment). 
אנחנו ראשית צריכים לזהות את הצורך בשיפור איכות, את האזור הנכון אשר ייתן לנו את הרווח המקסימלי בשיפור האיכות בשלב זה, ורק לאחר מכן להגדיר את אופי וכמות המשאבים שנרצה להשקיע. גם כאן בדומה למאמרים קודמים שכתבתי בדבר הטמעת שיטות חדשות – הדרך הנכונה להטמעת נושא האיכות בתהליך הייצור הינה התקדמות בצעדים שקולים, מפוכחים, ויכולת מדידה וניתוח נכון של השפעת הצעדים על התהליך עצמו.


יוגב טל, PMP
Program Manager, Agile/Lean Practitioner
PMI Israel E-Magazine Editor




בחזרה לעמוד הבית - מרעננים את הפיתוח

מאמרים נוספים שיכולים לעניין אותך - 





אין תגובות:

הוסף רשומת תגובה