פיתוח זריז (Agile)

מאת Image IT
בתאריך 13 יוני, 2013

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

פיתוח זריז (Agile)

הקדמה:

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

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

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

 

פיתוח Agile

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

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

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

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

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

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

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

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

 

יתרונות השיטה:

  • לא חייבים להחליט הכל מראש – מאפיינים ומפתחים רק את מה שיודעים, בהתאם להחלטות מושכלות.
  • מפתחים רק מה שצריך – מכיוון שהפיתוח הינו במודולים קטנים. לא מפתחים מודולים ללא צורך. וכל מה שמפותח, מיידית עובר לשטח ונמדדת מידת "הצלחתו"  ונחיצותו.
  • משלמים רק על מה שצריך – התשלום מתבצע בסוף כל מודול. כך שבכל שלב, הלקוח משלם רק על מה שהוא קיבל ומה שהוא היה צריך. עצם העבודה במודולים קטנים מאפשרת ללקוח שליטה טובה יותר בתזרים והוצאות הפיתוח.
  • ניתן לשנות/לעצור/להאט בכל שלב – שינוי אפיון, שיפור פונקציות, פיתוח יכולות נוספות ו/או שדרוג  קיימות, אפשרי בגמישות גדולה מאד. כך אפשר להגיב במהירות לצרכי השוק ולדרישות המשתמשים.
  • TTM  גבוה (Time To Market). – עבודה במודולים קטנים מאפשרת מתן תוצאה מהיר, גם אם זה לא 100% מהפתרון.

חסרונות השיטה:

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

 

 

אופן העבודה

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

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

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

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

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

 

לסיכום

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

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

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

מכאן שמה של השיטה: פיתוח זריז (Agile).

 

אלו היו, על קצה המזלג, ההיבטים הקשורים  לפיתוח זריז בגישת ה agile.

 

 

יפתח קוניק

מהנדס ויועץ מערכות מידע.

ImageIT

www.imageit.co.il

 

מאמרים נוספים...