כשה-AGILE עולה לרמה הארגונית

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

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

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

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

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

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

כאשר Offshore פגש את Agile - חלק שלישי

הקונספט של Agile Development התפתח מהשטח, לאחר שעוד ועוד מנהלי פיתוח יצרו לעצמם best practices על מנת לנהל פרוייקטי תוכנה במתודולוגיה המתאימה את עצמה לאופי של פרוייקט תוכנה טיפוסי.

תפירת חליפה לפי מידה כמשל למתודולוגיית Agile

על מה מבוססת בעצם מתודולוגיית הפיתוח Agile? אני אמחיש זאת באמצעות דוגמא מהחיים:

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

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

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

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

זוהי למעשה כל מתודולוגיית הפיתוח Agile על רגל אחת:

● שיתוף הלקוח בתהליך הפיתוח.

● חלוקת הפרויקט לאיטראציות  קצרות ובסיומן נקודות ביקורת.

● הסתגלות לשינויים (היקף המותניים שלי...) תוך כדי פיתוח.

למה פיתוח Agile תופס תאוצה כל כך גדולה בעולם פיתוח התוכנה?

המתודולוגיות הישנות לפיתוח תוכנה מבוססות על גישת מפל המים (Waterfall). דהיינו, בתחילת הפרויקט מקצים זמן לאפיון וניתוח הדרישות, מן הדרישות העסקיות גוזרים את הדרישות הטכניות וארכיטקטורת המוצר. השלב הבא הוא שלב ה-Design, פיתוח, בדיקות ולבסוף שלב התחזוקה. זו אותה הגישה בה ניגשים לפרויקט של בניית גשר למשל.

הסיבה לפופולריות הגואה של פיתוח Agile היא שפרויקט תוכנה מתנהג יותר כמו תפירת חליפה לפי מידה, מאשר כמו פרויקט להקמת גשר:

● הדרישות של פרויקטי תוכנה נוטות להשתנות באופן תדיר.

● פיתוח תוכנה הוא לרוב מלאכת יד (תרתי משמע!) ולא עבודה אוטומטית וממוכנת ברובה, לכן טעויות האנוש (באגים) מאוד נפוצות.

● תוכנה שאינה מותאמת לדרישות יקר מאוד לשנות, כפי שיקר לשנות חליפה קטנה מדי...

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

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

כאשר Agile פגש את Offshore - חלק ראשון

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

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

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

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

יחד עם זאת, ישנם סימנים שיש דרך אפקטיבית להעביר פרויקטי פיתוח לספק מיקור חוץ בארץ אחרת. הפיתרון טמון במקום שבו offshore outsourcing נפגש עם Agile development.

* על המחבר: אבירם איזנברג הוא המנכ"ל של איגנייט, חברת לשירותי פיתוח תוכנה, המפעילה מספר מרכזי פיתוח במזרח אירופה ומתמחה במודלי פיתוח אג'יליים מבוזרים. בעשור האחרון, אבירם מסייע לחברות היי-טק ישראליות וגלובאליות, מהשורה הראשונה, להפוך לארגונים אג'יליים ובכך לרתום את היתרונות של אג'ייל וסקראם על מנת למקסם את ביצועי מחלקת הפיתוח. אבירם מוביל את פורום מנהלי הפיתוח בישראל, SD FORUM, מארגן את כנסי Agile Tour בישראל ובאוקראינה ומרצה לעיתים תכופות בכנסי אג'ייל בארץ ובאירופה.