Posts in למה כדאי agile

היי אתה, בוא רגע לפה

 

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

תגיד לי אתה, כן אתה שם בפינה, כן כן אתה – התוכניתן עם האוזניות:

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

אתה. אתה יודע מי אתה?

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

הבחירה היא שלך:

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

 אתה הבנת את זה?

 

 

 

מקור התמונות:
http://www.flickr.com/photos/a2gemma/1448178195/
http://www.flickr.com/photos/infomofo/154877897/

10 סיבות לא לעבור לסקראם

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

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

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

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

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

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

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

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

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

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

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

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

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

למה? ככה! 😉

מה יוצא לי מ-Unit tests ?

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

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

clip_image002[2]שיפור קורות החיים – אם אתם עובדים באותה תעשיה כמוני, ישנו סיכוי לא רע שלכל היותר בתוך 4 שנים מהיום תעבדו בחברה אחרת, ואפילו סיכוי טוב יותר שהחברה האחרת הזאת, כאשר תגייס עובדים, כנראה תבקש לראות שיש לכם ידע וניסיון בכתיבת בדיקות אוטומטיות, אבל לא סתם ראיתם-הכרתם, אלא ניסיון ממשי. אז אם אתם רוצים להשאיר לעצמכם סיכוי למצוא עבודה בחברה טובה ורצינית כדאי לכם להתחיל ללמוד ולהטמיע את הנושא.
Unit tests = בטחון תעסוקתי.

הערכה טובה יותר ע”י הממונים – כמו שאתם בודאי יודעים, אחד הפרמטרים שלפיו מודדים אותנו (המפתחים) הוא איכות הקוד, כמות הבאגים, ומהירות התיקון, את שילוב כל הדברים האמורים (ועוד) נהוג לכנות מדדי תפוקהפרודקטיביות, אני חושב שדבר טבעי הוא לרצות הערכה טובה יותר של הממונים שלנו, אם נשתמש ב-Unit tests נכון מובטח לנו שתרד כמות הבאגים באופן משמעותי, נגלה את רוב הבאגים עוד לפני שהתחלנו לדבג (debugging), ואתם הבאגים שכבא ימצאו לנו נפתור בזמן קצר הרבה יותר, כלומר, נעלה משמעותית את הביצועים האישיים, נראה לי שזו עסקה שווה לכל נפש,
Unit tests = הערכה גבוהה יותר ע”י ממונים.
ואם זה לא מספיק אז….

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

בואו נחבר את המשוואה:
Unit tests = בטחון תעסוקתי + הערכה + משכורת.

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

אבל… זה כמובן לא מספיק, כי השאלה היא “בשביל לקבל את כל התועלת הזאת, כמה עליי להשקיע?”, וזו שאלה טובה, אבל התשובה היא טובה לא פחות: השקעה נמוכה מאוד, ללמוד את הבסיס לוקח לכל היותר יום (מה כבר צריך ללמוד? מה זה Assert?),
ספריות ה-Unit tests השונות הן בד”כ עם ממשק קריא פשוט ואינטואיטיבי, הזמן שלוקח לכתוב בדיקה בודדת הוא בד”כ דקות בודדות, אז מה רע?
יש שיטענו שהכתוב לעיל לא נכון, כתיבת בדיקות לוקחת המון זמן, אם כך כנראה שצריך להראות לאותם אנשים מה הם מפספסים, איזה ידע או הבנה חסרים להם בכדי לכתוב בדיקות קטנות שבודקות דבר אחד בלבד, אולי זה פשוט קשה להם וצריך להסביר להם יותר טוב?
תופעה נפוצה שאני נתקל בא היא שבבדיקה אחת מנסים לבדוק המון, ואז כמובן גם הבדיקה מורכבת ולוקחת זמן, גם קשה לתחזק אותה והיא גם פחות קריאה.
יש מספר חריגים, אתייחס לשניים:
– כאשר כותבים את הבדיקות בסוף שלב הקידוד, הכתיבה שלהן יכולה לקחת המון זמן – אז תתחילו לכתוב בדיקות כבר מהתחלת הפיתוח (אני לא מדבר על TDD)
– כאשר כותבים קוד בתוך מערכת קיימת (legacy) יכולה להיות סיבוכיות ראשונית לנתק את הקוד החדש מהקיים, עם הניסיון גם זה נהיה יותר ויותר פשוט (בד”כ, אבל לא תמיד).

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

