כלי הפיתוח שאתם פשוט חייבים

30 במרץ 2011

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

 

 הכי מוכנים שאפשר

 

אז מה צריך להכין?



  1. Source Control: המקום שבו ישמר הנכס החשוב ביותר שלכם אחרי האנשים. הכלים המובילים היום הם TFS בעולם המיקרוסופט, SVN בעולם שאינו מיקרוסופט (וגם לא מעט מפתחי .Net נהנים פחות או יותר להשתמש בו) ו – Git הכוכב העולה החדש המגיע מעולם הפיתוח המבוזר של הקוד הפתוח. כמובן שיש כלים נוספים בינהם כלי Rational.


  2. כלי ניהול משימות: המקום שבו תרשמו את המשימות שלכם. הכלי הבסיסי ביותר שכולכם תחזרו אליו (או תתחילו איתו) כששום דבר לא יעבוד: הלוח המחיק או ה – White Board. מלבדו ישנם כלים רבים המתחלקים לשלושה סוגים:



    1. כלים הכוללים תמיכה בניהול תהליך ניפוי הבאגים (Bugzilla ו – Trac).


    2. כלים עם אוריאנטציה של ניהול משימות כדוגמת BaseCampHQ (מוגש בהמלצה חמה).


    3. כלים שמשתלבים בסביבת הפיתוח כדוגמת ה – TFS של מיקרוסופט וה – Rational של IBM.


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


  4. Unit Tests: כתבתם קוד? רצוי מאוד שתהיה לכם סביבה מסודרת לכתיבת בדיקות יחידה (וגם בדיקות נרחבות יותר במקרה הצורך). מימוש טוב של בדיקות אלו יאפשר לכם לבצע אוטומציה מלאה לקוד ולזהות שבירה שלו (ולחסוך הרבה שעות שינה וכאבי לב). הסביבה הנפוצה ביותר בתחום היא משפחת ה – XUnit הכוללת את JUnit ל – Java, ה – NUnit לעולם ה – .Net ו – SimpleTest לעולם ה – PHP. ההמלצה שלי: אל תחפשו בכלל פתרון אחר למשפחה הזאת. טיפ למתקדמים: תוכלו לשלב פתרונות Mock המסמלצים מוצרים חיצוניים כמו בסיסי נתונים על מנת לבודד את בדיקות היחידה שלכם. אחת החברות המובילות בשוק זה היא TypeMock הישראלית.


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


  6. Continuous Integration: או בקיצור CI: אחרי שכתבתם קוד מסודר, הטמעתם מערכת ניהול תצורה ויש לכם אפילו 100% כיסוי עם בדיקות אוטומטיות, למה לא לדאוג שהגרסה האחרונה שנמצאת במערכת בקרת התצורה תקינה ואין בה באגים? למה לחכות עד לסיום הגרסה ובדיקות האינטגרציה? בחירה בכלי מתאים כדוגמת TeamCity, FinalBuilder או Jenkins (לשעבר Hudson) יעשו את העבודה. הכלים הללו יודעים לזהות ביצוע Commit במערכת ה – Source Control שלכם, למשוך את הקוד, לבצע Build ואפילו להריץ את כל (או חלק מ)בדיקות האוטומציה שלכם. המתקדמים ביניכם יוכלו לשלב גם Build לילי עם בדיקות מסיביות יותר כדוגמת בדיקות עומסים. רוצים להוציא מהם עוד? הכלים הללו גם יודעים לאתחל את בסיס הנתונים ואפילו לממש את השלב הבא: Continuous Deployment שיביא את הקוד שלכם ממש אל המשתמשים.


  7. Continuous Deployment: או בקיצור CD: מימשתם את התהליך שבודק את הקוד? נותנים שירות ללקוחות שלכם (לדוגמה מערכת SaaS)? פתרונות ה – CD לוקחים אתכם צעד אחד קדימה, ומתקינים את הקוד בשידור חי אצל המשתמשים שלכם. עם קצת מיומנות ובטחון תגיעו לעד עשרות התקנות בייצור ביום! הכלים שישמשו אתכם למהלך הם Selenium, BuildBot, Atlassian Bamboo, Apache ZooKeeper, Capistrano, LinkedIn/Glu (ותודה לישי סמיט)


  8. Logging/Tracing/Analytics: מעלים את הקוד לייצור? רוצים לדעת מה הולך שמה? רוצים לראות איזה Exceptions עפו? במה משתמשים באמת משתמשים ובמה לא? מבחר כלים ואמצעים יעמדו לרשותכם:



    1. Logging/Tracing: הכלי הבסיסי ביותר, שילוב של API חיצוני בתוך הקוד יאפשר לכם לתפוס שגיאות או לציין נקודות משמעותיות בתוך הקוד ולרשום אותן החוצה לעיון מאוחר יותר. השליטים הבלתי מעורערים בתחום הזה הם כלי ה – Log4X וביניהם Log4J ו – Log4Net. המלצה חמה: אם המערכת שלכם גדולה, אל תתפתו לשמור את קבצי ה – Log בבסיס הנתונים עצמו. הסיבה לכך היא שזהו מתכון בטוח לבעיות ביצועים בייצור, ולטבלאות שיהיה קשה מאוד לתשאל אותן במקרה הצורך. התחליף המומלץ הוא שמירת הנתונים לדיסק ושימוש בכלי MapReduce ובראשם ה – Hadoop לביצוע אנליזות.


    2. Analytics: רוצים לדעת איפה המשתמשים שלכם? כמה זמן הם בכל עמוד? ומה המסלול האהוב עליהם? Google Analytics החינמי הוא הכלי הבסיסי ביותר והנפוץ ביותר בתחום. אם אתם רוצים לדעת אינפורציה נוספת תוכלו לעשות שימוש בכלים נוספים שכל אחד מהם מביא את היכולות שלו:



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


      2. היזון חוזר? בשוק כלי Feedback רבים, המאפשרים לכם לקבל סיוע בזמן אמת מהמשתמשים שלכם, מתלונות ועד להמלצות. בין הכלים המובילים: Kampyle, GetSatisfaction ו – uservoice. תוכלו להשתמש בכלים הללו גם כדי לתעדף תכונות חדשות במוצר בשיתוף הקהילה וגם כדי לייצר קהילת משתמשים מסביב למוצר.


      3. רוצים לדעת מטריקות מדויקות עבור כל משתמש: totango של גיא נירפז תשמח לעזור לכם בקרוב.


  9. ניטור סביבת הייצור: שתי משפחות מוצרי הניטור הנפוצות ביותר כיום בתחום האינטרנט (ולא רק לניטור של ה – CPU Utilization אלא גם כמה Signups לדקה יש במערכת) הם Nagios ו – Zabbix. המערכות הללו ידאגו שתתעוררו באמצע הלילה אם עשיתם שטויות במהלך היום…

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

 

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

 

