ניהול סיכונים ברמת הפרוייקט ו(בדיקות)הגרסה

"If you don’t actively attack the risks, the risks will actively attack you." - Tom Gilb

כל גרסה שמתוכננת כוללת בתוכה סיכונים, כשהתממשותם / התממשות חלקן עלולה לגרום ל:

• אי-עמידה בזמנים.
• אי-עמידה באיכות המצופה.
• חריגה כספית מהתקציב המתוכנן.

המקרה הקיצוני הוא כישלון הגרסה עד כדי אי-שימוש בה וביטולה. אם היינו חיים בעולם מושלם הכל היה עובד לפי התכנון, ואם לא עשינו טעויות היינו מסיימים בזמן, באיכות ובתקציב שקבענו. אבל אנחנו לא חיים בעולם כזה. כיוון שכך, עלינו להיערך גם לדברים שעלולים להתרחש. יש לתכנן את התנהלות הגרסה בקפידה, להבין את כל הבעיות שאנו יכולים להעריך ושעלולות לצוץ ולהערך אליהן בהקדם, לפני שהן קורות, מבחינות של הדרכה, טכנולוגיה, ספקים וכו'. לחידוד העניין: ניהול סיכונים (או RBT - Risk Based Testing) הוא תמיד על פריטים (items) שליליים שיש סיכוי שיקרו אך אין וודאות לכך. ברגע שסיכון הופך לבעיה אמתית הוא עובר מ"ריסק" ל-open issue.

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

ניהול סיכוני הפרויקט

בעולם שלנו, שיש בו פיתוח באג'ייל (בין אם אנו עובדים באג'ייל או מושפעים ממנו) ומעדיפים שיחה על פני מסמכים, אנשים עשויים שלא להבין למה צריך מסמך ניהול סיכונים. ואני אומר: אם אתה לא יודע לייצר מסמך כזה תוך 30 ד', זה אומר שגם בראש אין לך הידע של הסיכונים, כלומר את/ה לא ערוך לסיכון. צריך מסמך ולו לשם כך (וכמובן לשם מעקב).

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

ניהול סיכוני גרסה באופן כללי עשוי להכיל סיכונים כמו:

• חוסרים של משאבים שלא ישתחררו בזמן למשל או גיוס המוני למילואים כמו צו 8.
• איחור / אי-קבלת חומרים שאמורים להשתלב או לקדם את הפרוייקט כמו קוד של צד שלישי, תרגומים.
• חוסר ידע טכנולוגי של העובדים (למשל טכנולוגיה חדשה).
• שינוי של חוקים מסוימים במדינות שהן קהל היעד או איגודים שונים שיכריחו שינויי מוצר.
• בעיות מהשטח שידרשו זמן אנליזה, תיקון והפצה.
• לקוח שלא תמיד זמין ויש לחכות לתשובות.
• בעיות פנימיות בין מחלקות.
• ריבוי של אנשים חדשים שלא מכירים את המוצר בחברה ולכן הם לא יעילים ועלולים לגרום לפגיעות כאלה או אחרות.
• עבודה מבולגנת שעלולה להאריך את הזמן.

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

איך נראה כזה מסמך? טבלאי למשל. הסעיפים להלן הם שמות העמודות, ה-columns, במסמך כזה.

1. ה-ID של הסיכון

2. רשימה של הסיכונים איך קובעים מה הסיכונים? אישית, הייתי עובר על מסמך תכנון הגרסה. על כל נושא שרשום הייתי מנסה לחשוב מה עלול לקרות, במסגרת ההיגיון, ורושם את זה בצד. אח"כ הייתי מנסה לחשוב מניסיוני ומתייעץ עם אחרים (ר"צ בפיתוח, בדיקות, מהנדסי מערכת ועוד) בנוגע לדברים שעלולים להתרחש, מסתכל על הגרסה מ"גבוה". עם זאת, יש דברים שלפעמים חוזרים: עיכוב בגרסה קודמת תעכב את הנוכחית, מעבדות שעלולות לקרוס, בעיות ועיכובים בקבלת חומרים מצד שלישי וכד'.

הערכת הריסק - הגרסה הארוכה (סעיפים 3 עד 5):

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

כדאי לכמת את ההסתברות מ-1 עד 5 כאשר 1 שווה לכך שכמעט אין סיכוי שזה יקרה ו-5 כמעט בטוח שהסיכון יתממש.

4. חומרת הנזק אם הסיכון יתרחש כאן ננסה לכמת את הנזק שזה עלול להוביל אליו אם האירוע יתרחש (1-5). למשל אי-קבלת חומר מצד שלישי בזמן יניב עיכוב טוטאלי של הגרסה (5). לעומת זאת אם התרגום לפינית יתאחר נוכל להוסיף אותו אח"כ בלי הרבה נזק (1).

