BarCampBlock : BarCampBlockSessionNotes
What's Agile development and how do I know that I'm doing it?
Covering the fundamentals of agile development
Fascinated by extreme programming by Kent Beck (sp?)
SOcial text does a hybrid -- Agile styles of XP, scrum, -- No one right way to do it.
Social text does change it around a bit a lot b/c they're a collaboration company
THere is NO MAGIC BULLET
IT's hard to write software -- STill hard to specify software -- Agile helps, but it's the most complex artifact of human civialization --- New style isn't going to solve it all.
What problem is agile trying to solve? kredyty mieszkaniowe wino kredyt mieszkaniowy sprzedam mieszkanie sprzedam bilet
Can't do big design upfront and do waterfall development -- Do it fast -- Fail fast.
Agile Manifesto -- Google it
INdividual responsibiilty -- trust -- ego is programming, a short set of fundamental principles
Better to find out sooner than later
Quick reviews and iterate a lot
There is some reeducation that goes on -- and it's with the customer -- Customer becomes a pig... Challenge in big orgs -- Put the customer at arms length,
They used to want to throw requirements over the wall and walk away and not be involved every two weeks.
If you're building something compltely new -- then it's hard to get someone to come in every 2 weeks.
How can you get customer to get that investing w/ this type of agiles dev?
If something for the general market -- Customer means something that represents the interst of the customer than cusotmer themselves
Need user-centered perspective
2-3 week sprint -- how does a UI be involved -- It is preceeded and drives the dev process
In terms of Buyers and sellers -- dev for customer -- does that mean buyer? Not much more commitment than money...
Diff between user customer market --
PPl who use it are not the same who pay for it.
As a buyer -- only criteria is quality -- and doing what I want.... But those are different.
Only enterprise apps? No, we're not.
Software -- Find it -- Buy it -- And then users use it
What customer wants -- Health -- privacy -- software needs quick training curve -- that's a product differentiator
What's missing w/ most software that she uses and others -- How long it will take it'll take actual user to get up to speed w/ it
The key to that is -- You have to design the app that is easy to learn b/c it does things in the right / intuitive way
User story ...
Some basic terminology now...
1.) Use case
2.) Story
3.) Priorities
4.) Iteration
5.) Daily SCRUM / Standup
6.) Retrospective
Customer
Backlog
Iteration -- Sprint -- set of time -- Set a time 2 weeks. Get something that runs or works
Set the increment time, start a fresh set of tests -- get something that works -- whatever doesn't work gets pushed down to the next cycle -- Make it small and manageable
Ordering -- Storytelling and Usecases are a huge part -- NOT WATERFALL. not a series Not a huge chunk. Supposed to be small
WHat are the use cases? Register a new patient. Resolve name conflicts. Enter X in Y way. Envision actually using the thing.
"Use cases" LEAD to "stories" -- A story is a short story of a concrete action of what needs to happen. Stories are in natural language
Stories drive priorization & customers get nervous when you ask.. What do you want us to do first. Think hard about cost and how long it'll take. Real customers will never want to give you half of the list.
Most software projects fail -- 50% of it gets thrown away.
Write the priorities on Post It notes and argue it out. Gives an appreciation to the entire team what is important and what isn't
Teach each other what is important -- intitively easy -- to develop it may take a week, but the test may take a month. So you have to hash it out as a team.
How do we break this project down into managable chunks? We think we can do 2-3 issues at a time. Define what is going to be working at the end of the time set.
Once you have the backlog -- criteria is passing the test
What's the first step that you can take in order to get something tangilble done?
What's problems w/ Software vs. Real World architecture -- Real architects can't build roofs before they build walls. Software can, and so it is easier for software to collapse and fail.
So using real world architectular analogies is very useful in communicating agile development to real customers. Dig holes, build foundation, etc.
Individual backlog items -- stuff that still needs to be done ever -- tasks that you know about -- negotiate w/ the customer what needs to done.
You need a dedicated designer for agile to really work.
Everyone agrees what needs to be done after negotiate, have daily quick check ins with progress -- "I need help on X" -- This is what I did yesterday... Well I already did that....
At end of iteration, you have a demo for whomever is representing the customers interest -- Then do a retrospective of what works well, and what didn't work. You learn who's fast. Who's slow. Resources, etc. Can then plan better in the next sprint. W/ team continuity, then they can be a better guage of it.
Standup is a meeting where people are standing up -- b/c it should be short -- 15 minutes for everyone -- Big issues are taken offline.
SCRUM: Rugby term -- intensive huddle where the get together quickly. Only 3 issues are addresses: What did I get done yesterday? , What can I get done today? WHat's in my way from getting it done now? Everything else is taken offline.
Refactoring can be done quickly if you have a good test suite.
Ideal world -- "Test" is an exit criteria for a developer. When is done "done"? At the end of the iteration, you complete what you were supposed to do for this. Be sure that the story has everything that you need to do.
No such thing as 90% done in software dev. Either it's done or not. There's always one more edge case, one more bug Voltaire: Best is the enemy of the good. What is this iteration doing?
PAIR programming is often tied to Agile -- comes from XP -- Pair = 2 software devs. No code is written by a single dev. It's written in tandem by screen sharing. 2 pair of eyes.
Join senior and junior programmers for mentoring. But also senior programmers from different realms.
You either have to drink the Kool-aid w/ Agile -- or you have to suffer enough with your current way that you try Agile... But there is a middle way though. Exceptly for the zealot PAIR XP programmer, you don't PAIR program "everything"
PAIR programming is literally working side by side -- sometimes virtually. Both ways think they have evidence that their way is better. Ppl have experience and evidence that it is faster and more efficent to have 2 eyes
The single coders and their code -- often time their code was obsolete by the time that they got done.
If you love your work, and you work on something that gets thrown away, then it's heartbreaking and the team breaks up. They have a deep commitment that the code is thrown away and they feel like they've failed whether they have or not. You loose good and bad people when that happens.
Be transparent -- be brave enough to say it's broken. If you can't hear that people have problems that they need help, then you'll deal w/ it later.
If management can't hear bad news early, then they deserve what comes.
