יעדי התכן ומסמך התכן

להלן רשימה כקו מנחה להגדרת התכן ורשימת הפרקים בו

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

אתגרי תכן תוכנה

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

לתכן, כתהליך, יש מספר אתגרים:

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

בהיבט האתגרי – תכן הוא יותר אומנות ממדע.

פידבק ב15 שניות

בספר “the effective manager” יש מדריך למסירת פידבק ב15 שניות ב4 צעדים פשוטים:

1. שאל – “האם אני יכול לתת לך פידבק?”
2. ציין את ההתנהגות (“כשאתה עושה X…”)
3. ציין את האימפקט (“… התוצאה היא Y.”)
4. ציין את היחס (“המשך כך” לפידבק חיובי, או “אנא המנע מזה בעתיד” לפידבק שלילי).

דוגמאות מהיומיום:

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

זהו! קצר וקולע! לא צריך לתאם פגישות, אפשר לעשות את זזה אד-הוק, להעביר את המסר מהר, וכך להעביר יותר פידבקים!

הספר מעלה גם 3 שאלות שכדאי לשאול את עצמנו לפני שאנחנו ניגשים לתת פידבק:
1. האם את\ה כועס? אם כן – אל תספקו את הפידבק.
2. האם את\ה מתעסק\ת בעבר במקום בעתיד? (האם את\ה מזכיר\ת שוב ושוב את אותו אירוע שקרה בעבר?) אם כן – אל תספקו את הפידבק.
3. האם את\ה יכול לוותר על הפידבק? (לשחרר) – אם לא – אל תספקו את הפידבק.
בגדול – אם את\ה מרגיש דחף לתת את הפידבק – את\ה כנראה עושים משהו מהסיבות הלא נכונות.

העובד שרוצה רק לקודד – או – אתה לא חי בקופסא

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

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

עמרם הוא תפוח רקוב.

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