← מסות

תכנון ספרינט בעזרת AI: איך להאיץ את ההכנה בלי לאבד אחריות

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

19 דקות קריאה
Telegramמקור
תכנון ספרינט בעזרת AI: איך להאיץ את ההכנה בלי לאבד אחריות

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

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

אך זו בדיוק המלכודת.

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

"AI עוזר להרכיב תוכנית שנראית מציאותית. רק הצוות הופך אותה למציאותית."

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

מדוע תכנון הספרינט אינו רק "לאסוף משימות לספרינט"

במדריך Scrum 2020, תכנון הספרינט מתואר כאירוע שמ� iniciates את הספרינט. התוצאה שלו נוצרת בעבודה משותפת של כל צוות הפיתוח.

תכנון הספרינט בנוי סביב שלושה נושאים

  • מדוע הספרינט הזה בעל ערך?
  • מה ניתן לעשות בספרינט הזה?
  • כיצד תבוצע העבודה הנבחרת?

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

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

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

מה AI באמת משנה בתכנון

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

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

עם AI, שכבת ההכנה הזו יכולה להפוך למהירה noticeably יותר — בתנאי שלצוות יש הקשר קלט איכותי ותהליך ברור לבדיקת התוצאה. המודל יכול לעזור לאסוף כמה גרסאות של Sprint Goal, לקבץ פריטי backlog סביב המטרה, להאיר נקודות חולשה בקריטריוני הקבלה, להציע רשימת תלויות, למצוא משימות דומות בהיסטוריה, לשרטט סיכונים ולהכין שאלות ל-QA, backend, frontend ועיצוב. אבל זו אינה הוכחה שה-planning הסופי תמיד יהיה מהיר או מדויק יותר: חלק מהרווח עשוי ללכת לבדיקה אנושית, לאימות מקורות ולתיקון שגיאות בטיוטה.

זה שימושי במיוחד כשהצוות מגיע ל-planning אחרי AI-assisted refinement. במאמר הקודם הראיתי ש-AI עוזר להפוך בקשה גולמית לפריט backlog בוגר יותר מהר. אבל עכשיו עולה השאלה הבאה: אם פריטי ה-backlog נראים טוב יותר, האם זה אומר שגם התוכנית נהייתה טובה יותר?

לא בהכרח.

AI יכול להפוך את חפצי ה-planning למסודרים יותר. הוא יכול ליצור תחושה שהכול כבר מחובר: הנה Sprint Goal, הנה היקף העבודה, הנה הסיכונים, הנה התלויות, הנה הערות בדיקה. אבל זו עדיין לא תוכנית. זו טיוטת תוכנית. והערך של Sprint Planning הוא בדיוק בכך שהצוות בודק את הטיוטה הזו מול המציאות.

הצוות דן ב-AI-assisted Sprint Planning: Sprint Goal, הקיבולת הזמינה של הצוות, תלויות והצעות AI
הצוות דן ב-AI-assisted Sprint Planning: Sprint Goal, הקיבולת הזמינה של הצוות, תלויות והצעות AI

AI עוזר לאסוף מהר יותר גרסאות של Sprint Goal, היקף עבודה, תלויות וסיכונים, אבל אינו מחליף את בדיקת הצוות את ריאליות התוכנית.

נמשיך באותו מקרה: B2B LMS ותזכורות email

כדי לא לדבר באופן מופשט, אמשיך את המקרה מהמאמר הראשון.

יש פלטפורמת B2B LMS ללמידה ארגונית. לקוחות גדולים מקצים לעובדים קורסי חובה בנושאי compliance, אבטחה ותקנות פנימיות. העסק רוצה להוסיף תזכורות email אוטומטיות לעובדים שלא השלימו קורס חובה לפני הדדליין.

ב-refinement הצוות כבר גילה שהמשימה רק נראית פשוטה. למעשה צריך להסכים:

  • מי נחשב כמי שעומד בתנאים לתזכורת;
  • האם לקחת רק קורסי חובה;
  • אילו סטטוסים להתחשב בהם: not_started, in_progress, expired;
  • איך להחריג archived ומשתמשים מושבתים;
  • היכן נשמר אזור הזמן;
  • איך עובדת הגדרת השפה ו-fallback של שפה;
  • איך להתגונן מכפילויות בהרצה חוזרת של משימת ה-scheduler;
  • האם נדרש יומן היסטוריה / יומן ביקורת;
  • מה צריך להיות גלוי לצוות תמיכת הלקוחות;
  • היכן מסתיים היקף העבודה המינימלי של הגרסה הראשונה.

