AGILE:
שיטה בפיתוח ש"מניחה שלא ניתן להגדיר במלואה תוכנה מסוימת קודם לפיתוחה בפועל, ומתמקדת במקום זאת בשיפור יכולתו של הצוות לספק תוצרים במהירות ולהגיב לדרישות העולות תוך כדי הפיתוח". כלומר מעיין אמירה שדומה למה שאמרתי בעבר: אי-אפשר לעשות תכנונים יפים על הנייר כשהניסיון מלמד אותנו שבחיים זה לא עובד כך אף פעם.
חלק מהעקרונות:
סיפוק הלקוח ע"י אספקת תוכנה מועילה במהירות ובהמשכיות.
אפילו שינויים מאוחרים בדרישות באים בברכה.
שיתוף פעולה יומי בין כל הגורמים.
שיחות פיזיות הן צורת התקשורת הטובה ביותר.
הפרוייקט בנוי מאינדיבידואלים בעלי מוטיבציה, ויש לסמוך עליהם.
טיפוח יכולות טכניות מעולות ודיזיין נכון.
פשטות.
צוותים שפועלים עצמאית.
יכולת פיתוח בסביבה משתנה.
*שימו לב למידת האחריות שמוענקת לכל חבר צוות.
SCRUM – דרך ליישם AGILE
Framework for none predictable complex projects
בתחילת התהליך ניצב באקלוג (backlog) של המוצר: סך הפיצ'רים שרוצים להכניס למוצר.
מי שאחראי על התוכן הזה הוא בעל המוצר (product owner), או מנהל מוצר. הוא מחליט אילו פיצ'רים יכנסו, מסדרים לפי פריוריטיזציה ונותנים הערכת זמנים בהתייעצות עם המפתחים וכד'.
אחרי קביעת התכולה מחלקים את הפיצ'רים לספרינטים , אבני דרך, לפי עדיפות: נניח ספרינט ראשון כולל פריטים שבעדיפות 1 עד 5, וכן הלאה. הבאקלוג של המוצר עונה לשאלה מה לעשות, וכשזה עובר לפיתוח הוא נקרא ספרינט באקלוג והוא מתורגם למשימות – כלומר עונה לשאלה איך לעשות. המטרה היא לקיחת כמה פיצ'רים מסה"כ וסיום העבודה עליהם. כלומר בסיום ספרינט יש X פיצרים בדוקים ומתוקנים המוכנים בעצם ללקוח.
יש לטפל בבאגים הנובעים מפיצ'רים בספרינט מיידית. בנוסף יש להחזיק באג באק-לוג ולייעד ספרינטים רק לתיקון באגים.
אורך ספרינט אמור להיות בין ימים בודדים לחודש (הרבה נוקבים בחודש). יש להוסף יום תכנון לפני ויום רוויו בסוף.
ככל המחזור הפיתוח קצר יותר כך הספרינטים אמורים להיות קצרים יותר. אמורים להיות מ-4 עד 12 ספרינטים למחזור פיתוח אחד.
כיוון שכל עיכוב בספרינט אחד יעכב את הספרינט הבא יש לעקוב אחרי ההתקדמות בעזרת ה-burn-down chart. מדידה יומית של שארית העבודה, אמור להגיע לאפס. ציר ה-X הוא תאריכים, ה-Y – שעות שנותרו. בעזרת CHART זה קל למדוד קצב התקדמות או velocity. אם למשל הצוות עושה ביום 50 שעות ויודעים שנותרו 150 שעות לסיום הפרוייקט קל למדוד את הזמן הנותר לספרינט או RELEASE.
איך מחשבים: בכל ספרינט יש הערכת זמנים פר פיצ'ר. בסוף כל יום המשתתפים מעדכנים את הזמן הנותר.
מי שמנהל את התהליך ברמה היומית הוא הסקראם מסטר, שהוא בעצם מנהל פרויקטים.
המלצה שבסה"כ ישתתפו בספרינט 5-9 אנשים.
אמורות להיות פגישות יומיות שנערכות בעמידה ואורכות לא יותר מ-15 ד'. חלק חשוב בעיקר למי שאינו מסונה בתהליך הזה, אבל לא מנדטורי – רק כשיש באמת דברים לסגור. על כל חבר להיות עם תשובות ל:
• מה עשיתי מהפגישה האחרונה.
• מה אעשה עד לפגישה הבאה.
• אילו בעיות יש לי.
בישיבות אלה רק המשתתפים בצוות הם בעלי רשות הדיבור.
מקורות:
http://www.youtube.com/watch?v=Q5k7a9YEoUI
http://he.wikipedia.org/wiki/פיתוח_תוכנה_זריז
http://en.wikipedia.org/wiki/Agile_software_development
שיטה בפיתוח ש"מניחה שלא ניתן להגדיר במלואה תוכנה מסוימת קודם לפיתוחה בפועל, ומתמקדת במקום זאת בשיפור יכולתו של הצוות לספק תוצרים במהירות ולהגיב לדרישות העולות תוך כדי הפיתוח". כלומר מעיין אמירה שדומה למה שאמרתי בעבר: אי-אפשר לעשות תכנונים יפים על הנייר כשהניסיון מלמד אותנו שבחיים זה לא עובד כך אף פעם.
חלק מהעקרונות:
סיפוק הלקוח ע"י אספקת תוכנה מועילה במהירות ובהמשכיות.
אפילו שינויים מאוחרים בדרישות באים בברכה.
שיתוף פעולה יומי בין כל הגורמים.
שיחות פיזיות הן צורת התקשורת הטובה ביותר.
הפרוייקט בנוי מאינדיבידואלים בעלי מוטיבציה, ויש לסמוך עליהם.
טיפוח יכולות טכניות מעולות ודיזיין נכון.
פשטות.
צוותים שפועלים עצמאית.
יכולת פיתוח בסביבה משתנה.
*שימו לב למידת האחריות שמוענקת לכל חבר צוות.
SCRUM – דרך ליישם AGILE
Framework for none predictable complex projects
בתחילת התהליך ניצב באקלוג (backlog) של המוצר: סך הפיצ'רים שרוצים להכניס למוצר.
מי שאחראי על התוכן הזה הוא בעל המוצר (product owner), או מנהל מוצר. הוא מחליט אילו פיצ'רים יכנסו, מסדרים לפי פריוריטיזציה ונותנים הערכת זמנים בהתייעצות עם המפתחים וכד'.
אחרי קביעת התכולה מחלקים את הפיצ'רים לספרינטים , אבני דרך, לפי עדיפות: נניח ספרינט ראשון כולל פריטים שבעדיפות 1 עד 5, וכן הלאה. הבאקלוג של המוצר עונה לשאלה מה לעשות, וכשזה עובר לפיתוח הוא נקרא ספרינט באקלוג והוא מתורגם למשימות – כלומר עונה לשאלה איך לעשות. המטרה היא לקיחת כמה פיצ'רים מסה"כ וסיום העבודה עליהם. כלומר בסיום ספרינט יש X פיצרים בדוקים ומתוקנים המוכנים בעצם ללקוח.
יש לטפל בבאגים הנובעים מפיצ'רים בספרינט מיידית. בנוסף יש להחזיק באג באק-לוג ולייעד ספרינטים רק לתיקון באגים.
אורך ספרינט אמור להיות בין ימים בודדים לחודש (הרבה נוקבים בחודש). יש להוסף יום תכנון לפני ויום רוויו בסוף.
ככל המחזור הפיתוח קצר יותר כך הספרינטים אמורים להיות קצרים יותר. אמורים להיות מ-4 עד 12 ספרינטים למחזור פיתוח אחד.
כיוון שכל עיכוב בספרינט אחד יעכב את הספרינט הבא יש לעקוב אחרי ההתקדמות בעזרת ה-burn-down chart. מדידה יומית של שארית העבודה, אמור להגיע לאפס. ציר ה-X הוא תאריכים, ה-Y – שעות שנותרו. בעזרת CHART זה קל למדוד קצב התקדמות או velocity. אם למשל הצוות עושה ביום 50 שעות ויודעים שנותרו 150 שעות לסיום הפרוייקט קל למדוד את הזמן הנותר לספרינט או RELEASE.
איך מחשבים: בכל ספרינט יש הערכת זמנים פר פיצ'ר. בסוף כל יום המשתתפים מעדכנים את הזמן הנותר.
מי שמנהל את התהליך ברמה היומית הוא הסקראם מסטר, שהוא בעצם מנהל פרויקטים.
המלצה שבסה"כ ישתתפו בספרינט 5-9 אנשים.
אמורות להיות פגישות יומיות שנערכות בעמידה ואורכות לא יותר מ-15 ד'. חלק חשוב בעיקר למי שאינו מסונה בתהליך הזה, אבל לא מנדטורי – רק כשיש באמת דברים לסגור. על כל חבר להיות עם תשובות ל:
• מה עשיתי מהפגישה האחרונה.
• מה אעשה עד לפגישה הבאה.
• אילו בעיות יש לי.
בישיבות אלה רק המשתתפים בצוות הם בעלי רשות הדיבור.
מקורות:
http://www.youtube.com/watch?v=Q5k7a9YEoUI
http://he.wikipedia.org/wiki/פיתוח_תוכנה_זריז
http://en.wikipedia.org/wiki/Agile_software_development
הערה קטנה (מה לעשות, איש QA...): "כיוון שכל עיקוב בספרינט אחד יעקב את הספרינט הבא יש לעקוב אחרי..." יכול להיות שהתכוונת "כיוון שכל עיכוב בספרינט אחד יעכב את הספרינט הבא יש לעקוב אחרי..." ?
השבמחקיום נפלא, גלעד
אצלי זה עובד :)
השבמחקתודה
אחלה שיטה, כשייסמו אותה אצלנו לא אהבתי אותה (למרות שראיתי את היתרונות שלה), כנראה שקשה לעשות שינויים כאלה מבחינה פסיכולוגית, אבל בדיעבד זאת אחלה שיטת עבודה, מהירה, קלה ופשוטה
השבמחקתודה על השיתוף