הקדמה
לכל שלב בפיתוח תוכנה יש
קריטריוני כניסה ויציאה, כולל בסביבה אג'ילית, גם אם זה לא מסודר ומנוסח במפורש.
קריטריונים אלה עומדים
בפתחו וסופו של כל מעבר בתהליך הפיתוח. למשל התחלת בדיקות ומסירה ללקוח.
קריטריון כניסה משמעותו
שאפשר לקבל את התוצרים של קודמו ולהתחיל לעבוד עליהם, לדוגמה התכנה הגיעה לבשלות
מסוימת אחרי בדיקות היחידה (שהם קריטריון קבלה) ואנחנו יכולים להתחיל לבדוק אותה.
קריטריון יציאה משמעותו
שמבחינת אלו שהמוצר אצלם הוא יכול להמשיך לתחנה הבאה, למשל כל הבדיקות שלנו
הסתיימו.
נקודת היציאה של אחד היא
נקודת הכניסה של השני אמנם, אבל לא בהכרח שקריטריון היציאה של שלב א' זהה
לקריטריון הכניסה של שלב ב'. למשל, שלב ב' הוא הבדיקות אחרי פיתוח ואולי מעבר
לקריטריון היציאה של הפיתוח הוא רוצה גם אישור ממנהלי המעבדות שהן מוכנות לבדיקות.
אבל קריטריון הכניסה של שלב ב' מגורם מסוים, נניח הפיתוח, כדאי שיהיה זהה
לקריטריון היציאה של השלב הקודם. אגב יתכן שדווקא שלב א' יכיל קריטריון יציאה
"קשוח" יותר מקריטריון הכניסה של שלב ב'.
במאמר זה אני רוצה לדבר
על קריטריון היציאה של הגרסה, כלומר הנקודה האחרונה לפני שהמוצר עובר פריסה (deployment) אצל הלקוח או למשל עולה לסטור. אגב ייתכנו פעולות אצל הלקוח גם
אחרי שלב זה כמו בדיקת מערכת לפני מסירה סופית לאחריות הלקוח.
חשוב לציין שקריטריוני
היציאה האג'ילית ללקוח, לפחות בחברות גדולות, אינן שונות מווטרפול או מושפעות
ממתודת הפיתוח.
מדוע יש צורך בקריטריון
היציאה של הגרסה?
יש כמה סיבות, כאלה שהן
מוצהרות וכאלה שהן סמויות.
א. הגלויה
ברורה: לוודא שהמוצר הנו באיכות המספיקה בכדי להעביר אותה ללקוח. מודדים את האיכות
הזו לפי קריטריונים חד משמעיים ככל הניתן שנקבעו מראש, למשל מהירות ההתקנה.
הסמויות הן:
ב. זו נקודה
בזמן שנקבעת בד"כ בתחילת הגרסה ויש לעשות כל מאמץ להגיע לתאריך המקורי
שלה.תכלס זה גם אם לא רשמי אחד מהמדדים של קריטריון היציאה.
ג. כאשר יש
קריטריונים ברורים הפיתוח מתכוונן לפי קריטריונים אלה. למשל אם מותרים לא יותר
מ-10 באגים בחומרה גבוהה (high),
כבר בשלבי הפיתוח המפתחים למשל יודעים שכדאי להם לתקן כמה שיותר באגים בדרגת חומרה
זו אחרת הגרסה לא תצא.
ד. היוריסטיקת העיגון והתיקון. כאשר יש קריטריונים ברורים למשל 90% מסך הבדיקות
צריך לעבור, לא יקרה מצב שבו יכנס מנהל פרויקט לישיבת סיום גרסה ויגיד "נראה
לי ש-60% pass זה סבבה" ואז כל הדיון שיבוא לאחריו יתייחס למספר הראשון
שנזרק - 60.
אחרי שזה נאמר, גרסה
שאינה עומדת במדדים שקבענו אינה בהכרח נעצרת וחוזרת לפיתוח. אפשר וצריך
לדבר על כך, על ההשלכות ללקוח והערך שהוא כן מקבל, ואם אפשר להתייעץ עם הלקוח זה
מצוין ואולי הוא יהיה מוכן לקבל את המוצר בשלב זה.
מקורות המחקר
המחקר שערכתי כלל גם
חומר ממאמרים וספרים ומהרשת, וגם קריטריונים אמתיים של חברות גדולות וידועות וגם
חברות שאינן כאלה.לצערי אינני יכול לפרסם אותם כיוון שזה נושא רגיש ולא ניתן
למציאה ברשת. מן הסתם לא כל חברה מעוניינת שהלקוחות שלה וכמובן המתחרים ידעו מהם
הקריטריונים הללו.
אני יכול לציין שהיו
לנגד עיני קריטריונים של ארבע חברות גדולות (ולפעמים יותר מסט קריטריונים אחד
לחברה), כארבע קטנות ועוד מידע ממקורות כלליים ברשת ובספרים.
ברור לי שזה עקב האכילס
של המאמר, מצד שני גם אם אינכם בטוחים שהתיאור כאן אינו מה שקורה
"בעולם", או שאתם מאמינים אבל כל עוד אתם לא יודעים במי המדובר אין לזה
ערך מבחינתכם, עדיין אני חושב שהקריטריונים עצמם שווים קריאה ושיקול בהקשר של
חברתכם, כי הרי בסופו של דבר לכל חברה כדאי להתחשב במאפיינים הספציפיים שלה.
מהם הקריטריונים
המקובלים בתחום?
אפשר לחלק את
הקריטריונים הללו לארבעה אזורים:
א. כיסוי
ב. תוצאות
ג. ביטחון בגרסה
ד. אינפרה
כל מה שיבוא מעכשיו אינו
- כמובן - תורה מסיני ויש להתאים למערכת ולשאר הנסיבות.
יש לציין
שכל הקריטריונים שאביא להלן מתבססים על איכות התהליך שקדם להם. למשל, אם הבודקים
אינם חזקים (חדשים לדוגמה) ואינם יודעים כיסוי מהו, או תכנון בדיקות נכון,
הקריטריונים של היציאה עשויים להראות ירוקים ויפים, אבל לא הייתי במקרה כזה ממהר
לפתוח את השמפניה.
א. כיסוי
בגדול הכיסוי הוא מה
שתכננו לבדוק לעומת מה שאכן בדקנו.
- הדרישות
החדשות
(הרלוונטיות ללקוח הספציפי הזה לפעמים) כוסו בבדיקות:
ה-KPI הרלוונטי כאן בד"כ הוא: 100%. כלומר 100% מהתכולה החדשה מכוסה בבדיקות. - הרצת
הבדיקות:
כלומר האם הרצנו את כל הבדיקות שתכננו להריץ בתחילת הגרסה.
בד"כ מקובל ש-100% מהתכנון אכן יתבצע. בחברות מסוימות יש הפרדה לבדיקות שחייבות לרוץ כולן וכאלה שחלק מהן, נניח 80%, חייב לרוץ.
יש בבדיקות שמריצים חלוקה לבדיקות פונקציונליות, עומסים, פרוגרסיה ורגרסיה וכד', ואולי שווה לראות מדד של כל סוג בנפרד. אבל ה-KPI הוא מול אגריגציה של כולם. - ביצועים: לא אתייחס לבדיקות של ביצועים כיוון שבכל תעשיה יש קריטריונים אחרים, אבל כדאי שהיה מדד כזה גם כחלק מקריטריוני היציאה של הגרסה.
- מגבלות. בד"כ אין התייחסות ספציפית למגבלות, וזה בסדר אם דנו בפורום המתאים בכל המגבלות והחליטו לצאת בכל מקרה. אני מכיר חברה שאומרת שאסורה מגבלה שהיא בדרגת חומרה קריטית (לפי מדדי הבאגים). אני מניח שזה כיוון שלא רצו לתת פתח למעבר של באגים קריטיים לסטטוס של מגבלה בכדי לעקוף את קריטריון היציאה של הבאגים (שעליו נדבר בהמשך).
- מסמכים: פחות קריטריון יציאה (ללא KPI) ויותר תנאי מעבר: שיש מסמכים כמו help, מדריכים, release notes וכד'.
ב. תוצאות
- אחוז
ההצלחה,
או pass
rate. הכוונה כאן היא לכמה
מהבדיקות שהורצו עברו בהצלחה.
הצלחה = ללא באגים, כולל באגים בדרגת חומרה מינורית. נמצא באג מינורי - הטסט כשל.
ה-KPI כאן תלוי בחברה ויכול לנוע מ-80% ועד ל-97% כשאזורים מסוימים יכולים להיות אפילו מוגדרים ב-100%.
הבעיה כאן היא מצב כזה: יש לנו קריטריון של 95% למשל, ויש לנו 1000 בדיקות. הבדיקות הולידו 60 באגים מינוריים בלבד ואין לנו זמן לתקן. האם סך הבאגים המינוריים שקולים לחומרה של עצירת גרסה? לא בטוח. ואם רק 2 בדיקות נכשלו אבל כישלון חרוץ - כל הבאגים שנמצאו הם שם, וזה בפיצ'ר הכי חשוב ללקוח, עדיין עברנו את המדד אבל לא את זה של הלקוח. - מספר הבאגים לפי
חומרה
(או דחיפות או שקלול שלהם).
מקובל לא לצאת אף פעם עם באגים קריטיים. לגבי השאר תלוי בחברה ובגודל המוצר נניח לפי שורות קוד או ימי אדם. למשל במוצר שכולל 2500 עד 5000 ימי אדם בפיתוח קוד, מותר 20 באגים מג'ורים ו-60 מינוריים.
לא תמיד כמות הבאגים משקפים את איכות המוצר. נניח בכרום יש עשרות אלפי באגים פתוחים, ואמנם זה לא מוצר ללא בעיות - למשל צריכת הסוללה בלפטופ - אבל הוא עדיין המוצר הנפוץ ביותר בתחומו.
לפי חברה מסוימת 90% ממספר תסריטי הבדיקות צריך לעבור ללא באגים מג'וריים ו-80% ללא באגים מינוריים, וזה קריטריון המחליף את השניים למעלה.
יש בזה היגיון כיוון
שמצד שני יכולים להיות כמה באגים מינוריים בפיצ'ר מסוים אפילו תוך כדי יצירת בעיה
בשימוש בו, אבל כל עוד 80% מהפיצ'רים נקיים מבאגים זה נסבל, וכנ"ל לגבי
הבאגים המג'ורים.
בכל מקרה שהוזכר, אמנם
זה לא קריטריון אבל מן הסתם נתון שממילא יסתכלו עליו (אני מקווה) כשיוציאו את
המספרים, רואים אילו פיצ'רים הם עם הבאגים המג'וריים ואילו המינוריים, ואפשר
להחליט אם זה מקובל - האם אלו עם המג'וריים בעלי באג אחד או יותר ואיך זה משפיע על
הפיצ'ר.
ג. ביטחון בגרסה
- בחברה אחת
שאני מכיר מקובל להתייחס להרגשת הבודקים. הרעיון כאן הוא לא אמירות באוויר
כמו "אני מרגיש שהגרסה לא טובה". לדעתי הרעיון הוא למשל מקרה שאמנם
לפי ה"כללים" הגרסה נחשבת לטובה, אבל כיוון שקיבלנו הרבה תיקונים
בשבוע האחרון (שאותם בדקנו אמנם והבדיקות עברו) אני מרגיש שיש להריץ עוד בדיקות
שלא מן המניין*.
יש כאלה שמבקשים מכל הבודקים לתת ציון נניח מ-1 עד 5, ומספר מסוים כבר לא עובר. אבל כדאי שמנהל הבדיקות יעבור על הציונים ויביא טיעון משמעותי כמו שנאמר למעלה. - טרנדים של
באגים. למשל הגרף הידוע של באגים פתוחים מול באגים סגורים. לקראת סוף הגרסה
רצוי שמספר הבאגים הפתוחים יהיה קטן והסגורים גדול (ובד"כ זה הפוך
בתחילת הגרסה).
גם כאן צריך לשים לב להקשר הנתונים. למשל אם בשבועות או בימים האחרונים כמעט ולא בדקו יותר את הגרסה אז כמובן שהטרנד יראה מעט פתיחת באגים, ואם זה לא היה כך אולי היו מתגלים הרבה יותר. - בדיקות קבלה של לקוח,
משחק הקץ או כל בדיקות שמחקות
שימוש של לקוח.
יש כאלה שנותנים מדד מסוים של באגים ספציפית לבדיקות אלה, אחרים סופרים אותם כחלק מהמספר הכללי. חשוב יותר שהפעילות הזו תעשה בסופו-של-דבר מאשר ה-KPI.
ככל שהמוצר חדש יותר או הלקוח חדש, קשה יותר לדמות מה הוא יעשה.
* וראו גם: מחפש צרות - הרגשת בטן - מיכאל שטאל
ד. תשתיות
- התקנתיות:
במערכות מורכבות זה קריטריון בפני עצמו ויכול לכלול מספר באגים מותר לפי
חומרה, כמה workarounds מותר וכמה זמן הם לוקחים פר שרת וכד'.
חשוב שההתקנתיות נבדקה בתנאים דומים לתנאי השטח. - יש שמזכירים תוצרים של הפיתוח כמו מסמכים סגורים ומעודכנים, אבל יש לזכור שכאן זה שחרור גרסה, ובין אם פיתחנו באג'ייל או בכל דבר אחד, הפיתוח היה צריך לאשר את עצמו לפני כן בין אם זה ב-DoD ובין אם בכניסה לבדיקות.
- הבילד עצמו ותשתיות: נניח הקשחה של השרתים ובדיקות של security, וירוסים, source control וכד'.
הרמזור
כל ה-KPI שהזכרתי, באם נעמוד בהם, הגרסה מוכנה לשחרור. מצד שני מספיק
קריטריון אחד בכדי להכשיל את כל הגרסה.
ניתן לתת איזה תחום
צר בו לא יהיה "שחור ולבן", ובו הגרסה אינה מושלמת (כביכול - לעולם היא
אינה מושלמת באמת) אבל עדיין ניתן לשקול להוציא אותה. למשל כמות הבאגים בחומרה
מאג'ורית המותרים היא 20, אבל אם יש בין 21 ל-23 זה גם יכול להיות בסדר להוציא את
הגרסה (אבל במקרה של 24 - הגרסה אדומה). בשל כך אפשר לדמות את ה-KPI לרמזור.
כמובן צריך לראות אם
הגרסה צהובה, האם היא צהובה (אם נמשיך את הדוגמה מלמעלה) במקום אחד או חמישה.
מה ההמלצה שלי בנושא?
אני חושב שמאוד כדאי
שלכל חברה יהיו מדדי איכות של היציאה ללקוח. זה לא בא לסרבל את התהליך אלא לוודא
שאנו מוכנים. הרי בסופו של דבר זו נקודה קריטית בחיי שלב הפיתוח של המוצר.
מצד שני יש להפעיל שיקול
דעת כי לא תמיד המספרים "אומרי אמת". אם המספרים יצרו דיון אמתי, שקול
ועם נתונים והסברים טובים - דיינו.
בגדול כל חברה צריכה
לראות מה מתאים לה, אבל אני ממליץ כן להתייחס לארבעת הקטגוריות - כיסוי, תוצאות,
ביטחון בגרסה ותשתיות - ולתת לכל קטגוריה מדדים משלה.
אין תגובות:
הוסף רשומת תגובה