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

מאת: קרן סגל כהן, מנהלת פרוייקטים ואינטגרציה GlobaLeadPro

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

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

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

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

התהליך התחלק לשלושה שלבים:

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

איך זה בדיוק התבצע (עכשיו הפרטים):

הצעד הראשון היה זיהוי ממשקים בין צמדים/זוגות בפרויקט.

מהו ממשק/צמד?

ממשק הוא נקודת החיבור בין שני רכיבי תוכנה שונים (או יותר) בזמן ריצה.

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

ממשק יכול להיות סינכרוני או אסינכרוני (כלומר מחזיר פידבק / פלט או לא בהתאמה)

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

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

צעד שני – לכל ממשק/צמד נכתב (או על ידי המאפיין או על ידי) תיעוד טכני במסמך IDD (Interface Detailed Design) –

התיעוד הטכני כלל ערכי קלט/פלט אפשריים –

אורך

סוג

חובה? כן/לא

מיפוי הערכים (כלומר "לאן הם הולכים?" מה שדות היעד שלהם?
 Source to target)

לכל IDD יהיה Review משותף לכל המשתתפים בממשק עד "חתימה"

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

צעד שלישי – ניהול כל הממשקים במטריצת אינטגרציה עד סיום הבדיקות

סוגי הפעילויות שהוחלט לבצע לכל צמד/ממשק:

לכל תהליך עסקי שמעורב בו צמד/"זוג" היו 3 שורות במטריצה:

1. תיעוד הממשק - במסמך נפרד תיעוד טכני של הממשק. שני הצוותים המעורבים יעברו על התיעוד ויאשרו אותו בזמן האפיון
2. בדיקות dev2dev – תכנון תאריך ומעקב לבדיקות "זוגות" בסביבות פיתוח בזמן הפיתוח.
3. בדיקות E2E – תכנון תאריך ומעקב לבדיקות E2E

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

דוגמה לבעיות אינטגרציה שנמצאו בזמן אפיון הממשק:

דוגמה לבעיות אינטגרציה שנמצאו בזמן Dev2dev

דוגמה לבעיות אינטגרציה שנמצאו בזמן E2E:

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

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