אחרי refinement טוב הצוות יכול להגיע ל-Sprint Planning כבר עם הכנה חזקה. לדוגמה, AI עזר לאסוף טיוטת user story, קריטריוני קבלה, רשימת מקרי קצה, גרסאות של גישה טכנית ושאלות פתוחות. אבל ב-planning צריך לקבל סוג אחר של החלטה: מה בדיוק הצוות לוקח לספרינט הקרוב ובאיזו מטרה.

Sprint Goal גרוע למקרה כזה יכול להיראות כך:

"לעשות scheduler, תזכורות email ויומן היסטוריה."

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

ניסוח חזק יותר:

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

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

איך ה-planning היה נראה בלי AI

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

חצי מהפגישה הולך לא על בחירת תוכנית ריאלית, אלא על העלאת החומר מחדש לראש של הצוות. בשלב מסוים מופיע הפיתוי פשוט "לקחת את כל החשוב": התאמה לתנאים, scheduler, תבנית מייל, דה-דופליקציה / הסרת כפילויות, יומן היסטוריה, הגדרת שפה fallback, אזור זמן, נראות מידע לצוות תמיכת הלקוחות, טיפול ב- expired, הגדרות לקוח ועוד כמה מקרי קצה.

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

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

איך planning משתנה עם AI

עם AI אותה פגישה בדיוק יכולה להתחיל ברמה אחרת.

לפני ה-planning ה-AI עוזר לבעל המוצר להכין כמה וריאנטים של Sprint Goal: גרסה ראשונה צרה, היקף עבודה מוצרי רחב יותר, היקף עבודה בטוח מבחינה טכנית, היקף מורחב ושאפתני. האנליסט מבקש מה-AI לקשר את פריטי הבקלוג לכל וריאנט של מטרה ולהראות אילו מהם אינם תומכים במטרה ישירות. ה-Backend מריץ דרך ה-AI את תיאור ארכיטקטורת ההתראות ומבקש להדגיש את הסיכונים של משימות המתזמן, הדה-דופליקציה והאידמפוטנטיות. ה-Frontend והמעצב בודקים אם ה-UI נדרש בספרינט הראשון או שאפשר להסתפק בתצוגה מינימלית של ההיסטוריה. ה-QA מבקש מה-AI להכין רשימה של תרחישים שליליים, תרחישי גבול ותרחישים התלויים בזמן.

הצוות מגיע ל-planning לא עם דף חלק, אלא עם סט של וריאנטים:

  • היקף עבודה מינימלי: קורסי חובה, not_started / in_progress, החרגת משתמשים בארכיון ומשתמשים מושבתים, תזכורת אחת, הסרת כפילויות, יומן היסטוריה;
  • היקף עבודה מורחב: בנוסף הגדרת שפה ל-fallback ומדיניות אזור זמן מדויקת יותר;
  • היקף מורחב ושאפתני: בנוסף נראות לצוות תמיכת הלקוחות;
  • מחוץ להיקף העבודה: expired, כללי מחזוריות מורכבים, אנליטיקה מורחבת, לוחות זמנים אישיים לפי לקוח.

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

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

ואז ה-AI לא עוזר ל-planning. הוא רק הופך תוכנית אופטימית מדי לשכנעת יותר.

המלכודת העיקרית: ריאליסטיות כוזבת של התוכנית

ב-refinement הסיכון העיקרי היה בהירות כוזבת: המשימה נראית מובנת כי ה-AI עיצב אותה יפה. ב-Sprint Planning הסיכון שונה — ריאליסטיות כוזבת.

ריאליסטיות כוזבת נוצרת כאשר התוכנית נראית קוהרנטית, שלמה והגיונית, אך בו בזמן אינה נבדקה מול המגבלות האמיתיות של הצוות. יש לה Sprint Goal, רשימת משימות, הערכות, תלויות וסיכונים. אבל אף אחד לא באמת בדק אם הקיבולת הזמינה של הצוות מספיקה, אם יש עבודה שלא הושלמה מהספרינט הקודם, אם ה-QA אינו עמוס מדי, אם המומחה הנדרש זמין, אם באמת אפשר להגיע ל-Definition of Done ואם החלק הקשה ביותר אינו מוסתר מאחורי המילים "לשלב", "להוסיף תמיכה" או "לקחת בחשבון מקרי גבול".

סיכון זה משתלב היטב עם כמה בעיות מוכרות.

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

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

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

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

