בפגישת ה-Sprint Retrospective האחרונה שהשתתפתי בה שמתי לב לדבר מוזר.
משפט אחד, שנזרק בחלל, הפתיע ושימח את כל המשתתפים, והציג נקודה חיובית לסיכום ה-sprint והיא:
"התוצר של הפיתוח תאם את הגדרת הדרישות ב User Story".
הפגישה המשיכה ודנו בה על עוד נושאים רגילים של Retrospective:
למה ה daily לוקח יותר מ 15 דקות? האם הסביבה של ה QA מספיק טובה? איך מנהלים sprint בצורה אפקטיבית כשחלק מהצוות מרוחק? ועוד.
ואני, המשכתי להתבונן על המשפט הזה שכל כך הפתיע את המשתתפים.
הפתיע אותי עד כמה שזה לא מובן מאליו שכך יהיה.
כלומר – לרוב בעצם, התוצר של הפיתוח לא תואם את הדרישות???
כן – הסבירו לי.
או שהפיתוח לא קוראים עד הסוף את הדרישה, ואז עושים מה שהם רוצים,
או שמסתבר שהם לא יכולים לממש מה שהוגדר, וגם אז עושים מה שהם רוצים,
או שה PRD לא מספק פתרון טוב, ואז צריך לעשות שינויים תוך כדי ה sprint,
ועוד ועוד תירוצים.
אפשר כבר היה לחשוב שאין טעם לכתוב דרישות, כי בלאו הכי תוצר הפיתוח בסוף נקבע על ידי הפיתוח ולא על ידי מנהל המוצר.
אבל אז הגיע הספרינט האחרון והראה שאפשר גם אחרת, כאשר עובדים נכון:
מבינים היטב מהם צרכי הלקוח.
מנתחים נכון את האפשרויות ובוחרים פתרון מתאים לבעיה.
מתאמים מראש עם הפיתוח מה אפשרי לביצוע.
כותבים את ה user stories בצורה ברורה ומובנת.
ואז – קל לממש את מה שמוגדר ב User story, אין צורך בעשרות שינויים תוך כדי הפיתוח, והמוצר פשוט מספק את הפתרון הטוב ביותר עבור הלקוחות.
אלמנטרי.