This was presented by Ken Sipe from Perficient. It basically covered how to get Agile accepted into a business, starting out with the first iteration and what it all includes. Overall the presentation was great, but he was a little scatter brained in actually presenting it. It didn’t flow very well as it felt he was jumping back and forth quite a bit.
- Talked about waterfall development being the standard way companies generally tackle development.
- Iterative process’s biggest usefulness is the feedback. But companies don’t like it because they can’t plan long, long-term goals of when things will be delivered. Since priorities can be shifted around, knowing what will be delivered is nearly impossible.
- Talked about college experience when finding out you have a paper due in 3-6 months. Most people finish it the night before/week before/weekend before. When the instructor requires certain aspects of it at given points throughout the course, it’s an iterative approach. You get feedback from the instructor earlier and can make the paper that much better.
- Similar approach with the NASA Apollo missions.
- Finding the iterative length is really about what feels right for the company. Longer iterations means less feedback. Shorter iterations means not being able to get things done.
- Iterative delivery helps develops trust between the development staff and the business. Building the trust is essentially actually doing what you say you’re going to do.
- Agile is not evolutionary, no documentation, no architecture, cowboy development.
- Pair programming is extreme of code reviews.
- Programming engages the logical side of the brain. Taking a break causes it to disengage and lets the creative side tackle the problem. Pair programming allows a full brain to tackle a problem.
- Pair programming is actually about 1.5 develops worth of work, not just 1.
- “Bus Number” – the number of people on the project that need to be hit by a bus before the project can’t continue forward because expertise is gone.
- Agile at the micro view:
- Initial opening meeting
- *everybody* is there to make sure everybody’s on the same vision of the project.
- Agree on acceptance criteria
- Agree on the priority
- Break down into groups to figure out what some resources already exist or come up with estimates
- Opening meeting
- Should be attended by Developers, DBA, User/BA, Architects, QA
- Using a BA or having limited contact with the user, generally a failing point is not meeting the acceptance criteria.
- Assign tasks.
- Standup Meetings
- Can be sabotages by the Project Manager because they’re trying to get and provide too much information.
- Only pigs are allowed to talk. Chickens don’t talk.
- Closing meeting
- What was accepted by the user?
- What is the velocity?
- What architecturally significant has changed?
- It is a quality check of general
- Were the estimates accurate?
- Is the team performing as expected?
- Is QA catching bugs that weren’t functional bugs?
- Are functional bugs making to QA? Are the unit tests not being that effective?
- Agile at the macro view:
- Starting is the hardest part. Having a mentor who’s been through it is the greatest point
- Pre-iteration 0
- Project inception
- Stake holder level
- Business opportunity/concerns
- Collection of stories
- Estimating ROI and project justifications
- Building up team/resources
- co-ownership of code
- prepared to steal tasks
- pairing capable
- expected velocity. Adjust story alignment and release plan.
- Team phases:
- forming
- excitement/optimism
- storming
- resisting task, disunity
- norming
- constructive criticism
- performing
- self directed
- iteration sizing
- initial list of risks
- release plan
- iteration 0
- 2 store development approaches
- Majority of the stories upfront with the major understanding that you will likely discover more
- sone stories upfront to prime with the intent that you’ll have a trailing analyst
- Either approach needs an Analyst, BA or PM to keep feeding stories into the next iteration.
- Automate as many things as possible. Not just in software, but bringing on new people to the team. Take out as much manual work to a simple button click/one command line.
- Perform some spikes to learn about the new tools for the project
- Build system/continuous integration is a necessity.
- Set up reporting: burn down charts
- Get a story reposity/wiki going
- The general standards, annotations, and upfront patterns (MVC, presentation model, logging in all aspects…)
- feature slip are those features that don’t get completed in an iteration, but were meant to be part of it. Similar to RUP’s time slip.
- If you have humans doing regression testing, you will fail.
- Talked about different options in working with QA in the iterations. Will post pictures later.
No comments:
Post a Comment