-
להלן פרוטוקול ישיבת הוועדה המסדרת שנערכה ביום שני ה-23 באפריל.
- נוכחים: יו"ר רן תבורי, סיו"ר אורי להב, וכן ראשי הסניפים ערן הראל, יונתן, ארז מזור, איתי ממן, ישי סמית'. גם גילי בא.
- על הפרק היום: דד-ליין בעולם התוכנה.
- הערכות זמנים, בדומה לתכניות עסקיות של סטארטאפים, הן תת-ז'אנר בסוגת המדע הבדיוני, מאוד תלוי כמה המתכנת רוצה לבצע את המשימה וכמה היא מעניינת. בכל מקרה - לא טריוויאלי.
- ישנן כל מיני שיטות להעריך זמני ביצוע: לתת שלושה זמנים (נמוך, צפוי, ארוך), לתת הערכה של הזמן ואז להוסיף פקטור כלשהו (30 אחוז, כפול שתיים וכו'). צעירים משלמים כפול - פה זה לא סלקום.
- גם ב-Quora שאלו. בקצרה, המרחק בין סן-פרנסיסקו ללוס אנג'לס הוא לא בדיוק מה שנראה בהסתכלות ראשונית.
- האם חוסר היכולת להעריך זמנים נובע מחוסר בגרות של המקצוע ? חוסר מקצועיות של המתכנתים ?
- כל פרויקט תוכנה הוא ייחודי, גם אם יש לו מאפיינים דומים לפרוייקטים אחרים.
- לעומת תחומי הנדסה אחרים, העלות של טעות בתוכנה היא לא קטסטרופאלית ולכן אפשר להרשות לעצמנו לטעות.
- מה עושים עם דד-ליין שבאמת - אבל באמת - קשה להזיז ? נגיד, יום שבו יהיה ליקוי ירח?
- משולש הזהב הוא משאב-תוכן-איכות, כנראה שהתוכן ייפגע אם הדד-ליין מתקרב.
- ההגדרה של מה נכנס ומה לא למוצר עד הדד-ליין הוא פונקציה של מה מטרת הדד-ליין (לבדוק היתכנות, A/B testing, להשוויץ בעומסים הגבוהים שאפשר לעמוד בהם וכו').
- כדי לעמוד בדדליין, לפעמים חותכים פינות (קוד ספגטי, פחות עמיד וכו'). החוכמה היא לתקן את מה שמקולקל (או שדורש שיפור) בהמשך.
- ומה עושים עם מתכנתים שלא נותנים הערכות זמנים ? מחלקים לחתיכות קטנות יותר ומעריכים אותן (לדוגמה).
- בני אדם נוטים לצרוך את כל הזמן שהוקצה לביצוע משימה. מישהו כבר אמר את זה קודם.
- הערכות זמנים לא מתאימות לכל אחד, יש כאלה שזה יעשה להם רע - ולהיפך.
- אורי מדבר על יק. ועל סכיני גילוח. ועל גילוחים. מחלקה סגורה כבר אמרנו ?
- הערכות זמנים יכולות לשמש להערכה של הכדאיות העסקית של העבודה.
- דדליין יכול להכניס אנשים ללחץ. כן, זה קורה.
- "Your lack of planning is not my emergency". לחן - עממי. וגם: אם הכול הוא חירום, אז בעצם שום דבר הוא לא חירום.
- אוהבים תכנות ? מתכננים קריירה בתחום ? נהדר. יש לכם 40 שנה לעשות את זה, תעשו את זה בכיף, קחו את הזמן. קנת בק אמר (גם) את זה.
- למנהלים יש חומר קריאה מיוחד. אחת המסקנות - תן למתכנת לקבוע את הדדליין.
- מה שיכול להניע אנשים לקצר את לוחות הזמנים הוא הידיעה שמעט אחרי שהקוד ייכנס מישהו (ובשאיפה - הרבה אנשים) ישתמש בקוד.
- אנשים שונים מייצרים פיתרון שונה לאותה בעיה ולכן הערכת הזמן תלויה מאוד באדם שיממש בסופו של דבר.
- דדליין זה כמו חסה: בריא לאללה - אבל לאכול את זה כל יום בצהריים ?!
קצרצרים:
- בקאנדס למיניהם:
- למובייל: parse, usergrid, cocoafish, cloudmine, kinvey, stackmob, mobdb
- לריל טיים ווב: meteor, derby, firebase
הקובץ נמצא כאן
האזנה נעימה
ותודה למשורר יותם אורון :)
יש לכם באג בi++
השבמחקi = 134
i++
print i
>>>137?
היי,
השבמחקכמאזין קבוע הייתי מופתע מאוד לשמוע שאתם אומרים שאין דרך להעריך זמנים.
זו אחת המשימות היותר קשות שיש למפתחים וצריך למצוא דרך לבצע אותה.
להגיד שתכנות זו אומנות ובנית בתים זו הנדסה קרה שאין בה שום בעיה והכל אפשר לחשב מראש זו פשוט הפשטה מוגזמת. לא בניתי בית במו ידי אבל משיחה קצרה עם אדם שכן עושה זאת למחיתו הוא הסביר שבניה של שכונה של בתים שעל הנייר הם זהיים לחלוטין היא משימה קשה ומורכבת וכל בית יש לו את השיפוע של הקרקע, סלע שפתאום נמצא בקרקע שלא תככנו עליו ועוד הפתעות אחרות.
אני חושב שהנושא מאוד חשוב ואפשר להרחיב עליו את הדיון בכיון של דרכים להתמודד עם החלקים הלא ידועים, ההפתעות וגם עם החלקים שכן אפשר לתכנן מראש ובעיות שאפשר פשוט לא להכנס אליהן.
תודה על השיחה המעניינת,
עידו
עדו, תודה על ההערה, אבל אני חושב שהפעם אנחנו פשוט לא מסכימים...
השבמחקאולי לומר שתכנות זו אמנות ובאומנות כמו באומנות זה קצת מוגזם, אבל אני חושב שבכל הנוגע להערכת זמנים בהנדסת תכנה, זה בערך כמו להעריך מתי תהיה לך מוזה לצייר - רב הנסתר על הגלוי ולדעתי אסור לנו להשלות כאילו בכלים שעומדים לרשותנו היום, ביכולתנו להעריך זמנים באופן מדוייק או אפילו קרוב לכך.
שגיאה בפקטור של 1.5, 2 או 3 היא כל כך נפוצה כך שלדעתי אין כל תועלת במתן הערכה מלכתחילה.
יש מספר כלי שעוזרים במתן הערכה מדוייקת יותר (TDD, agile, CI וכו') ועלינו להשתמש בהם אבל גם בהמצאותם, עדיין פקטור הטעות, לפחות מנסיוני, הוא גדול מידי מכדי שזה יחשב לתהליך מדעי או הנדסי.