-->

יום שבת, 31 באוקטובר 2015

הכנס השני לארכיטקטורת תוכנה (30 לנובמבר - 1 בדצמבר)

בסוף החודש הקרוב, 30 בנובמבר - 1 בדצמבר, יתקיים בהרצליה הכנס השני לארכיטקטורת תוכנה.

הכנס מאורגן ע"י IASA ואילתם.

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

ILTAM, היא קהילה מקצועית, רחבה יותר, המורכבת בעיקר מחברות הייטק גדולות ומבוססות (לא רק חברות תוכנה נטו: אלתא, 3M, וצה"ל למשל - הם חברים) במטרה לקדם ולשתף ידע.


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


היום ראשון מורכב מהרצאות. הנה התכנית:



ביום שני מתקיים Tutorial בהדרכתה של Rebecca Wirfs-Brock (שהגיעה לארץ במיוחד, אני מניח), בנושאי ארכיטקטורה באג'ייל ו Quality Attributes בפרט (הנה פוסט שפירסמתי בנושא, אם אתם רוצים לקבל מושג במה מדובר).


האם כדאי לבוא?


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

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


  • אני נותן הרצאה על מיקרו שירותים (עדיין לא החלטתי בדיוק איך להעביר את הנושא...). אם אתם מגיעים - קפצו לומר שלום!
  • קצת אחרי ייתן הרצאה יונתן ממן, שכתב כאן פוסט אורח בנושא - ממש לאחרונה.
  • הנה אתר הכנס: http://conference70.wix.com/sw-architecture
  • בטופס ההרשמה שבאתר, ניתן לקבל הנחה אם מזינים את המילה "Presenter", בסעיף של קבוצת שיוך (אופס, אני מקווה שבאמת היה מותר לי לספר את זה...).


שיהיה בהצלחה!

ליאור

 


יום שישי, 23 באוקטובר 2015

כל מה שרציתם לדעת על הערכות זמנים בפרוייקטי תוכנה - ולא העזתם לשאול


בשנת 1975, נכתב הספר האלמותי "The Mythical Man-Month" ע"י בחור בשם פרדריך ברוקס (שכדרך אגב היה מנהל טכני בכיר בחברת יבמ, בימים בהם הייתה בחזית הטכנולוגיה). הספר זכה להערכה רבה בקהילת התוכנה, ונחשב עד היום כבעל מקום של כבוד בספריה של אנשי תוכנה "רציניים" [א].

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

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

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

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

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

לקוח של התוכנה - ניצב בפני ממש אותן ברירות.



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





רק עוד דקה...


לפני שאנו ממשיכים ודנים בפתרונות של ימינו, אני רוצה לחזור לכמה תובנות שהציג ברוקס, שעדיין רלוונטיות בימנו. אציין, שחלק גדול מהן נראה ברור, אך אנו נוטים לשכוח את הדברים הברורים הללו מפעם לפעם:
  1. ישנן משימות צפויות, שכבר עשינו אותן כבר כמה פעמים (לרוב: "משימות copy-paste") - אותן ניתן פחות או יותר לחזות בצורה טובה. משימוש שלא נעשו בדיוק כמותן לאחרונה - קשה הרבה יותר להעריך.
  2. יש שוני גדול בין משימה x במערכת קטנה, לביצוע משימה x במערכת גדולה. ביצוע משימה במערכת גדולה יותר - היא תובענית משמעותית יותר. (חשבו על פאזל, למשל: מה יותר קל? להוסיף עשרה חלקים לפאזל חצי-מורכב של 50 חלקים או לפאזל חצי-מורכב של 500 חלקים?)
  3. יש שוני גדול בין מורכבויות של סוג התוכנה. למשל: מערכות הפעלה נכתבת הרבה יותר לאט מקומייפלר, שכתב הרבה יותר לאט ממערכת עסקית / מערכת ווב.
  4. לרוב: המתכנים לא יצליחו להקדיש יותר מ 50% משעות העבודה לכתיבת קוד / טיפול בבאגים. מפתיע?!
    1. זמן בדיקות - הוא החלק שנוטים להעריך בצורה חסרה ביותר הוא בדיקת התוכנה ותיקון שגיאות. "יהיה בסדר!".
  5. הערכות הזמנים שלנו - משתפרות ככל שאנו מתקרבים למועד תחילת המשימה הספציפית.
    בגרסה מעט אחרת: הערכות זמנים בתוך הפרויקט משתפרות ככל שהוא מתקרב לסופו.
    לסיכום: ככל שאנו מעריכים זמנים מאוחר יותר - אנו עושים זאת טוב יותר. (הערכות בדיעבד - הן הכי טובות!)
  6. את זה אני כותב מהזיכרון (לא מצאתי בספר. אולי זה מספר אחר?!): בשקלול של דיוק וצמצם - המתכנת הוא זה שעדיף שיעשה את ההערכה.
    למשל: אם מנהל מעריך "12 יום" - המפתח יקפיד בד"כ לעמוד בהערכה. אם נשאל את המתכנת עצמו, הוא יאמר "8 ימים" - וישיג את התוצאה הרצויה בתשעה - וזה מה שעדיף לפרוייקט.
    כל זה עוד לפני העובדה שמנהל יש אחד - והוא מהווה צוואר בקבוק, ומתכנתים יש יותר.
  7. אווירת לחץ, באופן דיי עקבי - פוגעת בפריון.


עוד תובנות מקובלות (אין לי רפרנס ברור) של ימנו:
  1. קביעת מסגרת זמן היא חשובה מאוד בכדי להתמקד במטרה ולא להתבזר [ג].
    כלומר: אם נותנים למפתחים "את כל הזמן שנדרש" בכדי להשיג תוצאה - הם יהיו משמעותית פחות יעילים מאשר כאשר יש להם מסגרת זמן, ידועה שעוד אנשים בוחנים אותה (רפרנס קרוב: חוק פרקינגסון). אפילו אם מסגרת הזמן הזו הוגדרה ע"י המתכנתים עצמם.
  2. חוק ה"90-90" (הומריסטי) : תשעים אחוז מהקוד - ייכתב בתשעים אחוז מהזמן. יתר עשרת האחוזים מהקוד - ייכתבו ב 90 אחוז נוספים מהזמן. בקיצור: הערכת זמנים נועדה להערכת-חסר.



פרויקטי תוכנה בתקופתנו


האם פרויקטים כיום מצליחים יותר מהזמן בו כתב ברוקס את ספרו?

מקור: http://www.ambysoft.com/surveys/

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

למה ניתן לייחס את השיפור?
ע"פ גרסה אחת - ניתן לייחס אותה למהפיכת האג'ייל (נושא שכתבתי עליו הרבה בבלוג). למשל:


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

גורם אחר שיש מייחסים אליו את השיפור, הוא התמסדות מקצוע "מנהלי הפרויקטים", כדוגמת תואר ה PMP של ארגון PMI. זה הארגון שיצר את "Project Management Body of Knowledge", והסמיך יותר מחצי מליון מנהלי פרויקטים ברחבי העולם.



תובנות של "עולם ה Enterprise"


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

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


הנה למשל תובנה נפוצה ראשונה: מודל שנקרא Cone Of Uncertainty.

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

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




מה המודל בעצם נותן לנו?
  • חוסר הודאות המשמעותי בהערכות זמנים של פרויקט - מונחות על השולחן, בצורה שקל יחסית לתקשר (יש לזה ערך).
  • יש מן "אומדן אצבע" לטווחי הטעות הממוצעים. מספר מדויק שניתן לעבוד איתו. המספר מדויק (precise), אבל לא תמיד נכון (accurate) - כמובן.


זווית אישית

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

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

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

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

ספר מפורסם אחר הוא "Agile Estimation and Planning" שלא קראתי. את הידע שלי על Agile Estimation שאבתי ממקורות רבים שונים.





חזרה להערכות זמנים "קלאסיות":

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

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

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


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


משפחת כלים: Expert Estimation

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

Bottom-Up - מומחים (מתכנתים/ראשי צוותים) מעריכים את כל המשימות בפרויקט, ואז מחברים את ההערכות הללו (עם באפרים ופאקטורים) לתמונה אחת. החיבור של ההערכות נעשה באקסל או ב"תוכנה לניהול פרויקטים" - קשה לעשות אותו בלי איזה כלי. וריאציות של טכניקה משתמשות במונח בשם WBS (קיצור של Work Breakdown Structure) - כאשר החלוקה היא למשימות, או RBS (קיצור של Resource Breakdown Structure) - כאשר הבסיס לחישוב הוא המשאבים (תחומי-מומחיות) להם זקוקים. כלומר: החישוב הוא לא כמה זמן המשימה תיקח, אלא לכמה אנשים נזדקק (פה 2 אנשי QA ושם עוד אחד - אז סה"כ שלושה).

Group Estimation - יש פה כמה טכניקות, המנסות לצמצם את הטעות של ההערכה הסובייקטיבית של מומחה יחיד. 

טכניקה מקובלת אחת היא ה Planning Poker בה כל מתכנת נותן הערכה ומניח קלף עם הערכות הזמנים שלו (21 = 21 שעות, למשל) הפוך על השולחן. כולם הופכים ביחד את הקלפים וכשיש פערים משמעותיים - מתפתח דיון בו מסכימים על הערכה משותפת.

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


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



משפחת כלים - Analogy-Based-Estimation

בה הבסיס הוא להשתמש במידע קיים מהעבר - בכדי לבסס את ההערכות הזמנים לעתיד.

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

Function Points - סופרים את מספר ה APIs שיש לממש, מספר המסכים ב UI, מספר הכפתורים במסך - או כל דבר אחר שמאמינים שיכול לייצג, בידיעה שיחידה כזו "לוקחת בערך זמן x לפתח". למשל: אם מסך ב UI הוא שבוע - אז עשרים מסכים הם חמישה חודשים (ואולי אז מעגלים לשישה חודשים - ליתר בטחון).

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


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

למרבה ההפתעה הן מפורמלות ע"י מסמכים אקדמים וע"י כל מיני סטנדרטים בתעשייה (COSMIC הוא כמובן ISO/IEC 19761:2011, או IFPUG שהוא ISO/IEC 20926:2009, וכו') - מה שעלול להעלות את השאלה כיצד גופים רציניים שכאלו לא פסלו אותם מכל-וכל. התשובה: א. כנראה שלעתים זה הכי-טוב שיש. ב. כנראה שנוח לגופים הללו להמשיך להתעסק בזה.



משפחת כלים: גם וגם...

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

אחסוך מכם את ההתנסות הזו - ואומר שיש כל מיני טכניקות שמנסות לעשות על מיני ממוצעים בין 2 סוגי הערכות ולהיות גם "יחסית מדויקות" וגם "לא יקרות".
דמיינו אותן לרגע בעצמכם... - וזהו כנראה ה State Of The Art של עשרות שנות מחקר באקדמיה (סליחה על הביקורת הלא-מרומזת..., אולי קצת הגזמתי).




ההערכות בעולם ה Agile


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


עקרון: לא מנסים להעריך את כל הפרויקט מראש

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

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

הערה: יש גישה שכן מנסה לבצע הערכה גסה של הפרויקט בכללותו: מנסים להגדיר את כל ה backlog items "בערך באותו הגודל" וכך אם רוצים שכל ספרינט מתקדמים ב (נאמר) 5 פריטים, ובכל הרשימה יש עוד 30 פריטים - ניתן לומר בצורה גסה שעוד שישה ספרינטים יסתיים הפרויקט (סוג של Function Points estimation).

הערכות מסוג זה הן מאוד לא מדויקות (במיוחד כאשר באמת מה שחשוב הוא הערך למשתמש - וצפויים שינויים גדולים ב backlog תוך כדי התקדמות) - וחוזרות לטווח הטעות של The Cone of Uncertainty.



עיקרון: מנהלים רשימת פיצ'רים - מבלי להציב אותן על לוח-שנה

כותבים רשימה ארוכה של כל היכולות שאנו רוצים במוצר (product backlog) - וממיינים אותם ע"פ סדר חשיבות / סדר בניה נכון של הפרויקט.
בתחילת כל ספרינט (שבועיים עד ארבעה, בד"כ), שולפים משימות מה product backlog ומעריכים אותן. הן נכנסות לרשימה שנקראת ה Sprint Backlog. ממשיכים בתהליך הערכות הזמנים עד שיש לנו מספיק משימות מוערכות (נניח: 5 שבועות עבודה, אם אנו עובדים בספרינטים של 4 שבועות).

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

מוטיבציה:
  • אנשים הם יעלים יותר כשיש להם מסגרת זמן (=ספרינט).
  • אנשים הם יעלים יותר כשיש להם מסגרת זמן ללא הפרעות (=ספרינט, כאשר לא משנים את ה sprint backlog במהלך הספרינט).
    • יש איזה איזון בין ה product backlog שהוא "דינאמי ומשתנה" (= למידה), לבין הספרינט שהוא קבוע (= יציבות).
  • לאפשר לבצע הערכות מאוחר ככל האפשר - על מנת שיהיו מדויקות ככל האפשר.
  • הבנה שגם הערכה כמה שבועות קדימה היא לא מדויקת (על כן - מעריכים מעט יותר משימות ממה שנדרש).
וריאציה: Planning Poker היא טכניקה שהכרתי קודם מעולם האג'ייל - ורק אח"כ למדתי שהיא טכניקה "קלאסית".


Planning Poker בפעולה!
בפרויקט אחד אפילו רכשנו את "הקלפים המקוריים של CRISP". אם רוצים להעריך 31 שעות - מניחים על השולחן 3 קלפים (20+10+1).
בחפיסת הקלפים שלנו - היו מספרים לא עגולים (7, 21, 44 אך ללא 10 או 5) - בכדי להזכיר לנו שהערכות הן לעולם לא מדויקות.
מקור התמונה - וויקיפדיה.


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

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

הרציונל: לבני-אדם הרבה יותר קל להעריך רצף אירועים פשוט ("יום מושלם") על פני המציאות המורכבת ("יום מלא הפרעות").

במהלך כל ספרינט לומדים מה הפער בין "היום המושלם" ל"יום המעשי". הפער נובע מזמן שהמפתחים מקצים לדברים אחרים, כמו הטיות שלהם בהערכה. זה לא משנה. לאורך כמה ספרינטים ניתן ללמוד שצוות x מספיק בין 50% ל 60% מהמשימות שהעריך - ועל כן קובעים לו Velocity של 55%. כלומר: אם בספרינט יש 20 ימי עבודה - נעריך שבפועל יש לנו ספרינט של "11 ימים מושלמים". נבצע כיול של המציאות של הצוות הזה. ה Velocity הוא לרוב אינדוודואלי לשילוב צוות+פרויקט, ויש ללמוד אותו כל פעם מחדש.

וריאציה מעט אחרת: במקום "ימים מושלמים" יש "ימים ריאליסטיים" בו המתכנתים צריכים להניח שיום עבודה הוא (למשל) - 6 שעות עבודה.
קרי - לא לקבל את ההנחה של ימים מושלמים שההערכות הן טובות יותר כך, ולחסוך התעסקות בהמרות.

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

מוטיבציה:
  • מציאות - בואו לא "נשלה את עצמנו". 
  • הבנה שהערכה היא מלאכה לא מדויקת ולא-פשוטה, ועל כן נקל את המתכנים שלנו (= חשיבה ב"ימים מושלמים", נקראים לעתים גם "Story Points", הגבלת גודל התכולות אותן מעריכים).
בכל שלב הפרויקט אמור להיות "Shippable" (כל שאם נגמר הזמן - זה מה שמשחררים), ופיצר'ים אמורים להיות "Valuable" (מאותה הסיבה + היכולת לבדוק אותם עם לקוחות ולקבל כבר פידבקים על נכונות המוצר ואיכות הקוד).



מילת סיכום אישית


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

למשל:
  • פעמים רבות: התחייבנו על תכולה ולוחות זמנים חודשים קדימה (ולכן הוספנו "באפרים"). לא מיסדנו "חוזה אג'ילי" עם ההנהלה או הלקוח.
  • התעלמנו מהרעשים שיש למפתחים ביום העבודה - ובמשך שנה+ המופע בו צוותים לא סיימו 70% מתכולת הספרינט חזרה על עצמה כל ספרינט, וללא תיקון - כאמת עצובה שאין לה פתרון.
  • שימוש בבאפרים ואומדני "Function Points" שונים ברמת ההנהלה הזוטרה (במקום לבצע הערכות ע"י מפתחים).
  • מנהל פרויקטים שמרכיב תוכנית שבועיים קדימה: מה עושה בדיוק כל אדם בכל יום (ואז זו תוכנית שלמתכנת יש קשיים לזוז ממנה).
  • וכו'....


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


שיהיה בהצלחה!




------

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


------

[א] לא אנסה להגדיר זאת יותר מכך.

[ב] מה ההבדל בין אומלט לחביתה? - "20 שקל" - ע"פ בדיחה נפוצה.

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

אם יש לכם מנוי ל"הארץ" שווה לקרוא: http://goo.gl/82IwZb - צוות מדענים בינלאומי שבחן 100 מחקרים בפסיכולוגיה לא הצליח לשחזר את תוצאות 64% מהם: "הקורא הממוצע צריך ללמוד שאין להתייחס לשום מחקר בודד כאל המלה האחרונה"

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



יום שבת, 17 באוקטובר 2015

כל מה שרצית לדעת על ארכיטקטורת מיקרו-אפליקציות (Micro-Apps Architecture) - ולא העזת לשאול

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

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

Fox News, ה Rolling Stone, "הארץ", "בלוג ארכיטקטורת תוכנה" (בדיחה, בדיחה), ועוד. אאוטבריין מייצרת כ-+150 מיליארד המלצות תוכן בחודש - כמות Traffic יוצאת דופן! בזירת ההייטק הישראלית היא נחשבת מובילת-דרך בכל הנוגע ל Scale, Operations, וכו'. החברה גם פעילה למדי בקידום אירועים ושיתוף ידע בתעשייה (IL TechTalks, רברסים וכו').



---

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


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


ה tutorials שתמצאו, כנראה ידברו על שירותי רשת (web services) - ללא UI ובעיקר ללא ניהול session. אבל מה עם אפליקציות רשת (web applications), שם ה UI, וניהול ה session של המשתמש הם החלקים המרכזים ? האם גם אותם ניתן לפצל ל ״מיקרו-אפליקציות״ ? נניח שלקחת אפליקציה אחת ובדרך קסם פיצלת אותה לשניים, איך תתמודד עם:
  • שמירה על חווית כניסה (login) אחת? 
  • מעבר חלק, ושיתוף session בין האפליקציות? 
  • מניעת שכפול קוד ?



בוא ניקח לדוגמה אפליקציית רשת נפוצה: אתר של חברת סטארטאפ.

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

האתר לרוב יהיה מהמערכות הוותיקות בחברה - ולכן גם עם חוב טכנולוגי גבוה / Technology Stack ישן.
לכאורה מועמד מצוין לשדרוג ולמעבר לארכיטקטורת מיקרו services, אבל אליה וקוץ בה: דווקא אפליקציית רשת קשה מאוד לפצל ויש מעט מאוד מידע ברשת כיצד לעשות זאת.

פוסט זה יתאר ארכיטקטורת מיקרו-אפליקציות (Micro-Apps Architecture) שמטרתה (בדומה ל Micro-Services Architecture) לסייע בפיצול אפליקציית רשת למיקרו אפליקציות ובכך ליהנות מהיתרונות המדוברים.



אז איך עושים את זה ?

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




כל אזור (אדום, צהוב או כתום) הוא מועמד להיות מיקרו אפליקציה עצמאית.

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


המיקרו אפליקציה בנויה מטכנולוגיה המתאימה לה ולצוות שלה ומותקנת על שרת ייעודי. האפליקציה יכולה להגיש גם את צד הלקוח (client side) וגם את צד השרת (server side). האפליקציה מותקנת בתוך ה firewall ולא מקבלת תעבורת רשת באופן ישיר.


micro-colored.png


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


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

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



מה עושה הפרוקסי?
  • הפרוקסי הוא יחידה לוגית בתוך ה service המארח. תפקידו להוות צינור ולהעביר בקשות מהלקוח למיקרו אפליקציה עליה הוא אחראי. התקשורת בין הפרוקסי למיקרו אפליקציה באמצעות פרוטוקול HTTP. לכל מיקרו אפליקציה קיים פרוקסי משרת אותה. 
  • כל פרוקסי נרשם על מסלול אחר של ה URL. לדוגמה כל בקשה למשאב תחת הכתובת www.yoursite.com/app1 תופנה לפרוקסי האדום. 
  • כשהבקשה מגיעה לפרוקסי כבר ידוע מיהו המשתמש, ולכן הוא יכול להעביר את שם המשתמש (או כל מידע אחר עליו) למיקרו אפליקציה באמצעות HTTP Header. 
  • הפרוקסי מנהל את כמות החיבורים הפתוחים לאפליקציה שלו, ומדווח על כמות החיבורים הפתוחים למערכת הניטור. 
  • הפרוקסי מקבל בחזרה את התשובה מהמיקרו אפליקציה ומעביר אותה חזרה למשתמש.



יתרונות - או מה יצא לנו מכל זה?
  • הפרדה ברורה בין אפליקציות: זליגת זכרון במיקרו אפליקציה אחת לא תביא לנפילה של מיקרו אפליקציה אחרת. 
  • ה service המארח הופך מהר מאוד לתשתית שבה אין הרבה פיצ'רים חדשים. הוא הופך לפשוט וקל יותר לתחזוקה. 
  • כל מיקרו service נכתב בטכנולוגיה שמתאימה לדרישותיו ולצוות שמפתח אותו. 
  • ניתן לעשות את המעבר מאפליקציית רשת מונוליטית למיקרו אפליקציות בשלבי, ובכך להקטין את הסיכון. לדוגמה: 
    • לייצר מיקרו אפליקציה שתגיש רק את קוד הלקוח שנכתב בטכנולוגיה חדשה, נניח ב AngualrJS, ולהשאיר את קוד השרת ב service המארח. 
    • לייצר מיקרו אפליקציה חדש שיגיש קוד שרת בלבד. ניתן להחליט שלא מעבירים קוד ישן אלא רק קוד חדש של פיצ'רים חדשים. וכך לבצע החלפה אטית אך שיטתית ומדורגת מתשתית שרת ישנה לתשתית שרת מודרנית יותר. 
  • ניטור -- כל פרוקסי מדווח על כמות הכישלונות, הצלחות, מספר החיבורים התפוסים וכו'. 
  • רישום בקבצים - ה service המארח אחראי על כתיבת קבצי הגישה access log עבור כל המיקרו אפליקציות. 
  • אבטחה -- ה service המארח מבצע את כל מנגנוני האימות של כניסת משתמשים ו CAPTCHA. 
  • אפליקציות חדשות -- נניח שאתה רוצה לפתח אפליקציית-רשת חדשה. תוכל לממש אותה כמיקרו אפליקציה בתוך ה service המארח. כך תחסוך בפיתוח מנגנוני אבטחה, רישום וכניסה, כתיבת קבצי גישה וכו', כל מה שתדרש זה להוסיף עוד חוק ניתוב service המארח. בנוסף לא תצטרך את עזרת אנשי ה OPS. גישה זו היא מיושרת עם רעיון ה DEVOPS.



כמובן שאין ארוחות חינם. אז מה אנחנו מפסידים?
  • עוד תחנה במסלול -- טיפול בבקשה של משתמש לוקחת זמן ארוך יותר. 
  • שיתוף קוד לקוח -- כבר לא תוכל לשנות בקלות את ה JS/CSS שמשותפים עבור כל המיקרו אפליקציות. בכדי לשתף קוד לקוח (למשל ניווט בתוך האפליקציה), תצטרך להתייחס אל הקוד כאל ספרית צד שלישי. תוכל להשתמש ב bower בכדי לנהל את הגרסאות ולהעלות את הקוד ל repository. דרך נוספת תהיה להעלות קבצים משותפים ל CDN. 
  • הגדל הקושי בתחזוקה ובמציאת תקלות - כל תוספת של חלק נע במערכת מקשה על מציאת באגים. עוד קבצי לוג שצריך לבדוק כמשנסים לאתר תקלה. נניח שמשתמש מנסה לגשת למיקרו אפליקציה ומקבל HTTP CODE 403. יהיה עליכם לבדוק האם ה service המארח חסם את הגישה, או אולי האבטחה של המיקרו אפליקציה חסמה את הבקשה. 
  • הפרוקסים הם פשוטים ולא משוכללים כמו HAProxy






הניסיון שלנו באאוטברין:
  • פתחנו את הארכיטקטורה הזו בתחילת 2015, כאשר הבנו שאנחנו הולכים לחשוף הרבה יכולות של המוצר שלנו למשתמשי הקצה באמצעות שירות עצמי דרך אפליקציית רשת. אפליקציית הרשת שלנו הייתה מבוססת על תשתיות ישנות והבנו שמבחינה טכנולוגית אנחנו צריכים לבצע שדרג משמעותי. 
  • המטרה הייתה לפתח יישומים חדשים בטכנולוגיות מודרניות באופן בלתי תלוי ע"י צוותים שונים עם סט בדיקות שונה תוך כדי שיתוף session בין האפליקציות, כל זאת בלי לכתוב מחדש את כל התשתית של אפליקציית הרשת הקיימת. 
  • התחלנו עם מיקרו אפליקציה אחת, ועכשיו יש לנו 4 מיקרו אפליקציות שמגישות גם צד שרת וגם צד לקוח. הנה דוגמה ל Stack הטכנולוגי של 3 מארבעת מיקרו אפליקציות בתשתית של אאוטברין:


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