לא, אין כאן כוונה לשערים כמו בכדורגל, אלא לתהליך מסודר של העברת אחריות, או מעבר בין פאזות, בתוך תהליך הפיתוח.
טרמינולוגיה:
שער = gate, והישיבה = Readiness before X, כאשר X יכול להיות בדיקות.
מהו השער?
השער הוא בעצם ישיבה (אפשרי טלפונית, תלוי בבגרות התוכנה, פשטותה וכו') בין א' כשא' הוא זה שסיים שלב בתהליך הפיתוח, ל-ב', שאמור להמשיך את התהליך. מטרת הישיבה היא לוודא מהו המצב של הגרסה כפי שבאה לידי ביטוי אצל א', והאם ב' מוכן לקבל את התוכנה במצב הזה ומוכן להמשיך בתהליך.
חשיבותו של השער:
לא ניתן להגזים בה.
דבר ראשון, מעצם קיומו (כמו שאומרים בפוליטיקה). כשלמשל כותב הדרישות יודע שיש שער פורמלי בו הוא מוסר את המסמך לפיתוח הוא מראש יכין את המסמך לביקורת, כיוון שהוא לא ירצה להכשל בהעברה. כשל בד"כ גורר הפניית זרקור לנכשל.
דבר שני אפשר להבין באמת את דרגת הבגרות של המוצר אותו אנו מקבלים. אם למשל נראה לכם ברור מאיליו שאין שינויים קרובים במסמך, כשיש ישיבה וצ'ק ליסט, כשאחת השאלות האם יש שינוים בפתח, כותב הדרישות עלול להפתיע. כמו גם בשאלה האם הוא עדכן את כל הבעיות ועוד.
אחריות:
מי שאחראי לשער הוא הצד המקבל. הוא מנהל את הישיבה ובסמכותו לקבוע אם הוא מוכן לקבל את התוכנה, מוכן אבל בתנאי או תנאים מסויימים, או לא מוכן. באנגלית:
Go, Conditional Go, No Go.
הדגש:
מי שמנהל את הישיבה, אמור וצריך לעבור על צ'ק ליסט ולפי התשובות להחליט מה יהיה צעדו הבא. אבל לא רק השאלות הפורמליות חשובות, אלא גם שאלות כמו: האם אתה מרוצה מהתוכנה? היו בעיות שנפתרו? מה הסיכונים?
אדם בעל ניסיון יוכל לדעת בסוף הישיבה בדיוק האפשרי איזה מוצר הוא מקבל.
הדבר החשוב ביותר הוא להבין ששער אינו מתמצא בפגישה. על האחראי לקבלה, נניח ר"צ בדיקות, להיות מעודכן במשך כל הזמן שהתוכנה בשער הקודם (נניח פיתוח) לגבי קצב ההתקדמות, בעיות, שינויים וכד'. אם צריך - להיות פרואקטיבי ולסייע על מנת שידע שהוא מקבל את המוצר הטוב ביותר האפשרי. לא מקובל בעיניי שר"צ הבדיקות ינוח על שמריו ולא ידע מה קורה ומתי הוא יקבל את המוצר ומה מצבו.
לכן על הספקים לדעת בדיוק את ציפיותיך. שלח להם צ'ק ליסט של הישיבה.
בעצם בתנאים נורמליים ולפי האמור לעולם לא תסתיים ישיבה ב-No Go כיוון שאם המצב רע מקבל המוצר אמור לדעת מזה ובהסכמה עם המוסר לא לקיים את הישיבה, ואם מקיימים אז כישיבת סטטוס אבל לא כשער פורמלי. שער ייכשל רק כשהמצב לא היה ידוע לאשורו.
עכשיו אני לא אומר שצריך לדעת במדוייק כל דבר, אחרת למה הישיבה, אבל לפחות בגדול.
וודא שהמשתתפים המנדטוריים יגיעו לישיבה.
אם הישיבה לא התקיימה כי המוצר אינו מוכן לגיטימי להוציא על כך מייל.
בנוסף, דיברתי רבות על המוסר, אבל כמובן וכמובן שגם המקבל צריך להיות מוכן (TD, מעבדות, אנשים ועוד) לקבלה.
להערכתי יש לבצע את השערים האלה:
1. בין השיווק למהנדס המוצר.
2. בין המהנדס לפיתוח (כולל בדיקות).
3. אם יש אינטגרציה - בין הפיתוח לאינטגרציה.
4. בין האינטגרציה / הפיתוח לבדיקות.
5. בין הבדיקות למייצג של הלקוח.
שער לכניסה לבדיקות - readiness before testing:
- זהו שער שהתכולה לבדיקות נבדקת לפני הרצה של הבדיקות.
- מנהל השער הוא מנהל הבדיקות.
- מטרות:
א. מציאת בעיות ומניעת זליגה שלהן הלאה.
ב. תמונת מצב של בגרות המוצר (תכנון אל מול הבפועל). - צריך להערך לפני כל "דליברי", במקרה של דליברי קטן אפשר לצמצם (או טלפונית). סיכום חייב לצאת תמיד.
הישיבה:
כל המשתתפים המנדטוריים מגיעים.
שומעים מהצד המוסר מעיין סיכום על מה שהיה, מה נעשה, בעיות וכד', דגשים ועוד.
על מנהל הישיבה למלא את הצ'ק ליסט, לרשום את הנושאים הפתוחים, ולקבוע את הסטטוס (Go, No Go וכד). כמובן שאף לעקוב אחרי מה שפתוח.
אחרי הדיון נשלח מייל סיכום עם ההחלטה.
אין תגובות:
הוסף רשומת תגובה