1-80 leveling guide



Why XP matters





 ~ # whoami

Fulvio Meden


Developer @ eMaze Networks
 Student @ UniTS (information engineering)

XP?



eXperience Points?





I thought this was about software development...

XP




eXtreme Programming


xp


Is a discipline


  • created by Kent Beck
  • based on simplicity, feedback, courage
  • aims to improve quality and responsiveness

xp

Some practices in random order:

  • sustainable pace
  • simple design
  • pair programming
  • TDD
  • small iterations
  • whole team
  • integrate frequently
  • more ...

XP




xp summary





  • good ideas, very effective
  • could be hard to introduce in some companies
  • the success depends on people
  • depending on people, could have drawbacks

why XP?


Looks like a bet (and something for managers).
Why should I be interested?


Most of these practices help in our professional growth.



NOTE: you don't need to "do XP" to use those practices.

pair programming




All code is created by two people working together at a single computer.


pair programming



pair programming



May sound odd, but two people working on a single workstation are as productive as two people working separately.


But they produce code of much higher quality!

pair programming



Not intended as mentoring, but cooperation as peers.


Nonetheless, everyone has different knowledge, at a different level.


There's always to learn from others and compare ideas!

pair rotation


Another practice is to swap the team's pairs every now and then.

This ensures that knowledge flows.


This also means that there is always more to learn, teach and refine, from more people.

pair programming

NOTE:

  • Getting it right is not easy. Might feel awkward at first
  • It's a social skill
  • Arguing and sparring is a good sign!

            This is good                                                  This is not
                                   

test driven

 

test driven

Unit Tests:

A unit test is an automated piece of code that invokes a unit of work in the system and then checks a single assumption about the behavior of that unit of work.

test driven

Test Driven Development:

 Developing using tests as definitions of intent, purpose and functionality.

----- me

test driven

Test Driven Design:

 Designing using tests to prove abstraction effectiveness, and the capability of being testable as a driver.

----- me

test driven

How it works:
 

  • Tests are created first
  • Functionality and its tests written by the same pair
  • All tests are to be run as often as possible
  • You are not done until all tests are green
  • If you notice a missing test, add it now
  • A line of code is added only if a test requires it


test driven

How it helps: 


A red test warns you immediately that you screwed up.


Having a tests that covers your back gives you more confidence.


More and more as you learn to write better tests.

test driven

How it helps:


If you're not familiar with design or architecture, design for testability could be the first step.


It's just the tip of an iceberg in the sea of design knowledge, but it's still an important step!

test driven

How it helps:


Unit tests are also precise and updated documentation and examples about functionality and constraints.


Reading a few well-written tests is by far more effective than trying to reverse-engineer a complex component or algorithm.

Spikes


Spikes


Spike solutions are potential solutions, written fast, simply and (often) ugly.


The purpose is to reducing risk, evaluating feasibility or discovering technical limitations.


Expect a spike to be thrown away after being used.

Spikes



Used to reduce risk, and being actually explorations and prototypes, they have very least risk per se.



Implementing a spike solution could be a good occasion to assess a new technology, methodology, language, tool.

Spikes


Even if it will not be adopted or you didn't have enough time to say you "learnt" it, you'll still have an opinion about it.


There is a huge variety of things out there, it's impossible to know everything.


But knowing many alternatives and having an idea about them is very important. 

Collective ownership





Collective ownership



Every person in the team is responsible for the system's health.



There is no Master Programmer that takes all decisions.

Collective ownership



Everyone is encouraged to add ideas to the project.



This gives much responsibility, but also great freedom and power to the developers.

Collective ownership



Take courage and put yourself on the line!


This doesn't mean "Do a shit if you want to, someone else will fix it".


You are given great freedom, but use it wisely and respect teammates!

Collective ownership



Taking part in the game, you will eventually fail and get it wrong.


It's no blame nor sin, but when you are corrected by your seniors or the chief architect, learn your lesson and treasure it for the next time.

Retrospectives




Look at the past, and decide for the future

Retrospectives



A retrospective is a periodical meeting where team members make a summary for what worked and not during the project.



Then they exploit that insight to make decisions for the upcoming challenges.

Retrospectives



You are encouraged to have opinions and propose change.



Not only about the past, but also about other ideas that are being proposed now.

Retrospectives



Listen to other viewpoints.


The same event may be seen from different angles,
discover new optics.


Better criticism makes you a better developer.

Kaizen


改善



Continuous improvement, bit by bit

Kaizen



XP practices are filled with 
opportunities for improvement.



Be it big or small, don't miss the chance
and value everything you learn.




thanks





leveling_guide_1_80_why_xp_matters

By Tsukihara Caligin

leveling_guide_1_80_why_xp_matters

  • 3,827