Posts tagged ‘מתודולוגיה’

הרצאה בכנס PMI

image

לאחרונה הצגתי בכנס PMI הרצאה שנותנת מבוא לאג’יל (Agile) וסקראם.

אם אתם מוצאים את זה מעניין, אז הנה לינק למצגת.

מכתב פתוח לדוד בוב

בוב היקר,

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

אתייחס כעת לעל אחת מהנקודות שהעלית:

1. חוסר בטכניקות טכניות – אתה צודק, וזה ידוע לרוב שסקראם, בניגוד למשל ל-XP אינו מציין באיזה טכניקות או שיטות יש להשתמש כשמפתחים תוכנה, ולטעמי לא סתם: לו היה סקראם מגדיר באיזה שיטות לעבוד כשמפתחים תוכנה הרי היה גורלו להפוך לא רלוונטי כעבור פרק זמן מסויים, וכידוע לנו, תחום התוכנה הוא דינאמי ומשתנה. כאשר צוותים היום בוחרים לעבוד בסקראם הם בד”כ משתמשים בשיטות כגון CI, Pair programming, TDD וכו’ מכיוון שאלה דברים שנכון להיום אנו יודעים שהם עובדים, אבל מה יהיה עוד 10 שנים, האם עדיין אותן שיטות יהיו רלוונטיות ? אז ממש כמו ה-Agile Manifesto שאתה מהיוזמים שלו, לא צוינו פרטים טכניים בכדי לשמר אותו לאורך זמן, כך גם סקראם, ואני רואה בכך יתרון.

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

3. מסכים בהחלט – לא מומלץ ואף גורם נזק בד”כ כשהסקראם מסטר הוא גם מנהל פרויקט. אבל זה לא חסרון של סקראם.

4. מסכים! מסכים! מסכים! אבל גם זה לא חסרון של סקראם אלא של הארגון שמפיץ אותו, היה נפלא לו היינו נפתרים מה-“Certified” לאלתר.

5. סקראם לא צריך לספק הנחיה על איך לתחזק את ה-Backlog מאותה סיבה שאינו צריך להגדיר מתודולוגיות טכניות (ראה 1).

6. אני לא יודע מהיכן אתה מסיק את המסר הזה, לדעתי לסקראם יש זרם על קרקעי וברור שדוחף לפחות בזבוז (יותר Lean) ובין השאר גם לפחות מנהלים ויותר עובדים שמייצרים ערך (Value workers). העובדה שסקראם דורש צוותים מנוהלים עצמאית אינו אומר אנטי הנהלה – הוא אומר ניהול משותף איפה שהוא תורם יותר.

7. זו הנקודה היחידה שאני נוטה להסכים איתך, יש מקום (אם כי לא חובה) לציין כי Continuous integration צריך להיות חלק מהשיטה.

8. צוותים מרובים או “סקראם בגדול” היא באמת שאלה פתוחה ואני לא חושב שמישהו עדיין מצא אחת גלובאלית להתמודד עם השאלה, לטעמי האישי הרעיונות של Bas Vodde ו-Craig Larman הם טובים, אך גם הם לא מתאימים לכל מקום כמו כפפה ליד, הנושא של פיתוח בסדר גודל גדול הוא נושא כנראה סבוך מידי ואין פתרון אחד (ממש כמו התפיסה האג’ילית – One size does not fit all)

זוהי תשובתי מלאת ההערכה אלייך דוד בוב (Robert C Martin).

אלעד.

תכנון פרויקטים בסקראם.

clip_image002אחת התפיסות המוטעות הנפוצות ביותר, היא שפרויקטים שמתבצעים בסקראם לוקים בחסר באספקטים של תכנון, כמובן שההפך הוא הנכון, מניסיוני בפרויקטים אג’ילים מתעסקים באלמנטים של תכנון לא פחות ואף יותר מהשיטות מסורתיות. זה נכון שבפרויקט בסקראם אין שלב בתחילת הפרויקט שמוקדש כולו לתכנון, אנליזה והערכות זמנים “מדויקות” של הפרויקט, אך לעומת זאת, על סמך המידע הקיים בכל רגע נתון, אנו מנסים לקבל תמונה טובה ככל שניתן על מצבו האמיתי של הפרויקט. בפסקאות הבאות אנסה לתת לכם טעימה מתהליך תכנון פרויקט Scrum.