לכן שימוש בוגר ב-AI ב-Sprint Planning מתחיל לא בשאלה "איזה תוכנית הוא הרכיב לנו?", אלא בשאלה "מה בתוכנית הזו עלול להיות לא נכון, חסר או חלק מדי?". צוות טוב לא רק משפר טיוטת AI, אלא מנסה בכוונה להפריך אותה: בודק מקורות, הנחות, תלויות, הקיבולת הזמינה של הצוות, Definition of Done ומקומות שבהם המודל עשוי היה להכליל בביטחון מעבר למה שהעובדות מאפשרות.

מה משתנה לפי תפקידים

בעל המוצר

בעל המוצר עם AI מקבל מהר יותר אפשרויות ל-Sprint Goal ולהיקף העבודה. הוא יכול לבקש מהמודל להציג כמה תרחישים: מינימלי, בטוח, שאפתני, stretch. הוא יכול לראות מהר יותר אילו פריטים ב-backlog באמת תומכים במטרה ואילו רק "גם שימושיים".

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

אנליסט עסקי

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

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

מפתח Backend

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

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

מפתח Frontend

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

אך ה-planning חייב לענות בכנות: האם ה-UI באמת נדרש ל-Sprint Goal או שזה כבר הרחבה? אם המטרה היא לשלוח תזכורת בצורה נכונה ולשמור היסטוריה ניתנת לבדיקה, ייתכן שבספרינט הראשון אין צורך בממשק לקוח מלא. ה-AI יכול לעזור לנסח אפשרויות, אך הצוות חייב לקבל את הפשרה.

מהנדס איכות / QA

ה-QA אולי מרוויח מה-AI יותר ממה שנדמה. המודל מייצר במהירות תרחישים שליליים, תרחישי גבול, תרחישים התלויים בזמן, בדיקות אזור זמן, fallback שפתי, משתמשים archived ומושבתים, הרצות חוזרות של משימת המתזמן וסילוק כפילויות.

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

מעצב UX/UI

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

במקרה שלנו dashboard מלא עשוי להיות שימושי, אך אינו הכרחי ל-Sprint Goal הראשון. אם ה-designer עוזר לצמצם את מסלול המשתמש בלי לאבד ערך, הוא מגביר את הריאליות של התוכנית.

Scrum Master

ה-Scrum Master ב-AI-assisted planning הופך לא ל"מארגן הפגישה", אלא למגן על איכות ההתחייבות של הצוות. תפקידו הוא לוודא שטיוטת ה-AI לא תהפוך לסמכות בפני עצמה.

שאלות טובות של ה-Scrum Master כאן נשמעות כך:

  • האם אנחנו באמת מבינים מדוע הספרינט הזה בעל ערך?
  • האם המפתחים רואים ב-Sprint Backlog הזה את התוכנית שלהם?
  • מה בטיוטת ה-AI בדקנו באמצעות עובדות?
  • איפה התוכנית נראית חלקה מדי?
  • מה נסיר ראשון אם יופיע מידע חדש?
  • האם מטרת הספרינט הפכה לרשימת משימות?

השוואה: תכנון ספרינט ללא AI ועם AI

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

סיכונים חדשים ומה לבדוק ידנית

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

העיקר בטבלה הזו אינו ש-AI "עושה תכנון טוב יותר". הרעיון המדויק יותר: AI כמעט בכל מקום מאיץ את הרכבת הטיוטות, הרשימות, החלופות והפרוטוקולים. אבל כמעט בשום מקום הוא לא מבטל את מחזור הבדיקה האנושי האחרון לבדיקת עובדתיות, ריאליות ובעלות / אחריות.

ממשל והיגיינת נתונים: מה אסור למסור למודל בלי מחשבה

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

אבל מבחינת ממשל זה מסוכן.

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

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

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

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

רשימת בדיקה: אפשר לדון בתוכנית ספרינט שנאספה על ידי AI אם…

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

