מתודולוגיות לפיתוח תוכנה

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

מפל מים

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

• תיעוד מלא ועקבי בכל שלב;
• קלות שימוש;
• דרישות יציבות.
• התקציב והמועדים נקבעים מראש

פגמים:

• כמות גדולה של תיעוד;
• מערכת לא מאוד גמישה;
• הלקוח אינו יכול להציג את גרסת ההדגמה של המוצר;
• אין דרך לחזור צעד אחורה.

Scrum

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

• צוות Scrum הוא צוות שעובד על פרויקט (מפתחים, בודקים, מעצבים).
• Scrum Master הוא אדם שמבטיח שהעקרונות של Scrum יתבצעו.
• בעל מוצר – לקוח.

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

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

יתרונות:

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

פגמים:

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

קנבן

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

• לעשות - רשימה של משימות שצריך לעשות
• בתהליך - משימות שעובדים עליהן כעת
• סקירת קוד – משימות שהושלמו ונשלחו לבדיקה
• בבדיקה - משימות מוכנות לבדיקה
• בוצע - ביצוע משימות.

יתרונות:

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

פגמים:

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

לסיכום על מתודולוגיית פיתוח תוכנה

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