שיטת נת"י - כי קריירה צריך לתחזק!

שלום לכם,

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

1. תחושה כללית של חוסר הערכה.
2. לא מסתדרים עם הבוס.
3. לא מסתדרים עם הצוות.
4. התפקיד הפך למשמעם ולא מאתגר (בעצם, הוא תמיד היה כזה).
5. תנאי שכר (מי אמר הכי חשוב?).

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

1. פחות רוצים לעבוד מולם.
2. פחות סומכים עליהם.
3. פחות מעבירים אליהם אחריות.
4. פחות מקדמים אותם לאורך השנים.

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

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

אז מהי בעצם שיטת נת"י?

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

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

אפילו הוא:

אז איך עושים את זה?

אבני היסוד אשר יש לתחזק בקביעות:

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

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

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

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

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

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

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

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

נחישות + תשוקה + ידע = נת"י.
קדימה, רעננו את הגישה לקריירה שלכם, כי גם היא בדומה לזוגיות דורשת תחזוקה :-)

תודה,
יניב

!HTML 5 (five) is kicking and alive

שלום לכם,

על הכתפיים הרחבות של HTML5 הונחו משקולות די כבדות.
התינוק, שנולד באופן רשמי במאי 2011, קיבל משימה לא פשוטה, הוטל עליו להיות יורש העצר הרשמי של HTML 4.01, הידוע בכינויו המלך הבלתי מעורער של הרשת מאז 1999 ועל הדרך גם לערער את יציבותו של XHTML הנוקשה.
אבל הרכב מנצח לא מחליפים ולכן HTML5 נבנה על בסיסו האיתן של HTML4 ולמעשה מציע סט של Features על גביו.
אחת ממטרות העל של HTML 5, שפת הסימון לעיצוב דפי אינטרנט, היא לספק תכנים עשירים בעזרת HTML CSS ו Javascript, וללא צורך בתוספים של third-party companies.
תגיות כמו <canvas>, <video>, <audio> מציעות חלופה לשימוש ב Flash על גבי HTML 4.01.
HTML5 תוכננה לשמש כ cross platform, ויכולה לספק אחידות פונקציונלית וחזותית בין אם אתה גולש דרך PC, Tablet או Smartphone.

כגישה לחיים, HTML5 הינו הרבה יותר סלחני מ XHTML חמור הסבר.
אין חובה להקפיד על trailing slash, אין חובה לעטוף ערכים בגרשיים (אם אין רווחים) וקיים רק <!doctype>
יחיד ופשוט: <!DOCTYPE html>.
ומה זה אם לא החיים הטובים, או האקונה מטטה כפי שטימון הסוריקטה ופומבה חזיר היבלות הרבו לשנן באוזני סימבה הצעיר בסרט מלך האריות.



HTML5 is Backwards Compatible
שימו לב לדבר הבא: נוכל להמשיך לציית לחוקים המחמירים של XHTML ולהכניס קצת סדר לקוד שלנו, בעצם אין סיבה שלא נעשה כך.

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

Local Storage

מנגנון שמירת נתונים ב Client למצבים בהם cookies פחות יעילים.

המידע נשמר כ key/value ובעל קיבולת של לפחות 5MB ומידע זה לעולם לא עובר ל Server.

ל HTML5 קיימים שני סוגי אובייקטים:

1. localStorage (המידע נשמר ללא הגבלת זמן).

2. sessionStorage (המידע נשמר כל עוד הטאב פתוח).

HTML5 Geolocation

בעזרת Geolocation API נוכל לקבל מידע אודות המיקום הגרפי של משתמש מסוים (באישורו בלבד),

גם אם הדפדפן רץ מאחורי proxy, בעזרת GPS, WLAN ועוד, כתובת ה IP האמיתית תזוהה.

באמת שקל להתחיל.

שינוי קטנטן בדמות <!DOCTYPE html> וזהו, אתם די שם. דפדפן מתקדם שתומך באחד או יותר Features, יטפל בתגיות החדשות בחפץ לב, בעוד IE 6 נניח, יצנן את ההתלהבות שלכם ו"ירנדר" את הדף בהתאם ליכולותיו. 

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

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