סקראם – לא לכל אחד…

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

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

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

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

עבודת צוות – Team work
אני לא מתכוון לפרט על המשמעות של עבודת צוות (זאת עשיתי כבר בפוסטים קודמים) אבל אציין שזוהי מיומנות אישית ונרכשת (לא נולדים עם זה.. או שכן). להיות מסוגל לעבוד בצורה צמודה עם עוד אנשים בכדי להשיג את אותה מטרה זה לא עניין של מה בכך, וזה נכון לא לצוותי הפיתוח אלא לכל “השחקנים” כגון ההנהלה, ה-
PO וכו’, אם אין רצון ללמוד את המיומנות הזאת, אז יהיה קשה מאוד לקבל ערך מוסף אמיתי מסקראם (Scrum). בסקראם אין מקום ל”זאבים בודדים”.

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

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

ההוכחה שאג’יל עובד.

clip_image001שינוי משמעותי כגון שינוי של שיטת עבודה הוא שינוי קשה לרוב האנשים, ולכן לפני שאנשים מוכנים לשקול את ביצוע השינוי אחת השאלות שעולות היא “האם השינוי הזה טוב בשבילי?”. השאלה היא כמובן לגיטימית ועניינית מאוד.
אם תקראו חומר ברשת, וחומר כתוב בנושא אג’יל וסקראם, תגלו שכרגע יש סוג של הימנעות מלהתעסק בחיפוש מדדים וראיות ששיטות אג’יליות וסקראם בפרט, עובדות.
באופן אישי אני חושב שבשלב הזה התעסקות בשאלות כאלה יכולה אמנם להפיק תועלת מסוימת אך לדעתי הנזק שעלול להיגרם הוא גדול יותר, בשורות הבאות אסביר למה אני חושב כך.
• הרגע הגענו… – קודם כל יש להפנים את העובדה שמדובר בנושא חדש, התפיסה האג’ילית הינה דבר חדש. סקראם, שנחשבת ע”י חלק מהאנשים למתודולוגיה האג’ילית הוותיקה ביותר, הייתה בשימוש לראשונה באמצע שנות התשעים, וגם זה, בקנה מידה מזערי. Extreme programming – שהיא אולי השיטה הנפוצה ביותר בתחום כיום, הוגדרה לראשונה בסוף שנות ה-90, ורק בשנת 2000 פורסם הספר הראשון שמתאר את השיטה. אז אתם מבינים שכל הסיפור הזה הוא די חדש.
למרות כל זאת, קיימים מחקרים שמצביעים על כך שחלק גדול “מהעובדות” שעליהן מתבססות המתודולוגיות המסורתיות, ובפרט שיטת המפל, הן עובדות שווא, כמו כן קיימים מספר תחומים אשר יעילותם היא כבר קונצנזוס די רחב בתעשיית התוכנה, דברים כגון תכנות בזוגות (pair programming), צוותים מנוהלים עצמאית (self directed teams) ועוד.
• עוד לא למדנו איך למדוד – עקב הרגלי העבודה שלנו בשיטות המסורתיות, ובהתבסס על הנחות היסוד שמהוות את הבסיס לשיטות אלו, היה קל באופן יחסי למדוד הצלחה, תפוקה או כישלון במונחים “אובייקטיביים”. כל מה שהיינו צריכים לעשות זה להשוות את התוכניות למציאות, ככל שהיינו קרובים יותר לתוכנית נחשבנו מוצלחים יותר, זה קל.
בפרויקטים אג’ילים הנחת היסוד היא שלא ניתן לייצר תוכנית מספיק טובה שתשמש אותנו לכל אורך הפרויקט, דבר זה מייצר בעיה למדוד הצלחה או כישלון בכלים הרגילים, מכאן ברור שהצלחה או כישלון של פרויקט אג’ילי היא דבר שקשה יותר למדוד, הרי עדיין אין נתון חד משמעי שניתן לבדוק מולו את ההצלחה. בעיה.
המדדים שמצביעים על הצלחה של פרויקט אג’ילי לפי דעתי קשורים בעיקר לשני תחומים: שביעות רצונו של הלקוח ואיכות. מכיוון שהראשון הוא סובייקטיבי לחלוטין הרי קשה (למרות שאפשרי) למדוד את נתון זה, ואף קשה יותר לייצר סטטיסטיקות שמתבססות על נתון זה.
נותר לנו מדד מהימן אחר שהוא האיכות, על איכות כבר דיברתי לא מעט, אבל למרות שאין לי כל סטטיסטיקה, ובודאי שאני לא מייצג שום מדגם, הפרויקטים האג’ילים שלקחתי בהם חלק הצטיינו באיכותם פי כמה מהפרויקטים ה”לא אג’ילים”.
לסיכום הנקודה, קשה הרבה יותר למדוד הצלחה של פרויקטים אג’ילים.
• מי שמבקש הוכחות, מחפש משהו אחר – יכול להיות גם שחלק מאותם אנשים שמבקשים הוכחות ל”איכותה” של התפיסה האג’ילית למעשה לא מחפש חיזוקים בכדי לאמץ תפיסה זו. בחלק מהשיחות שאני מבצע עם אנשים אני חש לעיתים כי כשהם שואלים שאלות הם לא באמת מחפשים לחקור, להבין ולבדוק את האפשרות לאמץ תפיסה חדשה, אלא מנסים בכל הכוח להמעיט בערכה של תפיסת עולם שלא נוח להם איתה. האם אנשים אלו ריאלים מספיק בכדי להפנים את העובדה שפיתוח תוכנה בבסיס אינו תהליך פשוט ובטח שלא מושלם? האם הם מוכנים לקבל את העובדה שמה שאני מספר עליו הוא לא פתרון הקסם אלא הצעה לשיפור? האם בכלל הם באמת מחפשים הוכחה שזה עובד, או שמא מחפשים את אותה תחושת ביטחון מזויפת שנגזרת מהאמונה שאם משהו עבד למישהו אחר הוא מתאים גם להם?
דבר אחרון אולי בנושא זה, רבים שאותם אנשים שטוענים שהתפיסה האג’ילית אינה טובה, כלל אינם מכירים או מבינים אותה. לעתים הבקשה הלא מקוימת להוכחה, משמשת אותם כמנגנון הגנה מפני השינוי המתבקש.
טוב, אחרי שטענתי שלדעתי התעסקות בשאלת ההוכחה היא מיותרת בעת זו, בכל זאת צריך שיהיה משהו, לא? אז אם תסתובבו קצת ברשת של הכפר הגלובלי שלנו שנקראת האינטרנט, תוכלו למצוא לא מעט דעות חיוביות, בלוגים, קבוצות דיון וכדומה בנושא, כמעט כולם משבחים את העניין, כמעט כולם מביעים שביעות רצון גבוהה מהמעבר לחשיבה אג’ילית. ישנם סקרים של גופים לא נייטרלים שמראים שביעות רצון גבוהה ממעבר למתודולוגיות אג’יליות – זה גם משהו לא? בנוסף יש לא מעט סיפורים (case studies) על מעבר לתפיסה האג’ילית, ואף אוסיף ממש בקרוב דף באתר שמרכז לינקים בנושא.
על היתרונות של התפיסה כבר כתבתי לא מעט ועוד אכתוב הרבה, אם אתם מאלה שלא מוכנים לנסות עד אשר תוגש להם ההוכחה שזה עובד על מגש של כסף (וזה לגיטימי לגמרי מבחינתי) אני מזמין אתכם להישאר קשובים, להמשיך לקרוא ולהתעניין בנושא, ומקווה שיום אחד יקרה אחד מהשניים: תסכימו לתת צ’אנס לנושא, או שמישהו יספק איזה שהוא סקר שירצה אתכם.

