Upload
samuel90
View
870
Download
0
Tags:
Embed Size (px)
Citation preview
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
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
– Doesn’t 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 aren’t 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!
•Don’t 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.AgileManifestoAgileManifestoAgileManifestoAgileManifesto.org.org.org.org
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. 12
http://www.compuware.com/blogs/jkern/
Is Project Mgt. Orthogonal to Agile?
� Classic Project Management
– Loves detailed tasks, durations, serial/parallel, resources
– Frequently enjoys fine-grained long-term planning
– Provides (painful and tedious) tracking of task completion
– Can easily be a full-time job of mediocre activity
� Agile Development…
– Loves to do short-term planning in just enough detail
– Strives to provide accurate feedback of true goals
– Likes to do the simplest things that work
� Solution?
– Software projects need both:
� Tracking completion of prioritized features – no 90%s allowed!
� Traditional tracking and planning of
– Major milestones (releases, iterations)
– Non-feature type tasks
– Intra-project dependencies
In mid-1990s, I still clung to my use of Gantt charts – from an engineering
perspective – to attempt to run software projects. As it turns out, it did not
make as much sense to drive every activityevery activityevery activityevery activity that the team was doing (for
example, building features) into the project plan.
In most traditional projects, progress is measured through completing a task (is
the wall painted yet?). In software, progress is measured through a more
complex concept of completing a “feature” for the client to be able to use.
The best solution is to combine the power and familiarity of traditional project
management for classic tasks and for “outer loop” management with
development cycles. However, for details about what is being completed within
each development iteration, keep it simple and agile. Just a list of features
being worked on, and whether they are complete or not – no partial progress
reporting allowed, no detailed resource allocation needed, no interdependencies
necessary in Gantt. A simple list… no dependencies, nothing complicated. Items
on the list that don’t get done this iteration can slip to the next. No need to
change the project plan, however.
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. 13
http://www.compuware.com/blogs/jkern/
Manage the Right Things!
� Software is very people-intensive– Lots of brain activity
– Should not be treated like assembly line work
� Schedule and measure real progress– Feature Completion
– Required tasks to support feature completion
– Don’t mistake activity for progress!
� Empower the team(s)– Don’t micromanage, tear down barriers
– Ask for results, listen for an estimate
– Demand push-back, keep folks engaged and talking
� It’s all about the client getting features!
All too often, we can fall into the trap of being mired down in the minutiae of
project management software. We can track all sorts of tasks. We can add
resource allocations – even partial resources! We can figure out that a QA task
for Feature X has to follow the completion of Feature X – which of course was
on the heels of the “Estimate Feature X” task. This is a waste of time and effort.
If you set things up so the team knows what they are doing on a process basis
for EVERY feature, you do not need to even see a set of feature-related micro-
tasks on the schedule! There are plenty of larger issues to worry about in Project
Management to pull off a successful project. Micromanaging the team’s activity
is not one of them. Empower the teams to do their own micro managing. You
might be surprised – or you may need to find a better team!
Remember, you do not deliver the project plan to the end user… you deliver
ONLY features that work and provide 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. 14
http://www.compuware.com/blogs/jkern/
Laying the Project Foundation
� A key to managing is to get things set up properly– For requirements gathering
– For estimating
– For constructing
– For maintaining version after version
� Skip this and you are likely inefficient, probably micromanaging, and adding risk
� Simple Techniques– Domain Workshop
– Technical Architecture Workshop
– Release Planning
– Iterative/Time Box development
There is this “sweet spot” term we use in engineering. It means that you have
looked at many aspects of the overall goals, the various solutions, and have
weighed the pros and cons of each to determine the best approach for the given
constraints. Imagine passenger aircraft design… if I want to carry more people, I
make the plane bigger. If I want to make the plane fly at supersonic speeds, I
make the (vertical) cross-section as small as possible. If I want to fly half-way
around the world non-stop, I have to be very fuel efficient and carry enough
fuel… Engineers know the value of doing trade-offs, the same is true of doing
software.
Therefore, I present some ways in which you can approach doing software
projects. The intention is to arm you with just enough of a foundation such that
your project is more likely to succeed than not (far be it for me to challenge the
ability for some teams to fail regardless of how hard they might try). By
describing the foundation, the reasons behind it, and the resultant use of the
various artifacts, you will see how my simple project management techniques
can come into play.
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. 15
http://www.compuware.com/blogs/jkern/
Analysis
Test Design
Code Deploy/Run
AgileAgile
Development
#3
Three Keys to Software Dev Success!
#2
Point of Sale System Product System
Cashier
Inventory System
Scan Productor "Identify" Product
Total Items
Take in Payment
Credit
Check
Debit
Price Lookup
Determine Tax
Update Product Count
<<include>>
<<include>>
Right-click, choose "Hyperlink To" menu, select the hyperlink and watch what happens.
<<moment-interval>>CashSaleThe entity
<<ui-component>>POSFrame
The std cashier UICashier
SaleDM(The database)
makes a sale
lnkSaleDM
Please refer to Doug Rosenberg's book on "Use Case Driven Object Modeling with UML"for more information on Robustness Diagrams.
Application Arch. Technical Arch.ActionServlet
...ControllerServlet...ControllerServlet...ControllerServlet...ControllerServlet
EJBContainer:JBoss
EntityEJB:BudgetCenter(optional)
SessionEJB
LegacyCobol,IMS, etc.
Request
Response
Client:PC
Browser(IE)
DBMS:Solid
WebContainer:Tomcat
ControllerServletControllerServletControllerServletControllerServlet:ControllerServle:ControllerServle:ControllerServle:ControllerServletttt
View(JSP)View(JSP)View(JSP)View(JSP)
BusinessInterface
BusinessDelegate If both containersare on one server(e.g., WebLogic),better performancecan be achieved.
Working App!
Dual Architecture
Construction Guidelines
Separation of Concerns
#1
User Interface
Business/Problem DomainBusiness/Problem Domain
PersistencePersistence
DBDB DB
Legacy/Ext. SystemsLegacy/Ext. Systems
SynergySynergy
There are Three simpleThree simpleThree simpleThree simple best-practices that can help you meet your
challenges: Separation of Concerns, Dual Architecture/Construction
Consistency, Agile Development.
These principles, when applied, yield such advantages as:
•Improved time to market
•Apps that hit their target the first time
•Greater business agility
•Reduced maintenance
•On time and under budget delivery
•Quality architecture
These are the core principles embraced by and embodied in OptimalJ.
Anecdotal Aside:
It is rare to find a problem in an existing application/development project
that can’t be traced back to having not followed one of these three keys.
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. 16
http://www.compuware.com/blogs/jkern/
SDLC–Development Overview• Determine the feature set, domain model, technical approach to make an estimate
• Create release plan for next version + general roadmap
Inception
Develop
Deploy
Maintain
Sunset
• Develop iteratively• Continuously visible progress
Just to put forth a common look at a typical application’s life cycle… The point
here is that there is usually some sort of “Inception” phase where folks decide to
do a development project and have to think about ballpark estimates, feature
sets, driving vision behind the application idea, etc. These efforts can be
smushed into the front of the Development phase… but it is not the point to
manage the macro-process here. Similarly, within development, there are
multiple trial “deploys” to ensure the app is being built properly.
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. 17
http://www.compuware.com/blogs/jkern/
Inception Process
� Upfront Practices– Provide the basis for reqts
and development
– Allow for estimations
– Get you started on the right foot
� Can also do this as part of initial Development…
� Do to enough depth to geta “good enough” estimate
� Do spikes/POCs if needed
DomainWorkshop
TechnicalWorkshop
• Requirements• Architecture• Release Plan
What you call it is not nearly as important as doing it!
The point here is to gather enough requirements to make an appropriate start
at the project. This includes being able to estimate, have an idea of what the
first release will look like, and to know how you will be building the application.
Your major goal: flatten—or at least identify—the risks in the project. For
example, you may identify a technical architecture risk, or a complex business
requirement – feel free to call for more exploration (a “spike” or a “POC”) such
that you can improve the likelihood that your estimates are accurate.
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. 18
http://www.compuware.com/blogs/jkern/
Domain Workshop - Purpose
� It is critical to set the tone and direction for the project from the business/problem domain perspective.
� Derive a set of features to help paint the picture of whatthis product has to accomplish
� Solidify the vocabulary of the project
� Create classes in the domain model
� Enable derivation of estimates for – scope, cost, and schedule
� Enable an efficient development phase.
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. 19
http://www.compuware.com/blogs/jkern/
Domain Workshop – Artifacts
� Business definition, problem statement, vision document
� Feature set, roughly prioritized
� Domain model (initial cut)
� Technical architecture drivers– Addresses “non-functional” project aspects (e.g., performance,
security, availability, maintainability, quality, life expectancy of app)
– Allows you to understand how development will occur
� Estimate of development schedule and budget
� Cost / benefit analysis (by the stakeholders/business)
Naturally, the artifacts will vary to suit the nature of the project, the culture of
the company, etc.
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. 20
http://www.compuware.com/blogs/jkern/
Technical Workshop - Purpose
� Define and resolve any “risks” for the non-functional requirements; for example:
– Performance, security, availability, maintainability, quality, life expectancy
� Define architecture to enable accurate work estimates
� Prove architecture meets the needs of the project
� Discuss/set-up the reference architecture, build process, environments to enable team to begin
– Development and QA
– Test/performance benchmarks
– Production
� Determine integration/external touchpoints
� Can be in parallel with Domain Workshop
Sometimes the app you are building is just “another one of the same genre.” In
such a case, this step is less about determining a suitable architecture and
more about simply ensuring you have everything in place to enable the team to
“hit the ground running.”
When you have a very unique and demanding set of non-functional drivers, this
workshop/project becomes crucial. You simply cannotcannotcannotcannot begin to allow
development to occur without ensuring you have explored an architectural
solution and have built a reference implementation to prove it out. Once you
have the architecture, the “masses” can now begin to do iterative development
in a consistent manner (for each feature), following your architectural
guidelines.
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. 21
http://www.compuware.com/blogs/jkern/
Technical Workshop - Artifacts
� Working application (thin slice) to demonstrate arch.
� Or, enough small pieces of architecture proven out such that the next step could be to finalize the initial architecture
� Typically documents like:– Architecture vision
– Things we chose not to do (and why)
– Object models
– Sequence diagrams
– Deployment diagram
– Performance test results to prove goals are met
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. 22
http://www.compuware.com/blogs/jkern/
Where Are We?
� We have a domain model
� We understand the architectural approach
� We have a rough list of prioritized features
� We have uncovered risks and accounted for them or dug deeper until we could…
� We have a feel for the effort needed to build the app (not just development, but integration, testing rigor, deployment complexities, database loads, etc.)
� We are now ready to generate an estimate for the first “version” of the application!
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. 23
http://www.compuware.com/blogs/jkern/
Release Planning – Purpose
� Discuss/determine project estimates
� At a high level, define the “must haves” and “high priority” items/features to make a release
� (Re)Prioritize the features
� Determine a realistic 1st-pass product roadmap
� Evaluate the need for a technical spike or a feature exploration spike to reduce risk
� Consider issues like integration with other systems, deployment, rigor required for quality assurance
� GOAL: Arrive at a schedule, resource, and cost estimate
Given the list of roughly prioritized features from the Domain Workshop, take
another pass and determine what will constitute a release. Typically, this should
be the minimal set of features needed such that the delivered application can
begin to provide the stakeholders/users with some business 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. 24
http://www.compuware.com/blogs/jkern/
Release Planning – An Iterative Process
� Run through the prioritized list of features– Estimate the total cost (time for dev, test, deploy)
– Indicate confidence level (H/M/L) to act as a multiplier on estimate (1,2,3; 1,3,9)
� “Negotiate” on features and priorities based on– Cost of the feature based on possible variations
– Logical groupings based on construction efficiencies
� [optional] Additional separately-priced explorations into the details of the features– For complex, poorly understood high-value features
– For technically challenging features
Determining the schedule estimates is best done on an iterative basis – of
course, pretty hard if you are creating a fixed bid for an RFP and can’t speak
with the stakeholders or users.
Just because a client asks for a feature doesn’t necessarily mean that it has to
be blindly answered. Sometimes you need to help the client ask for the right
things to solve their true business needs. Also, it is the development team’s
responsibility to not only give a feel for the price of a “feature” but to also offer
up some alternatives. That is, variations on a theme – especially when the
feature is costly and there could be some subtle changes to the feature that
result in significant reduction in cost and time.
If you have a need to do some initial phases of the project aimed at reducing
risk and accelerating a good solution, then you can break the project up into
phases and separately estimate each. NOTE: you will also reserve the right to
refine the subsequent phase estimates – this is the whole point. You want to
explore, reduce risk, and re-estimate the following phase(s). This is similar to
continuous re-estimating as you actually build the product via each iteration.
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. 25
http://www.compuware.com/blogs/jkern/
Release Planning - Artifacts
� Overall Roadmap with Release 1 in enough detail to drive the initial development iterations
– Release Plan
� Feature List in the order of highest to lowest priority
� Rough Iteration plan – at least for the first few
� Integration plan with other systems
– Rough Acceptance Test Plan if needed
– Deployment Plan
– Budget Estimates
– Schedule/Timeline & Resource Estimates
� Tailor the plan(s) to address/estimate known efforts
� Create a project plan as required!
The artifacts of the planning process should meet the needs of your culture,
stakeholder, and development team.
The project plan – if you need one – should have traditional milestones for
releases and iterations, plus non-feature-related development tasks, integration
with other projects or teams, and so on.
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. 26
http://www.compuware.com/blogs/jkern/
The “Iron Triangle” of Development
� Client– Can specify any 2 of the 3
– Cannot specify all 3
� Development team dictates “cost” of a feature (time and resources)
� Management cannot at once:– Dictate features,
– Fix the number of resources, and
– Dictate a completion date
� Planning is a group effort
� Goal is to be as “honest” as possible with the plan
Sco
pe
Schedule
Resources
During the planning process, it is critical to note that software development is a
team effort.
The management cannot dictate how much and when the team will produce the
features. Similarly, the team cannot dictate the feature order, or blindly allow
the client or manager to not understand trade-offs and costs.
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. 27
http://www.compuware.com/blogs/jkern/
Where Are We?
� Now we have our release plan!
� We have our domain model
� Good foundation for coding– Reference/working example of architecture
– Automated build scripts
� Next we need to start!– Iteration #1 is a good place!
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. 28
http://www.compuware.com/blogs/jkern/
The Feature List
� A simple linear list of requirements
� Prioritized, controlled by client’s needs– Can easily change over time
� Work from the top down each iteration
Rel
ease Ite
ratio
n
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. 29
http://www.compuware.com/blogs/jkern/
Iteration – Purpose
� Each iteration builds a discrete set of features
� Defines the “when” for delivery of features
� One or two weeks long (malleable)
� Delivers working features to the build / QA
� Demonstrates tangible progress
� Gets early feedback from client / Product Mgt.
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. 30
http://www.compuware.com/blogs/jkern/
Development “Tasks” to Plan & Track
� Feature– Client-valued
– Can be enhanced, changed, potentially removed
– “Precisely-defined” to know when you are done
– Can be scheduled, assigned and estimated
– Can be used as Marketing bullets
� Task– Piece of work to be done, usually once
– Can be scheduled, assigned and estimated
� Defect– Some sort of error
– Is related to/against a feature
– Can be scheduled, assigned and estimated
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. 31
http://www.compuware.com/blogs/jkern/
Iteration Planning
Development Process – An Iteration
� A rough overview
� Plan an iteration– From top of prioritized
feature list/bugs
– Choose only as muchas you can build
� Implement– Code & QA Tests
� Works?– Pass tests local, check it in
– Pass tests on build machine…
– Close the issue!
Deploy
ForEach Feature
Write UA Tests
Review Reqts& Estimates
Select Features &Defects
Implement
Pass ?No
Yes
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. 34
CompuwareCorporation
Conclusions
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. 35
http://www.compuware.com/blogs/jkern/
Risk Management
� Much of what we do is all about managing risks:– Requirements being incorrect
– Code not working properly
– Delivering late
– Deployment / integration issues
� Agile – as a state of mind – is also all about managing risk
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. 36
http://www.compuware.com/blogs/jkern/
Habits of Successful Projects
� Embrace and empower quality people
� Do enough up-front modeling and architecture to create defensible estimate
� Employ an iterative process with stakeholder involvement
� Use tools to automate tasks: req’ts., codegen, daily builds (continuous integration), gathering metrics, and QA
� Measure demonstrable features via working code
� Always use an agile state of mind
� Recognize what you don’t know, mitigate risks, collapse timeframes, continually question and improve!
� Slip features, not dates
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. 37
http://www.compuware.com/blogs/jkern/
Always Meet Budget and Schedule!
� Use a technique known as Time Box– Agree to a list of features, more or less,
– A timeframe
– A budget
� Client understands that features lower on the list might get bumped, or they may be able to add features
� The point is simple: the flexibility is in the feature set, not the date or the cost
� Slip features, not dates!
� Need something unforeseen? – No problem, add it in. But take something out!
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. 38
CompuwareCorporation
Great! So how do we start?
What does an agile MDA project look like?
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. 39
http://www.compuware.com/blogs/jkern/
How it Works in PracticeR
elat
ive
Par
tici
pat
ion
By T
ask
Development Cycle Duration / Time
Model the Business (Appl. Architecture)
Create Technical Architecture(Or re-use existing)
Work out Appl. Details (Coding, UI, Integration)
Continuous Integration and Testing
Design the technical
architecture
Each Iteration/ReleaseWork out ‘N#’ of features to be delivered.
Work out breadth of application’s features
Conduct verification of high-risk issues
(as often as needed) OptimalTrace, OptimalJ, DevPartner, QA Center, Vantage,…OptimalTrace, OptimalJ, DevPartner, QA Center, Vantage,…
Typical application life cycle might look like this.
Technical Architecture.Technical Architecture.Technical Architecture.Technical Architecture.
An application must have a technical architecture upon which features are delivered. This could be in parallelparallelparallelparallel with initial
application modeling, or be done prior to the application’s start (serial). In general, you might build many applications
with the same technical architecture. Or, if you have software as a product, you usually stick with a given architecture
for a year or two of releases.
OptimalJ provides an initial technical architecture out of the box.
Business ModelBusiness ModelBusiness ModelBusiness Model
To properly build an application to meet the company’s current and (more importantly) future needs, it must be
architected around the specific Problem Domain. To ensure the application development is off to a good start, the
“breadth” of the application should be modeled in terms of the business. Sometimes this is based on a set of pre-
defined requirements (features). Other times, the act of modeling is effectively used to elicit the features. This helps to
shape the size and direction of the application architecture, plus it generally provides a glimpse into the overall ultimate
scope – even if you are just implementing a small slice in the current project.
OptimalJ provides the required focus on modeling the business aspects of the application.
Iterative DevelopmentIterative DevelopmentIterative DevelopmentIterative Development
Once the breadth of the application is modeled, and a great features list is available (and prioritized), the top features
(and/or riskiest) can be implemented in the first iteration. For each iteration, the domain model may be revisited and
more specific details added.
Application Details Application Details Application Details Application Details –––– IterativelyIterativelyIterativelyIteratively
Beyond the additions to the business model, the application details might involve some rough user interface design,
database modeling, integration with other systems, and other necessities to get to a working application. Often,
methods may need to be written, and other dynamic behavior addressed.
OptimalJ makes it easy to focus in on specific feature areas of the application via the focus on the domain model.
Continuous Integration & TestingContinuous Integration & TestingContinuous Integration & TestingContinuous Integration & Testing
To improve the quality of the application, it is critical to be able to always produce running code. Most successful teams
have daily build procedures, some even more than one build per day! The idea is to always strive to have running
software and automated tests to help find errors early in the process. At the end of each iteration, a complete, working
application is the deliverable, with the chosen features implemented.
OptimalJ provides such an environment within which to conduct iterative development.
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. 40
http://www.compuware.com/blogs/jkern/
Continuous Integrated Testing
� Test early, Test often…
� Test via Automation, Test With Confidence!
� Three Components to the Process
– Collection
– Analysis
– Remediation
� Increased number of test cycles per project
� Low Resource Overhead
– Tests are fully automated and can be run unattended, offering minimal distraction to Developers.
Planning Iterative Development Formal QA Production
Go Live ?
Continuous Integrated Testing
Test Cases
Compuware’s Continuous Integrated Testing solution brings together two
areas of testing into one process that is more efficient and allows more
testing to be performed more quickly and more accurately and detect
coding mistakes and coding logic much earlier than before. The two
areas are line-of-code root cause analysis (extended debugging of code)
and automated testing of software components.
Line-of-code root cause analysis is where a developer profiles their code
with Compuware’s developer productivity tools. This enables the code to
be assessed for memory leaks, poorly designed code, code coverage,
poor performing code, and even security vulnerabilities.
Automated testing of software is the ability to capture manual testing
efforts into a re-usable and repeatable script that can be executed
whenever needed.
Pulling these two areas together into one solution allows not only testing
to be automated, but if a defect is found the ability to trace that defect to
the exact line of code that needs to be modified to correct the defect.
Also, Compuware’s automated testing solution can uniquely offer the
ability to test code components without the need for a GUI front-end to
call the component. With application components typically being
developed first in a software project, and the application GUI front-end
being developed later, this unique technology means that automated
testing can begin much early than has ever been possible.
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. 41
http://www.compuware.com/blogs/jkern/
Wrap-up: 3 Keys to S/W Development
� Separation of Concerns
� Construction Consistency/Dual Architecture
� Agile Development Environment
� What will you do on your next project?
� Remember, it’s all about the business!
Think about how your team gets software built…
•Do you have a notion of the Problem Domain Model, clearly
separated from the UI or persistence layers?
•Do you attempt to lay down some guidelines for how developers
should produce code in specific instances?
•Do you demonstrate progress through running software?
There are Three simpleThree simpleThree simpleThree simple best-practices that can help you meet your
challenges. We’ll cover these in the next slides.
These principles, when applied, yield such advantages as:
•Quality architecture
•Improved time to market
•Apps that hit their target
•Greater business agility
•Reduced maintenance
•On time and under budget delivery
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. 42
http://www.compuware.com/blogs/jkern/
People and software for business applicationssm
Thank [email protected]