סקירה קצרה של אתגרים ביישום SCRUM בארגון - גישת Agile ( א'גייל ), הלכה למעשה. המצגת עדיין בשלבי עבודה -זהו תוצר חלקי. יישום שיטת SCRUM - אג'ייל

1. ‫2102/50‬
‫הוכן ע" י‬
‫דן- אייל גזית‬
‫מנהל פיתוח בכיר‬

2. ‫זכויות יוצרים‬
‫במצגת זו שולבו תמונות וציטוטים שנמצאו באינטרנט.‬ ‫‪‬‬
‫יתכן וכי בתום לב נעשתה הפרת זכויות יוצרים –‬
‫אם זיהתם הפרה כזו, אנא יידעו אותי ואתקן בהקדם.‬
‫2‬

3. ‫תוכן עניינים‬
‫‪ – Scrum‬מציאות העשייה :‬ ‫‪‬‬
‫הכנה לפיתוח‬ ‫‪‬‬
‫תכנון ‪.RELEASE‬‬ ‫‪‬‬
‫פרויקטים גדולים.‬ ‫‪‬‬
‫אזהרה...‬ ‫‪‬‬
‫לאן להמשיך מכאן.‬ ‫‪‬‬
‫3‬

4. ‫הכנה לפיתוח‬
‫4‬

5. ‫הכנה לפיתוח )1( אי אפשר לרוץ כל הזמן.‬
‫מומלץ לתת לצוות להתרענן מדי פעם בין ‪Sprints‬‬
‫ימי מעבדה :‬
‫• למידת חומרים חדשים ותרגול טכנולוגי‬
‫• ביצוע משימות טכנולוגיות כלליות,‬
‫לא דווקא קשורות לפרויקט.‬
‫• עבודה בלחץ מופחת.‬
‫• לרוב לא יותר מיום.‬
‫5‬

6. ‫הכנה לפיתוח )2( תהליך ניתוח משתמשים‬
‫הקדישו זמן לפני כתיבת ה ‪ user sorties‬לזיהוי‬ ‫‪‬‬
‫סוגי המשתמשים במערכת :‬
‫‪ ‬משתמשים "אמיתיים" – בעלי תפקיד בתהליך‬
‫○ מנהלן.‬
‫○ ספק.‬
‫‪ ‬משתמשים לא פורמאליים, אבל בעלי ערך עסקי‬
‫○ משתמש שבילה במערכת כבר זמן רב.‬
‫○ משתמש שביטל הזמנה בפעם האחרונה שהיה באתר.‬
‫○ משתמש מנוי חדש מול מנוי ותיק.‬
‫6‬

7. ‫הכנה לפיתוח )3( ‪Sprint zero‬‬
‫לא על פי מתודולוגית ‪" SCRUM‬הקלאסית"‬ ‫‪‬‬
‫‪ ‬מקובל בתעשייה.‬
‫‪ Sprint‬הפתיחה של הפרויקט.‬ ‫‪‬‬
‫יוצא דופן אל מול שאר ה ‪ sprints‬הצפויים :‬ ‫‪‬‬
‫○ אורך קצר יותר - לא חלק מ"פעימת הקצב" בפרויקט.‬
‫○ בסופו לא יהיו תוצרים עובדים ללקוח‬
‫○ עוסק בעיקר בהתארגנות הצוות לעבודה.‬
‫7‬

8. ‫הכנה לפיתוח )4( ‪Sprint zero‬‬
‫פעילויות עיקריות נפוצות במהלך ‪: Sprint zero‬‬
‫○ הכרות הצוות ולמידת ‪ SCRUM‬במידה ויש צורך.‬
‫○ בניה והבנה של הפריטים הראשונים שיפותחו.‬
‫○ תאום ציפיות והכרות הפרויקט ומטרתו.‬
‫○ תכנון על – ארכיטקטוני, ראשוני - "קליל"‬
‫○ כתיבת קוד ראשוני קטן – "מיני" תחילת פיתוח.‬
‫8‬

9. ‫הכנה לפיתוח )5( - מסמכים ותיעוד‬
‫‪ ‬בזמן הנכון ובמידה הנדרשת - ”‪.“only good enough‬‬
‫‪ ‬ייצור מסמכים הוא כדאי –‬
‫‪ ‬בתנאי שיש להם ערך מוסף ברור.‬
‫‪ ‬לרוב עדיף מסמכים קצרים ונקודתיים.‬
‫‪ ‬לא מעכבים פיתוח אלא תומכים ומסייעים לו.‬
‫‪ ‬על פי אופי הפרויקט והארגון‬
‫‪ ‬אפשר ליצור סוגי מסמכים שונים, להם יהיה הצוות מחויב.‬
‫‪ ‬לזכור את עקרונות ‪...Agile‬‬
‫9‬

10. ‫הכנה לפיתוח )6( - מסמכים ותיעוד‬
‫‪ ‬תיעוד טכני‬
‫‪ ‬נגזר מבדיקות הקוד.‬
‫‪ ‬הקוד צריך להיות קריא, קצר וברור. הערות רק שנדרש הסבר ממשי.‬
‫‪ ‬מסמכים שונים נדרשים בפרויקטים שונים.‬
‫‪ ‬דוגמא למסמכים מקובלים :‬
‫מסמך מדריך למשתמש.‬ ‫○‬
‫מסמך למרכז התמיכה.‬ ‫○‬
‫מסמכי תיעוד מקיפים כגון הנ"ל –‬
‫עדיף לכתוב באופן מדורג, בסיום כל ‪.Sprint‬‬
‫01‬

11. ‫הכנה לפיתוח )7( – שילוב עם ‪XP‬‬
‫‪ SCRUM ‬היא מתודולוגיה שמתרכזת בהנהלה‬
‫ובפרקטיקה ארגונית.‬
‫‪ ‬ארגונים רבים משלבים אותה עם גישת ‪ Agile‬נוספת‬
‫בשם ‪ – XP‬ראו שני שקפים הבאים לעקרונות בסיס.‬
‫‪ ‬אפשר לאמץ גם עקרונות מסוימים מגישת ה ‪XP‬‬
‫ולא את כולה.‬
‫11‬

12. ‫הכנה לפיתוח )8( – שילוב עם ‪XP‬‬
‫‪XP =EXTERIM PROGRAMING ‬‬
‫‪ ‬דגש על פרקטיקה תכנותית. נקודות יסוד עיקריות :‬
‫‪ ‬תכנות זוגי – ‪Pair Programming‬‬
‫שני מפתחים עובדים בשיתוף פעולה יחד. הוכח‬
‫כמשפר תוצרי קוד.‬
‫‪ – TDD ‬גישת פיתוח מונחת בדיקות – כל פיתוח‬
‫מתחיל מכתיבת תוכנית הבדיקות לקוד העתידי.‬
‫21‬

13. ‫הכנה לפיתוח )9( – שילוב עם ‪XP‬‬
‫‪ ‬עוד נקודות יסוד עיקריות של ‪: XP‬‬
‫‪ ‬אינטגרציה מתמשכת –‬
‫בדיקה שוטפת אוטומטית לקוד שמתווסף לפרויקט,‬
‫שעומד בסטנדרטים ולא "שובר" את המערכת.‬
‫‪ ‬עיצוב מתמשך – ניסיון לשמור על עיצוב פשוט ככל‬
‫הניתן בהתחלה ואז באופן קבוע לשפר אותו.‬
‫‪ ‬הגדירו תקן לכתיבת הקוד בארגון וסטנדרטיזציה.‬
‫31‬

14. ‫הכנה לפיתוח )01( – שילוב ‪QA‬‬
‫41‬

15. RELEASE ‫תכנון‬
15

16. ‫1‬ ‫‪RELEASE‬‬ ‫תכנון‬
‫‪ ‬אומנם בכל ‪ Sprint‬אנו מיצרים תוצר מוכן לשחרור,‬
‫אולם נפוץ כי מתעורר צורך ב ‪: Release sprint‬‬
‫אינטגרציה‬
‫בדיקות ביצועים‬
‫בדיקות והשלמות בתחום אבטחת מידע‬
‫השלמת תיעוד‬
‫ועוד...‬
‫61‬

17. ‫2‬ ‫תכנון ‪RELEASE‬‬
‫‪ ‬קבוע זמן‬
‫○ הערכת תכולה – כמה נוכל לפתח עד תאריך היעד –‬
‫‪ ‬בדיקה של כמה ‪ sprints‬נספיק‬
‫‪ ‬שימוש בנתון ה-‪velocity‬‬
‫‪ ‬קבוע תכולה‬
‫○ הערכת זמן - כמה ‪ sprints‬ידרשו לפיתוח התכולה‬
‫‪ ‬סכימה של הערכות המאמצים של הפריטים שאמורים להיכלל בגרסה.‬
‫‪ ‬חלוקת המספר שהתקבל ב-‪- velocity‬‬
‫נקבל הערכה של מספר ה ‪ Sprints‬שידרשו לנו.‬
‫71‬

18. ‫3‬ ‫תכנון ‪RELEASE‬‬
‫הערכה – לא הבטחה, מדובר בהערכה בלבד !!!.‬ ‫‪‬‬
‫יש לזכור לשם מה נדרשת לנו הערכה :‬ ‫‪‬‬
‫‪ ‬תכנון של פרויקטים גדולים.‬
‫‪ ‬הבנת סדרי גודל של עלות.‬
‫הערכה מתבצעת בשיתוף כל גורמי הצוות.‬ ‫‪‬‬
‫81‬

19. ‫4‬ ‫תכנון ‪RELEASE‬‬
‫ואם הערכות מוטעות ?‬ ‫‪‬‬
‫‪ - Agile ‬גישה תומכת שינוי.‬
‫‪ ‬במתודולוגיות פיתוח אחרות, הערכות היו יותר מדויקות ?...‬
‫‪ ‬בזכות גישת ה ‪ ,Agile‬סבירות גבוהה שנזהה הערכה שגויה כבר אחרי ה‬
‫‪ Sprints‬הראשונים ואז ניתן :‬
‫○ לשנות תכולה.‬
‫○ להוסיף כוח אדם.‬
‫○ לשנות את הערכות ובהתאם את לוחות הזמנים.‬
‫91‬

20. ‫תכנון ‪RELEASE‬‬
‫ואם הערכות מוטעות ?‬ ‫‪‬‬
‫‪ ‬הערכות לוחות הזמנים וההספק מתעדכנות ומשתפרות,‬
‫ככל שאנו מיצרים עוד ועוד ‪ Sprints‬עם קוד עובד.‬
‫‪ ‬הלקוח מקבל שקיפות מלאה לגבי התכולות עד כה‬
‫והערכה שלנו לעתיד.‬
‫‪ ‬בסוף כל ‪ Sprint‬מתבצע "טיוב" של הערכת הזמנים.‬
‫02‬

21. ‫5‬ ‫תכנון ‪RELEASE‬‬
‫ואם הערכות מוטעות ?‬ ‫‪‬‬
‫‪ ‬הערכות לוחות הזמנים וההספק מתעדכנות ומשתפרות,‬
‫ככל שאנו מיצרים עוד ועוד ‪ Sprints‬עם קוד עובד.‬
‫‪ ‬הלקוח מקבל שקיפות מלאה לגבי התכולות עד כה‬
‫והערכה שלנו לעתיד.‬
‫‪ ‬בסוף כל ‪ Sprint‬מתבצע "טיוב" של הערכת הזמנים.‬
‫12‬

22. 6 RELEASE ‫תכנון‬
22

23. ‫פרויקטים גדולים‬
‫32‬

24. ‫פרויקטים גדולים )1(‬
‫‪ ‬באופן טיפוסי צוותים הם בגודל של עד עשרה איש‬
‫‪ ‬הגדלת סדר הגודל מתבצעת ע"י הוספת צוותים‬
‫‪ ‬יצירת כלים לשיתוף פעולה בין צוותים מרובים -‬
‫שיחה ישירה עם תקשורת וידיאו כאופציה מומלצת.‬
‫‪ ‬פרמטרים ל"גדילה"‬
‫סוג האפליקציה‬ ‫‪‬‬
‫גודל הצוות‬ ‫‪‬‬
‫תפוצת הצוותים‬ ‫‪‬‬
‫משך הפרויקט‬ ‫‪‬‬
‫42‬

25. ‫פרויקטים גדולים )2(‬
‫בפרויקטים גדולים יש צורך בצוות אינטגרציה.‬ ‫‪‬‬
‫‪ ‬גדל הצורך ב ‪Release sprint‬‬
‫אם אפשר כדאי לחלק מוצרים גדולים לכמה תתי מוצרים‬ ‫‪‬‬
‫שמתנהלים בנפרד.‬
‫אם מוצר גדול לא ניתן לחלוקה, צריך להחליט אסטרטגיה‬ ‫‪‬‬
‫ניהולית :‬
‫‪ ‬מנהל מוצר כללי עם רשימה אחת ארוכה של דרישות‬
‫‪ ‬מנהל מוצר כללי עם כמה רשימות של דרישות – לצוותים שונים.‬
‫‪ ‬כמה מנהלי מוצר , שכל אחד מהם מחזיק רשימת דרישות.‬
‫52‬

26. ‫פרויקטים גדולים )3( - ‪Scrum of scrums‬‬
‫62‬

27. ‫פרויקטים גדולים )4(‬
‫‪ Scrum ‬הוכח כעובד בהצלחה גם בפרויקטי תוכנה של‬
‫מאות שנות אדם.‬
‫‪ ‬סביר להניח שיהיה צורך בהוספת ‪ Sprints‬של‬
‫בדיקות אינטגרציה, לתוכנית הפיתוח.‬
‫‪ ‬היישום בפרויקטים גדולים הוא מורכב :‬
‫‪ ‬מומלץ לגייס לעזרה מומחי ‪ ,SCRUM‬בעלי ניסיון.‬
‫‪ ‬היתרונות של גישת ‪ ,Agile‬עדיין באים לידי ביטוי היטב.‬
‫72‬

28. ‫אזהרה‬
‫82‬

29. ‫אזהרה )1(‬
‫‪ ‬העישון מזיק לבריאות....‬
‫‪ ‬לא פשוט לאמץ ‪ Agile‬ו ‪Scrum‬בארגון‬
‫○ חשוב לשמור על עקרונות הבסיס ולהתעקש על יישומם.‬
‫○ יש לנהל את השינוי‬
‫גם ברמה האישית וגם ברמה המקצועית.‬
‫○ רצוי להתחיל בפרויקט ניסיון לבדיקת יישום אימוץ הגישה.‬
‫לבחור פרויקט לא שולי מדי ולא מרכזי מדי.‬
‫92‬

30. ‫אזהרה )2(‬
‫סיבות נפוצות לכישלון פרויקטי ‪: SCRUM‬‬ ‫‪‬‬
‫‪ ‬חוסר בהבנת הגישה ועקרונותיה – מוביל ליישום בעייתי.‬
‫‪ ‬אי הצלחה לגבש צוות בעל מחויבות –‬
‫○ אי יכולת להפנים את האחריות הקבוצתית‬
‫○ אי הגעה לישיבות / חוסר השתתפות בתהליך.‬
‫‪ ‬חוסר במנהיגות וביכולת הובלה על ידי ה ‪.Scrum Master‬‬
‫‪ ‬חוסר תקשורת עם בעלי העניין השונים בפרויקט.‬
‫03‬

31. ‫אזהרה )3(‬
‫סיבות נפוצות לכישלון פרויקטי ‪: SCRUM‬‬ ‫‪‬‬
‫‪ Product owner ‬שלא זמין מספיק עבור הצוות‬
‫או שלא יודע מה הוא רוצה.‬
‫‪ ‬אי ביצוע תהליך רטרוספקטיבה – אי שיפור התהליך.‬
‫השאיפה היא לבחינה ושיפור מתמיד.‬
‫‪ ‬אי מוכנות של הארגון לשיתוף פעולה ולהצפת ונתינת‬
‫פתרונות לבעיות שיתעוררו.‬
‫שקיפות התהליך מציפה מהר בעיות שהוסתרו.‬
‫13‬

32. ‫אזהרה )4(‬
‫23‬

33. ‫שאלות ללא הפסקה‬
‫‪ ‬איך ליישם ‪ SCRUM‬בארגון שלי ?‬
‫‪ ‬איך משתנה חלוקת התפקידים הקיימת ?‬
‫‪ ‬איך משתלב ה ‪ QA‬הארגוני בתהליך ?‬
‫‪ ‬מה בדיוק קורה במהלך ה ‪? SPRINT‬‬
‫‪ ‬איך מחלקים נכון הדרישות ל ‪? User stories‬‬
‫‪ ‬בוודאי עוד הרבה....‬
‫33‬

34. ‫תשובות )1(‬
‫‪ ‬אין אמת אחת.‬
‫○ מתודולוגיה עם מעט הנחיות וחופש יחסי.‬
‫○ משתנה לפי צרכי הארגון הספציפי ויכולותיו.‬
‫‪ ‬קראו וצפו בחומרים מקצועיים.‬
‫○ עושר עצום של ספרים יעודים משלימים.‬
‫○ מגוון מידע ברשת האינטרנט – לקריאה וצפייה.‬
‫43‬

35. ‫תשובות )2(‬
‫‪ ‬קחו יועץ מנוסה שהנחה פרויקטים רבים.‬
‫○ שווה לשלם מעט, כדי להרוויח הרבה...‬
‫‪ ‬אין חכם כבעל ניסיון‬
‫○ ככל שתתנסו בתהליך ותבינו איך עובדת המתודולוגיה כך‬
‫תהיה קלה יותר ליישום.‬
‫‪ ‬עקבו אחרי המצגות הבאות שלי בנושאי ‪.SCRUM‬‬
‫53‬

36. ?‫לאן ללכת עכשיו‬
 www.mountaingoatsoftware.com/scrum
 scrum alliance
 Scrum Organization
 scrumdevelopment@yahoogroups.com
Scrum Extended ‫ למצגת הבאה שלי בנושא‬
...‫ ועוד‬
36

37. ‫יצירת קשר‬
‫‪ ‬המצגת הוכנה ע"י דן-אייל גזית, מנהל פיתוח בכיר.‬
‫‪ ‬ליצירת קשר : ‪gazitde@gmail.com‬‬
‫‪ ‬לדף שלי ב ‪– LINKEDIN‬‬
‫‪http://www.linkedin.com/in/gazitde‬‬
‫אשמח לקבל הערות והארות. תודה !‬
‫73‬

38. ‫מקורות‬
: ‫ חלק מהחומרים למצגת זו נלקחו מתוך‬
Presentation by: Mike Cohn 
mike@mountaingoatsoftware.com ○
www.mountaingoatsoftware.com ○
38