נתחיל במספר נקודות:

  • אם נחזור רגע להערכת משימות בשיטה אג’ילית, יש שבוחרים (ואני גם ממליץ) להשתמש ביחידות מידה יחסיות שנקראות Story points (ראו הרחבה בפוסט בנושא).
  • אחד המאפיינים הבולטים של שיטות ה-agile השונות וביניהן Scrum הוא איטרציות קבועות בזמן שבסופן הצוות מספק תוכנה עובדת (Done), היתרון העיקרי של איטרציות שכאלה, הוא קיומו של “דופק” קבוע לפרויקט, שמאפשר לנו לקבל תמונה לא רעה בכלל על מצב הפרויקט והתקדמותו, אחד המדדים החשובים שניתן לקבל כאשר עובדים באיטרציות הוא כמה תפוקה הצוות (או הצוותים) מסוגל לספק באיטרציה אחת (במקרה של סקראם ספרינט), נהוג לכנות את המדד הזה בשם Velocity.
  • רשימת הדרישות נמצאת בתוך מסמך שאנו מכנים Product backlog, המסמך מאופיין בכך שבכל רגע נתון, הפריטים בו מסודרים לפי הסדר שבו אנו מבקשים לפתח אותם.

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

אז מה אנחנו רוצים לתכנן ? התכנון מתבצע ברמות שונות:

  • יומית – בכל יום אנו מבצעים ישיבה ובודקים האם אנו עומדים בהתחייבויות שלנו לספרינט הקרוב.
  • · ספרינט – בתחילתו של כל ספרינט אנו מבצעים ישיבה שבה הצוות מתחייב לסיים מספר פריטים מרשימת הדרישות – Product backlog.
  • · גרסה (Release) – תכנון גרסה תלוי בעיקר בסוג הגרסה, אני אחלק את הנושא לשני סוגים: גרסה עם קבוע זמן, וגרסה עם קבוע תכולה.
    • כאשר הקבוע הוא הזמן, אז פעולת התכנון מנסה להעריך כמה מתוך התכולה ניתן להכניס עד התאריך הנקוב, עושים זאת ע”י בדיקה של כמה איטרציות נכנסות עד תאריך שחרור הגירסא ומתוך מספר האיטרציות ניתן להעריך תוך שימוש בנתון ה-‘velocity כמה מתוך הפריטים ברשימה נספיק לפתח.
    • כאשר הקבוע הוא התכולה, אז פעולת התכנון מנסה להעריך לכמה איטרציות נזדקק ע”מ לסיים את הפריטים שהוקצו לגרסה, זאת ע”י סכימה של הערכות המאמצים של הפריטים שאמורים להיכלל בגרסה, וחלוקת המספר שהתקבל ב-velocity. התוצאה מספקת לנו את מספר האיטרציות שאנו זקוקים להם על מנת לסיים את התכולה.
      בשני המקרים, ככל שהמידע שבידינו מהימן יותר, כך פעולת התכנון תספק הערכות טובות יותר.
  • ניתן ואף נהוג לתכנן ברמות נוספות כגון: רמת המוצר (סה”כ הדרישות לכלל הגרסאות).

תאמינו או לא אבל זהו. היופי בתהליך הזה הוא בפשטות ובהיגיון שבו, וכמו שאני מקווה שראיתם, התכנון הוא חלק חשוב ומשמעותי בניהול פרויקטים אג’ילים ו-Scrum בפרט.

ההוכחה שאג’יל עובד.

