proj6-iterations.md

חזרה לעמוד ראשי

פרויקט קבוצתי 6 – פיתוח בסבבים –Iterations

מטרת המשימה

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

פירוט הציון

ראו בהמשך

תאריכים והגשות

בכל סוף סבב יש להגיש קישור לדף הסבב ע״י פתיחת משימה חדשה משויכת למתרגל\ת.

המשוב יהיה באמצעות סקר בע״פ כדלקמן והערות משלימות במשימה. המתרגל\ת סוגר\ת את המשימה עם ציון שיפורסם בגליון הציונים ע״פ הקריטריונים המפורטים במשימה זו ובגליון.

בנוסף:

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

במאגר התבנית דוגמא למשימת הגשה הכוללת קישור לדף הסבב ורשימת מטלות לתזכורת (מבוססת על התבנית למשימות).

ציונים

הניקוד שיינתן לכל סבב יהיה בדגש על הנושאים הבאים:

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

סבבי פיתוח

1. תכנון הסבב הבא

במקביל לסיום העבודה על הסבב הנוכחי, יוגש גם תכנון עבור הסבב המתקרב (n+1). התכנון כולל בחירת סיפורים ותכנון משימות בתיאום עם הלקוח. פתיחת עמוד וויקי עבור הסבב ועדכון ה- product backlog וה- sprint backlog.

תכנון משימות

בתיאום עם הלקוח וצוות הקורס נפגשים ובוחרים את הסיפורים והמאפיינים, בעלי הערך הגבוה ביותר כרגע, למימוש (עבור ארבעה סבבים - כרבע מכלל הסיפורים). הסיפורים מועברים מה-product backlog אל ה- sprint backlog ע"י שיוך לסבב (אבן דרך ב-github issues) וע"י גרירה אל העמודה Ready בלוח הויזואלי ומיון (בגרירה) לפי עדיפות המשימה.

אפשר גם להוסיף משימות שכבר ידועות מראש על פי תוצרי השלבים הקודמים, משימות הפרויקט המוגדרות כאן (למשל יישום חומרי הקורס, סעיף ‎6 להלן) וכל מה שלדעתכם מצריך עבודה של הצוות. ישנן מערכות ייעודיות לניהול משימות אך כאמור מספיק השימוש ב- github issues. במיוחד עבור כל סיפור שבחרתם לממש, מפרטים לתת-משימות פיתוח לפי המימוש הנדרש. כל תת-משימה כזו מוכנסת למערכת כולל הערכת המאמץ הנדרש בשעות (רשות), תיוג, שיוך וכדו'. לפי הצורך מעדכנים את הערכות המאמץ והזמנים לפי הניסיון שנצבר.

בדיקות

בטקסט של הסיפור\ים העיקרי\ים לסבב זה יש לפרט תרחיש בדיקה (קבלה) שמדגים כיצד תוודאו שהסיפור הושלם (ראו לדוגמא כאן).

המלצה: ניהול תת-המשימות של סבב 0 (ZFR) גם כן במערכת זו. בבחירת המשימות יש להתייחס לערך המקסימלי שהלקוח יכול לקבל מעבודתכם ומצד שני לגודל המשימות בהתאם להערכת הזמנים שלכם.

עמוד סבב

בוויקי יש להוסיף עמוד חדש עבור הסבב הקרוב (ולקשר אותו לעמוד הראשי\readme). העמוד יהווה לוח עבודה משותף להעלאת נושאים בין חברי הצוות במשך העבודה בסבב. העמוד יכלול לפחות:

• כותרת עם שם הסבב
• מטרות הסבב
• בעלי תפקידים מהצוות בסבב זה (למשל: Scrum Master, Product Owner)
• מידע על מצב המשימות, בצורה של קישור קבוע לטבלאות משימות פתוחות וסגורות לסבב זה וכן ללוח ויזואלי של המשימות, כגון:
  • https://github.com/jce-il/se-class/issues?milestone=1&state=open
  • https://github.com/jce-il/se-class/projects/2
