שלום לכולם,

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

הטענה הראשונה שכדאי להפריך היא שמתודולוגיות ותיקות פשטו את הרגל ...

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

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

בלב המהפכה נמצאים אנחנו, האנשים.

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

והשאלה הגדולה  היא: איך מנהלים פס ייצור אנושי?

כדי לא להכנס כרגע יותר מדי עמוק לשאלות הפילוסופיות אני אומר את זה:

יש משהו מאוד אנושי במתודולוגיות קלות (Agile) אבל צריך להבין ולדעת איך לעשות זאת נכון.

בהרבה אירגונים נוטים לעבור למתודולוגיות קלות (Agile) כחלק מתהליך פיתוח בריא.

 אירגונים צעירים (Start-up) נוטים לאמץ מתודולוגיה קלה בלי ממש להבין את המשמעות ארוכת הטווח שיש למתודולוגיות האלו... מה שלא ממסמכים לא ניתן לנהל והופך להיות סיכון שקשה להעריך.

עד כאן להיום. 

מדי פעם אוסיף הבטים שונים שקשורים לסוג זה של מתודולוגיות (גם מעשיים ום פילוסופיים)

שאלות יתקבלו בברכה. 

מעניין, תןדה.

בבקשה תוסיף קישורים לחומר קריאה מומלץ. 

למטה יש כמה לינקים בסיסיים בנושא XP שהיא אחת מהמתודולוגיות היותר "ותיקות".

לכל מי שמחפש אתרים ו/או ספרים בנושא, פשוט כיתבו XP ב Google ותקבלו רשימה מכובדת.

יש כמובן מתודולוגיות חדשות יותר ולחפש אותן, אני ממליץ לכתוב Agile Processes ב Google

בדיון הזה הייתי מעוניין להתמקד יותר בנושאי ניהול ומשמעות .

http://www.extremeprogramming.org

http://www.xprogramming.com

http://www.xp123.com

בהרבה אירגונים נוטים לעבור למתודולוגיות קלות (Agile) כחלק מתהליך פיתוח בריא.

אירגונים צעירים (Start-up) נוטים לאמץ מתודולוגיה קלה בלי ממש להבין את המשמעות ארוכת הטווח שיש למתודולוגיות האלו... מה שלא ממסמכים לא ניתן לנהל והופך להיות סיכון שקשה להעריך.

 

 איפה כתוב שמתודולוגיות agile נוגדות כתיבת מסמכים?!

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

 הוא העדפה של תוכנה עובדת על דוקיומנטציה מפורטת ראה http://agilemanifesto.org

ארנון 

הי ארנון,

תודה על התגובה, מכיוון שלדעתי כדאי לדון בניהול ובמשמעיות של מתודולוגיות זריזות

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

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

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

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

אתה מוזמן לקרוא פוסט שלי בנושא כאן: http://cafe.themarker.com/view.php?t=31927

ממליץ לכול מי שלא מכיר את הנושא לרוץ ולקרוא את הפוסט של אריאל.

תקציר יותר ממצה מזה בעיברית לא תמצאו. נקודה!

יחד עם זה,

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

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

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

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

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

צטט: גנאדי 2007-11-28 23:28:54

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

 

אתה לא באמת מאמין בזה נכון?

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

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

בנוסף התעוד לא צריך להיות בסוף הוא פשוט צריך להבחר בקפידה-  הן אילו מסמכים לכתוב והן ברמת הפרוט והליטוש של כל מסמך. חלקו הוא on-going (למשל תעוד הדרישות שנעשה בכמה רמות פרוט לפי הקרבה לזמן המימוש והודאות בנכונות) חלקו לפני התחלה (למשל אני חושב שמסמך vision and scope הוא די חשוב) חלקו תוך כדי התהליך (למשל אין טעם לכתוב מסמך ארכיטקטורה מפורט לפני שהארכיטקטורה מתייצבת) וחלקו לא צריך להעשות כלל (מסמכי תכן מפורט למשל, כל מסמך שהופך לwrite-only document) 