clip_image001שינוי משמעותי כגון שינוי של שיטת עבודה הוא שינוי קשה לרוב האנשים, ולכן לפני שאנשים מוכנים לשקול את ביצוע השינוי אחת השאלות שעולות היא “האם השינוי הזה טוב בשבילי?”. השאלה היא כמובן לגיטימית ועניינית מאוד.
אם תקראו חומר ברשת, וחומר כתוב בנושא אג’יל וסקראם, תגלו שכרגע יש סוג של הימנעות מלהתעסק בחיפוש מדדים וראיות ששיטות אג’יליות וסקראם בפרט, עובדות.
באופן אישי אני חושב שבשלב הזה התעסקות בשאלות כאלה יכולה אמנם להפיק תועלת מסוימת אך לדעתי הנזק שעלול להיגרם הוא גדול יותר, בשורות הבאות אסביר למה אני חושב כך.
• הרגע הגענו… – קודם כל יש להפנים את העובדה שמדובר בנושא חדש, התפיסה האג’ילית הינה דבר חדש. סקראם, שנחשבת ע”י חלק מהאנשים למתודולוגיה האג’ילית הוותיקה ביותר, הייתה בשימוש לראשונה באמצע שנות התשעים, וגם זה, בקנה מידה מזערי. Extreme programming – שהיא אולי השיטה הנפוצה ביותר בתחום כיום, הוגדרה לראשונה בסוף שנות ה-90, ורק בשנת 2000 פורסם הספר הראשון שמתאר את השיטה. אז אתם מבינים שכל הסיפור הזה הוא די חדש.
למרות כל זאת, קיימים מחקרים שמצביעים על כך שחלק גדול “מהעובדות” שעליהן מתבססות המתודולוגיות המסורתיות, ובפרט שיטת המפל, הן עובדות שווא, כמו כן קיימים מספר תחומים אשר יעילותם היא כבר קונצנזוס די רחב בתעשיית התוכנה, דברים כגון תכנות בזוגות (pair programming), צוותים מנוהלים עצמאית (self directed teams) ועוד.
• עוד לא למדנו איך למדוד – עקב הרגלי העבודה שלנו בשיטות המסורתיות, ובהתבסס על הנחות היסוד שמהוות את הבסיס לשיטות אלו, היה קל באופן יחסי למדוד הצלחה, תפוקה או כישלון במונחים “אובייקטיביים”. כל מה שהיינו צריכים לעשות זה להשוות את התוכניות למציאות, ככל שהיינו קרובים יותר לתוכנית נחשבנו מוצלחים יותר, זה קל.
בפרויקטים אג’ילים הנחת היסוד היא שלא ניתן לייצר תוכנית מספיק טובה שתשמש אותנו לכל אורך הפרויקט, דבר זה מייצר בעיה למדוד הצלחה או כישלון בכלים הרגילים, מכאן ברור שהצלחה או כישלון של פרויקט אג’ילי היא דבר שקשה יותר למדוד, הרי עדיין אין נתון חד משמעי שניתן לבדוק מולו את ההצלחה. בעיה.
המדדים שמצביעים על הצלחה של פרויקט אג’ילי לפי דעתי קשורים בעיקר לשני תחומים: שביעות רצונו של הלקוח ואיכות. מכיוון שהראשון הוא סובייקטיבי לחלוטין הרי קשה (למרות שאפשרי) למדוד את נתון זה, ואף קשה יותר לייצר סטטיסטיקות שמתבססות על נתון זה.
נותר לנו מדד מהימן אחר שהוא האיכות, על איכות כבר דיברתי לא מעט, אבל למרות שאין לי כל סטטיסטיקה, ובודאי שאני לא מייצג שום מדגם, הפרויקטים האג’ילים שלקחתי בהם חלק הצטיינו באיכותם פי כמה מהפרויקטים ה”לא אג’ילים”.
לסיכום הנקודה, קשה הרבה יותר למדוד הצלחה של פרויקטים אג’ילים.
• מי שמבקש הוכחות, מחפש משהו אחר – יכול להיות גם שחלק מאותם אנשים שמבקשים הוכחות ל”איכותה” של התפיסה האג’ילית למעשה לא מחפש חיזוקים בכדי לאמץ תפיסה זו. בחלק מהשיחות שאני מבצע עם אנשים אני חש לעיתים כי כשהם שואלים שאלות הם לא באמת מחפשים לחקור, להבין ולבדוק את האפשרות לאמץ תפיסה חדשה, אלא מנסים בכל הכוח להמעיט בערכה של תפיסת עולם שלא נוח להם איתה. האם אנשים אלו ריאלים מספיק בכדי להפנים את העובדה שפיתוח תוכנה בבסיס אינו תהליך פשוט ובטח שלא מושלם? האם הם מוכנים לקבל את העובדה שמה שאני מספר עליו הוא לא פתרון הקסם אלא הצעה לשיפור? האם בכלל הם באמת מחפשים הוכחה שזה עובד, או שמא מחפשים את אותה תחושת ביטחון מזויפת שנגזרת מהאמונה שאם משהו עבד למישהו אחר הוא מתאים גם להם?
דבר אחרון אולי בנושא זה, רבים שאותם אנשים שטוענים שהתפיסה האג’ילית אינה טובה, כלל אינם מכירים או מבינים אותה. לעתים הבקשה הלא מקוימת להוכחה, משמשת אותם כמנגנון הגנה מפני השינוי המתבקש.
טוב, אחרי שטענתי שלדעתי התעסקות בשאלת ההוכחה היא מיותרת בעת זו, בכל זאת צריך שיהיה משהו, לא? אז אם תסתובבו קצת ברשת של הכפר הגלובלי שלנו שנקראת האינטרנט, תוכלו למצוא לא מעט דעות חיוביות, בלוגים, קבוצות דיון וכדומה בנושא, כמעט כולם משבחים את העניין, כמעט כולם מביעים שביעות רצון גבוהה מהמעבר לחשיבה אג’ילית. ישנם סקרים של גופים לא נייטרלים שמראים שביעות רצון גבוהה ממעבר למתודולוגיות אג’יליות – זה גם משהו לא? בנוסף יש לא מעט סיפורים (case studies) על מעבר לתפיסה האג’ילית, ואף אוסיף ממש בקרוב דף באתר שמרכז לינקים בנושא.
על היתרונות של התפיסה כבר כתבתי לא מעט ועוד אכתוב הרבה, אם אתם מאלה שלא מוכנים לנסות עד אשר תוגש להם ההוכחה שזה עובד על מגש של כסף (וזה לגיטימי לגמרי מבחינתי) אני מזמין אתכם להישאר קשובים, להמשיך לקרוא ולהתעניין בנושא, ומקווה שיום אחד יקרה אחד מהשניים: תסכימו לתת צ’אנס לנושא, או שמישהו יספק איזה שהוא סקר שירצה אתכם.