האם שיטת המפל היא אג’ילית ?

בתגובה לפוסט הקודם, שאל ג’וני, ובצדק רב ” מה היא הסתירה בין העקרונות של אג’יל (Agile) לשיטת המפל?”. שאלה טובה.

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

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

הערך הראשון: Individuals and interactions over processes and tools – בשיטת המפל, כפי שאתם יודעים הדרך לפיתוח תוכנה מוגדרת היטב בתהליך הבא: דרישות (Requirements), עיצוב (Design), פיתוח (Implementation), בדיקות (Verification). כבר כאן נשאלת שאלה, האם כל תוכנה יכולה להיות מפותחת בצורה כזאת, למה אי אפשר למשל לבצע Design תוך כדי פיתוח ? או למה אי אפשר לפתח קצת, ואז לבדוק, ועוד קצת פיתוח ואז לבדוק, או חס ושלום לבדוק ממש תוך כדי פיתוח (עיין ערך TDD) ?
בשיטת המפל החלוקה לצוותים היא לפי התמחות, צוות פיתוח, צוות בודקים וכו’, חשבתם פעם כמה אנרגיה מתבזבזת בהעברת הידע בין הצוותים השונים וכמה מידע הולך לאיבוד בתהליך כזה ? כמה פעמים קרה שהבודקים לא בדקו נכון או שהמפתחים לא פיתחו את מה שצריך ? אחת הסיבות היא התהליך. אם יש תהליך ברור ומסמכים ברורים וכך הלאה, אין צורך להשקיע אנרגיה בתקשורת. חבל. בשיטת המפל יש צוות פיתוח, הצוות כפוף לסט של חוקים וכללים שמישהו פעם חשב שמתאים לכולם, האם הוא באמת מתאים לכולם? אני חושב (ויש סטטיסטיקות) שאם יינתן לצוות מידת חופש מסוימת אז אולי הפרודוקטיביות תשתפר.
בשיטת המפל מכינים תוכנית לפני שמתחילים לפתח שמכילה את כל הפרויקט מתחילתו ועד סופו, ניסיתם פעם לשכנע מנהל פרויקט שיש בעיה בתוכנית ואולי הסדר של הפיתוח לא נכון ? השיטה שבה מי שמנהל את הפרויקט אינו מעורב בפיתוח בעייתית. מה הסיכוי של תוכנית כזאת לשקף מציאות ? אפס!
מה שאני אומר שבשיטת המפל האנשים שמפתחים את התוכנה הם בעלי ההשפעה הנמוכה ביותר על ההתנהלות של הפרויקט, בין השאר עקב חוסר “קווי תקשורת ראויים” (ישיבה היא לא תקשורת!), ולכן הרכיב שהוא בעל השפעה קריטית על הצלחת הפרויקט זה התהליך והכלים. כאן הסתירה.

