Agile Round Table

‫‪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‬‬