סקראם מסטר – טכנולוג או טכנופוב ?

לפוסט “סקראם מסטר – מי אתה ?” נכתבה הערהשאלה על מידת הידע הטכני הנדרשת לסקראם מסטר, למרות שכתבתיי את דעתי בתגובה להודעה, אני חושב שיש מקום להרחיב בשאלה הזאת : כמה ידע טכני צריך הסקראם מסטר?

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

אם קראתם טוב את ההגדרה אני מניח שלא ממש מצאתם שום דבר שמצביע על כך שעליו להכיר באיזה שהיא רמה את הצד הטכני של הבעיה שהצוות מתמודד איתו, לעומת זאת עליו להכיר ולהבין לעומק את מתודולוגית הסקראם (שהיא פשוטה), עליו לדעת להנחות ישיבות, ולהסיר מכשולים, גם אין כמעט ויכוח על כך שרצוי שהסקראם מסטר יבין ויפנים את התפיסה האג’ילית כדי שיהיה מסוגל להנחיל אותה לצוות, ואף יכיר כלים אג’ילים כגון XP, TDD, Pair programming, Continuous integration וכו’
אם כך, הסקראם מסטר לא צריך ידע טכני. נחמד. אבל… ותמיד יש אבל, מה אם יש לו ידע טכני, האם זה יעזור או יפריע לביצוע התפקיד? שאלנו את פלוני ואלמוני ולהלן תשובתם:

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