הערך השני: Working software over comprehensive documentation – בהמשך ישיר לערך הקודם, שיטת המפל מכתיבה סוגי מסמכים רבים, אם תסתכלו בהגדרה הרשמית של שיטת המפל תראו שהדבר הראשון שיש להגדיר עבור פרויקט חדש הוא קונספט של המסמכים (Document System Concept), למה ? למה אי אפשר לסכם קווים מנחים למינימום ההכרחי מול הלקוח ולגבי כל השאר לתת חופש לפיתוח להחליט מה הוא צריך ומה לא? אני יודע מה תגידו, שימור ידע. שמעתי על זה.
שאלה: מתי פעם אחרונה פתחתם מסמך שמישהו אחר כתב וממש הבנתם למה הוא התכוון? או אולי כמה זמן השקעתם במסמכים שאף אחד לא קרא? אל תטעו, אני לא טוען שאין צורך במסמכים בכלל, אני טוען שיש להחליט לפי הצורך.התפיסה האג’ילית טוענת שבשביל להצליח בפרויקט תוכנה יש לעשות את המינימום ההכרחי ולא פיפס מעבר. כל מסמך מיותר אינו מקדם את הפרויקט ולהפך.
בשביל למדוד התקדמות של פרויקט אין שום ערך במסמכים, תוכניות וכו’.
הדרך היחידה להבין האם פרויקט מתקדם היא ע”פ מצב התוכנה. בשיטת המפל אומרים שפרויקט הוא 50% כאשר 50% מהתוכנית גמורה, באג’יל טוענים, שפרויקט הוא 50% גמור רק כאשר 50% מהתכולה הם 100% גמורים. ההבדל הוא קריטי. באג’יל אם יש משהו ש-50% מהפיתוח שלו נגמר הוא פשוט לא נחשב. אין ערך באג’יל ל-90% פיתוח או 90% בדיקות, רק 100% נחשב. וזו הסתירה.

