מנהלי קומפוננטה

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

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

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

למשל: מי ייצור מפת תלויות של כל הקומפוננטות בגרסה? מי יתאם לוחות זמנים?

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

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

הוא קבע ישיבה עם כל הגורמים הרלוונטיים.

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

כמו כן אנשים שעד בה עבדו בשיטת הסמוך קשה להם לקבל מרות.

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

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

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

וכך היה גם כאן.

מקרים מהחיים: אחריות במערכת מורכבת

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

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

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

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

מהן הבדיקות ואיך עושים את זה?

לא מזמן כתבתי על בניית קבוצת בדיקות.

במידה ומדובר במקום בו הבדיקות היו עד כה חובבניות ואת רוצה לעלות שלב, מומלץ לשתף את ההנהלה בתוכניות. כאשר ישנה הסכמה - משתפים את כולם.

מצ"ב פרזנטציה שכתבתי בדיוק בשביל זה. מטרתה:

- להבהיר את השאלה "מה בדיוק עושים בודקי התוכנה" - כן, יש כאלה שחושבים עדיין שאנו סתם "רצים" על התוכנה.

- להסדיר נהלי עבודה חדשים.

- תיאום ציפיות.

- לקבל התחייבות לתהליכים החדשים.

מצ"ב לינק למצגת.