• תמונות (לכידות מסך) של לוח המשימות הוויזואלי בתחילת וסוף הסבב
• מספר נקודות ההערכה מתוכננות למימוש (ע"י סיכום הנקודות של המשימות השונות)
• הפניות לתרשימים נדרשים לצורך המימוש בסבב למשל class diagram או כרטיסי CRC.
• קישורים לסקרי קוד, לפחות לכל חבר צוות ולפחות אחד שנסקר ע"י צוות הקורס
• סיכומי פגישות, חוות דעת של הלקוח וסיכומים שבועיים – בפרט יש לגבות את החלטותיכם לגבי המאפיינים שנבחרו והיקפם.
• סיכום הסבב (ימולא בסיומו; ראו פירוט להלן בסעיף 3)
• תכנון הסבב הבא
• כל מידע אחר שדרוש לכם לצורך שיתוף פעולה בסבב

2. מימוש סבב

תוך כדי המימוש המשימות מועברות עמודות בלוח ונסגרות בסיומן (Ready -> Working -> Review -> Done, Close).
עבור הסיפור העיקרי הממומש בסבב יש להגדיר תרחישי בדיקה שיובילו את המימוש. מאגר הקוד מתעדכן באופן רציף בתוצרי עבודתכם יש לציין בהערות ה-commit את מספר המשימה שקשורה לפעולה, למשל #42. כל commit יבוצע ע"י מי שבפועל עבד עליו.

מילוי דו"ח שבועי בעמוד הסבב – מומלץ שבכל שבוע יוגדר חבר צוות אחר שאחראי על ההתקדמות והדוחות (ראש צוות, סקראם מאסטר) במקרה כזה ציינו בדו"ח מי היה אחראי.

3. סיכום סבב \ רטרוספקטיבה

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

• תמונה (screenshot) של מצב לוח המשימות בסוף הסבב
• תכנון מול ביצוע - סיכום של נקודות הערכה שבוצעו והשוואה לסבבים קודמים (velocity).
• מה עבד טוב ומה פחות בסבב? למשל:
  • מהו מצבו הנוכחי של המוצר, האם עמדנו בדרישות? האם הוא איכותי מספיק? האם הבדיקות שנכתבו מראש עזרו?
  • האם השיטות שהשתמשנו בהן לפיתוח עד כה היו טובות? מה ניתן לשפר לסבב הבאה?
  • כיצד עבדנו כצוות עד עכשיו? האם כולם תרמו את חלקם? מהם אופני ותדירות התיאומים בינכם? מה לא עבד טוב? האם וכיצד ניתן לשפר? מה הוחלט לשנות באופן העבודה?
  • לקחים הקשורים לחומרי הקורס ההרצאה והתרגיל והאם עזרו (או להיפך..) להשלמת הסבב
  • כיצד מתקדם הפרויקט? האם יעמוד בלו"ז ובמשימות? כמה נקודות הערכה הספקנו לבצע? אלו סיכונים עדיין קיימים? מהי תכנית ההתמודדות איתם?
  • חוות דעת שהתקבלה מהלקוח על תוצרי הסבב והערות שלו על הצגת/דף סיום הסבב.
  • יישום נושאים נלמדים בקורס (ראו סעיף ‎6)
• משימות: יש לסגור את המשימות והסיפורים שהסתיימו.
• הפצה: יש להוסיף בדף הסבב קישור לגרסת הרצה של המוצר.

4. בקרת גרסאות

יש להוסיף tag במאגר הקוד עבור הסבב שהסתיים, למשל:
git tag -a v0.1 -m 'Iteration 1 – XXX - MVP'

וגם לדחוף למאגר המשותף:
git push --tags
(אם רלוונטי מומלץ גם לסמן גרסה לשחרור, ראו הנחיות Releases).

5. סקר סיום סבב (הצגה, סיכום ותכנון סבב הבא)

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

מה נדרש?
א. הדגמה קצרצרה! של עבודה עם המוצר ב- production! (אחרת: יש להיערך מראש עם כל ההתקנות והחיבורים הדרושים ופשוט למשוך את הקוד מהמאגר ולהדגים את הפונקציונליות העיקרי שמומשה). אם יש דברים שלא הספקתם לסיים (Done) ציינו זאת בקצרה (לא צריך להתבייש...)
ב. סיכום הסבב - הצגת דף הסבב, דיון והצגת לקחים לפי הזמן
ג. סקר קוד – הציגו קטע קוד משמעותי שכתבתם לצורך דיון עם הסוקרים. נשתמש בממשק הווב של גיטהאב להצגת הקוד ומתן הערות (ראו עוד בסעיף 6.4).
ד. לסיום הציגו בקצרה את מצב המשימות והתכנון לסבב הבא (חזרה לסעיף 1). רשימת המשימות צריכה להיות מעודכנת כך שהמשימות של סבב זה במצב Done, למעט משימות שעוברות לסבבים הבאים.

6. יישום חומרים מההרצאה

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

1. MVP

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

2. בדיקות ובדיקות יחידה

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

3. סקר שיפורי קוד – Refactoring

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

• הציעו רעיון להרחבת המוצר שלא נלקח בחשבון בתיכון עד כה.
• זהו את המקומות בקוד שבהם יש לבצע את השינוי או ההרחבה.
• זהו 3-5 בעיות בתיכון קוד זה או "ריחות" שיקשו על השינוי המתבקש. יש להפנות לבעיות מרשימה זו: http://users.csc.calpoly.edu/~jdalbey/305/Lectures/SmellsToRefactorings
• תארו באלו שיפורי קוד (Refactorings) מתוך הרשימה תשתמשו כדי לתקן את הקוד (תוכלו להשתמש בהצעות אלו למשימת הסבב הבא). הגשה – א. קישור לסקר מדף הסבב בוויקי ובמייל הגשת הסבב. ב. התייחסות קצרה לנושאים שעלו בסקר סיום סבב זה.

4. סקר קוד -

עליכם לבצע סקרי קוד בתוך הצוות דרך מערכת ה- pull request ב- github או באמצעות הערות על commit מסוים. על כל חבר/ת צוות לבצע לפחות סקר אחד לחבר אחר. מומלץ להשתמש כקלט בתוצרי הסקר מהסבב הקודם. ניתן להתייחס גם לנושאים כמו חווית משתמש.
הגשה: בדף סבב הסיום תהיה פסקה של סקרי קוד. הפסקה תכיל לכל חבר צוות קישור ל- issue (או pull request) שנפתח עבור סקר קוד שבוצע על קוד שהוא כתב. ה- issue יכיל את הדו-שיח בין הנסקר לסוקר וקישורים מתאימים למאגר ה-pull, diff או הערות הקשורות לסקר.
(המלצות: שימוש בסקר שיפורי הקוד מהסבב הקודם, הוספת בדיקות כיסוי כשלב מקדים לשינוי, התייחסות בשינויים לחומרי הקורס האחרונים – תיכון, תבניות, refactoring ו-UX)

5. סיכום פרויקט (חובה לסבב אחרון)

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

כל חברי הצוות נדרשים להציג (תכננו מי אומר מה) וייתכנו שאלות (ניקוד אישי). יש להירשם בעמוד הפגישות. קיום ההצגה יפורסם ויהיה פתוח לצופים. מומלץ להזמין את הלקוחות.

• במסגרת סיכום הסבב כרגיל בצעו גם סיכום מפורט יותר לפרויקט כולו. עליכם להכין דו"ח בעמוד הסבב הכולל תקצירים (ו\או קישורים) עבוד הנקודות הבאות:
  א. סיכום הסבב האחרון, בדומה לקודמים.
  ב. עדכון מסמכי תיעוד המוצר, ובמיוחד כל מה שקשור לתחזוקה: צילום מסכים עיקריים, הוראות התקנה והפצה, טיפול ועמידות המוצר לתקלות שונות: קלטים שגויים, שינויים בסביבת ההתקנה וההפעלה (ניתוקי רשת), אבטחת מידע וכדו'.
  ג. דיון על רוח\ערכי הצוות. הערכת המידה בה הצוות עבד לפי רשימת "רוח הצוות" שפורסמה באתר בתחילת הדרך. תנו דוגמאות ספציפיות מניסיונכם על מנת לאשש את המסקנות.
  ד. דיון על תהליך הפיתוח – האם בחרתם אורך סבבים מתאים? האם הניקוד ומדידת הקצב עזרו וכדו'
  ה. רפלקציה על הפרויקט והקורס כולו. רשמו את שלשת הלקחים העיקריים שלמדתם מהפרויקט שליווה את הקורס. הלקחים יוכלו להיות לפי שלבי הפרויקט השונים (הצעה, דרישות, תיכון, בדיקות, מימוש, עבודת צוות, עבודה עם הלקוח וכדו'), מה עבד טוב? מה פחות? מה תעשו אחרת בפרויקט הבא? עם אילו אתגרים והתמודדתם? כיצד ניהול הסיכונים השפיע? האם הרצאות האורח נתנו פרספקטיבה שונה? אלו כלים סייעו ואלו פחות? האם העבודה מול הלקוח הייתה משמעותית ותורמת? האם יש לכם תכניות להמשיך את פיתוח המוצר\להעביר אותו לקוד פתוח וכדו'?
  רשות: הכינו גראף הסוקר את החשיבות לדעתכם של תהליכים, שיטות וכלים שנלמד בקורס.
  .