Life Of A Bulgardener: eXtreme Programming In Practice
•Download as PPTX, PDF•
0 likes•111 views
Have you heard of eXtreme programming? We all have read numerous articles and books about TDD, refactoring and pair programming, but have you ever seen them in action? Georgi and Yulia are part of a distributed team that puts those into practise. They want to share with you their daily routine and the tools they use to combine those practices into a fluid process that works.
More Related Content
What's hot
What's hot (20)
Similar to Life Of A Bulgardener: eXtreme Programming In Practice
Similar to Life Of A Bulgardener: eXtreme Programming In Practice (20)
Recently uploaded
Recently uploaded (20)
Life Of A Bulgardener: eXtreme Programming In Practice
- 2. Life of a Bulgardener: eXtreme Programming in Practice Georgi Sabev, SAP Yulia Nedyalkova, SAP
- 3. TL;DR • Team • Process • Practices
- 4. The Team What are we building Who are we Team Structure
- 5. Team Structure • Product Manager • Anchor • Engineers
- 6. How did we get here?
- 7. How to become a Cloud Foundry committer? • Active contributor • CF DOJO • Working in-person with other Cloud Foundry engineers • Pair programming interview • 6-12 weeks
- 8. The Process • Inception • Weekly iterations • Continuous Release Inception Week Day IPM Retro Standup
- 9. Milestones
- 10. Inception
- 11. Inception • At the beginning of a project or a new topic • Goals • Anti-goals • Risks • User Story Mapping
- 12. Inception: Risks
- 13. Inception: User story mapping
- 14. Interactive Planning Meeting • Upcoming work • Story Points • Breakdown
- 15. Tech session
- 16. Retrospective
- 17. Standup • Status • Pairing • Parking Lot
- 21. Pair Programming Pros • Collective mind • Knowledge transfer • Flexibility • Communication & Discipline
- 22. Pair Programming Cons • Takes more time • Loss of initiative • It takes faith • Little time on your own
- 23. To pair or not to pair • Reading • Trivial or easy tasks • Have breaks
- 24. Test-driven development Make it pass Refactor Write a failing test
- 25. Our tests Unit Black-box integration White-box integration
- 26. How we do TDD Top down approach • Write an integration test and see it fail • Start applying TDD on unit test level until functionality is finished • See integration test passing
- 28. Why we don’t like TDD • Hard • Slow Why we do • Forces good design • Make code easy to test • Increase code coverage
- 29. Automation & CI
- 30. Flake hunting
- 31. Thank you!
- 32. Used Resources • Images • CC: https://creativecommons.org/licenses/by/2.0/ • https://goo.gl/L2fg2E • https://goo.gl/5U8Kd7 • https://goo.gl/vPZVnE • https://goo.gl/e3H7Hm • https://goo.gl/yRyC9d • https://goo.gl/ek7XLp • CC BY-NC https://creativecommons.org/licenses/by-nc/2.0/ • https://goo.gl/3yyi8z • Tools: • Postfacto: https://postfacto.io/ • Concourse: http://concourse.ci/ • Pivotal Tracker: www.pivotaltracker.com • Pairup Board: https://github.com/julz/pairup9000
Editor's Notes
- Cloud Foundry multi tenant application platform. Containers: performance, isolation, density. Garden: CF’s container runtime, low level, linux kernel, golang. Garden team. 1 team, 2 countries, 3 companies Roles; PM, anchor, engineers, 4 pairs Gardeners, Bulgardeners.
- Every developer can join the foundation as a “commiter”, responsible for building the cloud app platform, Typically employed by companies that participate in Cloud Foundry as a member or Certified Platform. Active Contributor: Anyone can contribute to Cloud Foundry (with a signed CLA) and those that have demonstrated consistently valuable and high quality contributions may be nominated to become a project committer by the project team. Cloud Foundry Dojo: unique approach to gaining Committer status by working in-person with other Cloud Foundry engineers.
- There are three main cycles Inception weekly iterations. standup meeting. No commitment, milestone
- Finish Lines are milestones Release not bound to weekly iterations
- On this meeting the IPM presents the topic to the team and the main goal at the end is that every team member has a deep understanding of what the team should build as a product and the main steps to how to achieve that. Typically the process takes half or a full day and the whole product team should attend. Remoters
- Pointing. Story points: complexity, not time. 1pt for simple time consuming story Velocity. Driving analogy – good to know velocity. Fibonacci points Types of stories Pointing encourages discussion Flesh out acceptance Breakdown Key for predictability Reduce scope to be able to point a story
- Optional Spread knowledge in the team about difference topics. Any team member can propose a topic and present it in front of the team. When new team members are joining - using this time slot to make intro sessions (for example basic arcitecture and stuff)
- Everyone is sitting down Status on tracks Decide on pairing Soloing Local pairing
- Everyone is sitting down Status on tracks Decide on pairing Soloing Local pairing
- Two monitors Large desks 2 pairs of peripheral devices Headphones with mic Slack, zoom, tmate
- Two mirrored monitors Large desk 2 pairs of peripheral devices Headphones with mic Slack, zoom, tmate
- Collective mind Less likely to get stuck Combinations of ideas Knowledge transfer: Daily rotations Sharing knowledge (pairing on different levels) Engagement – you will have to stick Learning tricks rom the other pair – tools, scripting, shortcuts Flexibility Bus factor Communication Get to know everyone Communicate more and better Discpipline Best practices are looked after, live code review No attachment
- But that is time well spent If you do not participate enough Easy to blame the process when we are applying it wrongly Hard to catch up with communication, thinking about stuff
- Who knows what TDD is?
- Black-box: do not care about implementational details
- Forces: equally active, stay concetrated
- Slow – spend more time to write tests that actual code
- Concourse, pipeline Periodic tests that test that check if the code & tests are stable. Tests are code without tests -> Very often we catch flakes (ocassionally failing).