Posts tagged ‘iteration’

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

בוב היקר,

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

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

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 בפרט.

אלמנטים של סקראם… מיון רשימת הדרישות (Product backlog) – חלק שני

לפני שאני ממשיך אני רוצה להזכיר שהפוסט הוא חלק שני וההתחלה שלו נמצאת כאן.

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

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

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

עבור כל פריט מהרשימה, נסמן לכל קריטריון בתא המתאים בטבלה האם הוא טוב יותר (+), טוב פחות (-) או טוב באותה המידה (0). אחרי שסימנו את כל הטבלה נותר רק לסכום עבור כל פריט: כל ‘+’ מעלה בנקודה, כל ‘-‘ מוריד נקודה ו-‘0’ לא משנה ניקוד. למעשה, דירגנו את הפריטים באופן יחסי זה לזה (על סמך פריט הבסיס כמובן).
את השיטה הזאת ניתן לשכלל במספר דרכים שכמובן דורשות מאמץ נוסף כגון:
– להחליט על פריט להשוואה שונה עבור כל אחד מהקריטריונים וכך לקבל תמונה טובה יותר.
– במקום להשתמש ב ‘+’ ו ‘-‘ ניתן להשתמש במספרים 1-5, שלא רק אומרים אם פריט מסוים עונה טוב יותר או פחות על קריטריון אלא גם לציין עד כמה באופן יחסי.
– ניתן להוסיף פקטור לכל אחד מהקריטריונים בכדי לבטא את החשיבות שלו למשל לקריטריון 1 ניתן פקטור של 0.5 ולקריטריון 2 ניתן פקטור של 0.1 ורצוי שסה”כ הפקטורים יהיה 1 (על בסיס של 100%).
– וניתן כמובן לשכלל את המודל בכל צורה שעולה על דעתכם.

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

ניקוד יחסי.
הרעיון הכללי בניקוד יחסי הוא הכללה מספר פרמטרים שעד כה לא לקחנו בחשבון במודלים הקודמים, הפרמטרים הללו הם: עלות ותועלת. אם עד כה הצגתי שיטות שמנסות לדרג את הפריטים ע”פ האיכות הפונקציונאלית שלהם, אציג כעת שיטה שנותנת משקל לעלות והתועלת שכל אחד מהפריטים מביא איתו. לדעתי לא ניתן לומר בצורה חד משמעית אם השילוב של הפרמטרים האלה הוא טוב או רע, וכנראה שזה תלוי בסוג הפרויקט, ובהעדפה אישית, יש שיגידו שהאיכות הפונקציונאלית כבר כוללת בתוכה את התועלת, והתחשבות בעלות היא חשובה, אבל פחות. כפי שציינתי זה גם מאוד תלוי על איך מגדירים את המושג ROIומהן מטרות הפרויקט.
במודל הזה, עבור כל פריט אנחנו ננסה לענות על מספר שאלות, תוך שימוש במספרים 1-9 כתשובות אפשריות. השאלות עליהן אנו מתבקשים לענות הן, אני גם אתן דוגמאות בכדי להמחיש:
– מה היא תועלת יחסית שנקבל אם הפריט ייכלל בתכולה ?
– מה הוא נזק יחסי שיגרם אם הפריט לא ייכלל ?
– מה היא העלות ?- הערכת מאמץ (לא משנה באיזה יחידות)
דוגמאות להמחשה :
– תמיכה ל-iPhone – מצד אחד יש תועלת משמעותית כי זה יכול לחשוף את האפליקציה שלנו לשוק חדש, מצד שני, אם לא נכלול את זה, יגרם נזק אבל הוא לא משמעותי. הערכתנו לפיתוח היק 20 נקודות (Story points).
– תמיכה בחוק הספאם לרשימות תפוצה – אם לא נוסיף תמיכה אז הנזק יהיה משמעותי ונאבד חלק ניכר מהלקוחות, למרות שהוספה שלו לא נותנת לנו שום תועלת ממשית. הערכתנו לפיתוח היא 8 נקודות (Story points).

אחרי שסיימנו למלא את הנתונים, מבצעים את החישובים הבאים :
– ערך = (ייכלל) + (לא ייכלל)
– ערך יחסי = 100 * (ערך סכום (ערך))
– עלות יחסית = עלות סכום (עלות)
– דירוג = 100 * (ערך יחסי עלות יחסית).

התבוננות על שדה הדירוג מדרגת את הפריטים לפי עדיפות מהגבוה לנמוך.

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

כמו שאומרים… עד כאן דברינו להיום בנושא של מיון וסינון תכולה, ניפגש בפוסט הבא. :)

אלמנטים של סקראם….רטרוספקטיבה

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

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

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

תפיסת ה-“בחינה והתאמה” מיושמת בסקראם באמצעותה של ישיבה שמתבצעת בסוף כל ספרינט ונקראת רטרוספקטיבת הספרינט (Sprint retrospective).

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

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

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

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

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

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

אבטחת איכות (QA), לא מה שחשבתם.

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

אני חושב אחרת.

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

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

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

בואו נבחן את הרעיון הבא: מחקרים מראים שכ-80% מהבאגים נגרמות ע”י טעויות אנוש, אז אם הייתה לנו מערכת שמונעת לפחות חלק מטעויות האנוש היינו יכולים להימנע מחלק מהבאגים, ובכן, יש מערכות כאלה.

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

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

לתפיסה הזו אני קורא (מתרגם): להכניס את הבדיקות פנימה – Build quality in*.

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

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

