אני שמח לפתוח את הדיונים בפורום החדש - ותודה לאריאל ולגנאדי על פתיחתו.

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

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

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

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

מנסיוני במרבית החברות יש שימוש בכלי source control, bug tracking וכו'. קשה לי להאמין שחברה בלי תהליך מסודר בכלל (ועם לפחות כמה עשרות מתכנתים על אותו מוצר או תת-מוצר) תצליח לייצר תוכנה איכותית לאורך זמן, ולו מהסיבה שאם אין מסמך design או requirements בסיסי אז QA לא יוכל לבדוק את המוצר (וזה כנראה אומר שיהיו באגים...).

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

בא נאמר, שבכל הארגונים יש:

Requirements Sheets Management

Configuration Management

Bug Tracker

ושאר הכלים החשובים. השאלה היא, כמה מזה מיושם בפועל:

- האם קורה שמנהל הפרוייקט צריך פיצ'ר "כי הבטא יוצאת מחר ללקוח", ולכן הוא מוותר על רישום דרישה?

- האם ישנן דרישות המנוסחות בשורה אחת בלבד, ומשאירות את כל ההחלטות לשלב האימפלמנטציה?

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

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

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

עבדתי תקופה בקומברס, יש להם מערכת ניהול גרסאות שמבטיחה שכל Check in יהיה מקושר לאיזשהו מספר באג עם תאור הבאג ותיאור התיקון או למספר feature עם SRS ו SDD שקשורים במערכת התיעוד ל SysRS ו MRD וכל שאר השמחה.

הי miqe, וברוך הבא.

לדעתי התהליך החשוב והמסודר ביותר צריך להיות בשלב הדרישות והעבודה מול לקוחות.

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

בחברה הקודמת שבה עבדתי תהליך ניהול הדרישות היה מאוד מסודר ובד"כ תורגם גם למסמכים טכניים. גם הבאגים תועדו היטב ונכתבו גם מסמכים טכניים לרכיבים מרכזיים במערכת. לא היה נהוג לרדת לרמה של very" detailed design".

IBM (לשעבר rational) מציעים את ה-rational unified process שבגדול אמור לעשות סדר בכל הדברים האלה. לדעתי ברוב הפרוייקטים הבינוניים (עד 50 איש) קישור ניהול גרסאות/באגים מספיק ביותר.

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

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

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

לתעד בעיקר שיקולים להחלטות ובחירות בין אופציות.

אם אתה צריך מתודולוגיה עם שם היום קוראים לזה Agile Development. 

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

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

בכל מקרה, לדעתי, למעט מספר קטן מאד של פרויקטים השיטה הסדרתית, המכונה גם מפל המים , פשטה את הרגל מזמן ואולי מעולם לא היתה לא זכות קיום- אפשר לכרון פוסט נחמד על הנושא הזה כאן: http://www.techdarkside.com/?p=164

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

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

יש לנו קו רציף בין QUICK & DIRTY לבין עבודה לפי הספר.

בין מהיר לבין מסודר ומאורגן.

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

תהליך תכנון מסודר (אפילו אם אינו מושלם) יכול להועיל מאוד בתהליך המימוש ואף לקצרו.

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

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

ברמת המקרו לרוב התהליכים הרי יש לנו קלט -> עיבוד -> פלט

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

חשיבות המסמכים באה כמו שנאמר גם לשלב הבדיקה QA וQC של כל התהליך.

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

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

אני מסכים בהחלט.

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

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

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

אשמח לשמוע תגובות נוספות.

כמה הערות

נראה שמשתמע כאן ש Agile=quick & dirty = אז לפחות לדעתי זה ממש לא המצב- נהפוך הוא. אם כבר זה שימת דגש גדול מאד על איכות ובדיקתיות. Agile מדברפשוט על סט ערכים מסויים אבל אין כאן אנרכיה או cowboy programming

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

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

ארנון  

צטט: arnonrgo 2007-11-03 23:47:19

כמה הערות

 

נראה שמשתמע כאן ש Agile=quick & dirty = אז לפחות לדעתי זה ממש לא המצב- נהפוך הוא. אם כבר זה שימת דגש גדול מאד על איכות ובדיקתיות. Agile מדברפשוט על סט ערכים מסויים אבל אין כאן אנרכיה או cowboy programming

 

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

 

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

 

ארנון

מסכים עם כל מילה 

הדיון של מתודולוגיות עבודה במערכות מידע/פיתוח הינו השלב השני.

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

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