הערך השלישי Customer collaboration over contract negotiation: שוב, ולא במקרה בהמשך לסעף הקודם, בשיטת המפל מגדיר הלקוח מראש את התכולה שהוא רוצה, אומרים (מנחשים) כמה זה יעלה לו, ויוצאים לדרך. בסוף מישהו מפסיד (בד”כ כולם). התפיסה האג’ילית אומרת שעקב העובדה שפיתוח תוכנה הוא עסק מורכב ובלתי צפוי יש לערב את הלקוח בכל שלבי הפרויקט, ולתת אפשרות לשנות, ולעדכן את ההערכות (לטובה ולרעה). למה שהוא יסכים? שאלה טובה, אם נסביר לו את מה שהוא כבר יודע (שפרויקטים של תוכנה הם עסק בעייתי) ונציע לו בתמורה גמישות, אפשרות לשנות את התכולה ללא עלות נוספת מעבר למשאבי הפיתוח, בנוסף נציע לו שקיפות מלאה ואמיתית למצבו והתקדמותו של הפרויקט, יכול להיות שזה ימצא חן בעיניו. ניתן לו לאורך כל הפרויקט אפשרות לראות את התוכנה ממש ולתת ביקורת ובקשות לשינוי מבלי לחייב אותו להיצמדות לתכולה המוגדרת בחוזה. וזו הסתירה.
קוריוז: יש היום חברות שלא מוכנות לעבוד עם חברות שאינן Agile ואף יש קרנות הון סיכון שמשקיעות רק בחברות שאימצו את תפיסת העולם האג’ילית.
הנושא הנ”ל מורכב מאוד, ולכן ההסבר כאן הוא שטחי בלבד. אז אני אכתוב פוסט ארוך ומלא רק על עניין הלקוחות בעולם אג’ילי בעתיד.

הערך הרביעי Responding to change over following a plan: הפתעה, ערך זה גם בהמשך לערך הקודם (וזו פעם ראשונה שאני שם לב לכך – תודה שוב ג’וני). אני חושב שלמעשה ערך זה משתקף בכל אחד מהערכים הקודמים ומסכם אותם, ובכל זאת, יש להדגיש כי זאת המשמעות.
להיות מוכן לשינויים, לאהוב אותם! למה? כי הם מוסיפים ערך לקוח (שבשבילו אנחנו עובדים). בשיטת המפל, כפי שאתם כבר יודעים, אין כמעט מקום לשינויים, וכשכבר יש (ובמודל המקורי אין!), אז הם כואבים, ארוכים ויקרים. בעולם האג’ילי שינויים הם חלק מהיום-יום, מי שעובד אג’ילי מברך שינויים, מקבל אותם באהבה, וד”א – מקבל אותם פחות עקב העובדה שלא נכפה על אף אחד להגדיר את הכל מראש. התגובה המהירה לשינוי היא מפתח חשוב להצלחה, בטח בעולם מהיר כמו שלנו. דמיינו לכם פרויקט של חברה סלולארית (ללא ספק תחום דינאמי) שבאמצע הפיתוח מספר דרישות נהיות לא רלוונטיות, מה קורה בשיטת המפל? מפתחים כרגיל, יש תוכנית. הגיוני? לא ממש. באג’יל זה לא קורה, יש שינוי, משנים! הפיתוח לא רלוונטי, מפסיקים ועוברים הלאה.
קיימת טענה נפוצה שבאג’יל לא מתכננים, חד משמעית לא נכון, מתכננים, ואף יותר מבשיטת המפל, התוכניות משתנות ללא כל מאמץ ומספקות תמונה נכונה מאוד של התקדמות הפרויקט. וזו הסתירה. בתכנון אג’ילי עוד נדון רבות בבלוג הזה.

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