HTML5 כאן כדי להישאר, אז אמצו אותו בהקדם.

Boxing and UnBoxing

שלום רב,

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

אז בעצם מדובר על פעולה שהיא מקרה פרטי של Casting.
כשאנחנו מדברים על Boxing אנחנו מתכוונים ל value type to a reference type conversion.
לדוגמא המרה של integer ל object.
בתהליך ה Boxing, ה value type מוקצה על ה Heap (זהו בעצם העתק הערך של ה value type המקורי), ואליו מצביע object הנמצא ב Stack.

Unboxing, לעומת זאת, זה בדיוק אותו דבר רק הפוך, הכוונה להמרה של אותו boxed reference type חזרה אל value type.
בפעולה זאת, ה boxed reference type, עובר תהליך של unboxing מה Heap, ומתבצעת השמה ל value type אשר מוקצה ב Stack.

אם עדיין לא ברור, התרשים הבא הולך לפזר את הערפל שנותר:

     

                                                                                                                                        

תודה,
יניב

#Arraylist and List in C

שלום לכם,

בטח שאלתם את עצמכם לפחות פעם אחת, באיזה Collection עדיף להשתמש?
אז ככה, <List<T הוא generic class. הוא תומך בשמירת אובייקטים מטיפוס מסוים מבלי לבצע המרה מ_ או ל_ object (ב Arraylist הייתה מתווספת תקורה של boxing/unboxing, ולכן <List<T יעיל יותר מבחינת ביצועים).
<List<T מממש את <IEnumreable<T ובכך ניתן לשימוש יעיל ללא המרות כלשהן ב LINQ.
Arraylist שייך לטרום עידן ה generics ב #C, כמעט לפני עשור, עוד לפני שהושק IPhone first generation.
כיום, לא נראה שיש באמת סיבה מוצדקת להשתמש ב Arraylist ב Net Frameworks. מתקדמים, אלא אם כן נרצה להתממשק ל API ישן.
דבר נוסף, השימוש ב Strongly typed objects ב <List<T, חוסך לנו התעסקות עם casting errors ב runtime.

תהנו!

מה חדש ב Net Framework 4.5.? חלק 1.

שלום לכם,

גרסת Net Framework 4.5. שוחררה באופן רשמי בתאריך ה 15/08/2012. הגרסה כוללת מספר Feature-ים ושיפורים חדשים.
Net Framework 4.5. נתמכת החל מ Windows Vista והיא עושה שימוש ב CLR 4.0.

בפוסט זה אסקור את החידושים בנושאים הבאים:
- GC.
- Asynchronous Programming.
- Parallel Computing.

בחלק שני אסקור את החידושים בנושאים הבאים:
- Asp .Net 4.5.
- EF 5.0.
- ADO .Net.
- WCF.
- WPF.

GC Background Cleanup:

ב Net. Framework 4.0, ה GC התנהג בצורה מעט בעייתית כך שבזמן ביצוע ניקוי האובייקטים, כל ה Thread-ים של האפליקציה הושהו וכך אותה אפליקציה איבדה חלק ניכר מהתגובתיות שלה בטווח זמן זה.
על מנת להתגבר על הבעיה, התווסף Feature חדש הנקרא Server GC.

כעת Net Framework 4.5. יודעת להקצות עוד Thread אשר מטפל ברקע בניקוי Generation 2 ומצטרף למאמץ המלחמתי של ה Thread המרכזי של ה GC. ובכלל, ככל שיהיו יותר ליבות פנויות במכונה, כך יתאים עצמו המנגנון וידאג לייצר עוד Thread-ים ויפנה אותם לטפל ברקע בניקוי ובכך מאפשר לנו לשלב יכולות של Scalability באפליקציה. כמובן שככל שיהיו לנו יותר ליבות פנויות, תגובתיות האפליקציה תוכל להשתפר. אגב, כל הטוב הזה מגיע ללא צורך בשינוי קוד קיים, אלא רק שינוי הגדרה בקובץ ה App.Config:

<configuration>

   <runtime>

      <gcServer enabled="true"/>

   </runtime>

</configuration> 

2GB Arrays:

Net Framework 4.5. מאפשרת שימוש במערכים הגדולים מ 2GB על גבי פלטפורמות של 64bit.
ללא כל תלות בכמות זיכרון ה RAM הפנוי שלנו במערכת, נוצרה לנו הרבה פעמים בעיה בשימוש במערכים מאוד גדולים ובד"כ היינו מקבלים System.OutOfMemoryException.
כעת, ע"י שינוי הגדרה בקובץ ה App.Config, ניתן לשלוט בהתנהגות ה GC בכל הקשור לאובייקטים אלו:

<configuration>

   <runtime>

      <gcAllowVeryLargeObjects enabled="true"/>

   </runtime>

</configuration> 

Regex Timeout:

Net Framework 4.5. מציגה לנו constructor חדש עבור המחלקה:
System.Text.RegularExpressions.Regex המקבל כפרמטר TimeSpan כ Timeout עבור ביצוע פעולת החישוב של ה Regular Expression.
אם ביצוע הפעולה אורכת יותר זמן מאשר ה Timeout המוקצה לה, יזרק Exception מסוג RegexMatchTimeoutException.
אם לא הוגדר Timeout, לא תהיה הגבלת זמן עבור ביצוע הפעולה.

Asynchronous Programming:

Async ו Await הם שני Keywords אשר מאפשרים לנו ליישם תכנות אסינכרוני בעזרת גישה חדשה.
בואו נביט בקוד הבא:

public async void RunItAsync() 

{ 

// let's wait asynchronously for fetching x & y. 

var x = FetchX(); 

var y = FetchY(); 

await Task.WhenAll(x, y); 

// The Remainder. 

Print(x, y);

}

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

שימוש ב Feature יכול לאפשר לנו ביצוע פעולות I/O ללא חסימת ה Main Thread של האפליקציה. כאשר מדובר ב UI הדבר מהווה יתרון עצום בכך שאנו מאפשרים המשך עבודה תקינה של המשתמש לצד המשך ביצוע פעילויות ברקע, אך גם מהווה יתרון בכל הקשור ל Server Side code אשר מורץ צורה מקבילית וע"י כך יגרום לשיפור בביצועי האפליקציה.

Parallel Computing:

Net Framework 4.0. ו Visual Studio 2010 הציגו מגוון יכולות תמיכה בתכנות מקבילי כגון TPL ו PLINQ ועוד. גרסת Net Framework 4.5. הרחיבה יכולות אלה בצורה די משמעותית:

TPL:
שיפור דרמטי של עשרות אחוזים בביצועי ספריית ה TPL ללא כל צורך בשינוי קוד קיים או ביצוע build לקוד, רק מעצם המעבר ל Net Framework. החדש.
המחלקה Task הפכה להיות Light Weight, בכך שנבנתה מחדש. שדות מסוימים של Task אשר אליהם לא ניגשים אופן תדיר הועברו למחלקה Task.ContingentProperties אשר כבר בתכנון הראשוני ב Net Framework 4.0. נוצרה על מנת להכיל שדות מידע פחות פופולרים של Task ובכך לצמצם את השימוש בזכרון.
והמספרים מדברים בעד עצמם: שיפור ניכר של בין 15% ל 100% בעת יצירת Task,
יצירת <Task<TResult, שימוש בפקודות כגון Task.WaitAll ו Task.WaitAny ועוד.

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

זהו לעת עתה,

להתקראות בחלק השני :-)

יניב

.Scrum Forrest, scrum

שלום רב,

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

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

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

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

השיטה..

