‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax.

972-97442444‬‬

‫סיכום מפגש שולחן‪-‬עגול‬

‫פיתוח וארכיטקטורות מערכות מידע בארגון‬

‫‪Agile Software Development‬‬

‫‪ 1‬ליוני ‪2008‬‬

‫מנחה פיני כהן‬

‫‪Page 1 of 7‬‬
 ‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫‪26.6.2008‬‬

‫לקוחות נכבדים שלום‪,‬‬

‫תודה על השתתפותכם במפגש שולחן עגול ‪ Round Table‬בנושא פיתוח וארכיטקטורה של‬
‫מערכות ארגוניות‪.‬‬

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

‫מסקנת ‪ STKI‬היא שבהחלט כדאי לארגונים להתנסות בפרויקט שמפותח ב‪ ,AGILE -‬על פי‬
‫המאפיינים המוזכרים בהמשך‪.‬‬

‫לגבי מועד ונושא למפגש נוסף בתחום זה‪ ,‬נעדכן אתכם בהמשך‪ .‬קרוב לוודאי שהמפגש הבא‬
‫‪ SOA‬וכמו כן נמשיך‬ ‫יתמקד בנושאים של הממשק בין פיתוח המערכות לצוות הממשקים\‬
‫לדון בתהליכי הפיתוח בארגונים‪.‬‬

‫בברכה‪,‬‬

‫פיני כהן‬

‫תוכן‬
‫סוגיות \ התלבטויות ‪3........................................ ................................ ................................‬‬
‫יישום ‪ Agile Software Development‬אצל לקוח מוסדי ‪4........................... ................................‬‬
‫רקע ‪4......................... ................................ ................................ ................................‬‬
‫מימוש ‪ Agile‬מן הכוח על הפועל ‪4..................... ................................ ................................‬‬
‫מתודולוגיית הפרויקט ‪4................................... ................................ ................................‬‬
‫מסקנות הלקוח מפרויקטים אלו ‪6...................... ................................ ................................‬‬
‫הערת ‪6................... ................................ ................................ ................................ STKI‬‬

‫‪Page 2 of 7‬‬
 ‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫סוגיות \ התלבטויות‬
‫להלן מספר סוגיות והתלבטויות שהועלו על ידי ארגונים‪ .‬עקב ההצגה המצוינת של מימוש‬
‫ארכיטקטורת ‪ , AGILE‬לא הספקנו לדון בנושאים אלו והם יהיו הבסיס למפגשים הבאים‬
‫שלנו‪:‬‬
‫התלבטויות – סיכון וסיכוי בהכנסה של טכנולוגיות חדשות לפלטפורמה של מערכות לבה‪.‬‬ ‫‪‬‬
‫התחלה של כניסה ל‪ SOA ESB -‬בארגון‪ .‬כפלטפורמה לאינטגרציה במערוכת בארגון‪ .‬צוות‬ ‫‪‬‬
‫קישוריות‪ ,‬הפך להיות צוואר בקבוק‪ ...‬ביצועים לא השתפרו‪ ...‬מקשה בתהליך הפיתוח‬
‫ובזמני תגובה‪ .‬צוות קישוריות – זה דבר בעייתי‪ .‬כי אנשי פיתוח לא מומחים בקישוריות‪ .‬ואז‬
‫הקישוריות הופכת להיות צוואר בקבוק‪ .‬לקישוריות צריך הכשרה כי לא רוצים שכל אחד יגע‬
‫בשרת הקישוריות‪.‬‬
‫התלבטות – פיתוח – האם פיתוח ‪ – best of breed‬או ‪ – JAVA‬לאפליקציות ‪ WEB‬האם ‪.net‬‬ ‫‪‬‬
‫או ‪ .JAVA‬השאלה מה החשיבות של אחידות בשפת פיתוח‪.‬‬
‫אתגרים – ‪ - time to market‬תחרות בשוק הפיננסי מול חברות ביטוח‪ ,‬חברת אשראי‪,‬‬ ‫‪‬‬
‫בנקים וכד'‪.‬‬
‫אתגר נוסף – מענה לרגולציה‪ .‬מסתבר ש"תקנת הלבנת הון" בתחום הפיננסי היא רק‬ ‫‪‬‬
‫חימום‪...‬‬
‫אחד ארגונים שהשתתפו הנו ארגון גלובלי שמבצע רכישות של חברות ופיתוח מוצרים בצורה‬ ‫‪‬‬
‫גלובלית‪ .‬בתחום זה ישנם אתגרים רבים‪ ,‬החל מאתגרים ארגוניים תהליכים וכלה באתגרים‬
‫טכנולוגיים כמו אבטחת מידע‪ ,‬ביצועים באופן כללי ו‪ latency -‬של הרשת‪.‬‬
‫אצל אחד הלקוחות הדבר הבולט השנה הוא שדרוג ‪ SAP‬לגרסה ‪ .ecc6‬מדובר זעזוע גדול‪.‬‬ ‫‪‬‬
‫‪ IT‬כל זאת בגיבוי המנכ"ל‪ .‬צפויים לסיים את השדרוג‬ ‫ולכן כחצי שנה לא יקבלו שירות‬
‫באוגוסט ‪ ,‬על פי המתוכנן‪.‬‬
‫טענות בארגון – שה‪ IT" -‬מעקב פעולות עסקיות" ‪ .‬יש להם הרבה בקשות ‪ .‬הלקוחות צריכים‬ ‫‪‬‬
‫עזרה של ה‪ IT -‬באפיון של הדרישות‪ .‬שלב הבדיקות ‪ -‬קשה לקבל זמן מהאנשים העסקיים‬
‫לבדיקות‪.‬‬
‫סוגיה נוספת שהוזכרה היא שהלקוחות משנים את דעתם במהלך זמן הפיתוח‪.‬‬ ‫‪‬‬

