Agile Project Management

Click here to load reader

  • date post

    14-May-2015
  • Category

    Documents

  • view

    865
  • download

    0

Embed Size (px)

Transcript of Agile Project Management

  • Agile Software Project Management Sep 2006

    http://www.compuware.com/blogs/jkern/

    2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 1

    CompuwareCorporation

    Agile Project Managementor

    How to Be on Time and Within Budget!(Really!)

    V1.1

    Jon Kern

    Agile / MDA Evangelist

    Compuware

    USA

    jon.kern@compuware.com

    http://www.compuware.com/blogs/jkern/Newsletter: http://frontline.compuware.com/javacentral/straight-talk/default.asp

  • Agile Software Project Management Sep 2006

    http://www.compuware.com/blogs/jkern/

    2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 2

    http://www.compuware.com/blogs/jkern/

    About Me (as if you care) Doing software since 80s, O-O since ~late 80s

    10 years DoD consulting, real-time, flight simulation, centrifuge, fighter agility, etc.

    Formed Lightship Inc in 95, clients like IBM, Ingersoll

    First published agile method in 97

    Co-author Java Design w/ Peter Coad

    Joined Peter to form/grow TogetherSoft Sep 99

    Led OO/Java workshops, mentored hundreds

    Led development team in St. Petersburg, Russia

    Co-author Agile Manifesto, 01

    Sold TogetherSoft to Borland in late 02

    Recruited by OptimalJ Team 03

  • Agile Software Project Management Sep 2006

    http://www.compuware.com/blogs/jkern/

    2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 3

    http://www.compuware.com/blogs/jkern/

    Topics Why is building software so hard?

    Keys to Successful Agile Project Management Laying the Foundation

    Gathering requirements

    Domain Modeling

    Constructing with Architecture & Quality

    Estimation Techniques Release Planning

    Managing Risks

    Constant feedback and re-estimation

    Time boxing to meet schedules and budget Iterations

  • Agile Software Project Management Sep 2006

    http://www.compuware.com/blogs/jkern/

    2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 4

    http://www.compuware.com/blogs/jkern/

    What Makes Software Dev So Hard? Ability to meet the demands of the business

    Shrinking business cycle, need more business agility

    Clear business vision/goals for the application

    Ability to meet the demands of development Crazy schedules/death marches

    Need for application agility

    Requirements are nebulous, non-prioritized

    Striving for effective process & productivity

    Ability to meet the demands of development Deploying a performant system

    Building the app properly for the expected lifespan

    Ask yourself questions like:

    How would you characterize your current development methodology?

    Waterfall, RUP, XP, FDD, ad hoc, could be better and so on.

    What kinds of modeling do you practice?

    Answers may range from very little (napkin designs? Sketches on whiteboards?), to too

    much (RUP).

    How do you manage requirements from conception to manifestation in your

    application?

    Here we seek to understand how well you are able to meet customer needs in the end

    product. Do you try to nail requirements down with 100 pounds of documentation? Or,

    are you more agile/XP like? Are you able to easily go from requirement to design and

    implementation? Can you understand/determine the impact of a change request

    through your application architecture?

  • Agile Software Project Management Sep 2006

    http://www.compuware.com/blogs/jkern/

    2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 6

    http://www.compuware.com/blogs/jkern/

    What do we Fix? Common Problems Today

    Requirements unclear, changes cause disruption

    Poor architecture & quality, maintenance nightmares

    Late breakage

    Delaying risk mitigation

    Performance woes

    Non-repeatable processes

    Lack of testing

    Blown schedules

    Built the wrong thing

    Filled an outdated need

    Outright abrupt cancellation

    Doesnt deliver expected ROI (if it was known)

    Staff is a revolving door

  • Agile Software Project Management Sep 2006

    http://www.compuware.com/blogs/jkern/

    2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 7

    http://www.compuware.com/blogs/jkern/

    Putting Engineering into S/W Dev Applications need to be architected and designed

    not just built

    Hardware/construction engineering uses Processes/Process Improvement

    Tools (but no silver bullets)

    Standards

    Highly Skilled, licensed/certified People

    Employs System Integration concepts

    Things arent just built with no planning

    Take advantage of the soft and apply more agile techniques (that manufacturing could only dream of)

  • Agile Software Project Management Sep 2006

    http://www.compuware.com/blogs/jkern/

    2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 8

    http://www.compuware.com/blogs/jkern/

    Where We Are Headed Agile Project Management must be discussed in context

    Discuss Agile concepts

    Think about Classic Project Management as applied to software projects (estimating and conducting)

    Describe how to conduct an agile software project

    Revisit ways to manage

    Risk

    Estimation

    Scope

    Time

    Budget

    The management techniques I use require being in the right state of affairs.

    That is, there are some synergistic foundational building blocks that make the

    techniques all more effective than their singular cumulative value.

  • Agile Software Project Management Sep 2006

    http://www.compuware.com/blogs/jkern/

    2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 9

    http://www.compuware.com/blogs/jkern/

    How Is Software Built? People,

    Process, and

    Tools!

    In about that order Good people will trump poor/non-existent process

    Good people will either create tools or use tools in an effective manner

    Process and Tools cannot make up for inadequacies of the development staff

    Gray matter is a pre-requisite

    It takes good people to build quality software.

    I would sooner take a team of 10 or 20 high-quality developers and

    management that gets it over a team of 50 or 100 with an insane

    stakeholder.

    To work with a good team is a tremendous pleasure.

    Good teams:

    Will form process if none exists.

    Will create helpful tools and utilities if none exist

    Will develop communication strategies to ensure minimal rework

    Will be able to intuit much of the development requirements

    Conversely, an under-performing team with old hat management and

    stakeholders will likely fail regardless of process and regardless of shiny

    new tools.

  • Agile Software Project Management Sep 2006

    http://www.compuware.com/blogs/jkern/

    2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 10

    http://www.compuware.com/blogs/jkern/

    Agile Development A state of mind, not a set of steps!

    Shrink waterfall cycle into small iterations

    Ensure working application and feature progress

    Make it simpler to embrace change

    Improve communication between business and IT

    Deliver business valuefaster and continuously

    Running Software: Necessary but not sufficient!

    Quality & -ilities from the start

    ANALYSIS

    DESIGN

    CODETEST

    DEPLOY

    One of the keys to successful software development lies in the

    straightforward principles of agile development:

    Prefer people and communication over tools

    Prefer working software over reams of documentation

    Prefer working with customers collaboratively versus contentious

    contracts

    Prefer embracing change over rigid project plans

    The bottom line is to demand progress, but ensure it is on top of a good

    architecture. Put another way, running software is necessary but not

    sufficient (even poorly designed software can look good on the

    surface!). By always supporting frequent, tangible, working results, a

    team is able to demonstrate progress at developing features to the

    users.

    Remember, running software is necessary but not sufficient!

    Dont be fooled by running software alone

    It must be built on a good architectural foundation

    It must not incur technical debt

    It must be treated as an important asset

    Even poorly architected software can give the appearance of being

    good at the user interface level.

  • Agile Software Project Management Sep 2006

    http://www.compuware.com/blogs/jkern/

    2006 Jon Kern, Compuware. All rights reserved. This presentation is for informational purposes only. 11

    http://www.compuware.com/blogs/jkern/

    Agile Manifesto

    Individuals and Interactions

    Working software

    Customer collaboration

    Responding to change

    Processes and Tools

    Comprehensive documentation

    Contract negotiation

    Following a plan

    While we value the things on the right, we value those on the left more

    http://agilemanifesto.org

    over

    over

    over

    over

    You can read more about these principles at: www.www.www.www.AgileManifestoAgileMani