מהי מתודולוגיה זריזה? הסביר פיתוח תוכנה מודרני

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

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

Agile הושק רשמית בשנת 2001 כאשר 17 טכנולוגים ניסחו את המניפסט Agile. הם כתבו ארבעה עקרונות עיקריים לניהול פרויקטים זריז, במטרה לפתח תוכנה טובה יותר:

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

לפני זריז: עידן מתודולוגיית המפל

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

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

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

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

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

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

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

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

סרטון קשור: איך באמת מתודולוגיית הזריזות עובדת

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

המפתח לפיתוח תוכנה זריז

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

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

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

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

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

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

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

מעקרונות אלה נולדה המתודולוגיה הזריזה לפיתוח תוכנה.

התפקידים במתודולוגיה הזריזה

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

מִשׁתַמֵשׁ

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

בעל המוצר

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

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

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

צוות פיתוח תוכנה

בזריזות, צוות הפיתוח ואחריות חבריו שונים מאלו בפיתוח תוכנה מסורתי.

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

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

מסגרות Scrum, Kanban ומסגרות זריזות אחרות

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

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

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

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

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

למרות שסקראם שולט, ישנן מסגרות זריזות אחרות:

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

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

אז, למשל:

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

מדוע המתודולוגיה הזריזה טובה יותר