‫‪Page 3 of 7‬‬
 ‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫יישום ‪ Agile Software Development‬אצל לקוח מוסדי‬

‫רקע‬
‫לפני תחילת המימוש של מיתולוגיית ה‪ Agile -‬בוצעו בארגון מספר שינויים מקדימים‪ .‬עקב‬
‫בעיה של עזיבה – החלפת תפקיד כל שנתיים –שלוש‪ ,‬הוחלט על ידי ההנהלה לתת דגש‬
‫טכנולוגי ולהצמיח ראש חץ של מומחים טכנולוגיים‪ .‬הלוגיקה היא שברגע שיש התמחות‬
‫טכנולוגית – אנשים לא רוצים לעזוב‪ .‬כלומר ישנה השקעה משמעותית במובילים הטכנולוגיים‬
‫מצד שני הם קבלו אחריות רבה יותר‪.‬‬
‫‪ - center of excellence‬קיבוץ אנשי מקצוע לצורך‬ ‫במקביל‪ ,‬הותחל להשתמש בארגון ב‪-‬‬
‫ביצוע משימה ספציפית לתקופת זמן מוגבלת‪ .‬לשיטת ניהול זו יתרונות רבים אך מצד שני‬
‫ישנם מספר קשיים לדוגמה‪ ,‬קשה לתוכניתנים לעבור ממקום למקום כי כל פעם הם צריכים‬
‫להזדהות עם פרויקט (מטרה) אחרת‪.‬‬
‫כמו כן‪ ,‬התרחשה בארגון מלאכה של שיווק חיצוני‪ ,‬כמובילים טכנולוגיים בתחומים מסוימים‪.‬‬
‫התוצאה היא שגם קיבלו פרויקטים חדשים רבים וגם שהמובילים הטכנולוגיים קיבלו תחושת‬
‫של גאוות יחידה‪.‬‬
‫הדבר גם הקל בצורה מסוימת על מצוקת כ"א מכיוון שהמנהלים הבכירים הבינו את חשיבות‬
‫הנושא‪ .‬דבר זה הכרחי לקראת מימוש ‪ , Agile‬לפחות בתחילת התהליך‪ ,‬וזאת מכיוון שרצוי‬
‫‪ agile‬בפעם הראשונה) כאשר יש צוות מספיק גם‬ ‫מאוד ללכת אל הלא נודע (כלומר ל‪-‬‬
‫לפרויקט שרוצים לבצע ב‪ Agile -‬וגם למילוי המשימות השוטפות של תחזוקה‪.‬‬

‫מימוש ‪ Agile‬מן הכוח על הפועל‬

‫נכון להיום לארגון יש כבר כמהפרויקטים בסביבת של ‪ Agile‬כאשר לפחות אחד מהם בייצור‬
‫‪ 10‬שנות אדם כל אחד‬ ‫(וממשיך להיות מפותח)‪ .‬מדובר על פרויקטים בסדר גודל של כ‪-‬‬
‫‪ 7‬אנשים‪.‬‬ ‫(וממשיכים לפתח) כאשר גודל הצוות המקסימלי (בחלק מהתקופה) היה של‬
‫‪ Agile‬היה שימוש בכלי ניהול סטנדרטיים כמו תרשים‬ ‫למרות השימוש במתודולוגיה של‬
‫‪ Gant‬וכד'‪.‬‬
‫‪ )sprint‬אחד הפרויקטים השתמש באיטרציה של שבועיים‪.‬‬ ‫מבחינת זמני האיטרציות (או‬
‫הפרוייטק השני באיטרציה של חודש‪.‬‬

‫מתודולוגיית הפרויקט‬
‫‪."sprints‬‬ ‫הפרויקט מתבצע על ידי צוות קבוע אשר מחלק את העבודה ל"איטרציות" או "‬
‫אורך כל איטרציה היא שבועיים (או חודש)‪ .‬בנוסף לכך ישנה ישיבת בוקר " ‪"daily meeting‬‬
‫של ‪ 15‬דקות‪.‬‬

‫‪Page 4 of 7‬‬
 ‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫בתחילת הפרויקט‪ ,‬באיטרציה הראשונה (שבועיים) מתקיים אפיון על ידי צוות הפרויקט עם‬
‫המשתמשים הסופיים (או לייתר דיוק עם נציגים שלהם) כאשר מדובר לא אפיון מפורט‪,‬‬
‫והתוצאה היא רשימה של משימות לביצוע ( ‪ .)backlog‬רשימה זו מוצגת בסוף האיטרציה‬
‫הראשונה למשתמשים‪ .‬שלב זה הוגדר כ"איטרציית ההקמה" או ספרינט הקמה‪.‬‬
‫‪ , )backlog‬מנהל‬ ‫לאחר שלב זה‪ ,‬מתחילה העבודה השגרתית‪ .‬מתוך רשימת המשימות (‬
‫הפרויקט ‪ ,‬ה‪ scrum master -‬בוחר את משימה (משימות) הראשונות לביצוע ומתחילים‬
‫בביצוע‪ .‬כשבתום האיטרציה‪ ,‬שוב מראים ללקוח מה בצעו ומעדכנים את רשימת המשימות‬
‫(‪.)backlog‬‬
‫ישנם שני מאפיינים בולטים נוספים לביצוע המשימות בפרויקט‪ .‬מאפיין ראשון הוא פגישות‬
‫בוקר – ‪ . daily meeting‬פגישות אלו הן פגישות סינכרון של כל חברי הצוות שבהם כל חבר‬
‫צוות מדבר על המשימות שבצע אתמול ועל המשימות שמתוכננות להיום‪ .‬לעיתים יש גם‬
‫‪15‬‬ ‫פגישות ארוכות יותר של חלק מחברי הצוות לליבון נושאים לעומק‪ .‬משך הפגישה כ‪-‬‬
‫‪5‬‬ ‫דקות‪ ,‬בעמידה! בארגון גם הונהג כלל שמי שמפספס פגישה‪ ,‬תורם לקופה המשותפת‬
‫‪...₪‬‬
‫מאפיין שני הוא שימוש במתודולוגיה של ‪ .test driven development -TDD‬במתודולוגיה‬
‫זו ישנה כתיבה של בדיקה לפני הכתיבה של הקוד‪ .‬כלומר ההחלטה העקרונית היא לקיים‬
‫‪ TDD‬אולם יש מקומות שלא רוצים לבצע ‪ -TDD‬בגלל שהבדיקות נמצאות במחלקה אחרת‪.‬‬
‫המשמעות היא שמהלך הפרויקט ישנה בניה של סביבת בדיקות מקיפה לכל אורך התקדמות‬
‫הפרויקט‪ .‬על פי הניסיון שקיים‪ ,‬ככל שרמת הבדיקות וכיסוין טוב יותר‪ ,‬הסיכוי לשינויים‬
‫גדולים בהמשך (כלומר ‪ refactoring‬נרחב) נמוך יותר‪ .‬כאשר בכל איטרציה עם הלקוח‪ ,‬פעם‬
‫בשבועיים ‪ ,‬מוסרים ללקוח מידע על הבדיקות וגם מידע נוסף על התקדמות הפרויקט‬
‫(לדוגמה‪ ,‬מאפיינים של הקוד‪ ,‬מידע על ביצועים או חשש לבעיות ביצועים וכד')‪ .‬כלומר ישנו‬
‫דגש על פתיחות מול הלקוח‪.‬‬
‫לגבי שינויים בקוד קיים‪ ,‬כלומר ‪ ,refactoring‬אם יש שינוי שמתבצע בגלל שינוי דרישות של‬
‫הלקוח‪ ,‬השינוי נכנס מחדש לרשימת הדרישות ( ‪ )backlog‬ללא בעיה‪ .‬מצד שני אם יש שינוי‬
‫ארכיטקטוני (שלא התבקש ישירות על ידי הלקוח)‪ ,‬זאת כמובן הבעיה או החשש בכתיבה של‬
‫פרויקט ללא ביצוע אפיון מפורט מראש‪ ,‬ובכן עד עתה ללקוח לא היו מקרים "קשים" של‬
‫‪ SPARE‬כאשר מתכננים ומעריכים כל‬ ‫שינויים מסוג זה‪ ,‬ובכל מקרה יש לקחת קצת‬
‫איטרציה וגם את כל הפרויקט כולו‪.‬‬
‫במקרי קצה‪ ,‬כאשר המשימות ב‪ backlog -‬באיטרציה שלמה לא כללו שינויים ב‪ gui -‬כלומר‬
‫לא היה מה להראות ללקוח אחרי שבועיים‪ ,‬בצע ה‪ scrum master -‬שינוי של ה‪backlog -‬‬
‫‪ GUI‬ספציפי וזאת בכדי שהלקוח יראה בכל זאת משהו!‬ ‫בכדי שיכיל תכונות נוספות עם‬

‫‪Page 5 of 7‬‬
 ‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫כלומר שלא תעבור איטרציה מבלי שיראו שום דבר‪( .‬אפילו שהורידו קצת מהתכולה‬
‫המלאה!)‬
‫נקודה רלוונטית נוספת היא ביצוע של סקר קוד‪ .‬כל הקוד בפרויקט עובר סקר‪ .‬אפילו של‬
‫המתכנתים הבכירים‪ .‬גם סקירה אוטומטית וגם סקירה ידנית‪ .‬בדרך כלל יומיים לפני סוף‬
‫האיטרציה‪.‬‬

‫מסקנות הלקוח מפרויקטים אלו‬

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

‫הערת ‪STKI‬‬
‫אין ספק שמדובר במהלך ייחודי וראשוני בקרב לקוחות ה‪ enterprise -‬בישראל‪ .‬מה שעושה‬
‫את המהלך לעוד יותר מיוחד הוא שהארגון לא השקיע רבות במשאבים חיצוניים (קורסים‬
‫והדרכה צמודה) בזמן מימוש הארכיטקטורה בפעם הראשונה‪.‬‬
‫‪ Agile‬הוא תחילת עבודה ללא‬ ‫הקושי‪ ,‬או החשש המרכזי בביצוע פרויקטים בארכיטקטורת‬
‫אפיון מפורט מראש (כפי שמקובל)‪ .‬החשש הוא ש‪ refactoring -‬נרחב יגרום לעיקוב "בלתי‬
‫אפשרי" בפרויקט ולחוסר עמידה בלו"ז ובתכולה‪ .‬חשש זה הנו מוצדק בהחלט‪ .‬לפיכך‪ ,‬להלן‬
‫מספר קריטריונים לכניסה לתחום ה‪: Agile -‬‬
‫‪ .1‬גודל פרויקט עד ‪ 6-7‬משתתפים (כולל כל החברים – ניתוח‪ ,‬מתכנתים‪ ,‬בדיקות)‪.‬‬
‫‪ .2‬פרויקט עם הלקוח שיכול להקדיש את הזמן (כלומר יכול להיפגש פעם בשבועיים‬
‫בסוף\תחילת איטרציה)‪.‬‬
‫‪ .3‬רצוי פרויקט שבו יש הגיון ל‪ delivery -‬אינקרמנטלי‬
‫‪ .4‬פרויקט שבו הטכנולוגיה כבר מוכרת‪ .‬לטכנולוגיה שאינה מוכרת כלל מוסיפה לרמת הסיכון‬
‫של הפרויקט‪.‬‬
‫‪ .5‬פרויקט שבו העולם העסקי של הלקוח כבר מוכר לצוות הפיתוח‪ ,‬גם כאן בכדי להוריד סיכון‪.‬‬

‫‪Page 6 of 7‬‬
 ‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7444474 Fax. 972-97442444‬‬

‫להערכתנו‪ ,‬פרויקט שעונה על קריטריונים אלו הנו בהחלט מועמד למימוש ראשוני תחת‬
‫מתודולוגיה של ‪.Agile Software Development‬‬

‫‪Page 7 of 7‬‬