זריז מול מפל: איזו גישה לנקוט בפיתוח אתרים?

זריז מול מפל: איזו גישה לנקוט בפיתוח אתרים?

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

שיטת מפל מים

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

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

זָרִיז

שיטת Agile, המבוססת על ה-Agile Manifesto היא צורה עדכנית יותר המשמשת מפתחים במחזור פיתוח התוכנה שלהם. שיטה זו מתמקדת בלהיות רזה ולפתח MVPs או Minimum Viable Products על פני כל איטרציות במקום לטפל בכל התכנון מראש.

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

ב-Agile, השלבים השונים של פיתוח הפרויקט מתרחשים במקביל, בעוד צבר עוקב אחר התכונות והשיפורים שנוספו. כמה מהיישומים הפופולריים ביותר של Agile כוללים Scrum, Kanban, FDD או פיתוח מונחה תכונות, ASD או פיתוח מערכות אדפטיביות ו-XP או תכנות אקסטרים.

בחירת אחד עבור הפרויקט שלך

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

אתה יכול להשתמש ב-Waterfall כאשר:

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

התפתחות זריזה עוקבת אחר סגנון התפתחות אבולוציוני יותר.

אתה יכול להשתמש ב-Agile כאשר:

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

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

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

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

ההבדלים במבט אחד:

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

זריזות מאפשרת טונות של גמישות, והדרישות המשתנות ללא הרף אינן דורשות דיוק בשמירה.

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

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

תהליך הגישה הליניארית של Waterfall:

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

תהליך גישת הספרינט של Agile

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

סיכום

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

Flikr : //visualpun.ch, mandaruby, לנה אליס


על המחבר: רימה עובדת כמנהיגת מחשבות ב-PHPBabu.

כתיבת תגובה