Coroid מדמה מחזור חיים מלא של תוכנה, ולא רק את שלב הבנייה. רוב התהליך מתבצע באופן אוטומטי; חלק אחד הוא נקודת בדיקה אופציונלית שניתן להפעיל כאשר העבודה חשובה מספיק כדי להצדיק זאת.
מחזור העבודה של SDLC האופציונלי
בתוך ה עבודה חדשה טופס, תחת הגדרות מתקדמות, קיים תיבה לסימון:
השתמשו במחזור העבודה של SDLC (אופציונלי) — בדקו את הכוונה והמפרט לפני תחילת התכנון. השאירו אפשרות זו כבויה כדי להתחיל בתכנון ישירות מהתיאור הקצר שלכם.
האפשרות הזו כבויה כברירת מחדל. כאשר האפשרות כבויה, התיאור שלכם עובר ישירות לתכנון. כאשר היא מופעלת, נוצרים ומאושרים קודם שני פריטים:
- כוונה — מטרת העבודה בפועל, יחד עם ההחלטות וההנחות שעומדות בבסיסה.
- מפרט — היקף העבודה, הסעיפים שאינם כלולים וקריטריוני הקבלה.
רק לאחר אישור שני הפריטים הללו מתחיל התכנון.
מתי להפעיל אותה?
הפעילו אותה כאשר עלות בניית המוצר הלא נכון גבוהה, כאשר הבקשה הגיעה מאדם שאינו מתכוון לבחון את התכנון בעצמו, או כאשר התיאור מכיל הנחה שהייתם מעדיפים לראות כתובה ומאושרת.
השאירו אותה כבויה כאשר התיאור כבר ברור לחלוטין. שער אישור נוסף על עבודה שגרתית יוצר חיכוך ללא תועלת — וה אישור התכנון שלב עדיין חל על כל מקרה.
חמש תחנות העבודה
מחזור החיים המלא מתבצע בחמישה שלבים, כאשר כל שלב מייצר ראיות שהשלב הבא משתמש בהן.
| תחנה | מה קורה בשלב זה? | מצב |
|---|---|---|
| הגדרה | בקשה עמומה הופכת לכוונה מאושרת, החלטות, הנחות ומדדי הצלחה. | גרסת בטא |
| ויזואליזציה | רעיונות UI אופציונליים, המעובדים ומאושרים כהנחיות עיצוב. | גרסת בטא |
| מסירה | התוכנית מתפרקת והסוכנים מבצעים אותה | זמין |
| להוכיח | דרישות מתויגות לפי משימות, בדיקות, ממצאי ביקורת ושינויים בקובץ בקשת משיכה | זמין |
| לשפר | מערכות ניטור, תיקון והערכה הופכות תקלות חזרה לעבודה של המחזור הבא | זמין |
הגדרה ויזואליזציה הן שתי פונקציות בתהליך פיתוח פעיל. אספקה, הוכחה ושיפור הן הפעולות המתבצעות על כל משימה כיום, בין אם תבחרו להפעיל את נקודת הביקורת או לא.
מדוע הפריטים מוגדרים כגרסאות
אישורים קשורים לגרסה מדויקת של פריט. עריכת פריט שכבר אושר יוצרת טיוטה חדשה במקום לשנות בשקט את מה שהוסכם עליו.
זה מה שהופך אישור לבעל משמעות. אישור שנשאר צף – מחובר ל'מפרט' ולא לגרסה ספציפית שלו – מאשר כל דבר שהמסמך יציין בהמשך, מה שבכלל אינו אישור.
תפקידי אישור
ניתן להקצות באופן עצמאי אחריות בתחומי המוצר, עיצוב, טכני, אבטחה ושחרור, כך שהאדם המאשר את ההשלכות התפעוליות אינו בהכרח זה המאשר את היקף העבודה.
שרשרת הוכחות
המטרה ביצירת הוכחות בכל שלב היא שניתן יהיה לעקוב אחורה אחר תוצר pull request המוגמר: שינוי זה מממש משימה זו, שמקורה בדרישה זו, שמקורה בכוונה מאושרת זו.
שרשרת זו היא שמאפשרת ביקורת על אספקה אוטונומית. בלעדיה יש קוד שפועל אך אין תיעוד לגבי הסיבה שהוא הקוד שביקשתם.
כיצד זה קשור לתוכניות
תהליך ה-SDLC ו תוכניות הם נקודות ביקורת שונות:
- ה תהליך ה-SDLC מאשר מה יש לבנות, עוד לפני שקיים גישה מסוימת.
- ה תוכנית מאשר כיצד הוא ייבנה, עוד לפני שקיים קוד.
ניתן להשתמש באחד מהם, בשניהם או באף אחד מהם. שניהם זולים יותר מאשר לבחון תוצר pull request מוגמר שאינכם מסכימים איתו.