החלק הזה בשיפור הבדיקות עוסק בלמידה מתוך ההיסטוריה הפנים ארגונית.
הרעיון הוא לבדוק במועדים קבועים מה עבד ומה לא, לשמור על הקיים ולשפר מה שצריך. זהו תהליך טבעי המונע למשל ממצבים לא טובים לחזור על עצמם שוב ושוב, מה שבסה"כ כל אחד היה מעדיף כי זה מונע בזבוז מיותר של אנרגיה.
העניין הוא שזה לא נעים, בעיקר כשרוצים להכיל את התהליך בארגון שבו אין תהליך פורמאלי כזה מתקיים. ברור שיהיו גורמים שיחשבו שהכל פוליטי ונעשה על מנת להציג אותם באור פחות טוב. מה שחשוב הוא לעשות עבודת הכנה לפני, לדבר עם האנשים ולהסביר מה המטרות של התהליך: לשפר את התהליך ולא לגעור באנשים. ברור שגם ההצגה של הדברים צריכה להיות בהתאם: לדבר על עובדות ולא על אנשים, לא להאשים אבל לא להתעלם מבעיות. מה שחשוב הוא שדברים ישתנו לטוב, ואם אין צורך לצלול למקומות כואבים אז חבל ממילא לעשות זאת.
----
יש שתי רמות ל-lesson learn : רמת חברה ורמת מחלקה. זה שברמת חברה נוגע לא רק בבדיקות אלא גם בבעיות של גרסה, ניהול מוצר, פיתוח ועוד. בעצם כל קבוצה לדעתי צריכה לעבוד על התחקירים שלה ולהציג בנפרד למנהל הגרסה תוך דסקוס, ואז להיות חלק מהמצגת הסופית שתתעד מה היו האירועים ומה נלמד לקראת הגרסה הבאה. את התהליך הזה מומלץ לבצע לאחר כל גרסה.
ברמת מחלקה אפשר לעשות את זה תדירות גבוהה יותר, מבחינת המבנה התהליך זהה לחלק של הבדיקות בתהליך כולל.
בכדי להיות מדייק יותר על מנהל הבדיקות, למשל, לפרט מקרים ברמת צוותים וגם ברמת מחלקה.
ברמת חברה על מנהל הגרסה לבקש מכל מחלקה 2-3 דברים שעבדו היטב בגרסה וכן 2-3 דברים שהיה אפשר לעשותם טוב יותר. לכל סעיף יש לפרט:
- תיאור,- אנליזה,- איך לפרמל (לעשות את זה פורמאלי) את זה בכדי שזה יהיה חלק אינטגראלי מהתהליך להבא.
לדוגמא:
מצב חיובי. תיאור:
לא היו מקרים של החזרת build לפיתוח כיוון שלא היה ראוי לבדיקות.
אנליזה:
העבודה הצמודה בין הבדיקות לפיתוח, תיאום ציפיות ומסמך בדיקות sanity שהבדיקות ביקשו שהפיתוח יערוך גרם לגילוי מוקדם של בעיות.
פירמול:
לקראת מסירה של build לבדיקות, הבדיקות יהיו מוחנים עם מסמך sanity אותו יעבירו לפיתוח. בנוסף יהיה דיון בקבלת המוצר על הבעיות שהתגלו בשלב הפיתוח, מה שלא מומש וכד'.
מצב שלילי. תיאור:
חלק קטן מבדיקת גרגסיה X לא בוצעו.
אנליזה:
העבודה הייתה בלחץ, ובמהלך הבדיקות בטעות דף אחד נפסח. הבעיה היא שדווקא שם היה באג קריטי.
פירמול:
סימון כל צעד בצורה בולטת עבר / נכשל, מעבר של המסמך לאחר הבדיקה וחתימת הבודק.
ברמת גרסה כדאי לערוך פרזנטציה שתכלול, מלבד לאמור למעלה, שקף כללי לגבי הגרסה: מטרות, תכולה, לקוחות ועוד, רשימת בעלי תפקידים, שינויים בתכולה במהלך הגרסה, בעיות כלליות, הבדלים בין צפי למה שהיה בפועל (תאריכים, מספר באגים וכד) עם הסברים כשאין תאימות, הבדלים במספר ה-buildים, מעבר על רשימת הסיכונים שהיו בשלב התכנון והאם יתממשו, ובעיות שלא חשבנו עליהן כסיכון אך התממשו.
הרעיון הוא לבדוק במועדים קבועים מה עבד ומה לא, לשמור על הקיים ולשפר מה שצריך. זהו תהליך טבעי המונע למשל ממצבים לא טובים לחזור על עצמם שוב ושוב, מה שבסה"כ כל אחד היה מעדיף כי זה מונע בזבוז מיותר של אנרגיה.
העניין הוא שזה לא נעים, בעיקר כשרוצים להכיל את התהליך בארגון שבו אין תהליך פורמאלי כזה מתקיים. ברור שיהיו גורמים שיחשבו שהכל פוליטי ונעשה על מנת להציג אותם באור פחות טוב. מה שחשוב הוא לעשות עבודת הכנה לפני, לדבר עם האנשים ולהסביר מה המטרות של התהליך: לשפר את התהליך ולא לגעור באנשים. ברור שגם ההצגה של הדברים צריכה להיות בהתאם: לדבר על עובדות ולא על אנשים, לא להאשים אבל לא להתעלם מבעיות. מה שחשוב הוא שדברים ישתנו לטוב, ואם אין צורך לצלול למקומות כואבים אז חבל ממילא לעשות זאת.
----
יש שתי רמות ל-lesson learn : רמת חברה ורמת מחלקה. זה שברמת חברה נוגע לא רק בבדיקות אלא גם בבעיות של גרסה, ניהול מוצר, פיתוח ועוד. בעצם כל קבוצה לדעתי צריכה לעבוד על התחקירים שלה ולהציג בנפרד למנהל הגרסה תוך דסקוס, ואז להיות חלק מהמצגת הסופית שתתעד מה היו האירועים ומה נלמד לקראת הגרסה הבאה. את התהליך הזה מומלץ לבצע לאחר כל גרסה.
ברמת מחלקה אפשר לעשות את זה תדירות גבוהה יותר, מבחינת המבנה התהליך זהה לחלק של הבדיקות בתהליך כולל.
בכדי להיות מדייק יותר על מנהל הבדיקות, למשל, לפרט מקרים ברמת צוותים וגם ברמת מחלקה.
ברמת חברה על מנהל הגרסה לבקש מכל מחלקה 2-3 דברים שעבדו היטב בגרסה וכן 2-3 דברים שהיה אפשר לעשותם טוב יותר. לכל סעיף יש לפרט:
- תיאור,- אנליזה,- איך לפרמל (לעשות את זה פורמאלי) את זה בכדי שזה יהיה חלק אינטגראלי מהתהליך להבא.
לדוגמא:
מצב חיובי. תיאור:
לא היו מקרים של החזרת build לפיתוח כיוון שלא היה ראוי לבדיקות.
אנליזה:
העבודה הצמודה בין הבדיקות לפיתוח, תיאום ציפיות ומסמך בדיקות sanity שהבדיקות ביקשו שהפיתוח יערוך גרם לגילוי מוקדם של בעיות.
פירמול:
לקראת מסירה של build לבדיקות, הבדיקות יהיו מוחנים עם מסמך sanity אותו יעבירו לפיתוח. בנוסף יהיה דיון בקבלת המוצר על הבעיות שהתגלו בשלב הפיתוח, מה שלא מומש וכד'.
מצב שלילי. תיאור:
חלק קטן מבדיקת גרגסיה X לא בוצעו.
אנליזה:
העבודה הייתה בלחץ, ובמהלך הבדיקות בטעות דף אחד נפסח. הבעיה היא שדווקא שם היה באג קריטי.
פירמול:
סימון כל צעד בצורה בולטת עבר / נכשל, מעבר של המסמך לאחר הבדיקה וחתימת הבודק.
ברמת גרסה כדאי לערוך פרזנטציה שתכלול, מלבד לאמור למעלה, שקף כללי לגבי הגרסה: מטרות, תכולה, לקוחות ועוד, רשימת בעלי תפקידים, שינויים בתכולה במהלך הגרסה, בעיות כלליות, הבדלים בין צפי למה שהיה בפועל (תאריכים, מספר באגים וכד) עם הסברים כשאין תאימות, הבדלים במספר ה-buildים, מעבר על רשימת הסיכונים שהיו בשלב התכנון והאם יתממשו, ובעיות שלא חשבנו עליהן כסיכון אך התממשו.
המגיש צריך לערוך את הפרזנטיציה כבר אחרי שדבר עם הגורמים (כדי לא להפתיע ולגרום גם לאי-נוחות וגם לויכוחים), אפשר לעודד תגובות אבל לא פולמוסים. חיובי מאוד בעיני להמשיך בקבוצות עבודה את ניהול השיפורים הללו.
אין תגובות:
הוסף רשומת תגובה