אלמוני אומר: מה פתאום! בשום אופן לא צריך ידע טכני, זה רק פתח לצרות, אחד הדברים המהותיים בסקראם זה צוות שמנהל את עצמו (Self managing team), אם לסקראם מסטר יהיה ידע טכני אז הוא למעשה ר”צ, כלומר יעזור להם בלפתור בעיות. שיתמודדו לבד. רק ככה הם ילמדו. יותר מכך, אם הוא יפתור לצוות בעיות הצוות יתחיל לפתח תלות בסקראם מסטר, ובכלל, אם הוא יהיה עסוק בצד הטכני מתי יהיה לו זמן להתעסק בדברים החשובים כגון פתרון בעיות לא טכניות, אימון הצוות, התבוננות. בקיצר – בשום אופן לא צריך ידע טכני.

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

יש עוד שתי נקודות שעולות לי בהקשר הזה:

  • כאשר שוקלים איזה “סוג” של לסקראם מסטר רוצים, יש לשקול את המחיר של ההתעסקות הטכנית, כאשר סקראם מסטר עסוק בפן הטכני של הפרויקט הוא מזניח, ולו במעט, את הפן ההתנהגותי של הצוות.
  • כאשר לסקראם מסטר ידע טכני, בנוסף לדילמות הרגילות שיש לו, נוספות לו דילמות חדשות בפן הטכני, למשל (דוגמא שלי מהחיים), הסקראם מסטר רואה שהצוות עושה החלטה טכנית גרועה (לדעתו), האם הוא מתערב לצוות בהחלטה ?
    נקודה למחשבה: אם נחזור רגע לערכים האג’ילים נמצא בראש הרשימה את המשפט הבא:
    Individuals and interactions over processes and tools.
    מה זה אומר לכם לגבי הנושא הזה?

יאללה סקראם (Scrum) !!!

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

הפעם הראשונה שנעשתה ההשוואה בין רוגבי לעולם הפיתוח הייתה בשנת 1986 במאמר שנקרא
“The new product development game” שנכתב ע”י שני סטודנטים בהרווארד .
הפעם הבאה שסקראם הוזכר הייתה בספר “Wicked Problems, Righteous Solutions“.

לאחר מכן (ולמעשה במקביל) קן שוובר (Ken Schwaber) וג’ף סת’רלנד (Jeff Sutherland) שהיו בעלים של חברות יעוץ תוכנה, החלו להטמיע את השיטה שמקורה במאמרים שהוזכרו.
ב-1995 נפגשו השניים בוועידה והחלו לשתף פעולה ע”מ לקדם את המתודולוגיה, הניסיון שלהם הוא מה שהיום ידוע כסקראם.
בשנת 2001 נכתב לראשונה ספר שמתאר את המתודולוגיה ונקרא – Agile s/w development with scrum.

