מומחים זריזים נגד מניפסט זריז

האם אתה חושב שה"מומחה הזריז המקומי "קרא את המניפסט הזריז? האם אתה? ובכן, זו לא בעיה ... אם אינך משתמש במילה "זריז" על בסיס יומי! אבל אם כן (או שהמומחה המקומי שלך כן)… ובכן - זה דומה לאנשים שמדברים יותר מדי על דת, אך לא פתחו את התנ"ך (התראה פוליטית נכונה) או את הספר הקדוש לבחירתם, מאז שיעורי הספרות שלהם לפני 10 שנים ... אנחנו לא אוהבים אותם. מסיבה מסויימת.

אוקיי אוקיי, בואו לא נתייחס לאנשים אחרים ולחוות דעתם. בואו, במקום זאת, נעבור על "התנ"ך הזריז" שלב אחר שלב.

ציטוטים ממניפסט זריז יינתנו

סוג זה של חסימת טקסט

וההערות שלנו יינתנו בכניסה רגילה כמו זו. בוא נלך!

המניפסט, אחד ויחיד!

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

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

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

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

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

הנקודה הבאה מכסה משהו דומה, בואו נמשיך את הנושא הזה שם.

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

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

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

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

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

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

אוקיי, אולי לא מדי יום, אלא גם - אגודל! אנחנו (אנשים) לא הצלחנו להרוס את זה ב -15 השנים האחרונות ... תן לנו זמן.

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

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

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

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

תוכנת עבודה היא המדד העיקרי להתקדמות.

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

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

קשה להשיג, אבל כמובן - הנחיה נהדרת.

תשומת לב מתמדת למצויינות טכנית
ועיצוב טוב משפר זריזות.

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

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

ברד, פשטות!

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

Ave!

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

אמן!