הרעיון הוא להכשיר קבוצה של מפתחים ובודקים, אשר תהיה אחראית על תכנון, פיתוח ובדיקת הרכיבים החדשים (או שינוי ותיקון הקיימים) של המערכת. מול הקבוצה עומד מנהל המוצר (Product Owner) הרלוונטי אשר אחראי על הגדרת הדרישות ואישור התוצרים המוגמרים לאחר ביצוע. ה Scrum Master הוא אותו גורם שאחראי על הטמעת השיטה ועל ההתמדה בה וגם על הסרת מכשולים מדרכו של הצוות אל עבר יעדיו. 
Feature נקרא User Story וניתן להבין מהשם כמה השיטה היא User Oriented. ה Product Backlog הוא הסל הוירטואלי, בו מאוחסנים כל ה User Stories אשר בקנה ופוטנציאליים להיכנס אל אחד ה Sprints הבאים.
מה זה Sprint?
הפיתוח יתקיים ב Cycles קצרים (Sprints) באופן יחסי (בין מספר ימים למספר שבועות) כך שבסיום כל Sprint יעלו לאויר אותם Features אשר הוגדרו ותוכננו מראש לאותו Sprint (הם נכנסו בעצם ל Sprint Backlog) בפגישת ה Planning אשר מתקיימת לפני תחילת ה Sprint.
על הצוות להעריך את המאמץ הנדרש עבור כל Feature ברמת דיוק של בין מספר שעות עד מספר בודד של ימים.
בסיום כל Sprint תתקיים פגישת Retrospective שהיא מעין פגישת הפקת לקחים של ה Sprint האחרון. 

היתרונות:

1. שליטה ומעקב הדוקים יותר אחר המפתחים והבודקים (הסוף לשאלה: תגיד לי בבקשה, על מה בדיוק אתה עובד עכשיו? רמז, לא באמת..).
2. יחידות עבודה קצרות הופכות להיות "טסטביליות" הרבה יותר.
3. האפשרות לג'נגל בין מפתחים, בודקים ויחידות עבודה בקלות יחסית. צוות מגובש יותר, בו מתקיימת הפרייה מקצועית הדדית, אשר מידת הידע של מפתחיו/בודקיו די מאוזנת, יצליח לעבוד בצורה יעילה יותר ולהתקדם אל עבר יעדיו.
4. האפשרות לנהל בקרות קוד בצורה צוותית הדדית בצורה מהירה יחסית.
5. הסוף לגאנט? שווה את הכל, לא? במקום להשתעבד לדיווחים ותכנונים שככל הנראה ישתנו לנו מהר מאוד, נגדיר לנו תכנית למספר שבועות בלבד. זה האופק היחידי שלנו ונתרכז רק בו.

באופן כללי ה Sprint נותן לנו את היכולת להיות גמישים לשינויים. כאשר דרישה משתנה לאחר הגדרתה, הרבה יותר קל לנו לשנות את תכנון האב כאשר הראייה היא תכנון ל short run.

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

