Scrum - The devil is in the details - Hebrew
1 like433 views
סקירה קצרה של אתגרים ביישום SCRUM בארגון - גישת Agile ( א'גייל ), הלכה למעשה. המצגת עדיין בשלבי עבודה -זהו תוצר חלקי. יישום שיטת SCRUM - אג'ייל
Scrum - The devil is in the details - Hebrew
- 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