משתמש:ABHB260576/טיוטה

זמישות באנגלית: (Agile)  

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

מהו ניהול פרויקט זמיש

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

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

עקרונות יישום ניהול בפרויקט זמיש

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

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

פתרון לא שלם המסופק בזמן קצר

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

למי מתאים פיתוח זמיש?

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

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

מודל זמיש לעומת מודל מפל המים

זמישות	מפל מים
מתודולוגיה זריזה מצטברת ואינטראקטיבית	מתודולוגיה רציפה ולינארית
הדרישות צפויות להשתנות והשינויים משולבים בכל נקודה	יש להקפיא דרישות בתחילת ה- (SDLC(System Development Life Cycle
המודל העובד מועבר במהלך השלבים הראשוניים ללקוח לצורך משוב	המודל העובד של התוכנה מועבר בשלבים המאוחרים יותר של (SDLC(System Development Life Cycle
שינוי גודל של פרויקטים קל בגלל הגישה האינטראקטיבית	קשה לפרוס פרויקטים על בסיס מתודולוגיית המפלים
אינטראקציות תדירות עם לקוחות ומשובים מעורבים במתודולוגיה זריזה	ללקוחות או למשתמש הקצה אין אמירה לאחר שהקפיאו את הדרישות במהלך השלבים הראשונים. הלקוחות מכירים את המוצר הסופי רק ברגע שהוא בנוי לחלוטין
בשיטה הזמישה תיעוד לעתים קרובות מוזנח, ואב-טיפוס עובד משמש לקוחות כבסיס להערכה ולמשוב	מפל דורש תיעוד רשמי
בדיקה רציפה מבוצעת במהלך כל איטרציה	הבדיקה מתבצעת לאחר בניית התוכנה

היסטוריה

כיצד נולדה שיטת הזמישות (Agile) ?

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

"Application delivery lag”

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

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

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

התסכולים הנ"ל סביב שיטת העבודה של מפל המים לפיתוח תוכנה, הובילו לפגישת של קבוצת מתכנתים ב 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).

ראה גם

• Scrum

קישורים חיצונים

• מאמרים אקדמים:
  • Protecting Organization Reputations During a Crisis: The Development and Application of Situational Crisis Communication Theory
  • Information technology Risk Management and Compliance in Modern Organizations