Extreme Programming

הנדסת תוכנה
ערך זה שייך לקטגוריית הנדסת תוכנה
פעילויות ושלבים
דרישות • ניתוח • אפיון • ארכיטקטורה • עיצוב • תכנות • ניפוי שגיאות • בדיקה • אימות • בנייה • פריסה • תפעול • תחזוקה
מתודולוגיות
זריזות • מפל המים • תכנת ותקן • Crystal Clear • Scrum • Unified Process • Extreme Programming • אינטגרציה רציפה • DevOps
תחומים תומכים
ניהול פרויקטים • ניהול תצורה • תיעוד • הבטחת איכות • Profiling
כלים
מהדר • מקשר • מפרש • IDE • ניהול גרסאות • אוטומציית בנייה

Extreme Programming (או בקיצור XP) היא מתודולוגיית פיתוח תוכנה שנהגתה על ידי קנט בק. המתודולוגיה תוארה לראשונה בשנת 2000 בספרו של בק eXtreme Programming Explained, אך קדמו לו פרסומים לא רשמיים ודיונים רבים בחוגי פיתוח תוכנה זריז והנדסת תוכנה.

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

יסודות ומונחים

ערכי היסוד של XP הם:

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

XP משתמשת במספר מונחים:

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

עקרונות

מעגל התכנון והמשוב של XP וציון מסגרות הזמן

מהיסודות שלעיל, יצרה XP תריסר מנהגים / עקרונות (practices), המסודרים בשלושה מעגלים:

המעגל הפנימי

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

המעגל האמצעי

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

המעגל החיצוני

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

אימוץ

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