ניתן לדון ב-Sprint Plan שנאסף על ידי AI אם:

  • Sprint Goal מנוסח כערך או כמצב משתנה עבור המשתמש / בעל העניין, ולא כרשימת משימות.
  • עבור כל פריט ב-backlog שנבחר, הצוות יכול להסביר כיצד הוא תומך ב-Sprint Goal.
  • הקיבולת הזמינה של הצוות נלקחה בחשבון לא באופן מופשט, אלא תוך התחשבות בחופשות, תמיכה, תיקוני באגים, העברת עבודה שלא הושלמה, קליטה והדרכה ופגישות חובה.
  • עבודה שלא הושלמה מהספרינט הקודם נותחה במפורש: מה מועבר, מה מבוטל, מה דורש הערכה מחדש.
  • תלויות חיצוניות צוינו במפורש, לכל אחת יש אחראי וסטטוס ברור.
  • עבור היקף העבודה שנבחר, הצוות רואה את הדרך ל-Definition of Done, ולא רק למצב "הקוד כמעט מוכן".
  • התוכנית ניתנת לבדיקה: יש קריטריוני קבלה, תרחישים שליליים, תרחישי גבול, ניתנות לצפייה ונתונים ברורים לבדיקה.
  • הצוות יכול לנסח במשפט אחד את היקף העבודה המינימלי בעל הערך של הספרינט.
  • הצוות מבין מראש מה ניתן להסיר ראשון מהיקף העבודה אם יצוץ מידע חדש.
  • טענות עובדתיות מהותיות מטיוטת ה-AI נבדקו ידנית: סטטוסים, תלויות, נתונים היסטוריים, מגבלות ארכיטקטוניות, כללי דדליין, לוקליזציה, דה-דופליקציה.
  • מישהו מהמשתתפים ניסה במיוחד להפריך את טיוטת ה-AI, ולא רק לשפר אותה.
  • הצוות בחן בנפרד היכן התוכנית חלקה מדי, מדויקת מדי או חשודה כ"מובנת מאליה".
  • המפתחים אישרו במפורש שה-Sprint Backlog הוא התוכנית שלהם, ושה-Sprint Goal הוא התחייבות הצוות לספרינט.
  • תוצאת ה-planning תועדה כך שברור: מה הוחלט, מה הונח, מה נותר לא ידוע ומה הוצא מהיקף העבודה.

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

מה הייתי ממליץ לצוות

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

שנית, תמיד להפריד בין טיוטת התוכנית לבין ההתחייבות הצוותית. טיוטת AI יכולה להיות הכנה מצוינת, אבל Sprint Backlog הופך לאמיתי רק כאשר המפתחים מבינים אותו כתוכנית שלהם.

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

רביעית, לתעד במפורש מחוץ להיקף העבודה. בפגישות planning טובות בתמיכת AI, הערך נוצר לעתים קרובות לא רק ממה שהצוות בחר, אלא גם ממה שהוא בכוונה לא לקח. במקרה ה-LMS זה יכול להיות expired, לוח מחוונים מלא של צוות תמיכת לקוחות, סגמנטציה מורכבת של תדירות התזכורות ואנליטיקה מורחבת.

חמישית, למנות בעלי בדיקה. את המשמעות העסקית בודק בעל המוצר, את קוהרנטיות הדרישות — האנליסט, את היתכנות הארכיטקטונית — המפתחים, את ניתנות הבדיקה — ה-QA, את גבולות חוויית המשתמש — המעצב, ואת איכות ההסכמה הצוותית — ה-Scrum Master. AI יכול להכין טיוטה כללית, אבל אינו יכול להיות בעל הבדיקה.

מסקנה

אם ב-Backlog Refinement AI עוזר לאסוף ולעצב מהר יותר חומר לדיון, הרי שב-Sprint Planning הוא עוזר לאסוף מהר יותר אפשרויות תוכנית. הוא יכול להציע Sprint Goal, לקבץ פריטי backlog, להדגיש תלויות, לשרטט פירוק, להכין תרחישי בדיקה, לרשום הנחות ואף לתעד יפה את תוצאת הפגישה.

אבל זה לא הופך את התוכנית לריאלית.

Sprint Plan ריאלי מופיע רק כאשר הצוות בדק ביושר את הערך, היקף העבודה, הקיבולת הזמינה של הצוות, התלויות, ה-Definition of Done, ניתנות הבדיקה והנכונות שלו לקחת זאת לעבודה. AI יכול להאיץ את הבדיקה הזו, אבל אינו יכול להחליף אותה. הוא יכול לעזור לראות יותר אפשרויות, אבל אינו יכול לבחור התחייבות צוותית במקום האנשים.

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

בצוות בוגר, AI אינו הופך את Sprint Planning ליצירה אוטומטית של Sprint Backlog. הוא הופך אותו לשיחה ממוקדת יותר על המטרה, האילוצים והפשרות. וזו, אולי, הצורה השימושית ביותר של אוטומציה: לא להוציא אנשים מה-planning, אלא לפנות את תשומת לבם להחלטות שהכלי אינו יכול לקבל עבורם.

מקורות ומדריכים

← כל המסות