Posts tagged ‘שיטת המפל’

כל אחד הוא מיוחד

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

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

imageולשמחתי חלק גדול מה-Product owners כבר הפנימו את הנקודה הזו והם מבינים, ועזבו רגע אסורמותר, שלא כדאי לשנות תכולה במהלך הספרינט. יופי !
עקב כך, אותם POs דואגים בין השאר לסדר את הבקלוג לפי עדיפות פיתוח אמיתית… כמעט.

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

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

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

חבל על הזמן…

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

יום שני 11:00 – ישיבת הנהלה הכירה:
המנכ”ל גדי מברך את כולם ביום טוב וסוקר את הפעילויות הצפויות לחברה בעתיד הקרוב, לקוחות פוטנציאלים ועוד מספר עניינים אדמיניסטרטיביים, גדי מזכיר לכולם שהחברה החליטה לעבור לגישות אג’יליות ורזות יותר, “השינויים שאנחנו עושים הם חשובים, הם נוגעים לחלקכם, ויש להקדיש זמן ליועץ שהבאנו ולהתייחס בכובד ראש לדברים” הוא אומר, “מסכנים הפיתוח“ אומרת דליה סמנכלית השיווק, גדי מחייך.
אחד כך עובר גדי לסבב הרגיל של דיווחי סטטוס:
image– שירה, סמנכ”לית פיתוח, מסתכלת על גדי ומספרת על מצב הפרויקטים, הבעיות, ואף מציינת שכבר שני צוותים עברו לפיתוח “בשיטת סקראם” שזה הטרנד החם כרגע בעולם תהליכי פיתוח התוכנה האג’ילים, “יופי, איך הולך?” שאל גדי, “אנחנו מנסים את זה, גם דיברנו עם היועץ שיעזור לנו, אני מאמינה שזה יכול לקצר משמעותית זמני פיתוח ולהגביר את האיכות”, מעולה! אומר גדי תעדכני אותי כשיהיו מסקנות.
– אחרי שירה דיבר יניב, סמנכ”ל HR, הוא סיפר לכולם שעקב חוסר תקציב אין יום כיף השנה, וגם כנראה לא יהיו בונוסים. בנוסף הוא הזכיר שיש למלא את הערכות העובדים עד סוף השבוע ולקבוע יעדים אישיים חדשים לשנה הבאה, “ולא לשכוח לנרמל את התוצאות ברמת הצוות, והמחלקה”, כולם מהנהנים.
– לבסוף מדבר אורן, סמנכ”ל תפעול, הוא טוען שהוא גילה לאחרונה שלקוחות יוצרים קשר עם אנשי פיתוח ולהיפך “זו תופעה חמורה ואנחנו חייבים לנתק את הקשר הזה”, כולם מהנהנים בהסכמה.
– דליה סמנכ”לית שיווק, מעלה בתורה את הבעיה שאנו לא עומדים בזמנים שהבטחנו ללקוח, ומעבר לכך יש לנו בעיה קשה עם לקוח X, יש כרגע מספר בעיות קריטיות וחייבים לפתור לו את הבעיות, ומהר. גדי (המנכ”ל) מסתכל על שירה, שירה אומרת שהם עושים את המקסימום והמפתחים כבר באו 3 סופי שבוע אחרונים בכדי לנסות להדביק את הפער, “והשבוע עוד מפתח עוזב, באמת שאנחנו עושים את המקסימום.”, “את צריכה לשמור על האנשי שלך יותר טוב” אומר גדי בחצי חיוך חצי רצינות. “אני מאמינה שעד סוף הגירסה נצליח להשלים את הפער” אומרת שירה. השיחה ממשיכה עוד קצת ואז תם הזמן לישיבה.
– “טוב, שבוע טוב לכולם” אומר גדי. שבוע טוב, הם עונים לו.

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

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

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

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

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

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

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

הרצאה בכנס 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) על מעבר לתפיסה האג’ילית, ואף אוסיף ממש בקרוב דף באתר שמרכז לינקים בנושא.
על היתרונות של התפיסה כבר כתבתי לא מעט ועוד אכתוב הרבה, אם אתם מאלה שלא מוכנים לנסות עד אשר תוגש להם ההוכחה שזה עובד על מגש של כסף (וזה לגיטימי לגמרי מבחינתי) אני מזמין אתכם להישאר קשובים, להמשיך לקרוא ולהתעניין בנושא, ומקווה שיום אחד יקרה אחד מהשניים: תסכימו לתת צ’אנס לנושא, או שמישהו יספק איזה שהוא סקר שירצה אתכם.

דיזיין אג’ילי – יש דבר כזה

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

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

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

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

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

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

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

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

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

