כבר אמרנו extreme נכון? אנשים פה קיצוניים... ;-)

ההודעה הזו לא קשורה, אבל לא יכולה להתאפק. זה מה שעלה לי לראש כשראיתי את כותרת הדף:

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

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


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

ברוב חנויות הספרים, וגם [url=http://www.ibooks.co.il/[po]NS]ברשת[/url] GetProdInfo[/po].asp?prodid=11910312

[u]אני מניח שהספר החדש שיצא בתחום, ניהול ממוקד, דן בתחום[/u]
איפה אפשר לראות / להשיג את הספר?

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

[hr]

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

[hr]

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

לעודד,

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

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

לגבי המתדלקים - אהבתי את הרעיון של "לרוץ ולמלא לחבר'ה".... ;-) באמת לא ראיתי הרבה תחנות כאלו.

לגבי סופרמרקטים - ישנו רעיון שכבר הרבה זמן חשבתי עליו ולדעתי יש לי בשורה, אבל לא פשוטה כל כך למימוש. ממעקב אחר התנהלות הדברים בתור לקופה (ומה אתם עושים עד שמגיע התור שלכם? ...) שמתי לב לתופעות מעניינות: קופת אקספרס שהתור בה הכי ארוך, אנשים עם מעט מוצרים שמעדיפים ללכת לקופה רגילה, אנשים עם עגלה עמוסה שמתקתקים עניין ומסיימים חשבון תוך 2 דקות, ואנשים עם בקושי חצי עגלה שרושמים שיקים ומבזבזים עוד מספר דקות יקרות על אישורים וכו'.
גם כאן אפשר לנתח את הפעילויות של הקופאית למספר פעולות:
[list=1]
[*] העברת המצרכים בבר-קוד.
[*] עריכת חשבון
[*] ניהול הקופה - פריטת כסף לקונה אחר, לקופאית אחרת וכד'.
[*] בדיקת שיקים, הדפסתם וכד'.
[*] (לפעמים) עזרה באריזה.
[/list]

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

וביחס לעולם התכנות, אין לי ספק שניתן ליצור "כושר ייצור עודף להשכרה", כלומר חברות כח אדם שיוכלו לסייע לבתי תוכנה בשעות העומס. אבל ישנם תנאים מקדימים (ברוח XP אם תרצו):
[list=1]
[*] עבודה בסטנדרטים ידועים מראש. והמדובר הוא גם על מסמכי תכנון וגם על כתיבת קוד. מתכנת זמני שכזה יוכל תוך פחות מיום להיכנס לעניינים. (אני יודע שזה חלום.... תנו לי לחלום...)
[*] מנסיוני, אילוצי בתי התוכנה בעיקר בימי העומס שלפני שחרור גרסה, זה לא בקידוד אלא בהעמדת סביבה ובבדיקות. XP טוען שהקמת סביבה (אינטגרציה) צריכה להיעשות במוקדם ככל האפשר. אם לא נעשה הדבר כהלכה (כמו שקורה ברוב המקרים) יוכלו המומחים תוך מספר ימים ספורים עד שבוע להקים סביבת BUILD וסביבת בדיקות. לכתוב סקריפטים וכד' כדי (במונחי גולדרט) "למלא את ה-BUFFER שלפני המשאב הקריטי". למעשה הם תוך מספר ימים יגרמו לכך שהאילוץ יהיה דרישות הלקוח לשינויים ולא היכולת של בית התוכנה לעמוד בהם. התנאי להתקיימות כל זה הוא קודם כל פתיחות מצד הלקוח לתת חופש פעולה כזה ליועצים, וגם תמיכה ברמת ציוד נדרש. לקוח קמצן במקרה זה יישאר תקוע עם האלוצים שלו ויפסיד הרבה יותר בגלל חוסר עמידה בזמנים, בתקציב, ובגלל איכות מוצר ירודה.
[*] "יועצי אינטגרציה אנושית" - יועצים לניהול תקין של קשרי קבלני משנה. מנסיוני, אני רואה כמה חוסר תקשורת טובה עם קבלני משנה שעושים את חלק מתהליך פיתוח הפרויקט, גורמת לנזקים ארוכי טווח ללקוח. אם לדוגמא, החברה שכרה חברת קבלני משנה שמפתחים GUI, אבל אין להם מושג על איך הם משתלבים במוצר בכללותו, ולמרבה הצער הם מפתחים ממשק משתמש שאפילו את הדרישות של הלקוח הם לא יודעים ומבינים לעומקם - אין ספק שבבוא היום הפרויקט יצלע ואולי אף יפול. האיכות של המוצר ירודה, הזמנים יוצאים משליטה. בלאגן מוחלט, מהומה... :-). יועצי האינטגרציה האנושית כמו בסעיף הקודם, יפרצו את האילוץ הזה, ויעזרו לבית התוכנה לגבש נוהלי עבודה תקינים מול קבלני המשנה. למשל: מערכות WEB שיאפשרו הן לבית התוכנה והן לקבלן לראות בזמן אמת את מערכת ניהול הגרסאות של הצד השני, וכמובן לבצע BUILD יזום על המערכת של הצד השני וכל לקבל גרסה עדכנית (כמובן שבמהלך ה-BUILD כבר נבדקו כל הבדיקות האוטומטיות והכל הצליח כי אנו עובדים XP :-)). התנאי לכך: שוב, פתיחות מצד המנהלים, ונכונות לבצע שינויים. גם היכולת להודות בטעויות יכולה לעזור כאן.
[/list]