יש לכם כלי מומלץ? יש לכם המלצות נוספות? עברתם חוויה כואבת במיוחד שאתם רוצים לשתף? זה המקום…

 

נהנית מהפוסט? רישום לבלוג הפתוח למנהל הפיתוח יבטיח לכם עדכונים חדשים ישירות לדוא"ל!

 

ממשיכים לפתח,
משה קפלן Follow MosheKaplan on Twitter

 

נ.ב ביום שלישי הקרוב, בשעה 18:00 יערך מפגש אלפאגיקס ה – 9. אם אתם מהנדסי תוכנה (וסביר להניח שזה המצב אם אתם קוראים את הפוסט הזה) ומעניין אתכם איך עובד שיווק באינטרנט, איך זה משפיע על צורת הפיתוח שלכם ואיך בעצם עושים כסף מהקוד שלכם, אתם מוזמנים להצטרף. בתוכנית: איך עושים SEO ואיך זה משפיע על הקוד, איך עושים A/B Testing וסיפור אמיתי על איך מצליחים לשווק אפליקציה ב – AppStore.

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

שלכם,

אנשי האלפאגיקס. תודה לכל מי שהשתתף! וידאו ומצגות יועלו בקרוב 🙂

 

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

Redmine הוא כלי מדהים (מבוסס רובי) אשר מנהל משימות, וויקי וניהול קבצים פר פרויקט. לכלי אינטגרציה מעולה ל – source control – גיט וכדומה, עם יכולת לראות Commits ו – Diff וויזואלי של ההבדלים בין גרסאות.
אנו עובדים עם רדמיין כבר יותר מ – 3 שנים. לאחרונה הרצאתי על מספר פלאגינים מתקדמים שלו ועל השימוש שלנו בהם בדרופלקון בשיקאגו – מומלץ!

 