למה אנחנו לא עומדים בזמנים? – חלק 2

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

  1. יותר מידי תכולה – מה? מי נתן לי את הזכות לטעון טענה כזאת?
    לא טוב לך? לך תעבוד בחברה אחרת שם יש פחות תכולה לפרויקטים!
    ובכן, תוצאות המחקר ה”מחמיא” ביותר מראות כי 40% מכל התכונות (Features) שמפותחות אינו כלל בשימוש ו-25% מהתכונות נמצאות בשימוש לעיתים רחוקות. כלומר – יש יותר מידי תכולה!
    נכון, אתם צודקים,בד”כ הלקוח מחליט על התכולה (גם לקוח פנימי הוא לקוח), אבל איזה היגיון יש ללקוח אם הוא בוחר לשלם בממוצע 40% תוספת על תכונות שהוא לא ישתמש בהן?
    ואני אומר – היגיון בריא!
    בשיטת המפל, עוד לפני תחילת הפיתוח, מספק הלקוח לחברת התוכנה את הגדרת התוכנה ומאפייניה, עכשיו דמיינו לכם שאתם מזמינים תוכנה, ואומרים לכם “תחשוב טוב מה אתה רוצה בתוכנה עכשיו, כי אם תרצה שינוי, זה יעלה לך, והרבה!”, מה תעשו? תכנסו ישיבה ותגדירו את הדרישות, ואז פתאום תעלה שאלה, “נראה לכם שנזדקק לתמיכה באורקל ?” אז תגידו, “לא בטוח, אבל אם נזדקק זה יעלה המון, אז תכתוב שכן.”, וכך עקב העובדה שהלקוח לא רוצה לשלם יותר, ועקב העובדה שהוא מודע לכך שכנראה הדרישות שלו ישתנו בעתיד, הוא משלם הרבה כסף על דברים שהוא לא צריך. מעניין. ב- Agile רוצים שינויים – אוהבים שינויים ! והלקוח לא צריך להגדיר הכל מראש
  2. תעביר את זה הלאה – בשיטת המפל, ברגע שמתחילים לפתח, כבר יש תוכנית מפורטת שמתארת את סדר הפיתוח, כמה זמן כל דבר ייקח ואת התלויות בין המשימות (תרשימי גאנט ופרט – GanttPert). התבוננו נא בשרטוט הבא:
    clip_image002
    למי שלא הבין את השרטוט: משימה ג’ יכולה להתחיל רק כשמשימה א’ ומשימה ב’ נגמרות, למזלנו משימות א’ וב’ יכולות להתבצע במקביל ובל לחסוך זמן.
    כעת, נניח שמשימה א’ ו-ב’ תוכננו להסתיים ביחד, וקרה מקרה ומשימה א’ איחרה בגלל אחת מאלף סיבות, מה עשינו, גרמנו לאיחור של ג’ (וכל מי שתלוי בה). עכשיו תגידו: ברור – יש דרך אחרת, הרי ג’ תלויה ב-א’ ו-ב’. צודקים אבל עכשיו דמיינו לכם תרשים גאנט אמיתי, שיש בו תלויות מספיק בשביל לגרום לאשפוזכם, והא לכם עוד פרויקט שלא עומד בזמן. ב-Scrum (מימוש של Agile) יש צמצום של התלויות על ידי תכנון שונה.
  3. יחידות המידה לא נכונות – אחת הבעיות בתכנון זמנים המסורתי של פרויקטים היא, תאמינו או לא, יחידות המידה.
    יש לנו מדד מקובל שקוראים לו זמן (או שעה), ומבחינה אנושית ופסיכולוגית אנחנו די מוגבלים ביכולת שלנו לחוש באמת את יחידת המידה הזאת, בשביל זה יש לנו שעונים. בעזרת יחידת המידה הזאת אנו מודדים מספר דברים שונים :
    מאמץ (Effort) – משימה X תיקח Y שעות עבודה.
    זמן קלנדארי – אמנם Y שעות עבודה, אבל זה ייקח חודשיים עקב אילוצים אחרים.
    דוחות – כמה שעות עבדנו על מה.
    העניין הוא שבכל שימוש מסתתר מידע שאינו חשוף לקורא, לדוגמה – 100 שעות, אולי מסתתר מי יעשה את המשימה או כי 100 שעות של מפתח מנוסה הן לא 100 שעות של סטודנט, או שיש מישהו בחופש בחודש יולי ולכן המשימה לא תוכל להתקדם, או שבדוחות לא מוכנס למשל ש-M עזר ל-Z שעה בפרויקט אחר ביום שני.
    בנוסף, ובאופן מסורתי, ההנהלה תמיד מנסה לאזן את המשוואה של שלושה גורמים, שאמנם תלויים זה בזה אך בד”כ לא שווים:
    זמן קלנדארי = מאמץ ( של גרסא נניח) = זמן בדוחות.
    אסיים בשאלה האלמותית : האם אנשים = שעות ? או, האם תשע נשים בחודש ראשון יכולות לייצר תינוק ?
    לשיטות התכנון האג’יליות יש אלטרנטיבה לתכנון בשעות.

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

