מה זה Agile ולמה זה טוב ?
המטרה של הפוסט הזה היא להתמקד ביתרונות החשובים שיש לשיטת העבודה האג'ילית להציע לנו ולהראות לכם איך הלכה למעשה אפשר ליישם אותם בפרוייקטים של בניית אוטומציה לתהליכים שלכם בעסק.
המטרה היא לא ליישם את השיטה האג'ילית בצורה "הקלאסית" שלה, כלומר בסגנון של פיתוח תוכנה, וגם לא להיכנס למונחים השונים של השיטה ולהסביר אותם במדויק, אלא "לגזור" את הנקודות הכי משמעותיות עליהן יש לשים דגש לאור השיטה ולהתוות דרך מעשית ופשוטה ליישום שלה בפרוייקטים מסוג של אוטומציה לתהליכים עסקיים.
כלומר לא להיצמד בצורה קפדנית לשיטה אלא לפעול לאור ההתוויות וההנחיות החשובות שהיא מציעה לנו וכך להרוויח את היתרונות שיש לה להציע ועם זאת לפעול בהקשר של פרוייקטי אוטומציה ולא פרוייקטים של פיתוח תוכנה "קלאסיים" שבהם בדרך כלל מיושמת השיטה בצורה מדויקת.
Agile היא מתודולוגיה או שיטת עבודה שניתן ליישם בכל סוג של פרויקט, למרות שהיא משמשת בדרך כלל בפיתוח תוכנה אני רוצה להראות לכם כמה זה חשוב
ליישם את השיטה הזאת בכל מה שאתם עושים בפרוייקט אוטומציה לעסק שלכם.
השיטה הזאת מעודדת שיתוף פעולה בין חברי הצוות המיישם, עדכונים תכופים על התקדמות ותגובות מהירות לשינויי כיוון.
השיטה הזאת קיימת כשיטת עבודה מאז שנות ה-90, אבל היא הפכה פופולרית יותר עם עליית הטכנולוגיה הדיגיטלית ובשנים האחרונות היא הפכה פופולרית יותר גם בתחומים אחרים של עסקים.
למעשה השיטה מורכבת מאוסף של עקרונות ושיטות לפיתוח תוכנה. הכל עניין של שיתוף פעולה בצוות, וניתן ליישם אותה בכל סוג של פרויקט או סביבת עבודה.
השיטה מתמקדת ברעיון שרוב הפרויקטים ישתנו במהלך תהליך הפיתוח. המטרה היא לקבל משוב מלקוחות מוקדם ולעתים קרובות ככל האפשר, כדי שניתן יהיה לבצע שינויים לפני שיהיה מאוחר מדי.
זה לא קשור לשלמות; מדובר בהתקדמות ושיפור מתמיד – שבו כל אחד בצוות חולק אחריות להצלחה או כישלון.
למעשה זוהי מתודולוגיית פיתוח תוכנה המדגישה תוכנה עובדת על פני תיעוד מקיף.
המניפסט (הצהרת הכוונות) האג'ילי, שנוצר בשנת 2001, מגדיר את הערכים הבאים:
– אנשים ואינטראקציות על פני תהליכים וכלים
– תוכנה פועלת על פני תיעוד מקיף
– שיתוף פעולה עם לקוחות על פני משא ומתן על חוזה
– תגובה לשינוי על פי תוכנית
המאפיינים העיקריים של Agile
– אינטגרציה מתמשכת: זה מאפשר לצוותים לשלב את עבודתם בתדירות גבוהה, בדרך כלל כל יום, ולא בתדירות נמוכה יותר, כגון פעם בשבוע או פעם בחודש. זה מוביל לזיהוי מהיר יותר של בעיות והזדמנויות מוקדמות יותר לפעולה מתקנת.
– מוצר עובד: לצוותים תמיד צריך להיות מוצר עובד בכל זמן נתון, מה שאומר שהם לא צריכים לעבוד יותר משבועיים בלי משהו עובד שאפשר להראות לבעלי עניין או לקוחות.
– שיתוף פעולה עם לקוחות: זהו אחד המרכיבים החשובים ביותר בשיטת העבודה האג’ילית. גם אם אתם הלקוח, חשוב שתבינו שאתם חייבים להיות מעורבים באופן פעיל בכל שלב מהשלבים הרשומים בהמשך ואל תחשבו שגישת ה”שגר ושכח” או “לא מעניין אותי בשביל זה אני משלם לך” היא הגישה הנכונה.
אם אתם כלקוחות לא רוצים “להכניס את הראש” ולעבוד ביחד עם איש האוטומציה או המיישם של התהליך העסקי אותו אתם רוצים ליצור, אז עדיף שלא תכנסו “להרפתקאה” הזאת כי זה יגמר לא טוב.
הכוונה כמובן היא לא שאתם תבצעו את העבודה אלא שתהיו מסונכרנים עם המיישם או המיישמים ותהיו מוכנים לבדוק את התוצר של חלק עבודה אחד, להעיר הערות, להמתין לתיקונים ושוב לבדוק.
וכמובן שתהיו מוכנים להיות מעורבים במקרה של בעיות כלשהן תוך כדי שיח והתייעצות עם המיישם על הפתרון המתאים. כמו שהאמרה הבאה באנגלית ממחישה את זה היטב:
If you can’t stand the heat, get out of the kitchen
אם אתם בעלי עסק אתם בהכרח חייבים להבין שאתם בעסקי הבנת התהליכים והשיפור שלהם. מי שלא יודע להגדיר במדויק איזה תהליכים יש לו בעסק לא מכיר את העסק שלו וזה רע מאד. סבלנות ואורך רוח, נכונות לרדת לפרטים, נכונות להפעיל חשיבה יצירתית, נכונות להתמודד עם בעיות, כל אלו ועוד, הן תכונות נידרשות ממכם כבעלי עסקים ולכן חשוב מאד לגשת לכל יצירת תהליך, שיפור תהליך, הכנסת תוכנה חדשה לעסק, הכנסת מערכת לניהול קשרי לקוחות וכ"ו, מתוך נכונות לעשות את כל הנ"ל,
וכל זה אם אתם באמת רוצים שהתוצאות יהיו לשביעות רצונכם וישפרו את העסק בכל היבט אפשרי.
מתודולוגיית הפיתוח Agile היא תהליך איטרטיבי ומצטבר, המאפשר לצוות לספק תוכנה עובדת במחזורים קצרים.
המושג Agile הוצג בשנת 2001 על ידי 17 אנשים שעבדו על פרויקט בשם "Scrum".
המתודולוגיה האג'ילית מדגישה שיתוף פעולה, גישות איטרטיביות ומצטברות לפיתוח תוכנה.
זוהי גישה אדפטיבית לפיתוח תוכנה המאפשרת לבצע שינויים במהירות, עם משוב ושיפורים מתמשכים.
חמישה שלבי תכנון
הצעד הראשון בתכנון עבודה ב-Agile הוא יצירת צבר מוצרים (מוצר יכול להיות תוכנה או אוטומציה לתהליכים בעסק), שהוא למעשה רשימה של כל מה שרוצים לבצע.
השלב השני הוא תעדוף העומס והחלטה על סדרי עדיפויות.
השלב השלישי הוא פיצול מה שצריך לבצע (תוכנה או תהליך) לגושים קטנים יותר של עבודה, הנקראים ספרינטים.
השלב הרביעי הוא הקצאת משימות ואחריות לכל ספרינט (יחידת עבודה שהיא תוצאה של הפיצול לגושים קטנים בשלב השלישי הנ"ל).
השלב החמישי הוא אומדן כמה זמן יידרש עבור כל משימה ולאחר מכן עדכון צבר ההזמנות עם הערכות אלו.
לבסוף, כל יום או לפחות כל שבוע צריכה להיות פגישה בין כל חברי הצוות המיישם.
עקרון חשוב בשיטה הוא שמירה על צוות קטן, בדרך כלל עם 5-9 אנשים כדי לאפשר תקשורת מהירה וזריזה בין כולם. בנוסף איסוף משוב מלקוחות לעתים קרובות, וביצוע שינויים על סמך משוב הם עקרונות מרכזיים נוספים.
משמעות איטרציה או מחזור עבודה
כאמור, אחד היתרונות הכי חשובים של גישת העבודה האג'ילית הוא חלוקה למחזורי עבודה קטנים.
שמו לב, אם אתם רוצים להיות לקוחות שמקבלים שירותי אוטומציה לדוגמא, אתם חייבים להתגבר על היצר "לאכול הכל בבת אחת, כאן ועכשיו, ומיד".
כמה שהנ"ל מובן בגלל רצון לשפר את העסק ולדחוף אותו קדימה, חשוב להבין שלבצע "הכל בבת אחת" לא יגרום ליישום יותר מהיר אלא בדיוק ההיפך מכך, ליישום איטי יותר והכי גרוע לבעיות שיתגלו (ותמיד יש בעיות ומכשולים שלא רואים בהתחלת העבודה וצצות רק אחרי שניכנסים עמוק לתוך היישום) מאוחר בתהליך ויגרמו לתיקונים שבתורם יגרמו לחלקים אחרים בפתרון לא לעבוד וגם הם יהיו חייבים בתיקונים, וככה הלאה בתגובת שרשרת שתגרום בסופו של דבר ללכת שני צעדים קדימה ושלושה צעדים אחורה, לעיכובים, ולעלות גבוהה יותר של הפרויקט, שלא לדבר על תסכול ועצבים מיותרים מכל צד, בין אם זה מהצד של מיישמי הפורייקט או מהצד של הלקוחות.
שימו לב כמה חוכמה יש לשיטה הזאת. היא נוסדה מתוך הבנה וניסיון רע ומר של פרויקטים רבים שנתקעו במשך חודשים ושנים בתוך כאוס של תיקונים, בעיות, ושוב תיקונים, שרשרת של תגובות בכל המערכת בגלל תיקונים ושינויים ברכיבי בסיס של המערכת, כשהכל כבר גמור, בזבוז כספים, בזבוז זמן, תסכול, עצבים, "צעד קדימה ושניים אחורה", מריבות בין המיישם ללקוח, ועוד…
והכל בגלל הרצון "לאכול את הכל בבת אחת" כלומר להתחיל את הפרויקט ולסיים אותו ביחידה אחת ענקית עם תכולה ענקית ללא חשיבה על מחזורי עבודה קטנים ובדיקה שלהם והתקדמות שלב שלב כשכל שלב ניבנה על הקודם לו.
חשוב להבין שכל מחזור עבודה בגישת ה-Agile ליישום של יחידת עבודה או ספרינט, מורכב מ-4 שלבים שונים:
1) תכנון – צריך להגדיר את הדרישות והמטרות של הפרויקט.
2) פיתוח – צריך ליצור תוכנית כיצד יפתחו את הפרויקט.
3) בדיקות – צריך לוודא שהכל עובד כמצופה ובהתאם לתכנון ןלדרישות הלקוח, לפני שהתוצר מוצג ללקוח.
4) תחזוקה – לאחר השחרור של התוצר, תמיד יש באגים או שגיאות שצריך לתקן אז השלב הזה מבטיח שגם אלה יטופלו.
איך מיישמים כל איטרציה הלכה למעשה
חשוב להבין שאחרי תכנון נכון וחלוקה למחזורי עבודה קטנים (כשכל מחזור לא ארוך יותר משבועיים של עבודה),
צריך יהיה לבצע את כל 4 השלבים הרשומים לעיל.
כמו שכתבתי בנ"ל, אתם כלקוחות, חייבים להיות מוכנים, אחרי סיום שלב 3 לעיל, דהיינו שלב הבדיקות, כאשר התוצר מוצג לכם, לבצע את הבדיקות שאכן קיבלתם את מה שתוכנן ואכן האוטומציה מבצעת את התהליך העסקי הרצוי. אחרי סיום הבדיקות שלכם, אתם ורק אתם תאשרו האם ניתן להמשיך לשלב הבא (לספרינט הבא כלומר ליחידת העבודה הבאה) או שיש באגים ותקלות שאתם רוצים לתקן.
אתם חייבים להיות מוכנים לתאר את כל הבעיות שמצאתם בפירוט הכי רב שאפשר כדי לעזור לאנשי האוטומציה שלכם לשחזר את התקלות ולהבין איך לפתור אותן.
אתם חייבים לחכות בסבלנות עד שהכל יתוקן ואז שוב לבדוק וחוזר חלילה עד להגעה למצב שבו אין תקלות והכל עובד כמצופה. אז ורק אז, תאשרו למיישמים להמשיך לשלב הבא (לספרינט הבא כלומר ליחידת העבודה הבאה).
איך כל הנ"ל יביא לסיום מוצלח של פרוייקט האוטומציה שלכם?
אז זהו, כאן בדיוק יבואו לביטוי המרכיבים שיגרמו להצלחת הפרוייקט.
בגלל שבוצעה חלוקה של העבודה לחלקים קטנים, סיום עבודה על כל חלק, בדיקה שלו, ווידוי שהכל עובד תקין, ואם לא אז כמובן יבוצעו תיקונים כנדרש ואז כשהכל עובד תקין, יהיה אישור שלכם כלקוח שהתנסה בעצמו באוטומציה ושהיא אכן מבצעת את מה שרציתם לקבל, כל היתרונות הבאים יתרחשו:
לא יהיה מקרה שבו העבודה על כל הפרוייקט תסתיים ורק אז תבדקו מה שקיבלתם, "ותקבלו חום" אחרי שתראו שזה בכלל לא מה שהתכוונתם לקבל.
לא יהיה מקרה שבו "התחבאה איזושהי עז" , כלומר בעיה שקשה היה להיות מודעים לה מהתחלת העבודה על הפרוייקט, והיא לא התגלתה ותוקנה במהלך סבבי העבודה בכל איטרציה (מחזור) של יישום יחידת עבודה מסויימת.
שימו לב שבעיה כזאת (או "עז עקשנית במיוחד") יכולה לגרום, בשלבים מאוחרים של הפרויקט, למצב שבו יהיו חייבים לחזור אחורה ולבצע שוב מחדש את כל הפרויקט, בייחוד אם מדובר על בעיה בסיסית ומהותית שכל המערכת או הפתרון תלויים בה וזה למעשה הבסיס שהכל, או חלקים מרכזיים בפתרון, תלויים בו.
זה בדיוק מה שקרה אינספור פעמים להמון פרויקטים שבוצעו בשיטת "לאכול את הכל בבת אחת" כפי שתיארתי לעיל, וזה בדיוק מה שגרם את ה"צעד קדימה ושני צעדים אחורה".
לא יהיה מצב שבו אתם כלקוחות לא "הרגשתם את הפתרון באצבעות" וחוויתם בדיוק איך הוא עובד.
לא יהיה מקרה שבו לא תהיו מודעים לתקציב ולזמנים של יחידת עבודה, מאחר ואתם מעורבים ומאשרים כל יחידת עבודה, ובמידה והתגלו דברים שלא היו ידועים מהתחלה (כאמור, "העיזים" החביבות שלנו:-) שיחייבו תוספת זמן ותקציב, תבינו בדיוק למה הם נידרשים, ומה נידרש כדי ליישם אותם.
כמעט כל פרוייקט אוטומציה, משתנה במהלך תהליך הפיתוח והיישום שלו
כאמור לעיל, שיטת העבודה האג'ילית מתמקדת ברעיון שרוב הפרויקטים ישתנו במהלך תהליך הפיתוח.
אני שוב מדגיש את זה כי ראיתי את זה קורה כל כך הרבה פעמים שאני ממש חייב לחזור על זה.
אתם חייבים להיות מוכנים ומודעים לזה שאם אתם בעסקים אתם גם בעסקי האוטומציה (בהנחה כמובן שאתם רוצים לייעל את העסק שלכם), אתם גם בעסקי פרוייקטים של אוטומציה, ואתם גם בעסקי הבדיקות הווידוי שהפתרון אכן עובד ומבצע את מה שאתם צריכים שהוא יבצע.
וכמובן שאתם גם בעסקי "הופה, הנה בעייה שלא היינו מודעים לה כל עוד לא ניכנסנו לפרטי הפרטים של יישום הפתרון" , ועכשיו צריך להתמודד ולמצוא פתרון יצירתי ויעיל בשיתוף עם המיישמים שלכם.
אתם כמובן גם בעסקי האנשים, תקשורת טובה עם המיישמים שלכם, סבלנות, הבנה, בלי עצבים ואגו נפוח.
אם תבצעו את כל הנ"ל, בין אם אתם לקוחות או בין אם אתם נותני שירותי פיתוח אוטומציה למיניהם, תצליחו ביחד (עם דגש על ביחד) לפתור כל בעיה ולהביא לסיום מוצלח של כל פרוייקט אוטומציה שתחליטו לבצע.