ישנן כיום מספר שיטות למימוש תפיסה כזאת, על אחת מהן דיברתי (Continuous integration), ובנוסף ישנם כלים רבים לכתיבה והפעלה של בדיקות אוטומטיות:
ל-JAVA יש את : Junit, EasyMock, NGTest,Fitnesse
ל- C++ יש את : CppTest,Jungle,Fitnesse
ל – .NET – יש את : NUnit, TestDriven.NET
וכו’…

*הביטוי מתוך הספר Lean Software development . הוספתי לינק.

טיפים לדיזיין אג’ילי

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

* בפוסט הזה אשתמש בביטויים ארכיטקט, דיזיין, מידול, מודל וכו’ – אני מתכוון לאותו דבר.

clip_image002

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

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

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

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

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

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

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

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

אלמנטים של סקראם…מה זה DONE ?

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

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

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

בואו נתבונן רגע בהגדרת DONE:

  • הקוד גמור
  • בדיקות גמורות
  • הפיצ’ר אושר ע”י מנהל המוצר.

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

  • הקוד גמור
  • נכתבו Unit tests והם רצים בהצלחה.
  • נכתבו Integration tests והם רצים בהצלחה.
  • הבדיקות התווספו לתשתית האוטומציה.
  • הפיצ’ר תועד (לפי הצורך).

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

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

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

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

נ.ב. – התוספת של התמונות לפוסטים מפריעה? מוסיפה? לא משנה? – אנא תגובתכם.

זהו – אני סיימתי – …I am DONE

 

*מקור התמונה : http://www.flickr.com/photos/hawaii-mcgraths/2701705139/lightbox/

אלמנטים של סקראם והפעם…. שקיפות

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

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


דוגמא לגרף ספרינט (אמיתי לחלוטין)

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

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

מצב ראשון: ספרינט 2, התקדמות כצפוי, נראה שנסיים אחרי 7 ספרינטים:
clip_image004

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

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

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

אלמנטים של סקראם והפעם… Sprint.

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

  • קל להיות גמישים ולשנות את תכולת המוצר כאשר מחזור הפיתוח הוא קצר, פשוט בגלל שבסוף כל מחזור המוצר אמור להימצא במצב שהוא פוטנציאלית מוכן למשלוח.
  • כאשר מפתחים בצורה קלאסית, בד”כ ניתן לראות תוצאות ולקבל ביקורת כל מספר חודשים, כאשר מחזור הפיתוח הוא קצר, ניתן לראות תוצאות מהר מאוד וע”י כך להגדיל את תחושת ההישגיות של הצוות.
  • כאשר מפתחים במחזורים קצרים ניתן לראות מהר מאוד כי הפרויקט אינו מתקדם בצורה הרצויה, ניתן לראות את הבעיות מיד ואין צורך לחכות לשלב מתקדם בפרויקט כגון נקודת ציון (Milestone) או שלב הבדיקות (Verification).
  • כאשר מפתחים במחזורים קצרים, באופן אוטומטי הגישה של הצוות משתנה והמוכנות הפסיכולוגית לשינוי עולה.
  • אז מה זה למעשה ספרינט של סקראם ומה הוא כולל ?
    ספרינט הוא מחזור פיתוח באורך של בן שבועיים לארבעה (ככל שהצוות מיומן יותר כך ניתן לקצר את אורך הספרינט), הוא מתחיל בישיבה שנקראת Sprint planning (עוד יהיה פוסט) שבה מחליטים ביחד, הצוות והאחראי על המוצר (Product owner) על איזה פריטים מתוך ה-product backlog הצוות מתחייב לפתח עד סוף הספרינט, בנוסף מגדירים ביחד מה המשמעות של פריט מוכן, ומחליטים על מטרה לספרינט (Sprint goal), אחרי הישיבה הצוות ניגש לעבודה.
    במשך הספרינט הצוות מקבל שלושה דברים: סמכות מלאה, תמיכה ושקט תעשייתי:

  • סמכות מלאה לקבלת החלטיות טכניות שקשורות לביצוע המשימות
  • תמיכה בפיתרון בעיות שהצוות נתקל בהן ואין בכוחו לפותרן – למשל השלמת ידע בתחום מסוים, חוסר בחומרה ספציפית וכדומה.
  • שקט תעשייתי משמעותו שהצוות למעשה “מוגן” מהתערבויות חיצוניות במהלך הספרינט, התערבויות משמעותן שינוי המשימות שהצוות התחייב עליהן, שינוי המשאבים או מצב כ”א של הצוות. עליי לציין שישנם מצבים שבהם הצוות מסכים מראש בתחילת הספרינט לרמה מסוימת של הפרעות.
  • בכל יום במהלך הספרינט מתכנס הצוות לישיבה שאורכה לא עולה על 15 דקות (בד”כ פחות) ובה כל אחד מחברי הצוות מעדכן את הצוות בשלוש שאלות : מה עשיתי מהישיבה הקודמת עד הנכחית? מה אעשה מעכשיו עד השיבה הבאה? האם משהו מפריע לי לביצוע המשימות? על הישיבה היומית (daily standup meeting) עוד נדון בהרחבה בפוסט משלה. בנוסף במהלך כל יום בספרינט מקובל שמעדכנים את גרף “שריפת העבודה” Burndown chart, גרף זה למעשה מייצג את התקדמות הצוות בצורה פשוטה לעדכון, ויזואלית וקלה להבנה.
    בסוף הספרינט הצוות מציג את ההתקדמות ואת העמידה בהתחייבויות בישיבת ה-sprint review, כמו כן הצוות מקיים ישיבת רטרוספקטיבה (sprint retrospective) שבה הצוות בוחן את הספרינט האחרון ואת הנקודות לשימור ולשיפור, שאחריה למעשה מתחיל ספרינט חדש.

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

שאלות ?