יאללה סקראם (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, גרף זה מספק תמונה טובה על התקדמות הצוותהמוצר בספרינט בפרויקט.

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

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

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

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

נשארו עוד ארבעה בסה”כ.

Continuous attention to technical excellence and good design enhances agility.

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

Simplicity–the art of maximizing the amount of work not done–is essential.

זה אחד העקרונות האהובים עליי ביותר, ואם זאת אחד הקשים ביותר לאימוץ, בעיקר ע”י מהנדסים מנוסים. פשטות כעיקרון, איזה יופי! הרי כבר נאמר כי לבעיות הכי סבוכות בד”כ הפתרונות הם פשוטים במהותם, ואני נוטה להסכים אם אמרה זו. מה המשמעות של פשטות?
הכי טוב שאתן דוגמא: יוסי מקבל משימה לפתח מכונת מצבים בעלת 5 מצבים שמתארת רמזור (אדום, כתום, ירוק , כתום מהבהב, כבוי) ועל הרמזור לשנות מצב כל 10 שניות למצב הבא ובסדר שהוגדר קודם. מה יעשה יוסי, כמובן שקודם כל יחשוב… ויחשוב עוד קצת, ואז, יעלה על הכתב את הדיזיין המדהים שלו למכונת מצבים אבסטרקטית, את המחלקה הג’נרית TrafficLightState שתמומש אחרת לכל State, ואפילו, אם תרצו תוכלו בעתיד להוסיף עוד מצבים, בנוסף לכך את 10 השניות ניתן יהיה להגדיר מתוך קובץ XML מדהים עם סכמה (Scheme), ויהיה ניתן להרחיב את הסכמה בעתיד, מדהים!
אבל רגע, תעצור, לא הגזמנו? אדם שמאמין בפשטות מה היה עושה עבור מכונת מצבים פשוטה של 5 מצבים? משתמש ב-switch case, את הזמן ניתן או להגדיר בקוד או אפילו להרחיק לכת עד כדי העברתו בתור פרמטר לתוכנית. ונניח מגדיר מחלקה למצב הרמזור (או אולי אפילו אינומרציה). אם בעתיד מישהו ירצה לשכלל את המכונה, נשכלל אותה, אבל כרגע הדרישות הן ברורות!
אז למה לבנות חללית כשאנחנו זקוקים לאופניים? זאת המשמעות של פשטות.
שלא תבינו לא נכון, אם היו עשרים מצבים, והרבה זמנים, ומכונה מסובכת, הייתי ממליץ בחום על מכונת מצבים אבסטרקטית, אבל זה לא המקרה.
עיקרון זה רלוונטי גם באספקט של פונקציונאליות במוצר (רק דברים שחייבים, למזער את כמות ה-“רק ליתר ביטחון”, ואף רלוונטי לאספקט של תהליכים, ניתן להשליך את העיקרון הזה על המון דברים נוספים, ואני בטח עוד אכתוב פוסטים רבים בעניין זה.
תקראו עכשיו שוב את המשפט באנגלית בבקשה, אז זהו אחד העקרונות האהובים עליי.

The best architectures, requirements, and designs emerge
from self-organizing teams.

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

At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

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

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

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

הפעם אין הקדמה, נמשיך.

Build projects around motivated individuals. Give them the
environment and support hey need, and trust them to get the job done.

העיקרון הזה מדבר על האנשים ומתחלק לשלושה חלקים, ואני אף,הייתי מפריד אותו.
1. בבסיס התפיסה האג’ילית קיימת ההנחה שללא אנשים מקצוענים, בעלי יכולת גבוהה לא ניתן בכל מקרה להגיע להישגים בתחום שלנו (פיתוח תוכנה), לכן בין השאר קיים העיקרון הזה, הוא מדגיש את החשיבות בבחירת האנשים המתאימים לפרויקט. עקרון זה הוא איננו טריוויאלי שכן ישנן חברות רבות שהקומפוזיציה של צוותים בד”כ נוטה לכיוון שבצוות יש כ-20% של מובילים ועוד 80% של כאלה שיעשו את ה”עבודה השחורה” (על צוותים והרכבם יש לי הרבה מה לומר).
2. ספקו לאנשים העובדים את כל מה שהם צריכים כדי להצליח במשימה, שוב נשמע טריוויאלי אך בד”כ לא ממומש, אני כמעט בטוח שיצא לכם להיתקל בסיטואציות שלא הסכימו לתת תקציב (או אפילו הסכימו אבל עשו את המוות קודם) לדברים קטנים שיכלו לעשות שינוי גדול כגון: החלפת מסך, הוספת זכרון, קורסים וכו’. ההוצאות התקציביות שהזכרתי הן בד”כ השוליים של הוצאות הפיתוח שרובן הן התקורה והאנשים. רק התסכול שנוצר עקב ה”חיסכון” עולה יותר.
3. החלק השלישי והכי לא טריוויאלי הוא לבטוח באנשים, זה לא פשוט אני מודה, אבל זה כדאי. המשמעות של לבטוח באנשים היא לתת להם את החופש לעשות את העבודה כמו שהם חושבים שצריך, לא להתערב להם בהחלטות (אפילו טכניות), אנחנו נדבר עוד הרבה על הנושאים הללו.

The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation.

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

Working software is the primary measure of progress.

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

Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace indefinitely.

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

נשארו עוד שלושה עקרונות… בפוסט הבא.