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

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

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

clip_image002

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

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

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

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

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

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

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

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

Comments are closed.