כאמור הוחלט שהפיתוח המתאים ביותר להמשך הפרויקט הוא פיתוח בסבבים (ספרינט \ איטרציה). כאשר בסוף כל סבב יש גרסה עובדת עם פונקציונליות נוספת של המוצר המפותח. בסוף כל סבב נבצע מדידה והערכה של מצב המוצר, התוצר (הערך ללקוח) והניהול
בכל סוף סבב יש להגיש קישור לדף הסבב ע״י פתיחת משימה חדשה משויכת למתרגל.
המשוב יהיה באמצעות סקר בע״פ כדלקמן והערות משלימות במשימה. המתרגל סוגר את המשימה ומעניק ציון שיפורסם בגליון הציונים ע״פ הקריטריונים המפורטים במשימה זו ובגליון.
בנוסף:
- הודעה על ההגשה בחדר הצווות עם תיוג צוות הקורס.
- מילוי הערכת עמיתים ע״י כל חברי הצוות
- רישום לסקר סבב בתרגול (ומדי פעם בהרצאה).
(תזכורת: לכל צוות יש חובת הרצאה של פעמיים במהלך הסמסטר לפני הכיתה, לא כולל מצגות הרעיון והסיום).
במאגר התבנית דוגמא למשימת הגשה הכוללת קישור לדף הסבב ורשימת מטלות לתזכורת (מבוססת על התבנית למשימות).
הניקוד שיינתן לכל סבב יהיה בדגש על הנושאים הבאים:
במקביל לסיום העבודה על הסבב הנוכחי, יוגש גם תכנון עבור הסבב המתקרב (n+1). התכנון כולל בחירת סיפורים ותכנון משימות בתיאום עם הלקוח. פתיחת עמוד וויקי עבור הסבב ועדכון ה- product backlog וה- sprint backlog.
בתיאום עם הלקוח וצוות הקורס נפגשים ובוחרים את הסיפורים והמאפיינים, בעלי הערך הגבוה ביותר כרגע, למימוש (עבור ארבעה סבבים - כרבע מכלל הסיפורים). הסיפורים מועברים מה-product backlog אל ה- sprint backlog ע”י שיוך לסבב (אבן דרך ב-github issues) וע”י גרירה אל העמודה Ready בלוח huboard ומיון (בגרירה) לפי עדיפות המשימה.
אפשר גם להוסיף משימות שכבר ידועות מראש על פי תוצרי השלבים הקודמים, משימות הפרויקט המוגדרות כאן (למשל יישום חומרי הקורס, סעיף 6 להלן) וכל מה שלדעתכם מצריך עבודה של הצוות. ישנן מערכות ייעודיות לניהול משימות אך כאמור מספיק השימוש ב- github issues. במיוחד עבור כל סיפור שבחרתם לממש, מפרטים לתת-משימות פיתוח לפי המימוש הנדרש. כל תת-משימה כזו מוכנסת למערכת כולל הערכת המאמץ הנדרש בשעות (רשות), תיוג, שיוך וכדו’. לפי הצורך מעדכנים את הערכות המאמץ והזמנים לפי הניסיון שנצבר.
בטקסט של הסיפור\ים העיקרי\ים לסבב זה יש לפרט תרחיש בדיקה (קבלה) שמדגים כיצד תוודאו שהסיפור הושלם (ראו לדוגמא כאן).
המלצה: ניהול תת-המשימות של סבב 0 (ZFR) גם כן במערכת זו. בבחירת המשימות יש להתייחס לערך המקסימלי שהלקוח יכול לקבל מעבודתכם ומצד שני לגודל המשימות בהתאם להערכת הזמנים שלכם.
בוויקי יש להוסיף עמוד חדש עבור הסבב הקרוב (ולקשר אותו לעמוד הראשי\readme). העמוד יהווה לוח עבודה משותף להעלאת נושאים בין חברי הצוות במשך העבודה בסבב. העמוד יכלול לפחות:
תוך כדי המימוש המשימות מועברות עמודות בלוח huboard ונסגרות בסיומן (Ready -> Working -> Review -> Done, Close).
עבור הסיפור העיקרי הממומש בסבב יש להגדיר תרחישי בדיקה שיובילו את המימוש.
מאגר הקוד מתעדכן באופן רציף בתוצרי עבודתכם יש לציין בהערות ה-commit את מספר המשימה שקשורה לפעולה, למשל #42. כל commit יבוצע ע”י מי שבפועל עבד עליו.
מילוי דו”ח שבועי בעמוד הסבב – מומלץ שבכל שבוע יוגדר חבר צוות אחר שאחראי על ההתקדמות והדוחות (ראש צוות, סקראם מאסטר) במקרה כזה ציינו בדו”ח מי היה אחראי.
עמוד הויקי של הסבב יכלול דו”ח (או קישור למסמך) המסכם ישיבת רטרוספקטיבה שביצעתם לסיכום הסבב ובה בין השאר הנושאים הבאים: - תמונה (screenshot) של מצב לוח המשימות בסוף הסבב - תכנון מול ביצוע - סיכום של נקודות הערכה שבוצעו והשוואה לסבבים קודמים (velocity). - מה עבד טוב ומה פחות בסבב? למשל: - מהו מצבו הנוכחי של המוצר, האם עמדנו בדרישות? האם הוא איכותי מספיק? האם הבדיקות שנכתבו מראש עזרו? - האם השיטות שהשתמשנו בהן לפיתוח עד כה היו טובות? מה ניתן לשפר לסבב הבאה? - כיצד עבדנו כצוות עד עכשיו? האם כולם תרמו את חלקם? מהם אופני ותדירות התיאומים בינכם? מה לא עבד טוב? האם וכיצד ניתן לשפר? מה הוחלט לשנות באופן העבודה? - אפשר גם לציין לקחים הקשורים לחומרי הקורס ההרצאה והתרגיל והאם עזרו (או להיפך..) להשלמת הסבב - כיצד מתקדם הפרויקט? האם יעמוד בלו”ז ובמשימות? כמה נקודות הערכה הספקנו לבצע? אלו סיכונים עדיין קיימים? מהי תכנית ההתמודדות איתם? - חוות דעת שהתקבלה מהלקוח על תוצרי הסבב והערות שלו על מצגת סיום הסבב. - יישום נושאים נלמדים בקורס (ראו סעיף 6) - משימות: יש לסגור את המשימות והסיפורים שהסתיימו. - הפצה: יש להוסיף בדף הסבב קישור לגרסת הרצה של המוצר.
יש להוסיף tag במאגר הקוד עבור הסבב שהסתיים, למשל:
git tag -a v0.1 -m ‘Iteration 1 – XXX - MVP’
וגם לדחוף למאגר המשותף:
git push –tags
(אם רלוונטי מומלץ גם לסמן גרסה לשחרור, ראו הנחיות Releases).
לקראת סיום העבודה על הסבב אתם מתבקשים להציג את מצב המוצר (ולהירשם להצגה בעמוד הפגישות להרצאה או לתרגיל). ללקוח עצמו הכי טוב להראות את מצב התוכנה, אך עבור כאלו שלא מצליחים להגיע לפגישות הטוב והפשוט ביותר הוא להוסיף מספר לכידות מסך של עבודה עם המוצר והסברים לפי הצורך.
מה נדרש?
א. הדגמה קצרצרה! של עבודה עם המוצר ב- production! (אחרת: יש להיערך מראש עם כל ההתקנות והחיבורים הדרושים ופשוט למשוך את הקוד מהמאגר ולהדגים את הפונקציונליות העיקרי שמומשה). אם יש דברים שלא הספקתם לסיים (Done) ציינו זאת בקצרה (לא צריך להתבייש…)
ב. סיכום הסבב - הצגת דף הסבב, דיון והצגת לקחים לפי הזמן
ג. סקר קוד – הציגו קטע קוד משמעותי שכתבתם לצורך דיון עם הסוקרים. נשתמש בממשק הווב של גיטהאב להצגת הקוד ומתן הערות.
ד. לסיום הציגו בקצרה את מצב המשימות והתכנון לסבב הבא (חזרה לסעיף 1).
רשימת המשימות צריכה להיות מעודכנת כך שהמשימות של סבב זה במצב Done, למעט משימות שעוברות לסבבים הבאים.
בעמוד הסבב יש לכלול פסקה המתארת יישום חומרים מהרצאות הקורס, להלן מספר אפשרויות ודוגמאות לביצוע:
מתאים לסבב 1 – דיווח על מימוש פונקציונליות עיקרית של המערכת שלכם עובדת מקצה לקצה. בפרט יש ליצור חלקים מהשכבות השונות הנדרשות להדגים את יכולתו העיקרית של המוצר. ייתכן מאד ששכבות אלו מאד ראשוניות – למשל ממשק משתמש עם פונקציונליות בסיסית, בסיס-נתונים דֶמה להחזרת תשובות קבועות וכדו’. בנוסף יש להתייחס לסיכון העיקרי בפרויקט על ידי טיפול בו ודיווח על סטטוס במצגת סיום הסבב.
דיווח על מחלקה עיקרית שפותחה בסבב בליווי בדיקות יחידה. יש לכתוב עבורה סט בדיקות משמעותי – בשאיפה לפני המימוש. מומלץ לבחור מחלקה מרכזית אך בעלת תלות נמוכה ברכיבים אחרים. יש לצרף דיווח על סקר שנעשה לבדיקות.
בצעו במהלך הסבב סקר פנימי או עם נציג מצוות הקורס לגבי איכות הקוד הנוכחי ועמידותו לשינויים עתידיים. מהלך הסקר:
עליכם לבצע סקרי קוד בתוך הצוות דרך מערכת ה- pull request ב- github או באמצעות הערות על commit מסוים. על כל חבר/ת צוות לבצע לפחות סקר אחד לחבר אחר. מומלץ להשתמש כקלט בתוצרי הסקר מהסבב הקודם. ניתן להתייחס גם לנושאים כמו חווית משתמש.
הגשה: בדף סבב הסיום תהיה פסקה של סקרי קוד. הפסקה תכיל לכל חבר צוות קישור ל- issue (או pull request) שנפתח עבור סקר קוד שבוצע על קוד שהוא כתב. ה- issue יכיל את הדו-שיח בין הנסקר לסוקר וקישורים מתאימים למאגר ה-pull, diff או הערות הקשורות לסקר.
(המלצות: שימוש בסקר שיפורי הקוד מהסבב הקודם, הוספת בדיקות כיסוי כשלב מקדים לשינוי, התייחסות בשינויים לחומרי הקורס האחרונים – תיכון, תבניות, refactoring ו-UX)
כל חברי הצוות נדרשים להציג (תכננו מי אומר מה) וייתכנו שאלות (ניקוד אישי). יש להירשם בעמוד הפגישות.
קיום ההצגה יפורסם ויהיה פתוח לצופים. מומלץ להזמין את הלקוחות.