למה אנחנו לא עומדים בזמנים? – חלק 1

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

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

  1. העתיד מלא הפתעות: בואו ניזכר רגע בהגדרת התפקיד של אנשים שמתעסקים בפיתוח תוכנה, “Software R&D Engineer”.
    R&D = Research and development, או בשפתינו מחקר ופיתוח.
    לדעתי, מעצם הגדרת התפקיד בולטת בעיה משמעותית, אנחנו מתעסקים במחקר!
    תנסו לשאול מישהו שמפתח תרופה מתחרה לאקמול כמה זמן ייקח לו, מה הוא יגיד? כנראה “לא יודע”.
    אז למה כששואלים אותנו “כמה זמן ייקח לפתח תמיכה באורקל ?” אנחנו עונים “שבועיים, עד חודש..” או משהו בסגנון. איזה כלים יש לנו לומר דבר כזה ? מתי פעם אחרונה פיתחנו בפרויקט שלנו תמיכה באורקל ? כנראה אף פעם, אחרת לא היה צריך.
    מעבר לכך, גם אם פיתחנו משהו דומה, הרי הפרויקט השתנה מאז, כמות אי הודאות וההפתעות היא גדולה, פתאום מסתבר שזה יוצר בעיית ביצועים, או שבכלל צריך לשנות ארכיטקטורה. אני יודע שלכם זה לא קרה, אבל יש מתכנתים שבפיתוח מסוים הכפילו (או יותר) את הזמן שהוערך מראש…
  2. פחד מטעות – דמיינו לכם סיטואציה: יוסי, מפתח מנוסה ומוערך נשאל ע”י המנהל שלו: “כמה זמן ייקח לך לפתח את X ?”, עונה יוסי שייקח לו יומיים (כך הוא באמת חושב), ואז, קצת מסתבך X, לא נעים. אחרי יומיים מגיע המנהל ומצפה לקבל את X, אך הפלא ופלא, X לא מוכן… לא נעים ליוסי. מה עושה יוסי פעם הבאה ששואלים אותו כמה זמן זה ייקח לפתח משהו ? יוסי יגיד 4 ימים (ליתר בטחון), צודק יוסי! מה הוא צריך צרות?
    אני חושב שאין צורך להסביר מעבר לכך.
  3. Procrastination – סינדרום הסטודנט – מי שהיה סטודנט מכיר טוב את הסיטואציה: לדני יש מבחן ביום שישי, היום יום ראשון, הוא מעריך שייקח לו יומיים ללמוד למבחן, אז מה עושה דני בד”כ? הולך לים… אחרי יומיים (ביום שלישי) הוא מתיישב ללמוד, לעיתים על 12 בלילה כי, אופס, צריך עוד קצת זמן – זה סינדרום הסטודנט, תופעה אנושית ידועה ומקובלת בפסיכולוגיה.
    עכשיו, בואו נדבר על יוסי מהסעיף הקודם: יוסי, כאמור, מעריך כפול ממה שהוא חושב, אהה, אז אם ליוסי יש 4 ימים לפיתוח שאמור לקחת יומיים לדעתו, מה יעשה יוסי? אמנם לא ילך לים, יעשה דברים אחרים מקבילים במקום העבודה כגון, קפה, ארוחות צהריים של שעתיים, יתכנת לעצמו תוכנה קטנה שצובעת את המסך בירוק ועוד…. מה לא יעשה יוסי ? את זה אתם כבר יודעים.

יש עוד סיבות רבות – המשך בפוסט הבא….
בינתיים, ולמי שמעניין אותו סינדרום הסטודנט : http://en.wikipedia.org/wiki/Student_syndrome

למה אנחנו לא עומדים בזמנים ?

אני לא מבין למה אנחנו לא עומדים בזמנים?

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

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

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

אם התשובה לשלושת השאלות היא כן, איחולי – שברתם את הסטטיסטיקה!
http://net.educause.edu/ir/library/pdf/NCP08083B.pdf
הלינק הוא סקר CHAOS המקובל מאוד בעולם המציין שיעור ההצלחה לפרוייקטי תוכנה הוא שרק 9% מפרוייקטי התוכנה בחברות גדולות ו-16.2% ו-28% בחברות בינוניות וקטנות (בהתאמה) מצליחים.

מה היא הפרדיגמה? או…הבהרה לג’וני ולכולם

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

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

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

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

ושוב….. תודה רבה ג’וני.