Coroid משתמש ב פיתוח מבוסס מפרטים: המפרט נשאר יחד עם חלק העבודה מתהליך התכנון ועד לבדיקה וסקירה, כך שכל שלב פועל על פי אותה הגדרה של הצלחה.
במקום להתחיל ממשפט ולקבוע את הפרטים בזמן כתיבת הקוד, Coroid הופך את הבקשה להגדרת תחום מפורשת, יוצאים מהתחום וקריטריוני קבלה. המסמך הזה הופך למקור האמת עבור התוכנית, הביצוע, הבדיקות והסקירה הסופית.
מהו פיתוח מבוסס מפרטים?
פיתוח מבוסס מפרטים הוא דרך לבנות תוכנה מתיאור מוסכם וניתן לבדיקה של התוצאה. המפרט מגדיר מה ישתנה, מה לא ישתנה, אילו מגבלות חלות וכיצד המבקר יוכל לדעת שהעבודה הצליחה.
הוא מפריד בין שתי החלטות שקל לערבב יחדיו:
- ה מפרט מגדיר מהי הצלחה.
- ה תוכנית ביצוע מגדירה כיצד להשיג זאת.
הפרדה זו מאפשרת לתקן את ההגדרה של התחום לפני קיומו של קוד, מבלי לקבוע את האופן שבו יתבצע הביצוע מוקדם מדי. ב-Coroid, ניתן גם להפעיל את תהליך העבודה האופציונלי של זרם עבודה של SDLC כאשר רוצים לאשר את הכוונה ואת המפרט לפני תחילת התכנון.
כיצד תהליך העבודה פועל ב-Coroid
- תארו את התוצאה הרצויה. מסרו ל-Coroid את התוצאה הדרושה, ההקשר הרלוונטי ואת המגבלות או היעדים שאינם רצויים.
- סקרו את המפרט. בדקו את ההגדרה של התחום, היוצאים מהתחום וקריטריוני הקבלה ב-כרטיסייה "מפרט" של המשימה. מפרט כרטיסייה
- אשררו את התוכנית. הארכיטקט הופך את התוצאה המוסכמת לצעדי ביצוע מסודרים.
- בנו ובדקו. סוכני הפיתוח ובקרת האיכות משתמשים באותם קריטריונים כדי לבצע את השינוי ולהוכיח כל התנהגות שהובטחה.
- סקרו את ה-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 עם ההתנהגות המובטחת.
מה הופך קריטריוני קבלה לטובים?
הם חייבים להיות ניתנים לבדיקה על ידי מישהו שלא היה מעורב בשיחה.
חלש:
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`.הגרסה השנייה מודיעה לסוכן המפתחים מה לבנות, לסוכן ה-QA מה לבדוק, ולך מה לבדוק ב-pull request. הגרסה הראשונה משאירה כל אחת מההחלטות הללו פתוחה.
הגדרת היקף העבודה חשובה לא פחות מהקריטריונים
הסיבה הנפוצה ביותר להיקף עבודה גדול מדי של ה-pull request אינה קשורה לחריגה של הסוכן מהתיאור – אלא למפרט שלא ציין היכן מסתיים התיאור.
אם אינך רוצה שמודול הסמוך יעבור ריפקטורינג בזמן שהעבודה מתבצעת, ציין זאת. 'אין לשנות את נקודות הקריאה' הוא קו מנחה לגיטימי ושימושי.
טעויות נפוצות במפרטים
| טעות | גישה טובה יותר |
|---|---|
| תיאור היישום במקום התוצאה | ציין את ההתנהגות והמגבלות, ואז תן לתוכנית לבחור את היישום |
| שימוש במילים כמו 'מהיר', 'בטוח' או 'פועל כראוי' | החליף אותן בסף ניתן לתצפית, התנהגות או בדיקה |
| השמטת מטרות שאינן רצויות | ציין קוד, ממשקים או התנהגויות סמוכים שחייבים להישאר ללא שינוי |
| שילוב תוצאות לא קשורות | חלק את העבודה כך שמשימה אחת תסתיים ב-pull request שניתן לבדוק על ידי אדם אחד בפגישה אחת. |
| העתקת כרטיס ללא בדיקת ההנחות | הוסף את ההקשר וההחלטות שהמאגר אינו יכול לחשוף |
כשאינך מסכים איתו
ערוך אותו. המפרט הוא מסמך דינמי עד תחילת הביצוע, ותיקונו זול בהרבה מתיקון הקוד שהיה נוצר ממנו.
אם המפרט מגלה שהעבודה היא למעשה שתי יחידות עבודה, חלק אותה לשתי משימות. משימה אחת צריכה להסתיים ב-pull request שאדם אחד יכול לבדוק בפגישה אחת.
לאן זה הולך מכאן
במקרים של שינויים מורכבים יותר, המפרט הופך לתוכנית עבודה. צפו ב- משימות, תוכניות, ספרינטים ונתיבי עבודה, המסביר כיצד העבודה מתחלקת ומתאשרת לפני כתיבת קוד.
שאלות נפוצות
האם מפרט זהה לתכנון טכני?
לא. המפרט מגדיר את התוצאה הרצויה ואת הגבולות שלה. תכנון טכני או תוכנית יישום מסבירים את הארכיטקטורה והצעדים הדרושים כדי להשיג את אותה תוצאה.
האם כל שינוי דורש מפרט מפורט?
לא. שינוי קטן וברור עשוי לדרוש רק מספר שורות של הגדרת היקף וקריטריוני קבלה. המפרט צריך לסלק חוסר ודאות משמעותי ולא להוסיף פורמליות מיותרת.
מי צריך לאשר את המפרט?
האדם האחראי על התוצאה צריך לאשר שהיקף העבודה והקריטריונים תואמים את הצרכים של הצוות. מאשרים טכניים, בתחום האבטחה או התאמה לתקנות יכולים להשתתף כאשר ההגבלות שלהם משפיעות על הצלחת הפרויקט.
האם ניתן לשנות מפרט לאחר תחילת העבודה?
ניתן, אך השינוי צריך ליצור גרסה חדשה ולדרוש סקירה של התוכנית והעבודה התלויות בה. שינויי היקף ללא ידיעה מפריעים לשרשרת הראיות שבין הבקשה לבין ה-pull request שנמסר.