טוב כתבתי הרבה. יאללה תגובות :-)

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

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

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

[u]מתכנתים זה בדרך כלל לא כח אדם זול[/u]
ואכן לכח האדם הזה התכוונתי. משם בעצם גם התחיל הדף. עוד לא שמעתי על בית תכנה שמחזיק מתכנת באויר
(לפחות לא בשלש שנים האחרונות..)

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

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

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

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

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

לגבי המתדלקים:

אין צורך במתדלקים בכמות הקרובה למספר עמדות התדלוק, כי הפעלה של עמדת תדלוק אינה דורשת זמן עבודה של מתדלק; עמדת תדלוק תפוסה גם בשלושה מקרים (לפחות) שאין צורך במתדלק צמוד:
[list]
[*] כאשר הדלק זורם.
[*] כאשר המכונית עומדת, אחרי סיום המילוי, והנהג מתארגן.
[*] כאשר עמדת התידלוק חסומה, בגלל מכוניות אחרות שמתדלקות, ואין גישה אליה.
[/list]

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

ואם ניקח את דוגמת סונול,

לא זכורה לי תחנת דלק בה יש [b]מתדלקים[/b] בכמות שווה או גדולה מכמות עמדות התידלוק.

עודד,

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

אדרבא,
היום ברוב המפעלים, האילוץ הוא אילוץ שוק, לא אילוץ של כושר ייצור.
[b] לסונול אין שום בעיה למלא בעשרים אחוזים יותר מכונית, חוץ מאשר בימי שישי בבוקר. האילוץ הוא מטיפוס [/b]אילוץ שוק*, כלומר: אין מספיק לקוחות. יש לה כושר עודף לאספקת דלק.
[list]
[*] למיקרוסופט אין שום בעיה להדפיס פי עשרה מכל תוכנה. הבעיה שלהם היא הביקוש. גם לאינטל אין בעיה להפיק בחמישים אחוזים יותר מעבדים - אם יימצא מי שיקנה אותם במחיר טוב.
[*] לכל המסעדות בארץ, ברוב שעות היום (פרט לארוחת הצהרים ולערב עד שלושה בסוף השבוע) יש כושר עודף לייצר ולהגיש אוכל.
[*] מי עדן יכולה בקלות להגדיל את התפוקה, אם את מבטיחה לה שתקני ממנה את המים.
[*] לאף זמר בארץ, אפילו לריטה, אין קושי להופיע בתדירות גבוהה פי שנים במקומות גדולים. הבעיה היא שקשה למלא אולמות שוב ושוב ושוב.
[*] רוב מפעלי המתכת והפלסיטקה ערוכים לספק את הביקוש, גם אם יגדל בעשרים אחוזים. האילוץ שלהם הוא נפח ההזמנות.
[*] למעריב אין שום בעיה להגדיל את המהדורות בעשרים אחוזים. להוצאת הוד עמי אין בעיה להדפיס פי עשרה מכל ספר. הסיבה שהם לא עושים את זה היא שאין מספיק לקוחות, לא שאין מספיק נייר או יכולת דפוס.
[/list]

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

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

