חוויות מסדנת הארכיטקטים של Juval, יום ראשון, ערב

4 בינואר 2009

אין תגובות

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

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

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

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

חוויות מסדנת הארכיטקטים של Juval, יום ראשון, אחר צהריים, TDD

אין תגובות

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

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

מה שמכניס לדיון המון נושאים שקשורים ל Testing. להלן כמה שאלות למחשבה. כמה טסטרים יש לך על כל מפתח. כל מספר שפחות מיחס של אחד לאחד לפחות, הוא סימן רע לסיכוי ההצלחה של הפרויקט שלך. האם אתה בודק גם את מסמך הדרישות ? האם אתה בודק את התכנון ? האם אתה בודק גם את הארכיטקטורה ? נכון שאלה לא פעולות של כתיבת קוד, אבל טעות שם תעלה יותר ביוקר מטעות בקוד. האם אתה מבצע Code Review ? והאם זה תנאי ל Check In ? אם לא, זה סימן לא טוב לאיכות הקוד שלך. האם לכל קומפוננטה של המערכת יש סביבת בדיקות עצמאית שלה ? האם הבדיקות שלך ממוכנות או ידניות ? אם לא יהיה לך יותר קשה לאתר תקלות בהמשך הדרך. האם אתה יכול להפעיל את הבדיקות גם בסביבת היצור מבלי להפריע לפעילות השוטפת (מה שנקרא תמיכה ב Instrumentation) ? אם לא, זה סימן שאין לך איש IT או Help Desk בצוות. האם המנטרה Quality is non negotiated עומדת למול עיניך כל הזמן, או שאתה מומחה בלעגל פינות. כל השאלות הללו הם שאלות שבאות בכלל מ MSF, וקפצו לי לראש כתגובה לחלק קטן מהדברים ש Juval הזכיר (כפי שכבר אמרתי, הסדנה צפופה מאד במידע).

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

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

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

אין תגובות

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

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

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

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

חוויות מסדנת הארכיטקטים של Juval יום ראשון, בוקר

אין תגובות

היום החלה סדנת הארכיטקטים של Juval. סדנת הארכיטקטים של Juval מטפלת בתחום שמשפיע הכי הרבה על תעשית התכנה שלנו. בתור אינסטלטור, שנקרא בדרך כלל כדי לתקן מערכות שמתמוטטות. אני יכול להעיד שכמעט כל הנפילות שאני מטפל בהם, נובעות בסופו של דבר מארכיטקטורה לא נכונה. כך שאף אחד לא צריך לשכנע אותי, שתפקידו של הארכיטקט קריטי להצלחת פרויקט תכנה. למעשה צברתי משך השנים שאני עוסק בתחום, המון תובנות ארכיטקטוניות, שבאו מהצד המעשי, של מי שאמור לאתר את ה Root cause of failure בנפילה, ומגיע בסופו של התהליך לתכנון הארכיטקטוני Bottom Up, ולא מהתיאוריה.

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

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

Juval200901a 103

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *