Infrastructure code in Agile software development
•Download as PPT, PDF•
4 likes•1,647 views
Infrastructure code refers to software layers with APIs that are used by multiple users and teams for different purposes. It supports principles like DRY and helps manage shared resources. Traditionally, infrastructure code is never truly complete, becomes too large to manage effectively, and creates bottlenecks. However, taking an agile approach by having multiple feature teams own infrastructure and developing it iteratively reduces bottlenecks and risk while increasing flexibility and business understanding within teams. This requires effort to implement cross-team communication but yields business benefits.
![Infrastructure code in agile software development Elad Sofer – Agile coach blog.thescrumster.com [email_address] Twitter: @ eladsof](https://image.slidesharecdn.com/infrastructureinagilever0-2-111006110359-phpapp01/85/Infrastructure-code-in-Agile-software-development-1-320.jpg)
![What is infrastructure code? ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (19)
Similar to Infrastructure code in Agile software development
Similar to Infrastructure code in Agile software development (20)
More from Elad Sofer
Recently uploaded
Recently uploaded (20)
Infrastructure code in Agile software development
- 1. Infrastructure code in agile software development Elad Sofer – Agile coach blog.thescrumster.com [email_address] Twitter: @ eladsof
- 4. Software infrastructure The traditional way - Common problems
- 5. #1 - It’s never DONE
- 6. #2 - Too big to handle
- 7. #3 – Who’s code is this?
- 8. #4 – Becomes the bottleneck
- 9. #5 – Too much functionality
- 10. #6 – House of cards
- 11. #7 – Hero culture
- 12. #8 – Component Teams Component A Component B Component C Infrastructure
- 13. #8 – Component Teams Release feature list: Feature 1 – A(20%) B(30%) I(50%) Feature 2 – A(40%) B(20%) I(40%) Feature 3 – B(50%) C(10%), I(40%) Feature 4 – A(40%) C(10%), I(50%) Feature 5 – A(20%) C(50%) I(30%) Total Effort needed: A – 120 B – 100 C – 70 D – 210 Component A Component B Component C Infrastructure
- 15. Software infrastructure The agile way
- 18. Simplicity
- 20. Feature areas UI Business logic Data model Infrastructure Security related Features User admin related features Item CRUD related features Reporting related features
- 24. Collaborative.
- 25. spiral (waterfall) vs. iterative
Editor's Notes
- בחברה שעבדתי בה , נפתח פרויקט חדש , הוקצה לו תקציב ואחרי תכנון מפורט ומדוקדק הוא יצא לדרך . ההחלטה היתה לפתח קודם כל את התשתית בצוות ייעודי ואחרי שהתשתית תהיה " גמורה " יצרפו עוד צוותים לפיתוח האפליקציה עצמה . יצאנו לדרך והתחלנו לפתח את התשתית , כעבור חצי שנה בערך החברה נתקלה בקשיים כספיים ובתור צעדי קיצוץ הוחלט בשלב ראשון להקפיא את כל הפיתוחים שאין להם עדיין לקוח , ומובן מאליו שאין לקוחות לתשתית של פרויקט ולכן היינו מועמדים טבעיים לסגירה , ואכן כך קרה . בשורה התחתונה בוזבזה חצי שנה של פיתוח לא כולל הזמן שהושקע ותכנון וניהול של הפרויקט .
- לשכבת התשתית יש נטייה ממגוון סיבות להפוך למפלצת קוד ענקית , שמאוד קשה לגעת בה אם אתה לא מכיר אותה מהעבר , היא עמוסה בפוקציונאליות שנכתבה מזמן ואף אחד כבר לא מכיר ואף אחד לא מוכן לגעת בה . סימן אזהרה הוא כשהתשתית הופכת להיות גדולה יותר מהאפליקציה עצמה . כשהקוד הוא גדול באופן טבעי יש בו יותר באגים ויותר קשה לבצע שינויים .
- כשהתשתית מפותחת ע " י צוות ייעודי נוצר מצב של בעלות על הקוד משני הכיוונים . אם צריך משהו שקשור לקוד התשתיתי אז תמיד מפנים אצבע אל איש התשתיות – זה שלו , דברו איתו . ואם בכל זאת מישהו ינסה לגעת בקוד התשתיתי שאינו חבר בקליקה הסגורה המכונה צוות תשתיות , מייד יקפצו עליו כל הרודוויילרים .
- מה קורה כשמגלים באג בתשתית ? צריך לתקן אותו זה ברור , אבל מה קורה לאפליקציה ? היא לא מתפקדת כמו שצריך . אז ע " מ לתקן את הבאג יש שתי אפשרויוית : הראשונה היא למצוא " איש תשתיות " פנוי שיתקן את הבאג ( ומאוד קשה למצוא כזה ) ובנוסף כעיקרון מנחה , אנשי תשתיות לא אוהבים לתקן באגים , הם מעדיפים לטעון שלא משתמשים בתשתית כמו שצריך . השנייה היא לשנות את קוד האפליקציה כך שיתאים לתשתית , אפילו אם היא " עקומה " קצת ובכך לפגוע בקוד האפליקטיבי . השלישית היא לא להשתמש בתשתית ולכתוב את הפונקציונאליות הנדרשת ברמת האפליקציה . כל אחת מהלטרניטיבות – לא משהו !
- כשכותבים תשתית לשם תשתית נוצרת הבעיה של נתק מהמציאות העסקית , נתק מהצרכים האמיתיים , דבר זה גורם בין השאר לכתיבה של אין סוף פיצ ' רים תשתיתיים שאין ולא יהיה לאף אחד צורך בהם , זה קורה בגלל שלמרות שברור לכולם שהתשתית היא לא מוצר סופי ומוגמר , מתייחסים אליה כאילו היא כזאת ואז על כל פיסת פונקציונאליות ש " אולי נזדקק לה " התשובה לשאלה האם לפתח היא כן . לדוגמא : למה שלא נוסיף אפשרות לייצא את האלמנטים שלנו ב - XML , זה יכול להיות חשוב אם ירצו להתממשק אלינו בעתיד , או אולי להדפיס את המידע ב - JMX . מעבר להשפעה על גודל הקוד ועל כמות הבאגים , מעבר לעובדה שזה מסרבל את השימוש בתשתית כי לא ברור באיזה דרך להשתמש בה , זה גם בזבוז זמן וכסף . היתה אפליקציה שהייתי מעורב בפיתוח שלה עוד בתחילת ימי בתוכנה , וזיהו מראש שיש שם לוגיקה עסקית מבוססת מכונת מצבים , מייד הלכו וביקשו מצוות תשתיות לפתח תשתית למכונת מצבים , צוות תשתיות אכן פיתח מכונת מצבים מאפס , שכוללת הגדרת מצבים , הגדרת מעבר בין מצבים עם תמיכה בתנאים למעבר מצב , מצב התחלתי מיוחד , מצב סופי מיוחד להצלחה \\ מצב סופי מיוחד לכישלון ומנוע שאמור ע " פ הגדרת המצבים להריץ את מכונת המצבים . נשמע סה " כ טוב , אבל .... מיותר לחלוטין . מכונת המצבים כללה בד " כ לא יותר משלושה מצבים מעבר להתחלה והסיום , לא היה כמעט כפילות בין מצבים במכונות שונות היה אפשר לעשות את זה ללא שום תשתית , בחצי מהזמן , ובאיכות גבוהה הרבה יותר .
- מכיוון שתשתית היא גדולה וסבוכה , היא הופכת עם הזמן למאוד מאוד רגישה לשינויים , כמו מגדל קלפים , אם תשנה את ה - IF הלא נכון אתה עלול להפיל את כל המגדל . ובניגוד למגדל קלפים לא תמיד תהיה הפריווילגה לגלות ת זה בזמן אמת , לפעמים נגלה את זה רק אצל הלקוח , כי למשל השינוי עובד מעולה ב - Solaris 10 אבל ב - Solaris 10.5 הוא גורם לבעיית ביצועים קשה ... אני מאמין שכמעט כולנו נתקלנו בשינויים תשתיתיים , אפילו קטנים יחסית , שהפילו מערכות שלמות .
- קיום של שכבת תשתיות שמפותחת ע " י צוות יעודי שבו מומחים ייעודיים מעודדת בצורה ישירה ועקיפה תרבות של גיבורי על , כאלה שנחלצים לעזרה ברגע האחרון ומצילים את היום . לעיתים קרובות מידי הגיבורים הללו הם אותם אנשי תשתית בעצמם שאחראים באופן מסוים לבעיה , אבל כשהם פותרים אותה , ובתור גיבורים מומחים , מות רלהם מה שלאחרים אסור , כלומר לבצע שינויים תשתיתיים , לשנות אפליקציה , לבצע מעקפים בקוד ועוד מיני חוכמות . כשסופרמן מציל מטוס זה לא משנה אם הוא הפיל בניין או שתיים על הדרך . התרבות הזאת מחלחלת לכל שכבות הארגון , ומתחילים להעריך פתרון באגים יותר ממניעת באגים .
- Every change can disrupt the entire system.
- Every change can disrupt the entire system.
- Every change can disrupt the entire system.
- Develop the infrastructure in a “step by step” approach – No BUFx
- Develop only what is required for the current iteration – No more no less.
- Infra code changes can be done by more than one person or team. Reduces bottlenecks. The right organizational structure – Cross functional Feature teams.
- Infrastructure code should be tightly coupled with the “real world”. The developers writing infra code should understand the feature the infra is required for. The developers writing infra code should also develop the business side of the feature.
- Infrastructure code emerges. Not every feature needs to be part of the infrastructure from the start.
- Collaboration should happen Inside teams and within teams. Teams should have open communication channels to discuss infrastructure issues. Create COP – Communities of practice. Have a wiki. Build a process to support this.