פיתוח מבוסס על מפרטים

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

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

מהו פיתוח מבוסס מפרטים?#

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

הוא מפריד בין שתי החלטות שקל לערבב יחדיו:

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

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

כיצד תהליך העבודה פועל ב-Coroid#

1. תארו את התוצאה הרצויה. מסרו ל-Coroid את התוצאה הדרושה, ההקשר הרלוונטי ואת המגבלות או היעדים שאינם רצויים.
2. סקרו את המפרט. בדקו את ההגדרה של התחום, היוצאים מהתחום וקריטריוני הקבלה ב-כרטיסייה "מפרט" של המשימה. מפרט כרטיסייה
3. אשררו את התוכנית. הארכיטקט הופך את התוצאה המוסכמת לצעדי ביצוע מסודרים.
4. בנו ובדקו. סוכני הפיתוח ובקרת האיכות משתמשים באותם קריטריונים כדי לבצע את השינוי ולהוכיח כל התנהגות שהובטחה.
5. סקרו את ה-pull request. השינוי שנמסר כולל את התוכנית, תוצאות הבדיקה, הממצאים והראיות שחוזרים למפרט המקורי.

התוצאה היא יכולת מעקב מהכוונה של המוצר ועד לקוד ולראיות שהמבקר האנושי רואה. צפו ב כיצד משימה הופכת ל-pull request כדי לראות את כל מסלול הביצוע.

מדוע השלב הנוסף?#

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

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

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

מה כולל מפרט?#

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

דוגמה מעשית: מהתיאור הקצר למפרט ניתן לבדיקה#

נניח שהתיאור הראשוני הוא:

Add caching to the user lookup so repeated requests are faster.

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

Scope
- Cache successful user lookups by user id for 60 seconds.
- Invalidate the cached entry when the user record is updated.

Out of scope
- Do not cache failed lookups.
- Do not change the public signature of getUser.

Acceptance criteria
- Two lookups for the same user id within 60 seconds call the data source once.
- Updating that user invalidates the existing cache entry.
- A cache miss preserves the current result and error behavior.

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

דוגמה מתועדת: Chrono City#

במשימת Chrono City ב־Coroid, קריטריון הקבלה מספר 3 דרש שהתקופה של שנת 1985 תוצג כאשר ייבחרה. הגרסה הראשונה שינתה את תווית השנה אך השאירה את הסצנה כשטח סגול ריק. צוות הבקרה שיחזר את התקלה שלוש פעמים בדפדפן פעיל ושלח את המשימה חזרה. במחזור השני, צוות הבקרה אישר את קווי הרקיע באמצעות הסליידר וגם מקש 3. המשימה הגיעה ל־pull request רק לאחר שכל 11 הקריטריונים נענו. קראו על תהליך עבודת Chrono City כדי לראות צילומי מסך, רצף ביצועים, זמן ביצוע ועלויות מודל.

מה הופך קריטריוני קבלה לטובים?#

הם חייבים להיות ניתנים לבדיקה על ידי מישהו שלא היה מעורב בשיחה.

חלשים:

Caching works correctly and performance is improved.

חזקים:

- Repeated lookups for the same user id within 60s hit the cache, verified
  by a test asserting the data source is called once across two lookups.
- Cache entries are invalidated when the user record is updated.
- A cache miss behaves identically to today, including error handling.
- No change to the public signature of `getUser`.

הגרסה השנייה מורה לסוכן המפתחים מה לבנות, לסוכן הבקרה מה לבדוק, ולכם מה לבדוק ב־pull request. הגרסה הראשונה משאירה כל אחת מההחלטות פתוחה.

קווי היקף חשובים באותה מידה כמו קריטריונים#

הסיבה הנפוצה ביותר להגדלת ה־pull request אינה סוכן החורג מההנחיה – אלא מפרט שלא ציין היכן ההנחיה מסתיימת.

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

טעויות נפוצות במפרטים#

כאשר אינכם מסכימים איתו#

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

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

לאן זה הולך מכאן#

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

שאלות נפוצות#

האם מפרט שווה לתכנון טכני?#

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

האם כל שינוי דורש מפרט ארוך?#

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

מי צריך לאשר את המפרט?#

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

האם ניתן לשנות מפרט לאחר תחילת העבודה?#

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

קשורים#

• כיצד משימה הופכת ל־pull request
• זרימת עבודה של מחזור חיי פיתוח התוכנה
• תיאור מה שאתם צריכים
• הקשר הפרויקט