להלן פרוטוקול ישיבת הוועדה המסדרת שנערכה ביום שני ה-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
הקובץ נמצא כאן
האזנה נעימה
ותודה למשורר יותם אורון :)