D-:

[u]דאג שיהיה לך מספיק כושר יצור עודף[/u]

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

[u]אגב, [po]מתכנת 1[/po]?, לפי הבעיות שאתה מעלה, אפשר להעריך את הגיל של ילדייך (או להבדיל: שלך...)[/u]

כרמית, תמיד אמרו לי שאני מקדים את זמני ;-)

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

אגב, [po]מתכנת 1[/po], לפי הבעיות שאתה מעלה, אפשר להעריך את הגיל של ילדייך (או להבדיל: שלך...) (-;

[u]כתיבת קוד בזוגות תמיד מזכירה לי את העונש שנתנו אצלנו בטירונות לאנשים ש"הלכו מכות"[/u]
סיוט.


[u]> גילה מעדיפה תמיד לעבוד בזוג/קבוצה <[/u]
טוב, זה לא חדש שאת מוזרה P-:

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

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

אני חושב שעודד עלה במדוייק על הסיבה ש-XP הוא יישום של תורת האילוצים: [u]האילוץ אינו השרשרת הקריטית אלא האי-וודאות והבאגים[/u]. זה אומר שלא צווארי הבקבוק מעניינים אותנו בניתוח הפרוייקט, אלא הסיכונים, ומיזעור הבאגים. (לכן, אגב, עושים pair programming (ולמי שאין אפשרות אז הרבה code reviews).)

[u]כתיבת קוד בזוגות תמיד מזכירה לי את העונש שנתנו אצלנו בטירונות לאנשים ש"הלכו מכות"[/u]
> גילה מעדיפה תמיד לעבוד בזוג/קבוצה <
> אבל אולי זה משום שהיא מנגה <

לרועי ועודד השלום והברכה.

אשתי אומרת שאני טוב בסלט ירקות. מסכימים שאקח את כל מה שהעלתם ואעשה מזה סלט ירקות משו משו? :-)

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

כפי שרועי כתב: [u]וזו בהחלט שיטה טובה. אבל לא בגלל שהיא יעילה במיוחד (למעשה יש שיטות יעילות ממנה), וגם לא בגלל שהיא משפרת את ההתמקדות, אלא בגלל שהיא משאירה דרגות חופש במקומות שבאמת צריך אותם[/u]

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

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

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

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


טוב, אולי עשיתי פה באמת קצת בלאגן, אבל זו בעיה שאפשר בקלות לפתור, ממש ב [po]צ'יק צ'ק[/po] :-)

[u]יש לכולנו (מפתחי תוכנות) בעיה: אנו מתוסכלים!!![/u]

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

בסה"כ אני די עובד על פי עקרונות ה XP למעט נושא הכתיבה בזוגות.
צטערת.
כתיבת קוד בזוגות תמיד מזכירה לי את העונש שנתנו אצלנו בטירונות לאנשים ש"הלכו מכות" - לרכוס מעיל דובון גדול אחד לשניהם (שרוול לכל אחד, ריצ'רץ' סגור) ולבלות קשורים אחד לשני במשך 12-24 שעות. נסו לדמיין בחור בגובה 1.90מ מחובר לבחור בגובה 1.60, רכוסים בתוך דובון ירוק, רצועות הקסדה שעל ראשם שלובות אחת בשנייה, ושניהם צריכים לרוץ למגדל המים וחזרה תוך 30 שניות. כך צומחות אהבות גדולות..