הטיפ של ישי סמיט
בנוגע ל – Continuous Deployment כלים רלונטיים הם Apache ZooKeeper, Capistrano ו – LinkedIn/Glu.
כלים כמו Puppet ו – Chef הם עבור קונפיגורציה של מכונות והם לא דינמיים מספיק עבור CD. לא ניתן לבנות בעזרתם מערבת הגנה חיסונית גמישה מספיק לפריסה בקצבים גבוהים.

 

הטיפ של מאור

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

 

ועוד כמה מילים על מוצרי ה – Source Control בתגובה לשאלה מה ההבדלים בין Git, Mercurial  ו – SVN

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

ישנם מספר מקומות שמשתמשים בארץ ב – Mercurial, אבל Git באופן עקרוני נכנס יותר טוב לתעשייה, ולכן הייתי ממליץ לך לבחור בין SVN ל – Git.

 

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

21 תגובות

  1. רן בר-זיק31 במרץ 2011 ב 12:22

    פוסט מעניין מאד. בתחום הקוד הפתוח לא רבים משתמשים ב-Unit testing וחבל.

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

    הגב
  2. Moshe Kaplan31 במרץ 2011 ב 13:12

    שלום רן,

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

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

    ממשיכים לפתח,
    משה קפלן

    הגב
  3. ripper2349 באפריל 2011 ב 12:04

    פוסט מעולה, קצת מזכיר לי פוסט דומה שכתבתי בנושא מזמן – http://ripper234.com/p/this-comes-before-your-business-logic/

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

    הגב
  4. Moshe Kaplan9 באפריל 2011 ב 13:06

    שלום רון,

    קודם כל תודה, ואכן הפוסט שצרפת מצויין,
    כנה דגשים טובים שציינת:
    1. בחרתם כלי ניהול קוד: תדאגו שכל הקוד יהיה בו, ולא יסתובב במקומות אחרים
    2. תשתית IT בסיסית: אני ממליץ על הפתרון של גוגל: דוא"ל, מסמכים (גם לתיעוד וגם לנהלים, שכולם יכולים לערוך בלי לנעול אף אחד) ויומן בלי העלויות (ובעיקר כאב הראש) של מנהל רשת צמוד. אם אתם צריכים שרת קבצים ממש, תבדקו את הפתרון של DropBox.

    ממשיכים לפתח,
    משה קפלן

    הגב
  5. שחר מור9 באפריל 2011 ב 21:16

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

    תודה!

    הגב
  6. Moshe Kaplan10 באפריל 2011 ב 0:35

    שלום שחר,

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

    אם אתה רוצה דגשים נוספים, אנא הגדר אותם בצורה יותר מפורטת,

    ממשיכים לפתח,
    משה קפלן

    הגב
  7. תמיר12 באפריל 2011 ב 23:17

    ובכל זאת, כמה הערות:

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

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

    כמו כן אני ממליץ לנסות את הכלים החדשים של Rational – ובמיוחד RTC Team Concert . מדובר בכלי רציני וחינמי לעד 10 מפתחים (אך ללא תמיכה!). מה שיפה זה שהוא כולל כבר את יכולות 1,2,6 שציין למעלה משה, וניתן גם להוסיף יכולות נוספות ע"י חיבור למערכות אחרות (מנסיון אישי).
    אפשר ליצור איתי קשר לשאלות – מבטיח להשתדל לענות 🙂

    הגב
  8. Moshe Kaplan13 באפריל 2011 ב 14:23

    שלם תמיר,

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

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

    ממשיכים לפתח,
    משה קפלן

    הגב
  9. תמיר14 באפריל 2011 ב 0:45

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

    להמליץ על כלים חינמיים מצויינים זה טוב ויפה , אבל אם הם לא כוללים תמיכה מקצועית, זה סוג של גול עצמי… במוקדם או במאוחר ה- R&D יתקע (ובמקרה הטוב יצליחו לצאת מזה לבד אך תוך עיכוב בפיתוח – ומי רוצה לאחר במסירת גירסא? לא חבל? השוק לא מחכה).
    אף חברה רצינית לא תסתמך על פתרון "חינם" שלא כולל תמיכה מקצועית מהצד.
    אגב – תמיכה מקצועית זה לא רק יעוץ, אלא גם הצהרה של "הנהלת" המוצר על road map קדימה, תיעוד מסודר של היכולות, הבאגים, מתן best practices וכד'. אני מניח שתסכים איתי שלא כל הכלים החינמיים מספקים את זה.

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

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

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

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

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

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

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

    בידידות,
    תמיר גפן
    GoMidjets

    הגב
  10. Moshe Kaplan14 באפריל 2011 ב 17:30

    הי תמיר,

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

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

    תודה שוב,

    ממשיכים לפתח,
    משה קפלן

    הגב
  11. ליאור16 במאי 2011 ב 9:30

    תמיר,

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

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

    הגב
  12. Moshe Kaplan16 במאי 2011 ב 11:02

    ליאור,

    אני בהחלט מסכים,
    למרות שלא צריך לזלזל גם בחברות המסחריות 🙂

    ממשיכים לפתח,
    משה קפלן

    הגב
  13. מאור5 ביולי 2011 ב 18:02

    מבחינת Code Review
    אני ממליץ בחום על Review Board
    כלי מבוסס WEB… מתממשק ל SVN (אני מניח שגם ל GIT) בצורה מצויינת
    מאפשר לבצע Review כולל מתן הערות השוואה בין ריוויסיות של אותו שינוי וכן הלאה.
    פשוט תענוג של כלי

    הגב
  14. Moshe Kaplan5 ביולי 2011 ב 20:31

    שלום מאור,

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

    ממשיכים לפתח,
    משה קפלן

    הגב
  15. קורא6 ביולי 2011 ב 12:34

    פוסט טוב!

    הגב
  16. Moshe Kaplan6 ביולי 2011 ב 12:50

    תודה!

    ממשיכים לפתח,
    משה קפלן

    הגב
  17. ערן5 בדצמבר 2012 ב 14:41

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

    הגב
  18. Moshe Kaplan6 בדצמבר 2012 ב 5:33

    שלום ערן,

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

    כל הדברים האלו יקבעו מה הפתרון העדיף עבורכם,

    ממשיכים לפתח,
    משה קפלן

    הגב
  19. עידן5 במרץ 2013 ב 7:17

    משה
    תודה רבה על המידע , מאוד שימושי.
    אהבתי את העדכון בעקבות הערות/תגובות.

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

    הגב
  20. Moshe Kaplan3 ביוני 2013 ב 7:55

    הי עידן,

    תודה על הערה, ניישם אותה בהמשך.

    ממשיכים לפתח,
    משה קפלן

    הגב
  21. Michelle Bar-lev31 במרץ 2014 ב 11:17

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

    הגב