ארנון 

צטט: Groove 2007-11-28 15:58:17

 

הי ארנון,

תודה על התגובה, מכיוון שלדעתי כדאי לדון בניהול ובמשמעיות של מתודולוגיות זריזות

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

 

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

 

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

 

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

 לגבי מה שרשמתי זה פשוט תרגום מילולי של העקרונות שמופיעים בקישור

אני לא מסכים שהשחיקה האנושית היא גדולה מאד במתודולוגיות זריזות - השחיקה האנושית גבוהה מאד כאשר מנסים לעמוד בלו"ז לא ראלי (בין אם במתודולוגיה זריזה או אחרת)

לגבי הצורך בתעוד ותעדופו - אני מסכים אתך (ראה גם תגובה אחרת שלי )

לגבי תעוד דינאמי  - זו השקעה מאד מאד גדולה 

ארנון  

צטט: arnonrgo 2007-11-28 23:41:59

 

צטט: גנאדי 2007-11-28 23:28:54

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

 

אתה לא באמת מאמין בזה נכון?

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

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

 

בנוסף התעוד לא צריך להיות בסוף הוא פשוט צריך להבחר בקפידה-  הן אילו מסמכים לכתוב והן ברמת הפרוט והליטוש של כל מסמך. חלקו הוא on-going (למשל תעוד הדרישות שנעשה בכמה רמות פרוט לפי הקרבה לזמן המימוש והודאות בנכונות) חלקו לפני התחלה (למשל אני חושב שמסמך vision and scope הוא די חשוב) חלקו תוך כדי התהליך (למשל אין טעם לכתוב מסמך ארכיטקטורה מפורט לפני שהארכיטקטורה מתייצבת) וחלקו לא צריך להעשות כלל (מסמכי תכן מפורט למשל, כל מסמך שהופך לwrite-only document) 

 

ארנון 

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

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

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

מה שאני מאמין בו הוא פיתוח של רכיבים גמישים שניתן להרחיב ולהשתמש בהם בפיתוח עתידי (זאת האינטרפרטציה שלי ל-agile). לדעתי כלי התיעוד מס' 1 הוא לקרוא לדברים בשמות שמתארים את מה שהם עושים (ולשמור על כך!) - ברמת הקוד, ברמת ה-design וגם בהכי high level שיש.

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

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

ונעבור לדוגמא מהחיים:

גוייסתי להקים ולנהל ארגון QA ב Start up אינטנסיבי.

עבדנו במין תערובת של XP ו Scrum באיטרציות של 10 ימי עבודה בסביבת Windows.

כבר בימים הראשונים גיליתי שהפיתוח משתמש ב Registry בצורה נרחבת לכל מיני מטרות למשל:

1. התקנה

2. קונפיגורציה

3. פרטי משתמש

4. פרטי רשת

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

מי לדעתכם אחראי לקיים ולעדכן מסמך מהסוג הזה?

ומה לדעתכם עשיתי?

Groove - אין ספק שצריך מסמכים . צריך לזכור שאם מבנה נכון של קוד וארכיטקטורה אמיתית והדוקה, אפשר לוותר על המון מסמכים. למשל בדוגמא שנתת - אם מנהל הפיתוח היה מקפיד שכל הגישה לregistry נעשית בלוגיקה מסוימת, בclass מסוים ולפי code practice מסוים, כל מה שהיה צריך לתעד זה את שם הclass הזה ואת הרעיון הלוגי מאחוריו (ללא רשימה ארוכה ומעייפת של כל מה שנרשם שם, שמן הסתם תמיד תהיה out of date) , ואף על זה היה אפשר לוותר אם יש Naming נכון (זה מזכיר לי משפט שקראתי פעם - "כל פעם שאני מרגיש שאני צריך לכתוב שורת תיעוד, אני משנה את שמות המתודות והמשתנים במקום, ורק אז כותב את התיעוד - אם עדיין צריך...").

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