TFS או JIRA למערכת ALM לארגון
- פותח הנושא lillitush
- פורסם בתאריך
כמו שאומרים - זה לא כוחות.
TFS הוא מוצר הרבה יותר יקר מ-JIRA וגם נותן יותר.
TFS בא עם סביבת פיתוח, עם MTM (המודול לניהול בדיקות) עם תוכנת מעקב לבאגים ועם אפשרות לאוטומציה של CodedUI בתוספת תשלום עבור הרשיון.
Jira משמש ככלי לבאגים עם כל מיני plugins שונים שאפשר לקנות ולהלביש עליו אבל הבסיס הוא אותו בסיס.
אני חושב שזה בעיקר תלוי בכסף. JIRA עולה 10% ממחיר ה-TFS ולא לשכוח שיש גם דמי מנוי שנתיים.
TFS הוא מוצר הרבה יותר יקר מ-JIRA וגם נותן יותר.
TFS בא עם סביבת פיתוח, עם MTM (המודול לניהול בדיקות) עם תוכנת מעקב לבאגים ועם אפשרות לאוטומציה של CodedUI בתוספת תשלום עבור הרשיון.
Jira משמש ככלי לבאגים עם כל מיני plugins שונים שאפשר לקנות ולהלביש עליו אבל הבסיס הוא אותו בסיס.
אני חושב שזה בעיקר תלוי בכסף. JIRA עולה 10% ממחיר ה-TFS ולא לשכוח שיש גם דמי מנוי שנתיים.
חקרתי את הכלי הזה לפני מספר חודשים.
ה-JIRA נראה הרבה יותר כי יש לו המון plugins שמאפשרים כל מיני דברים כמו ניהול בדיקות ועוד, אבל לא מדובר על משהו מקצועי מאד כמו TFS.
מבחינת התמחור של TFS זה עניין של license.
יש רשיון של באגים בלבד, עולה משהו כמו 250 דולר.
יש רשיון של MTM שעולה בערך 1500 דולר
ויש רישיון של CodedUI שעולה בערך 15000.
לעומת זאת רשיונות של JIRA עולים הרבה פחות.
ה-JIRA נראה הרבה יותר כי יש לו המון plugins שמאפשרים כל מיני דברים כמו ניהול בדיקות ועוד, אבל לא מדובר על משהו מקצועי מאד כמו TFS.
מבחינת התמחור של TFS זה עניין של license.
יש רשיון של באגים בלבד, עולה משהו כמו 250 דולר.
יש רשיון של MTM שעולה בערך 1500 דולר
ויש רישיון של CodedUI שעולה בערך 15000.
לעומת זאת רשיונות של JIRA עולים הרבה פחות.
פונטיוס פילאטיס
New member
עבדתי עם TFS ה"מקצועית"
וההמלצה שלי היא redmine
וההמלצה שלי היא redmine
תתחילי מלהגדיר צרכים - אח"כ מחליטים...
התחלת מהשוואת "תפוחים לתפוזים", אח"כ קיבלת הצעות לשילוב עם אפרסקים - בינתיים יצא סלט שלם... (אולי טעים - אך לא בטוח שמתאים
).
כלי ALM הינו כלי מקיף שמשמש לרוב לפחות 3 קבוצות בארגון:
1. מהנדסי מערכת - לכתיבת דרישות.
2. תכנתים - להוכחת קישוריות הקוד וכיסוי דרישות, תוך כדי התממשקות עם סביבת התכנות, וכלי ניהול קוד (מה שלמעלה קראו בשם של אחד הכלים הנפוצים - SVN)
כמו כן התכנתים זקוקים לחלק של ניהול הבאגים.
3. בודקים - להוכחת קישוריות הבדיקות וכיסוי דרישות, כתיבת באגים.
כולם לעיתים משתמשים (אם קיים) גם בחלק של ניהול פרוייקטים ומשימות, וניהול מסמכים מוגמרים.
מכיוון שיש כל כך הרבה קבוצות, עם מנהלים ושאר בעלי דעה, הפוליטיקה הארגונית חוגגת בתהליך הבחירה, וצריך לקחת זאת בחשבון.
צריך להבין את הצרכים והמגבלות של כל קבוצה (לרוב לתכנתים יש כוח רב, מכיוון שכנראה כבר בחרו כלים ,שפת וסביבת תכנות - וכאשר באים להחליט על מערכת, קשה לזרוק את מה שכבר נעשה.
(בודקים ומהנדסי מערכת, לרוב עבדו על מסמכי וורד/אקסל, או במקרה הטוב על מערכת ניהול בדיקות שמכיוון ומבוססת על DB, קל יחסית להמיר המידע מכלי לכלי - ולכן מהווה שיקול פחות).
שיקול סביבתי נוסף הן דרישות ההדרכה וההטמעה (דיי תלוי בגודל הארגון), וכמובן תקציבים.
לכל קבוצה ונושא שמטופל ע"י המכלול שנקרא ALM, יש צרכים משלה, דרישות בעדיפות גבוהה, ודרישות בעדיפות נמוכה.
בכדי לקחת החלטה, צריך לתחקר את כל הגורמים, להכין רשימת קדימויות של הצרכים, ובעזרתה להשוות בין הכלים או שילובי הכלים שירכיבו את מערכת ה-ALM.
הרבה מערכות מתפארות היום בהגדרה ALM - אך יש הבדלים באילו חלקים כל מערכת תומכת, היכן היא חזקה או לא, ומה יכולות ההתמששקות שלה עם מערכות אחרות.
מבחינת העלויות והתשתיות, ישנן כיום כ-3 סוגי תמחור שונים:
1. מערכות חינמיות ו-OpenSource - (עלות קנייה 0, לעיתים קשה יותר לקבל תמיכה, ולעיתים דווקא ניתן להשפיע ולקבל התאמות שחב' גדולת לא יבצעו/במהירות).
2. מערכות SAAS - מותקנות על מחשבי ספק השירות, אין עלויות קנייה אך יש עלויות שכירות חודשית, אין התעסקות עם שרתים וכד' - אך גם יש פחות שליטה.
3. מערכות מסחריות - יקרות יחסית (לרוב מתחיל מאזור ה-1000$ לרישיון צף/יחיד - תלוי במערכת, בתכולה הנקנית וכן הלאה.
אז, תתחיל מלהגדיר את הצרכים, ומידת ההשפעה שיש לך על תהליך קבלת ההחלטות,
צרי בריתות עם האנשים המחליטים והמשפיעים בקבוצות המקבילות,
ואז תוכלו לקבל החלטה.
יש ברשת מעט רשימות מהן ניתן לקבל תובנה כללית על רשימת הדרישות - רובן נמצאות באתרים של חברות, ולכן הן Biased - אך אם משלבים כמה מהן, ניתן להגיע לרשימת בסיס סבירה.
(למרות שחלקן עלו בדיונים בתקופה האחרונה, אין לי קישורים בהישג יד - אולי מופיעים בשירשורי הקישורים השבועיים, שאותם קל יחסית למצוא)
ואולי מישהו מהחברים שלקח החלטה כזו, יוכל לספק לך את רשימת הדרישות וההערכות של כלים שבחן.
את גם מוזמנת להעלות כאן רשימה משלך, ואנו נעזור להוסיף גורמים ולתעדף.
התחלת מהשוואת "תפוחים לתפוזים", אח"כ קיבלת הצעות לשילוב עם אפרסקים - בינתיים יצא סלט שלם... (אולי טעים - אך לא בטוח שמתאים
כלי ALM הינו כלי מקיף שמשמש לרוב לפחות 3 קבוצות בארגון:
1. מהנדסי מערכת - לכתיבת דרישות.
2. תכנתים - להוכחת קישוריות הקוד וכיסוי דרישות, תוך כדי התממשקות עם סביבת התכנות, וכלי ניהול קוד (מה שלמעלה קראו בשם של אחד הכלים הנפוצים - SVN)
כמו כן התכנתים זקוקים לחלק של ניהול הבאגים.
3. בודקים - להוכחת קישוריות הבדיקות וכיסוי דרישות, כתיבת באגים.
כולם לעיתים משתמשים (אם קיים) גם בחלק של ניהול פרוייקטים ומשימות, וניהול מסמכים מוגמרים.
מכיוון שיש כל כך הרבה קבוצות, עם מנהלים ושאר בעלי דעה, הפוליטיקה הארגונית חוגגת בתהליך הבחירה, וצריך לקחת זאת בחשבון.
צריך להבין את הצרכים והמגבלות של כל קבוצה (לרוב לתכנתים יש כוח רב, מכיוון שכנראה כבר בחרו כלים ,שפת וסביבת תכנות - וכאשר באים להחליט על מערכת, קשה לזרוק את מה שכבר נעשה.
(בודקים ומהנדסי מערכת, לרוב עבדו על מסמכי וורד/אקסל, או במקרה הטוב על מערכת ניהול בדיקות שמכיוון ומבוססת על DB, קל יחסית להמיר המידע מכלי לכלי - ולכן מהווה שיקול פחות).
שיקול סביבתי נוסף הן דרישות ההדרכה וההטמעה (דיי תלוי בגודל הארגון), וכמובן תקציבים.
לכל קבוצה ונושא שמטופל ע"י המכלול שנקרא ALM, יש צרכים משלה, דרישות בעדיפות גבוהה, ודרישות בעדיפות נמוכה.
בכדי לקחת החלטה, צריך לתחקר את כל הגורמים, להכין רשימת קדימויות של הצרכים, ובעזרתה להשוות בין הכלים או שילובי הכלים שירכיבו את מערכת ה-ALM.
הרבה מערכות מתפארות היום בהגדרה ALM - אך יש הבדלים באילו חלקים כל מערכת תומכת, היכן היא חזקה או לא, ומה יכולות ההתמששקות שלה עם מערכות אחרות.
מבחינת העלויות והתשתיות, ישנן כיום כ-3 סוגי תמחור שונים:
1. מערכות חינמיות ו-OpenSource - (עלות קנייה 0, לעיתים קשה יותר לקבל תמיכה, ולעיתים דווקא ניתן להשפיע ולקבל התאמות שחב' גדולת לא יבצעו/במהירות).
2. מערכות SAAS - מותקנות על מחשבי ספק השירות, אין עלויות קנייה אך יש עלויות שכירות חודשית, אין התעסקות עם שרתים וכד' - אך גם יש פחות שליטה.
3. מערכות מסחריות - יקרות יחסית (לרוב מתחיל מאזור ה-1000$ לרישיון צף/יחיד - תלוי במערכת, בתכולה הנקנית וכן הלאה.
אז, תתחיל מלהגדיר את הצרכים, ומידת ההשפעה שיש לך על תהליך קבלת ההחלטות,
צרי בריתות עם האנשים המחליטים והמשפיעים בקבוצות המקבילות,
ואז תוכלו לקבל החלטה.
יש ברשת מעט רשימות מהן ניתן לקבל תובנה כללית על רשימת הדרישות - רובן נמצאות באתרים של חברות, ולכן הן Biased - אך אם משלבים כמה מהן, ניתן להגיע לרשימת בסיס סבירה.
(למרות שחלקן עלו בדיונים בתקופה האחרונה, אין לי קישורים בהישג יד - אולי מופיעים בשירשורי הקישורים השבועיים, שאותם קל יחסית למצוא)
את גם מוזמנת להעלות כאן רשימה משלך, ואנו נעזור להוסיף גורמים ולתעדף.
ממש כך...
תיארת יפה את העניין.
יש גם את כנס סיגיסט הקרוב בנושא זה: ניתן ללמוד הרבה מהתהליך שיתאר פאבל מאינטל, שכלל התלבטות ובדיקה של כמה כלים, ובודאי גם מהמרצה מקוואלקום.
ספציפית לגבי מוצר מיקרוסופט ניתן יהיה ללמוד גם מהרצאת הספונסורים.
אני אישית מחזיק מאד מהמוצר של HP, אבל זול הוא איננו...
תיארת יפה את העניין.
יש גם את כנס סיגיסט הקרוב בנושא זה: ניתן ללמוד הרבה מהתהליך שיתאר פאבל מאינטל, שכלל התלבטות ובדיקה של כמה כלים, ובודאי גם מהמרצה מקוואלקום.
ספציפית לגבי מוצר מיקרוסופט ניתן יהיה ללמוד גם מהרצאת הספונסורים.
אני אישית מחזיק מאד מהמוצר של HP, אבל זול הוא איננו...
זה בדיוק התהליך שאנחנו מבצעים
עם כל הקבוצות שתיארת. עיקר הדרישות הן יכולות של אינטגרציה עם IDE שונים כגון VS ו-eclipse, שעובדים היום עם SVN כ-source control יכולות תכנון מספר פרוייקטים במקביל כמובן Pricing (בסביבות האלפי דולרים ולא להגיע לעלות של עשרות ומאות אלפי דולרים לארגון המונה כמה עשרות אנשים). כמובן יכולת ניהול tasks ברמת הצוות ושקיפות ניהולית מלאה לגבי התקדמות של פרוייקטים ואיכותם. (כמות באגים?)
אני מאד מתרשם מ-JIRA אבל לא מבין בדיוק מה חסר לו כדי להגיע לרמה של ה-TFS.
תודה על התשובות המפורטות. אני סמכים בהחלט עם מה שכתבת לגבי הגדרת דרישות. (שיש לנו אך ההחלטה לגבי הכלי קצת קשה)
עם כל הקבוצות שתיארת. עיקר הדרישות הן יכולות של אינטגרציה עם IDE שונים כגון VS ו-eclipse, שעובדים היום עם SVN כ-source control יכולות תכנון מספר פרוייקטים במקביל כמובן Pricing (בסביבות האלפי דולרים ולא להגיע לעלות של עשרות ומאות אלפי דולרים לארגון המונה כמה עשרות אנשים). כמובן יכולת ניהול tasks ברמת הצוות ושקיפות ניהולית מלאה לגבי התקדמות של פרוייקטים ואיכותם. (כמות באגים?)
אני מאד מתרשם מ-JIRA אבל לא מבין בדיוק מה חסר לו כדי להגיע לרמה של ה-TFS.
תודה על התשובות המפורטות. אני סמכים בהחלט עם מה שכתבת לגבי הגדרת דרישות. (שיש לנו אך ההחלטה לגבי הכלי קצת קשה)
לארגון של עשרות אנשים-תתקשו למצוא כלי מסחרי
בעלות שלא תעלה על כ-20K$.
(רישיון עולה לפחות 1K$ וכ 4K$ בכלים היותר יקרים)
אתם יכולים לשקול כלי חינמי שישמש לניהול הדרישות והבדיקות, ולשלבו עם JIRA לניהול באגים - יש מספר כלים כאלו (אני ממליץ בחום על XSTUDIO - עמו ניתן בהמשך לגדול לשיטת SAAS או רכישת תכונות ייעודיות ככלי מסחרי).
או לבדוק עלויות של כלי SAAS.
מעט מאוד כלים חזקים גם בתחום תיעוד הדרישות והבדיקות וגם בניהול הפרוייקט - מרביתם ייתנו חלק מן המידע על מצב הפרויקט, אך לצערנו לא יוכלו ממש לנהל את משימות הפרוייקט.
בעלות שלא תעלה על כ-20K$.
(רישיון עולה לפחות 1K$ וכ 4K$ בכלים היותר יקרים)
אתם יכולים לשקול כלי חינמי שישמש לניהול הדרישות והבדיקות, ולשלבו עם JIRA לניהול באגים - יש מספר כלים כאלו (אני ממליץ בחום על XSTUDIO - עמו ניתן בהמשך לגדול לשיטת SAAS או רכישת תכונות ייעודיות ככלי מסחרי).
או לבדוק עלויות של כלי SAAS.
מעט מאוד כלים חזקים גם בתחום תיעוד הדרישות והבדיקות וגם בניהול הפרוייקט - מרביתם ייתנו חלק מן המידע על מצב הפרויקט, אך לצערנו לא יוכלו ממש לנהל את משימות הפרוייקט.
כל דבר שעבר ליד ALM משווק כ-ALM - זה Hype
ה- Hype (טרנד) הנוכחי הוא ALM (בסוף שנות התשעים היה e-Business, אז מה?) , ולכן כל איש שיווק שרוצה שישימו לב למוצר שלו קורא לו ALM.
השאלה הינה למה נולד הכלי במקור?, היכן ממוקד הפיתוח הנוכחי והעתידי שלו?, היכן אזורי החוזקה והחולשה?, ומה בכלל צריכים מנהלי המוצר והפרוייקטים בחברתך? (וכמובן מה צריכים הבודקים והתכנתים - אחרת יעקפו את השימוש בכלי).
לא בחנתי את יכולות JIRA בשנים האחרונות, אך למיטב ידיעתי, מרבית המשתמשים ב-JIRA משתמשים בו לניהול באגים בלבד - ייתכן כי חלקם תפרו לו יכולות אחרות, אך סביר להניח כי אלו לא איכותיות בתחומי ניהול בדיקות ודרישות - כמו של כלי שמתמחה בכך - ולהיפך (כלים אחרים אולי מזניחים מעט את יכולות ניהול הבאגים).
אני יודע כי רבים משתמשים בו תוך כדי התממשקות לכלי ניהול בדיקות ודרישות - מה שמחזק את ההנחה כי אינו בשל להוות כלי כזה בפני עצמו.
ה- Hype (טרנד) הנוכחי הוא ALM (בסוף שנות התשעים היה e-Business, אז מה?) , ולכן כל איש שיווק שרוצה שישימו לב למוצר שלו קורא לו ALM.
השאלה הינה למה נולד הכלי במקור?, היכן ממוקד הפיתוח הנוכחי והעתידי שלו?, היכן אזורי החוזקה והחולשה?, ומה בכלל צריכים מנהלי המוצר והפרוייקטים בחברתך? (וכמובן מה צריכים הבודקים והתכנתים - אחרת יעקפו את השימוש בכלי).
לא בחנתי את יכולות JIRA בשנים האחרונות, אך למיטב ידיעתי, מרבית המשתמשים ב-JIRA משתמשים בו לניהול באגים בלבד - ייתכן כי חלקם תפרו לו יכולות אחרות, אך סביר להניח כי אלו לא איכותיות בתחומי ניהול בדיקות ודרישות - כמו של כלי שמתמחה בכך - ולהיפך (כלים אחרים אולי מזניחים מעט את יכולות ניהול הבאגים).
אני יודע כי רבים משתמשים בו תוך כדי התממשקות לכלי ניהול בדיקות ודרישות - מה שמחזק את ההנחה כי אינו בשל להוות כלי כזה בפני עצמו.
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.