יש מושג שנקרא in-process testing הנהוג במקומות שונים, ואחראי לבצע בדיקות פונקציונליות נקודתיות במהלך הפיתוח.
אחת הטענות כנגד השיטה היא שהיא דוחפת את המפתח לייצר קוד פחות איכותי ולהסיר מעליו אחריות בידיעה שיש מי שבודק בשבילו.
( [po]בטיחות בלי גבולות[/po] ?)

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

וברוח האתר:
האמנם המטרה צריכה להיות שאפתנית? האם אנחנו לא מפסידים משאפתנות סטנדרטית זו?

מתכנת, תתעניין אולי לדעת שאת [po]צ'יק צ'ק[/po] בנינו (ועודנו בונים) במתודולוגיה ששואבת הרבה מ-XP.

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

שלום לך [po]מתכנת 1 קטן[/po],
אני יועץ ניהולי לפי תורת האילוצים.
אני רואה ב- XP יישום של תורת האילוצים (TOC) לניהול פרוייקט שבו האילוץ אינו השרשרת הקריטית אלא האי-וודאות והבאגים. (זה לא עניין מוסכם בתורת האילוצים, אך נראה לי שזה ייכנס בעתיד הקרוב).
עם זאת, ככל הנראה, האבא הרוחני הישיר של XP הוא תורה ניהולית שכנה ל- TOC, בשם "בדיוק בזמן" (JIT). יש עוד שתי תורות עיקריות בשכונה, אשר משתלבות מצויין יחד. אחת מהן היא ניהול איכות כולל (TQM), והאחרת פחות ידועה, ניהול מוכוון ערך (VDM).

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

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

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

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

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

רוצים לגבי חינוך? בבקשה: הנה בעיות שהייתי שמח לשמוע על שיטות להציף אותן מה שיותר מהר:
[list]
[*] תסכולים שילד שומר בבטן
[*] בעיות חברתיות
[*] חוסר בטחון עצמי
[*] כוחניות יתר
[*] תפיסת עולם מעוותת
[/list]
וכו' וכו'.

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

ולסיום: [url=http://www.toc4ed.org.il/]לינק קטן[/url]

עכשיו אני ממתין לגל של תגובות. אשתדל לא לטבוע.
יום טוב לכם, מהמתכנת החושב :-)

וזה המקום להוסיף קישור ל-[po]כריסטופר אלכסנדר[/po], עוד חוט מקשר בין תכנות ל-[po]באופן טבעי[/po].
ולמי שרוצה לקרוא קצת על XP, אפשר גם אצלי: http://ootips.org/xp.html

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

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

טוב. קראתי. מה אתה אומר, הד, ש XP הוא - [po]תכנות באופן טבעי[/po]?
שוין.

_מה איתך גילה?
הכל מתחבר. (והתבנית הגדולה של היקום) בסך הכל מדובר פה ב eXtreme Parenting_

יו! כמעט גרמת לי לקרוא את הדף 0-:

וואללה, איזה היקש מגניב. אתה יודע, [po]מתכנת 1 קטן[/po], למה הרעיונות של xp מעוררים סלידה בלא מעט מתכנתים? כי יש בזה טונה של עבודה שחורה והתמודדות עם המציאות היומיומית. החכמולוגים שהמציאו את שיטות הפיתוח ההיררכיות (מלמעלה למטה, מלמטה למעלה) רוצים שהכל יהיה מסודר, נקי, לוגי. כמו בבית ספר, באוניברסיטה, בתאוריה. אבל מה, זה לא עובד ככה. בכל מקרה החיים הם תחזוקה בלתי פוסקת. וברוח דבריו של [po]הד בר ניסן[/po], ככה זה גם גידול ילדים, ככה זה גם גידול עצמי. אבל מה... גם פה יש סכנה להפוך את עקרונות ה xp לדת החדשה שלך, כאילו, אם לא עושים אינטגרציה כל הזמן הפרויקט לא יצא טוב וכו'