5. עצמת הסיכון

לאחר מכן מכפילים את ההסתברות בחומרת הנזק והתוצאה היא עצמת הסיכון.

חשוב לי לציין שזו אינה מתמטיקה, ולאחר מתן הציון יש לעבור שוב, ולראות אם זה הגיוני!

הערכת הריסק - הגרסה הקצרה:

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

יוצא שיהיו לנו מספרים מ-1 (אני מניח שלא באמת נתחשב בציון כה נמוך) עד ל-25. כמובן שככל שהציון גבוה יותר יש להיערך אליו בצורה יסודית יותר וכן שווה להשקיע בזה זמן ואולי גם כסף. אני לא אתן כאן חוקים של מה זה גבוה וכמה להשקיע וכד', כאן באמת אני חושב שאתם תדעו לבד ללא חישובים נוספים.

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

7. Contingency plan

ובכל זאת זה קרה? לשם כך יש ה-Contingency plan או fallback plan. כלומר למרות כל מה שעשינו, הרע קרה. במקרה זה, מהם הצעדים שנבצע?

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

8. Due date לישיבת מעקב אחר הנושא נראה ברור מאליו.

9. Due date שאחריו ברור שיש לנקוט אמצעים בפועל (כלומר ה-mitigations לא עזרו) לפעמים באותו רגע אנו נוטים לומר "טוב אולי באמת זה יסתדר מחר כמו שהם מבטיחים" או ש"אולי הם יצליחו להפעיל את המעבדה". זהו זה: הגענו, לא קרה כלום: מפעילים את ה-contingency plan. 10. אחראי זה החלק הכי חשוב אולי. אם אין אחראי לא יקרה כלום.

-----------------------------------------

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

ניהול סיכוני הגרסה עצמה (הקוד)

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

איך נראה ניהול סיכוני קוד?

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

הסיכון כאן מתחלק לשניים:

1.     הסבירות שבעיה קיימת. הציון: מ-1 עד 5, כאשר 1 הוא שיש סבירות נמוכה, 5 - כמעט בוודאות שיש בעיה.

2.     דרגת החומרה שהבעיה עלולה להגיע אליה. הציון: מ-1 עד 5, כאשר 1 הוא שכמעט אין בעיה, 5 - המערכת או הפיצ'ר לא יתפקדו.

רמת הסיכון היא הכפלה של השניים.

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

אנו מפתחים מעבד תמלילים והחלטנו להוסיף לו פיצ'ר חדש: שמירה אוטומאטית. הביצוע הוא קל - בסה"כ פונקציית שממתינה 5 ד' (או כל פרק זמן) ושומרת את המידע (השמירה עצמה כבר קיימת כפיצ'ר במוצר). הסבירות לבעיה הוא 1 או 2 (תלוי באפשרויות הקיימות למשתמש). אבל פיצ'ר כזה הוא קריטי ברמה שאם הוא לא יעבוד, המשתמש לא ידע על כך. ויצא שהמחשב שלו יקרוס, הוא עלול לאבד מידע חשוב ולתבוע אותנו. לכן החומרה היא 4. מזכיר את ההבדל בין severity לבין priority (ואם אתם מהדרים אולי אפשר לחלק את סעיף 2 למעלה לסיכון תוכנה וסיכון "תדמיתי").

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

ומה עושים עם התוצאות בעיקר היכן שהמדד מציג ציון גבוה?

1.     אם יש קבלה ושיתוף בפיתוח הוא יאמץ את המדדים הללו (או טוב יותר - יהיה שותף מלא) וישים לב לפיצ'רים הבעייתיים במובן של code analysis, unit testing וכד'.

2.     נתעמק בהבנה טכנית של מה שהמוצר עושה כאן ונוודא טסטביליות של כל נקודה בזרימת הקוד. 

3.     להתחיל בכתיבה וביצוע של בדיקות לפי הסדר של מדדי הסיכון.

4.     לשים לב במיוחד למקרי הקצה בבדיקות בעלות הסיכון הגבוה יותר.

5.     לתת לבדיקות את הזמן הראוי.

6.     אולי לתת לבודק מנוסה יותר לבדוק.

7.     נמפה השפעות. אולי יהיה מקום ליותר בדיקות רגרסיביות.

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

1. בדיקה של הפיצ'רים הקריטיים (נניח ציון מ-16 עד 25)

2. בדיקה של הפיצ'רים שהם medium (נניח ציון מ-8 עד 15)

3. בדיקה של הפיצ'רים שהם low (נניח ציון מ-1 עד 7)

ואז ניתן לומר: להבטיח שאין באגים קריטיים ייקח לי 5 ימים לבדוק לצורך הדוגמא, בינוניים 3 ונמוכים שניים.

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

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

סיכום:

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