Posts tagged ‘Architecture’

תשטויות

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

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

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

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

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

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

clip_image002

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

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

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

טיפים לדיזיין אג’ילי

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

* בפוסט הזה אשתמש בביטויים ארכיטקט, דיזיין, מידול, מודל וכו’ – אני מתכוון לאותו דבר.

clip_image002

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

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

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

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

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

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

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

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

דיזיין אג’ילי – יש דבר כזה

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

ישנן אי הבנות רבות בקהילת התוכנה לגביי אג’יל בכלל ולגביי סקראם בפרט, אחת מהידועות שבהן היא הבאה “באג’יל לא עושים דיזיין”. ובכן, מניסיוני – לא נכון! מה כן נכון? הדברים הבאים:

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

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

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

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

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

עוד הרגל שקשה לנו לשנות הוא הצורה או הגישה שבה אנו עושים דיזיין, באופן מסורתי הדיזיין שלנו ממוקד מסביב לארכיטקטורה של המערכת, כלומר, אחרי שחילקנו לאובייקטים, אנו נוהגים להתייחס לכל אובייקט כיחידה נפרדת (עם כך אין לי ויכוח). סגנון דיזיין כזה, מייצר באופן טבעי, עודף פונקציונאליות ומהווה מכשול לדיזיין דינאמי בעל יכולת לגדול לאורך זמן או בלעז: “איטרטיבי” או “אינקרמנטלי”. לעומת זאת אם נמקד את תהליך הדיזיין מסביב לדרישות של הלקוח, אז הדיזיין שלנו יכיל את מה שהתוכנה צריכה ע”מ למלא תא רצון הלקוח ולא יותר, כמו כן הסתכלות כזאת גורמת לנו להתבונן על כל המערכת, כל הזמן, ולא על מודול זה או אחר בכל רגע נתון.
חשבתי שיספיק לי פוסט אחד אבל טעיתי, נראה לי שאולי אפילו אזדקק לשלושה, אז בינתיים…
סיכום ביניים
: אני ממליץ כשעושים דיזיין לפרויקט תוכנה אג’ילי לבצע אותו בהדרגתיות, בצעדים קטנים, וממוקד מסביב לדרישות לקוח הרלוונטיות (איטרציה אחת קדימה לכל היותר), אני לא ממליץ לבצע את הדיזיין באופן רוחבי על בסיס “הכל כלול”.
לדוגמא, לתכנן ולבנות תשתית תוכנה גדולה מראש (עוד לפני שנכתבה שכבת האפליקציה) זה דבר לא אג’ילי, במקום זה ניתן לתכנן ולבנות את התשתית (אם בכלל צריך תשתית), חלק אחרי חלק, לפי הדרישה האפליקטיבית. לכם זה בטח לא קרה, אבל לי קרה שהצוות שבו הייתי פיתח תשתית תוכנה ענקית שאולי 20% ממנה היו בשימוש אפליקטיבי ושאר הקוד פשוט חיכה שמישהו “יתייחס אליו”.

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