1. הטמעה. על מנת שנוכל לרוץ עם השיטה החדשה בצורה כמה שיותר משוייפת וחלקה, צריך לדאוג לכך שחברי הצוות יכירו היטב את עקרונותיה. על נושא זה אחראי בין היתר ה scrum master. נקיטת פעולות העשרה והכוונה בנושא ה scrum יעזרו בהמשך לחיבור הצוות לנהלים החדשים.
2. רוח גבית. אוקיי, חשבנו, שקלנו ובחרנו לעבור ל scrum, אבל מה אם הארגון/לקוח/כל בעל עניין שקשור אליי לא כל כך מתלהב מהרעיון. במצבים פוטנציאלים כאלה, שווה לנהל מספר פגישות מקדימות עם בעלי העניין הרלוונטים, להסביר את המוטיבציה והיעדים וכל זאת על מנת שלא יערימו קשיים בהמשך ויטילו ספקות בנושא. עדיף לצאת לדרך חדשה עם כל הכוחות כולם.
3. שיתוף פעולה של הצוות (בין חבריו ומול השיטה). שיטה חדשה, גישה שונה, הרבה יותר אנרגיות נדרשות, הרבה יותר שקיפות נוצרת, תאריך היעד לסיום ה Sprint כל מספר שבועות מגיע כמו שעון שוויצרי, ותכל'ס? למי נהיה קשה יותר ולמי נהיה קל יותר? רמז, לצוות נהיה קשה יותר, אינטנסיבי יותר וככל הנראה, הולך להישאר לו הרבה פחות זמן ל YNET מבעבר. אז איך משכנעים את הצוות שזה דווקא טוב לו? באמת לא תמיד קל, אבל תנו לי לתקוף את הנושא מזוית אחרת ולקחת אתכם לדוגמא של צוות אג'ילי מספרד: ברצלונה (ההיא) של פפ גווארדיולה. כשפפ הגיע הוא עשה מהלך גאוני - בנה תלכיד של שחקנים מרובי כשרון ואינטיליגנטים ונטולי אגו, הוא חיפש את ה typecast הזה בכל מקום על כדור הארץ, מכיוון שהאמין שזהו הבסיס להטמעת כל שיטה חדשה ויישומה ב long run. אז לאחר שסיים עם ניקוי האורוות, הוא פנה להטמעת שיטתו (טיקי-טאקה כמובן) עם המון סבלנות. ולמרות שעדיין מהנדס תוכנה חזק מרוויח מעט פחות משחקני הספסל של בארסה ,ניתן לעשות הקבלות בין הצוותים והשיטות. צוות אג'ילי יעיל וטוב, לא יכול להכיל יותר מדי אגו, ההיפך, נדרשת פה עזרה הדדית ושיתוף פעולה. נדרשת פה גם המון סבלנות של מנהלי הפרוייקט בכל הקשור לעקומת הלימוד וההתקדמות. תהליכים אלה אורכים זמן, אבל ככל שהצוות יהיה מגובש יותר, איכותי יותר ומקצועי יותר כך יגברו הסיכויים שהשיטה תיושם בצורה טובה יותר. לצערי אני מחזיק בדיעה ש scrum לא מתאים לכל אחד, הוא באמת דורש יותר מהתוכניתן/בודק, אל גם נותן הרבה יותר (מה בדיוק?? התשובה בסעיף הבא). 
4. צוות איכותי. אין מה לעשות, פפ לא טעה. צריך אינטיליגנציה גבוהה על מנת ליישם שיטות עבודה מתקדמות. איך שאני תופס את זה, הצוות האג'ילי צריך לעבוד בצורה די מטריציונית, כאשר חבילות הפיתוח עלולות לעבור ממפתח אחד למשנהו בעקבות אילוצים שונים, כנ"ל לגבי בודק התוכנה - הוא צריך להכיר את התמונה הגדולה, כל צוות צריך, אי אפשר יהיה להמשיך ולהתבונן במוצר מנקודת מבט צרה יותר ובכדי לתמוך בשיטת עבודה כזאת, על חברי הצוות להיות באמת אינטיליגנטים יותר, טכנולוגיים יותר, נחושים יותר, עם חשיבה/הבנה עסקית גבוהה יותר. הרי הרעיון הוא שהצוות ינהל את עצמו, יקבל החלטות בעצמו, עם המון אחריות לגבי המוצר ולגבי תוצריו ולמה? זה כל העניין: כי אין יותר את מי להאשים! הצוות הוא הכל ולכן מי שרצה מתנות על העבודה הקשה הנה קיבל, הסיפוק האדיר של כל אחד מחברי הצוות, בכל צעד בכל check-in ובכל Feature שתוכנן פותח ונבדק על ידי אותה קבוצה (מופלאה כבר אמרנו?). אותי זה היה מספק, מה איתכם?

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

אז מה היה כל כך רע?

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

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

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

תודה,

יניב

X & Y

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

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

1. תאוריית X.

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

2. תאוריית Y.

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

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

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

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

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

עד כאן הגישות, אך למה הן עלולות לגרום?

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

בשורה תחתונה, If you love someone set him free, אז חבר'ה, מנהלים יקרים, הורים מותשים, שחררו! תייגתם? מילא! אבל תנו קצת קרדיט גם ל X-ים, ומי יודע, אולי יום אחד תופתעו לטובה.

טוב, אולי חוץ מה X הזה..

ניפגש בהמשך.