צטט: sivan 2008-03-20 00:37:20

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

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

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

עד עכשיו ה SVN לא אכזב אותנו בניהול גרסאות, גם במסמכים מורכבים.

 תודה סיון.

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

אני חושב שהכוונה שלו ב"איך אתם מתמודדים עם שינויי דרישות" היא:

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

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

3. איך מתמודדים ביעילות עם שינויי דרישות שמשפיעים על קוד שכבר נכתב ואפילו נבדק חלקית (ניתוח כל השינוייים "על הנייר" וQA מחודש עליהם, unit-testing אוטמטי אולי?)

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

1. שימוש בכלים שאמורים להחזיק את כל התלויות בין דרישות, ואז שמשנים דרישה אחת יודעים (תיאורטית) איפה היא משפיעה. כלים אפשרים: Rational RequisitePro  (של IBM, אני מתאר לעצמי שלחברות כמו HP mercury יש מוצרים מתחרים).

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

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

3. עריכת cycle-ים קצרים, בשיטות agile. פה הרעיון הוא שהדרישות מוגדרות לזמן יותר קצר, ויש "מעגלים" קצרים שבהם מפותחים feature-ים בזמן נתון. פה אם יש שינויי דרישות אפשר להכניס את זה לcycle הבא, בלי שישפיע על האחרים. מעבר לזה, שיטות agile מקדשות unit-testing אוטומטי, שמאפשר לשנות יותר בקלות את הקוד כי אפשר לבדוק את הside affects של השינויים באופן מיידי.

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

אשמח לשמוע עוד תובנות בנושא...

תודה liorebel, לכך אכן התכוונתי.

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

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

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

הדרך המומלצת לניהול דרישות, היא בעזרת כלים יעודיים כמו DOORS או  Focal Point .

היתרונות העיקריים של כלים אלו הם:

• כל הדרישות מאוחסנות במקום מרכזי, כך שיש אמת אחת ואין גרסה אחת למנהל המוצר, גרסה אחרת למנהל הפיתוח וגרסה שלישית למנהל ה QA.
• קישוריות בין דרישות, כך שאם למשל דרישת לקוח משתנה, המערכת מספקת Impact Analysis וניתן לראות אלו דרישות מוצר או דרישות מערכת מושפעות. דוחות אחרים הם  Coverage Report - ניתן לראות בקלות אלו דרישות לקוח מכוסות ע"י דרישות מפורטות יותר או ע"י הבדיקות.
• שמירת מידע נוסף על כל דרישה ודרישה (כמו באקסל) למשל, Priority, גרסה, לקוח, מי אחראי, סטטוס, זמן פיתוח מוערך, וכו'
• ניהול שיינויים מובנה - כל שינוי בדרישה מתועד וניתן תמיד לראות מי שינה, מתי, מדוע ואפילו לשחזר את הדרישה כפי שהיתה בנקודת זמן כלשהיא.
• הקפאת גרסאות של מסמכים והשוואה בין גרסאות שונות.
• הצגת מידע רלבנטי לכל משתמש ומשתמש, כך שמנהל צוות יכול להתמקד רק בדרישות הרלבנטיות אליו.
• מערכת הרשאות
• קישוריות לאפליקציות אחרות, כמו Project, configuration management or Test management
  
• בחירת הכלי תלויה באופי הארגון והתקציב העומד לרשותו.
• מידע נוסף תוכלו למצוא באתר חברת מנג'וור(Manageware), המטמיעה פתרונות לניהול דרישות
• http://www.manageware.co.il/

שלום לכולם,

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

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

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

כדי שדרישות לא יאבדו אסור שיהיו בניירת, עדיף להעבירם במערכת ERP כלשהי עם רוויזיה, כמות וכד'...כדי שיהיה מעקב אחריהן.

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

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

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

פיתחנו את PractiTest, אשר עוזר לניהול דרישות, ניהול טסטים וניהול באגים.

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

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

שווה בדיקה

צטט: כבשת הרעש 2009-03-04 08:46:19

שלום לכולם,

 

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

 

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

 

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

 מסכים איתך לגמרי,

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

ויש מקומות שמתנהלים במערכת Sharepoint, ויש מקומות שעושים התאמות של CVS.

כל אירגון עם מה שמתאים לו ולתרבות וצורת העבודה בו.

הכי חשוב ומעל הכל - כמה הפתרון תורם לתוצאה שאתה רוצה לראות בסופו של דבר! 

Get it Done!

 לזיו ארז שלום רב 

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

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

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

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

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

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

. 

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

.

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

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

. 

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

.

ברשותכם, אסיים בשני משפטים הנראים לי כחשובים והם:

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

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

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