CodeGym /בלוג Java /Random-HE /כל מה שאתה צריך לדעת על מתודולוגיות פיתוח תוכנה: מגמות, ע...
John Squirrels
רָמָה
San Francisco

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

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

שימו לב, מתחילים! מודלים, מתודולוגיות ובלבול כללי

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

1. Scrum

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

יתרונות:

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

חסרונות:

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

בשביל מי זה?

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

2. קנבן

המאפיין החשוב ביותר של Kanban הוא הדמיה של מחזור החיים של הפרויקט . נוצרות עמודות לביצוע פריטי עבודה. נושאי העבודה מטופלים בנפרד. העמודות מסומנות בסטטוסים כמו: To do, In progress, Code review, In testing, Done (כמובן, שמות העמודות עשויים להשתנות). המטרה של כל חבר צוות היא לצמצם את מספר פריטי העבודה בעמודה הראשונה. הגישה של Kanban היא אינטואיטיבית ועוזרת לך להבין היכן טמונות הבעיות. המבנה של Kanban אינו קבוע באופן סופי ובלתי הפיך: בהתאם לפרטי הפרויקט, אתה יכול להוסיף עמודות מאולתרות. לדוגמה, צוותים מסוימים משתמשים במערכת שבה עליך להגדיר כללים שנעשו עבור פריט עבודה לפני ביצועו. במקרה זה, מתווספות שתי עמודות: ציין (ציין את הפרמטרים) ויישום (התחל לעבוד).

יתרונות:

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

חסרונות:

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

בשביל מי זה?

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

3. תהליך מאוחד רציונלי (RUP)

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

יתרונות:

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

חסרונות:

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

בשביל מי זה?

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

יש הרבה מתודולוגיות, אבל מגמה אחת

בנוסף ל-scrum ול-Kanban, שהם ללא ספק פופולריים ומבוססים על עקרונות זריזים , כמו גם למתודולוגיית RUP הקשוחה והאיטרטיבית, חברות משתמשות בווריאציות רבות של מתודולוגיות. חברה אחת עשויה להיות קרובה יותר לתכנות קיצוני ולקבל את ההחלטות המהירות והפשוטות ביותר. אחר עשוי להיות קרוב יותר לפיתוח מונע מבחן. אחר עדיין עשוי להעדיף פיתוח יישומים מהיר (RAD). עם זאת, ישנה מגמה חזקה ובלתי ניתנת לערעור לשימוש במספר מתודולוגיות בו זמנית . או אפילו שילוב מודלים ומתודולוגיות למערכת ניהול ייחודית. החברות של היום שואפות לבטל חסמים בירוקרטיים וליצור אווירה של עבודת צוות מאוחדת בתוך הארגון, ללא העברת אחריות בין מחלקות ויחידות ארגוניות. לפי Scrum Alliance , 70% מחברות ה-IT משתמשות ב-Scrum. ביניהם ענקיות כמו גוגל, אמזון, סיילספורס, מיקרוסופט ואדובי. סטארטאפים ופרויקטים צעירים נוטים יותר לכיוון Kanban, אבל גם טויוטה ולמשל הגיימרים ב-Wargaming משתמשים בזה. Scrum הוא כלי תכנון, בעוד Kanban נועד לניטור ההתקדמות. לגבי RUP, הוא משמש לרוב חברות מערביות עם 50-200 עובדים והכנסות של 1-10 מיליון דולר. עם זאת, IBM שינתה את RUP כדי להתקרב לעקרונות הזריזים, ושחררה את מתודולוגיית OpenUP (RUP, אבל זריזה). מתודולוגיה זריזה מהודרת זו מניעה כעת את עולם ה-IT . זו לא רק אופנה חולפת - היא עדיין חדשנית, ולמעשה היא מנוצלת בחברות גדולות רבות. אג'יל משמש בעמק הסיליקון. פייסבוק ואובר משתמשות בו.

בשורה התחתונה

לכל פרויקט מתודולוגיית פיתוח תוכנה משלו, התלויה בצוות, במימון, במועדים ובדרישות הלקוח. אין טכניקת ניהול אוניברסלית: אפילו המתודולוגיה הזריזה הפופולרית ביותר לא יכולה להבטיח את הגישה הטובה ביותר לתהליך הפיתוח. כתוצאה מכך, מתודולוגיות נבחרות בקפידה, לפעמים אפילו על פי עקרונות. עד כדי כך שנוכל להסיק מסקנות על חברה עצמה או על לקוחותיה על ידי התבוננות במתודולוגיה שלה. מתודולוגיות מעורבות, משלימות מודלים ומותאמות. עד כדי כך שהם מולידים גישות חדשות. עם זאת, תחום הניהול נשאר בסופו של דבר בידיים של scrum ו-Kanban, עם אלמנטים בלתי צפויים של מודל המפל או מתודולוגיית ה-RUP האיטרטיבית.
קריאה נוספת:
אתרי אינטרנט: ספרים:
  • אנדרו סטלמן, ג'ניפר גרין: "למידה זריזה";
  • פר קרול, ברוס מקאייזק: «זריזות ומשמעת בקלות: תרגול מ-OpenUP ו-RUP";
  • מייק קון: "להצליח עם Agile: פיתוח תוכנה באמצעות Scrum";
  • רוברט סי מרטין: "פיתוח תוכנה זריז: עקרונות, דפוסים, שיטות עבודה";
  • מרקוס המרברג, יואקים סונדן: "קנבאן בפעולה";
  • I. Jacobson, G. Booch, J. Rumbaugh: "תהליך פיתוח תוכנה מאוחד".
הערות
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION