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