-->

יום שני, 5 בנובמבר 2012

סדרה: Agile (מתודולוגיות פיתוח רזות)

ישנם חילוקי דעות לגבי מתודולוגית הפיתוח החדשה יחסית "סקראם" (SCRUM): "שווה" או "לא-שווה"?

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

נתקלתי ברעיונות האג'ייל לראשונה בשנת 2002, עוד בתקופת האוניברסיטה, בעת שמנחה הפרויקט שלנו דרש מאיתנו לעבוד ב Extreme Programming - קיצוני למדי לאותה התקופה, אולי בכלל. רעיונות אלו טלטלו אותי והשפיעו עלי עמוקות.

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

בסדרה זו קיבצתי פוסטים העוסקים בנושא מתודולוגיות הפיתוח הרזות - Agile.
שימו לב שהפוסטים לא מוצגים בסדר שהם פורסמו: פרסמתי קודם "דיוני-עומק" ורק לאחר מכן חזרתי אל הבסיס.


אני מתכוון, עם הזמן, להמשיך ולהעמיק את הסדרה.




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





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





קיצור תולדות הסקראם - חלק ב'
בעוד חלק א' הוא יותר סיפורי - חלק ב' מתמקד בעקרונות עצמם, כפי שהושמו ע"י טויוטה וה TPS.
עקרונות אלו נקראם Lean או Lean Manufacturing - סקראם הוא רק תרגום שלהם, לעולם התוכנה.




כיצד ייתכן?!
כמה "פרדוקסים" של העולם הישן - שאג'ייל יכול להסביר.
כמו תיאוריות פיזיקליות שהצליחו להסביר התנהגויות משונות - שקודם לכן ראו אותן כמוזרות או סטייה.





סקראם - על חודם של שני אנשים
בואו נדבר ת'כלס: סקראם כולל הרבה רעיונות / כללים, אבל מה באמת הכי חשוב?
אם אנו רוצים להתמקד ברעיון אחד או שניים - מה הם צריכים להיות?






על תפקיד ה Product Owner
תפקיד ה PO כולל כל מיני פרטים משעממים, כגון תחזוקה של רשימות רבות וניהול ישיבות. בפוסט זה נדון בהיבט אחר, קצת יותר מעניין, שמשפיע ישירות על הארכיטקטורה ואיכות הקוד במערכת.



קאנבאן - תהליך שמנהל את עצמו
קצת על באזזים יותר חדשים, שהופיעו לפני שלוש-ארבע שנים כרעיונות ועכשיו אפשר למצוא אותם קורים, פה בישראל. "אג'ייל בלי סקראם".






אין תגובות:

הוסף רשומת תגובה