קצת היסטוריה- כיצד נולדו שיטות הAgile  ?

בתחילת שנות ה90, כאשר שימוש במחשבים אישיים לעובדים תפס תאוצה, ענף פיתוח התוכנה היה במשבר שכונה "המשבר בפיתוח יישומים- The application development crisis ", או "ההשהייה במסירת אפליקציות -  Application delivery lag."

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

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

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

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

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

 

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

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

במקביל- התסכולים הנ"ל סביב שיטת העבודה של מפל המים לפיתוח תוכנה, שהיו משותפים לאנשי מקצוע בעלי דעות דומות, הובילו לפגישת של קבוצת מתכנתים ב Rogue River Lodge במדינת אורגון בארה"ב באביב 2000 וכן לפגישת Snowbird המפורסמת במדינת יוטה בארה"ב ב 2001.

 קבוצה זו כללה את Jon Kern, Kent Beck, Ward Cunningham, Arie van Bennekum, Alistair Cockburn ו12 מתכנתים נוספים, כולם ידועים מאוד כיום בקהילת ה Agile.

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

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

1. מאפשרת למשתמשים לקבל חלק מהתועלות העסקיות (business benefits) של התוכנה החדשה מהר יותר
2. מאפשרת לצוות התוכנה לקבל משוב מהיר (rapid feedback) על הכיוון שיש להמשיך ולפתח את התוכנה מבחינת תכולת העבודה והדרישות מהתוכנה

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

אז מה הם עקרונות ה Agile ?

4 עקרונות העל המנחים, שנוסחו ע"י הצוות הנ"ל, שנקראים גם המניפסט- Agile Manifesto, הם:

1. יחידים ואינטראקציות חשובים יותר מתהליכים וכלים

   Individuals and Interactions over Processes and Tools

2. תוכנה עובדת חשובה יותר מתיעוד מקיף

   Working Software over Comprehensive Documentation

3. שיתוף פעולה של לקוחות חשוב יותר ממשא ומתן על החוזה

   Customer Collaboration over Contract Negotiation

4. תגובה לשינוי חשובה יותר מהיצמדות לתוכנית

   Responding to change over following a plan

עקרונות העל הללו תורגמו לסדרה מפורטת יותר של 12 הנחיות עבודה:

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

   The highest priority is to satisfy the customer through early and continuous delivery of valuable software

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

   Welcome changing requirements, even late in development, Agile processes harness change for the customer's competitive advantage

3. לספק תוכנה עובדת לעתים קרובות, החל מכל שבועיים עד כל חודשיים, עם העדפה לטווח הקצר יותר

   Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale 

   המשמעות היא עבודה באיטרציות:

    

4. אנשי עסקים ומפתחים חייבים לעבוד יחד מדי יום במהלך הפרויקט

   Business people & developers must work together daily throughout the project 

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

   Build projects around motivated individuals. Give them the environment and support their needs, trust them to get the job done 

6. השיטה היעילה ביותר להעברת מידע לצוות הפיתוח היא בשיחה פנים אל פנים

   The most efficient & effective method of conveying information to and within a development team is a face-to-face conversation

7. תוכנה עובדת היא המדד העיקרי של התקדמות

   Working software is the primary measure of progress

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

   Agile processes promote sustainable development. The sponsors, developers & users should be able to maintain a constant pace indefinitely

9. תשומת לב רציפה למצוינות טכנית ואפיון טוב משפרת את היכולת לפתח בזריזות וגמישות (לפתח בזמישות)

   Continuous attention to technical excellence & good design enhances agility

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

    Simplicity-the art of maximizing the amount of work not done-is essential 

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

    The best architectures, requirements & designs emerge from self-organizing teams 

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

    At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly 

מהעקרונות והנחיות העבודה הנ"ל צמחה משפחה של שיטות אג'יליות, שביניהן-

Scrum, Extreme Programming (XP), Lean Software Development, Dynamic Systems Development Method (DSDM), Crystal, Lean Kanban

כיום אנו רואים תעשיות שאינן תוכנה מאמצות שיטות אג'יליות או עקרונות אג'יליים, יחד עם זאת בל נשכח- שעקרונות שיטות האג'ייל עצמה והפיתוח שלהן, הושפעו תחילה משיטות של ניהול רזה- Lean Management, Kanban, ושיטות של אספקת מלאי בדיוק בזמן- Just In Time, שהיו קיימות כבר בעולם ניהול הייצור וניהול המלאי.

לגבי התנופה שמשפחת שיטות ה Agile תפסה ניתן ללמוד מכך שהPMBOK ® (Project Management Body Of Knowledge) מהדורה 6, שפורסם ב2017, ע"י ארגון ה PMI ® הוסיף לראשונה בכל 10 שטחי הידע לניהול פרויקטים התייחסות מפורטת  לאג'ייל תחת הכותרת-Considerationss for Agile/Adaptive Environments.

הסבר לגבי השיטות הנ"ל? במאמרים הבאים :)

מאמר זה נכתב ע"י
       דן ברזילי,MEng ,BSc ,PMP
       מנכ"ל ומנהל פרויקטים