Posts tagged ‘Design’

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

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

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

clip_image002

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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