מה איתך גילה?
הכל מתחבר. (והתבנית הגדולה של היקום) בסך הכל מדובר פה ב eXtreme Parenting
מה שלי מהדהד תמיד אותו דבר זה האנטי ל [url=http://www.c2.com/cgi/wiki?BigDesignUpFront]BigDesignUpFront[/url]
אחד הדברים האופיינים לXP זה האין בנייה למען העתיד. מה הלקוח צריך עכשיו. לא משחקים את האלוהים ומנסים לצפות לאן הדרישות יתפתחו. זורמים איתן. אוהבים שינויים.
אחד הדברים האופיינים לXP זה האין חינוך למען העתיד. מה הילד צריך עכשיו. לא משחקים את האלוהים ומנסים לעצב אותו כרצוננו. התכונות שלו יתפתחו מעצמן. זורמים איתן. אוהבים שינויים.

כל הנושא של לא להביא מעצמך אלא לזרום עם החיים מביא ממש משפטים דומים. (אולי אני קצת מפריז, אבל בבסיס זה שם)
[url=http://www.c2.com/cgi/wiki?ListenToTheCode]Listen To The Code[/url]
[po]להקשיב לילדים[/po]

ואני עוצר את עצמי לא לדבר על מקסימום מקומי.

שלום,
מי אתה? [אם יותר לי]
למה אתה מדבר אתנו בנושאי מחשבים? [ולא לקהל מבין]

אולי בתור התחלה, נדבר על eXtreme Programming או בקיצור XP. (לא, אין קשר לגרסת חלונות...)

נחשפתי לעניין עוד לפני מספר שנים. הרעיון מדהים בפשטותו:
יש לכולנו (מפתחי תוכנות) בעיה: אנו מתוסכלים!!!
תשאלו למה? אז ככה:
[list]
[*] אנו מאוד משתדלים לפתח תוכנות טובות ובזמן.
[*] אנו ממש אבל ממש לא מצליחים לעמוד בזמנים
[*] האיכות של התוכנה? בואו נגיד בעדינות, "היה יכול להיות טוב יותר"...
[*] הלחץ? מי לא מכיר... תשאלו את בני/בנות הזוג. לרוב הם סובלים לבד בבית...
[/list]

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

אז מה מציע XP?
[list]
[*] פתרונות!!!
[/list]

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

לדוגמה:
[list]
[*] code review (סקירת קוד? בעברית זה לא מצלצל לי בכלל...). זה דבר טוב? בואו נעשה אותו כל הזמן! איך? פשוט נתכנת בזוגות! נשב זוגות זוגות מול מחשב אחד, האחד יתכנת והשני יחשוב.
[*] אינטגרציה. כאב ראש לא קטן. לגלות שהשלם גדול מחלקיו. אוהו גדול. בעיקר במונחים של זמן עבודה. לוקח ה-מ-ו-ן זמן לגרום שכל החלקים שכתבנו יעבדו ביחד. איך מקצינים את זה? פשוט מאוד: עושים אינטגרציה כל הזמן! כלומר, בונים סקריפט שיודע לעשות לבד את כל התהליך של בניית התוכנה (build) ומפעילים אותו אוטומטית מספר פעמים ביום. התוצאה? אם משהו לא עובד - נדע את זה בשבל מאוד מוקדם.
[*] והעיקר - בדיקות! (unit tests). בעקרון אלו הן קטעי קוד הבודקים את קטעי הקוד המרכזיים של התוכנה אותה אנו מפתחים. תשאלו למה? שוב - מאוד פשוט: רשת בטחון! אנחנו כל הזמן מוסיפים עוד ועוד קוד בדיקה לקוד שאנו כותבים. הבדיקות יכולות לרוץ אוטומטית. המטרה - כל הבדיקות מצליחות. ואם לא? אז זה אומר שגילינו בשלב מאוד מוקדם בעיה או באג. זה הזמן לתקן. בלי לחץ ובלי שעות נוספות.
[/list]

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

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

בקצרה אני מתכנת מנוסה (5 שנים), אוהב טכנולוגיות ואוהב לחשוב.

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

בהצלחה לנו :-)