Agile Methods and Practices Ravindar Gujral mng technologies Who am I?



Download 12.21 Kb.
Date15.02.2017
Size12.21 Kb.
#11592

Agile Methods and Practices

  • ©Ravindar Gujral
  • MNG Technologies

Who am I?

  • Who am I?

It is difficult to describe. So instead I will talk about what I do.

What I do

  • Agile Philly: www.agilephilly.com Coordinator/Owner
  • Software Craftsman/Developer
  • Agilist
  • Scrum Master

Where have I worked?

  • Soon - ClickEquations
  • Comcast
  • Siemens
  • Various Startups

Being Agile

From Thoughtworks

Agile Methods

  • Agile Methods
  • Why do we want to talk about this?
  • What are Agile Methods and Practices?
  • In my mind all of this has to do with success.

What is success

  • What is success

For Organizations

For Customers

For some

The way I look at it

So success is intersection point of various other successes as defined by the parties involved.

  • So success is intersection point of various other successes as defined by the parties involved.
  • What has this got to with Agile Methods? What are Agile Methods?

Is this what we mean by agile method:

  • Is this what we mean by agile method:
  • public Method agileMethods{
  • getMethod(Agile.agile);
  • }

Definition Time Agile Philosphy

  • Agile methods are processes that support the agile philosophy. Examples include Extreme Programming and Scrum.
  • Agile methods consist of individual elements called practices.
  • Practices include using version control, setting coding standards, and giving weekly demos to your stakeholders.
  • Agile Methods combine these practices to accentuate parts that support agile philosophy.

And the philosphy….

Again looking at Success

Organization success is about delivering value – and agile philosophy has this at the heart of it.

  • Organization success is about delivering value – and agile philosophy has this at the heart of it.
  • Personal success is, well Personal, but everyone gains from improved collaboration.
  • Technical success, because of practices like TDD, CIT and pair programming you are continuously improving. This overlaps with personal.

Agile Practices

  • Every project is unique. So the trick is to customize an existing agile method to your project.
  • From Art of Agile Development- Jame Shore
  • Thinking - Pair Programming, Energized Work, Informative Workspace, Root Cause Analysis, Retrospectives etc.
  • Collaborating – Trust, Sit Together, Real Customer Involvement, Ubiquitous language, stand-up meeting, coding standards, sprint demo, reporting etc.
  • Releasing – Done, No Bugs, Version Control, Continuous Integration, Collective Code ownership, documentation etc.
  • Planning – Vision, Release Planning, Iteration Planning, estimating etc.
  • Developing – Customer Tests, Test Driven Development, Simple Design etc.

So lets look at some of the Agile methods

Scrum

There is this one by Mike Cohn

The one I like and will explain

  • ©David Harvey

Infact- This one is best

  • ©David Harvey

XP: the one I like

By Kent Beck

XP and Scrum

  • Scrum teams typically work in iterations (called sprints) that are from two weeks to one month long.
  • Scrum product owner prioritizes the product backlog but the team determines the sequence in which they will develop
  • XP teams typically work in iterations that are one or two weeks long.
  • XP teams work in a strict priority order.

XP and Scrum

  • Scrum teams do not allow changes into their sprints.
  • Scrum doesn't prescribe any engineering practices
  • XP teams are much more amenable to change within their iterations.
  • XP prescribes engineering practices, particularly things like test-driven development, the focus on automated testing, pair programming, simple design, refactoring.

Waiting till the last responsible moment

Individual Practices

Is this Pair Programming?

Pair Programming

  • We help each other succeed. This practice comes from XP.

Pair Programming

  • When you pair, one person codes—the driver. The other person is the navigator, whose job is to think
  • The driver focuses on writing syntactically correct code.
  • The navigator sometimes works on understanding how the current work fits in the over-all design and sometimes thinks of the next task.
  • Since we are trying to do simple design things are evolving the developers require a lot of discipline and pair programming enforces this.
  • This form of development is very resilient to external interruptions.
  • Above all it allows and forces individuals to collaborate and share knowledge.

Pair Programming- Challenges

  • Pair programming can be uncomfortable in the beginning, especially if you are not used to collaborating.
  • Comfort needs repeating.
  • Communication issues.
  • Organizational buy-in - Isn’t it more expensive?

Continuous Integration

  • We keep our code ready to ship.
  • At heart this is stop the line culture from TPS.

Continuous Integration

  • The ultimate goal of continuous integration is to be able to deploy all code.
  • Although you won’t release in the middle of a sprint, the point is to be technologically ready, even if you are not functionally.
  • With Continuous integration, you are integrating in short cycle and thus have smaller changes to deal with as you integrate.
  • Continuous integration does not make sense unless it’s automated, has a short turn around time (fast builds), and everyone owns the concept of Green Builds.
  • You need tests to fail or pass a build. Tests are the backbone that give you a green or a red light to take a snapshot of your build.

Continuous Integration- Challenges

  • Don’t force this. It requires everyone to buy-in.
  • CI also requires some setup, if you don’t have one.
  • Keeping build times short. This might require some serious effort and might show you the deficiency of your builds.
  • And you need a good version control system – VC systems like subversion that allows atomic check-in.

Test Driven Development

  • We produce well-designed, well-tested, and well-factored code in small, verifiable steps.

Test Driven Development

  • Test-driven development, or TDD, is a rapid cycle of testing, coding, and refactoring
  • Why do this: Programming is demanding. It requires perfection and consistency for months.
  • TDD cranks up the feedback on the execution of your code. Every few minutes TDD verifies that the code does what you think it should do.
  • If you do this correctly and in incremental steps you can reduce the defects in your system.

Test Driven Development

  • Benefits
  • Makes finding mistakes easy.
  • Think of double-entry bookkeeping. You express your intent twice, once with a testand another with production code.
  • All these tests are checked in and become part of your continuous integration.

Test Driven Development- Challenges

  • It will increase your effort. But should reduce effort at the end of delivery cycle.
  • If you have legacy code extra effort and time is required to place hooks for TDD.
  • The basic steps of TDD are easy to learn, but the mindset takes a while to master.
  • This is a skill and requires continuous practice to get better.

Being Agile

  • It is about the people and teams
  • It is about customer and delivering software
  • It is about continuous improvement

Stuff I read, listen

  • http://www.threeriversinstitute.org/blog/
  • http://www.jbrains.ca/
  • http://blog.objectmentor.com/
  • http://martinfowler.com/bliki/
  • http://jamesshore.com/Blog/
  • http://programmingtour.blogspot.com/
  • http://xprogramming.com/blog/
  • http://www.agilephilly.com
  • http://www.infoq.com/
  • http://www.ted.com/
  • http://thoughtadrian.blogspot.com/
  • http://blog.mountaingoatsoftware.com/
  • http://www.stackoverflow.com/
  • http://www.javaposse.com/
  • http://epistemologic.com/
  • http://elhumidor.blogspot.com/
  • http://blogs.agilefaqs.com/
  • http://sebastianlab.com/
  • http://aydsoftware.blogspot.com/
  • http://dhondtsayitsagile.blogspot.com/
  • http://mitworld.mit.edu/
  • http://ecorner.stanford.edu/podcasts.html
  • http://www.feld.com/wp/
  • Great set of essays: http://www.poppendieck.com/publications.htm
  • Presentation styles: http://www.agileopen.net/2006/PresentationZen.html


Download 12.21 Kb.

Share with your friends:




The database is protected by copyright ©sckool.org 2023
send message

    Main page