יופי, נורא מעניין, אבל מה זה סקראם ?
ובכן, סקראם למעשה אינה ממש מתודולוגיה מלאה, כי אם שלד או תשתית להתנהלות של פיתוח תוכנה, מה הכוונה? בסקראם ישנם מספר מאוד מצומצם של “חוקים”, מספר קטן של “תפקידים” וזהו.
זהו? כן!
ובכן נתחיל בתיאור : ישנו אחראי מוצר שמייצג את הלקוח (Product owner) שאחראי לתחזוקה של רשימת הדרישות הממוינת לפי ערך ללקוח (Product backlog), בכל תחילה של ספרינט (מיד תבינו בדיוק מה זה ספרינט) ,בישיבת תכנון הספרינט, הצוות בוחר לפי סדר העדיפות שברשימה על איזה פריטים הוא יכול להתחייב שיפותחו בספרינט הקרוב, ובסוף הספרינט הצוות מציג את המוצר עם התוספות שהסתיימו (DONE) בספרינט לכל מי שמעוניין. מה זה DONE? עוד רגע…
מהו הספרינט ? תקופה שבין 15-30 ימים שבה הצוות עובד על פיתוח הפריטים שנבחרו בתחילת הספרינט. במהלך הספרינט אין להפריע לצוות, אין לשנות עדיפות, ואין לשנות תכולה. בכל יום במהלך הספרינט ישנה ישיבה (Daily) של עד 15 דקות, שבה חברי הצוות מעדכנים זה את זה במצב המשימות ע”י מענה על שלוש שאלות פשוטות: מה עשיתי עד עכשיו? מה אני אעשה עד הישיבה הבאה? ומה מפריע לי? את הישיבה הזאת, כמו גם את תכנון הספרינט מוביל הסקראם מסטר (Scrum master). תפקידיו של הסקראם מסטר הם פשוטים, קשים וחשובים גם יחד: לדאוג שהסקראם יתנהל כמו שצריך, לדאוג שלא יפריעו לצוות לעבוד, לדאוג להסיר מכשולים שיש לצוות, ולהנחות את הישיבות של הסקראם. הסקראם מסטר אינו מוביל הצוות, הוא מוביל הסקראם, הצוות הוא יחידה עצמאית לגמרי.
בכל סוף ספרינט מציגים לכל מי שמעוניין את התוספת למוצר אשר פותחה מתוך הפריטים ואשר הם DONE. מה זה DONE ? DONE זה הקריטריון שמוסכם על הצוות ועל מנהל המוצר אשר מגדיר מתי פריט מהרשימה נחשב גמור, למשל DONE = Implemented, unit tested, acc tested.

בנוסף לכך בסוף כל ספרינט מתקיימת ישיבת רטרוספקטיבה, ישיבה זו נועדה לשקף את הספרינט האחרון ולדון מה היה טוב ויש לשמר ומה היה פחות מוצלח וניתן לשפר.
גם הצוות וגם מנהל המוצר מתחזקים גרף שנקרא Burn down chart, גרף זה מספק תמונה טובה על התקדמות הצוותהמוצר בספרינט בפרויקט.

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

זהו. זה הכל – פשוט, לא ?
שימו לב על כמה דברים סקראם לא מדבר, ובכוונה !

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

העקרונות האג’ילים – חלק 1.

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

Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.

זהו הערך הראשון ולא במקרה, הערך הזה מדבר על הלקוח בתור הדבר הכי חשוב שיש לנו, ושהמטרה החשובה ביותר שלנו היא לא אחרת מאשר לקוח מרוצה. לא יותר ולא פחות. האחורי הביטוי “לקוח מרוצה” מסתתר המון, ורק על זה אפשר לכתוב בלוג שלם, אבל אם נגביל את הדיון למקרה הפרטי שלנו בצורה פשטנית, ניתן לומר כי “לקוח מרוצה” הוא כנראה לקוח שמבין שמה שהוא קיבל הוא שווה ערך לכסף שהוא שילם. התפיסה האג’ילית שמה במרכז את הלקוח ומדגישה את הצורך בקבלת פידבק מהלקוח מוקדם ככל האפשר

Welcome changing requirements, even late in development
Agile processes harness change for the customer’s competitive advantage.

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

Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.

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

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

Business people and developers must work together daily throughout the project.

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

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

בואו נחבר את הנקודות עד כה + הבהרה

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

יופי !

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

מה היא הפרדיגמה? או…הבהרה לג’וני ולכולם

אתמול קיבלתי תגובה מאוד מעניינת ואף מאתגרת במובן מסוים, והרגשתי צורך להגיב אבל ממש בפוסט ולתת את הכבוד הראוי.
כתב ג’וני:
בהינתן מונח חדש בבלוג, בדקתי את פרושו, ולהלן שני פרושים:
1. תבנית מחשבה במסגרת של תחום מדעי או בהקשר אפיסטמולוגי דומה.
2. מודל, תיאוריה, תפיסה, הנחה או מסגרת התייחסות. במשמעות הרחבה יותר, משמעה הדרך שבה אנו “רואים” את העולם – לא באמצעות חוש הראייה, אלא במובן של תפיסה.

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

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

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

ושוב….. תודה רבה ג’וני.