Академический Документы
Профессиональный Документы
Культура Документы
varied strategies.
UI User Interface
DB Database
have been gathered, but by how much • The bottom team expects to get
running functionality has been designed, almost 20 percent completed and
Planned
Actual
burn-up charts, as in Figure 2, which Alert readers will notice that these
Part attachment
shows the expected versus actual integra- tickmark drawings capture the vertical
File attachment
Failure diagnosis
tion of a set of workflow components by axis of the burn-up charts at the IR
month. times.
Agile burn-up charts are very similar These small diagrams let different
Jan Feb Mar Apr May Jun Jul Aug
Figure 2: Burn-Up Chart to traditional earned-value charts with teams work in different ways and report
expected versus ideal progress. one crucial exception: The team only gets on their intentions. This is our goal.
Figure 2: Burn-Up Chart
credit when the features are integrated
into the full code base and the result Expected Versus Ideal Progress
In Figure 1, the three vertical rectangles passes testing [3]. This single chart shift Intention-Completion Bars
System Structure
indicate applications – the items bought makes a big difference in the reliability of Figure 4 adds to Figure 3 the work actu-
separately for end-user functionality. The the progress data presented. ally completed compared to the work tar-
seven horizontal rectangles indicate ser- Burn charts show more than we need geted for any point in time.
vice components needed across applica- and take too much space for governance In Figure 4, the taller vertical bar
tions – on the user’s desktop or the back oversight purposes. To reduce their size moves from left to right within each IR
end. Two of the horizontal components and information, we use the idea of an period to show the current targeted
cross in front of the applications to indicate internal release (IR). accomplishment. It can run at a constant
that the horizontal component contains a A team that cannot deploy its system rate within each period according to the
specific, different functionality or data to live users every few months can pretend calendar, or it can be synchronized with
for each application. Domain databases to deploy the system. It can test, inte- the team’s iteration plans (two- to six-
that get extended for each new applica- grate, and deploy the system to the com- week planning and tracking time win-
tion are likely to be among these applica- puter of one or two friendly but real users. dows). The shaded rectangles show the
tion-specific, back-end components The team thus exercises the end of their functionality (RTF) completed and inte-
(more on this later). development process and gets true user grated to date.
The system shown in Figure 1 is fairly feedback. Putting the system in front of In Figure 4, we see that the top team
simple. The first project for which I drew real users (as opposed to a test machine is delivering according to schedule, the
this graphic had 17 horizontal and 15 ver- in the basement) motivates the develop- middle team is a little behind, and the
tical components, and additional coloring ment team to take their work seriously. bottom team still has not finished the
to show legacy components that were to Such an IR should happen every one, work scheduled for the second IR.
be removed over time. We were still able two, or three months. There are many Two comments must be made at this
to draw it legibly on legal-sized paper. reasons not to deploy fully every three point about RTF. The first is that not all
months, but there is almost no reason not final deliverables consist of features that
to carry out an IR. These IRs fit neatly run. Content databases and end-user doc-
Although incremental development has into a monthly or quarterly reporting umentation are examples. Teams can cre-
Intended Strategies
been around much longer than the agile mechanism. ate intention-completion bars for what-
movement, the question of how to show With RTFs and IRs, we are ready to ever their final deliverables are, since
different incremental strategies for gover- capture various development strategy or those bars show growth of accomplish-
nance purposes – preferably in a small strategies that might show up on an ment over time.
incremental development project. The second comment is that mea-
Figure 3: Target Progress Markers In Figure 3, the vertical tick-marks sures not tied to RTF are naturally haz-
show 10 percent units of completed RTF ardous since it is so easy to start tracking
from left to right (100 percent complete completion of artifacts that do not
at the right). The triangle milestone directly get bought by customers. Linking
markers show the amount of RTF the accomplishments to RTF makes the
team targets to have completed and inte- reporting of actual value both easier and
grated at each IR milestone. Figure 3 more accurate.
shows three teams’ strategies as follows:
Figure 4: Intention-Completion Bars • The top teamFigure plans to4:get
Intention-Completion Bars
less than 10 Application-Specific
Figure 3: Target Progress Markers percent of its functionality in place in Horizontal components such as applica-
Components
the first IR, and to add functionality tion databases require new work and new
in roughly equal thirds after that. content for each new application.
• The middle team intends to get 25 Progress on these application-specific
percent done in the first quarter, 60 horizontal components is typically diffi-
percent by the end of the second cult to report on since where they are varies
quarter, and almost 85 percent from application to application.
Project/ Sub- Owner Percent Done in Total Units Confidence
14 Component
CROSSTALK The Component
Journal of Defense Software Engineering IR1 Size in Estimate February 2006
(L, M, H)
IR 1 IR 2 IR 3 IR 4
A Governance Model for Incremental, Concurrent, or Agile Projects
serve. This lets the teams move at differ- Desktop frame Mr. A 0 20 80 100 30 UI widgets Med :-|
ent speeds as suits their particular situa- Desktop APIs Mr. A 20 50 80 100 60 API calls Lo :-(
tions, and allows the steering committee
to see each team’s status. App 1 UI Mr. B 5 60 90 100 450 UC steps Lo :-(
App 1 app Mr. B 10 60 90 100 450 UC steps Hi :-)
App 1 bus svcs Mr. B 5 50 80 100 450 UC steps Lo :-(
Let us review the elements of the graph-
Summarizing the Graphic
DB 1 setup Ms. C ?? Lo :-(
ic briefly: DB 1 App 1 Ms. C 60 codes Lo :-(
• The rectangles represent components,
DB 1 App 2 Ms. C 10 codes
subsystems, or applications. Vertical Lo :-(
vices. The horizontal rectangles run- mates: “We expect somewhere between
IR 1 IR 2 IR 3 IR 4 (percent) (units) (units)
created for each component. They every few months can The initial rough-size estimate is still
show the percentage of RTF intended Table 2: Summary Spreadsheet
useful for getting an early handle on the
for completion at each IR milestone, pretend to deploy the size and shape of the thing to be built.
the expected and the actual current That is why the information is collected
accomplishment, and the alarm level. system. It can test, even when the confidence rating is low.
Intention-completion bars are created Marking a low confidence rating is useful
for each component and for each integrate, and deploy to the project leaders because they can
intersection of application-dependent then raise the priority of getting enough
components. the system to the information to improve the confidence
level.
computer of one or two Needless to say, the estimate should
be updated at the start of successive iter-
Collecting the Information
The information rendered in Figure 1
also fits into a spreadsheet, a more useful
friendly but real users.” ations with raised expectations about its
place to keep it while gathering and accuracy and confidence levels.
updating the information. We can use To capture the of what for tracking, we Table 1 shows a spreadsheet that can
automated tools to gather information need three pieces of information. The be used to capture the estimates. Note
about each component every week or first, “What is the unit of accomplish- that the confidence rating is accompanied
two, and roll up each team’s accomplish- ment?” often consists of use cases, or by a smiling, neutral, or frowning face to
ments into reports at various levels. The more likely, individual steps in use cases. visually tag this important information.
highest level is the one that gets painted Sometimes something quite different is
onto the graphic either by hand or auto- appropriate. A desktop component might
matically. (The graphic can be generated have as units of accomplishment user To tag the timeline, we need to give each
Gathering the Status
automatically using graphic markup lan- interface (UI) widgets (frames, pull-down iteration or planning window a milestone
guages, but that programming effort may lists, buttons) and interface calls used by number such as an IR completed then
take longer than simply coloring the bars the applications. A database might have followed by iteration completed. Thus,
each month). entities and attributes, a Web site might milestone 0.3 means the end of the third
have articles and images, a medical data- iteration before the first IR, and mile-
base might have medical codes as a unit stone 2.1 means the end of the first iter-
It is one thing to say, “We intend to be 20 of accomplishment. ation after the second IR.
Gathering the Estimates
percent done after the first internal The second piece of information is, After iterations, the teams send in
Project/ Sub- Owner Percent Done In Total Units Expected Expected Actual
Component Component Size at IR 2.3 at IR 2.3 at IR 2.3
IR 1 IR 2 IR 3 IR 4 (percent) (units) (units)
the header: design fully complete in the second quar- to reflect and report on what happened
• A status/targeted/deferred and risk ter. They plan to get perhaps 10 percent during the reporting period.
snapshot for each section of work of the programming done in the second The first section describes the sur-
within the component. quarter, and the rest done equally in the prises discovered. On projects I have vis-
• A commentary, including surprises third and fourth quarters. ited, these have included the program-
and lessons learned during the previ- Figure 6 shows a strong concurrent mers not getting as much done as expect-
ous period. strategy. This team plans to get not quite ed, a piece of technology not working as
• Cost roll-up information. a third of their requirements settled in expected, or, conversely, a new practice
The most unusual part of this status page the first period, and to have nearly as such as daily stand-up meetings being
is the way in which the intention-comple- much UI design and programming done effective.
tion bars are constructed to describe the as requirements gathered. The require- The second section describes the
strategy and accomplishments of non- ments people will lead the UI design peo- lessons to be taken out of the period’s
RTF work. ple by a small amount, and the UI design work. These might include multiplying
people will lead the programmers by a developer estimates by a factor before
Intention-Completion Bars for small amount, but otherwise these groups committing to them, doing technology
will run parallel to each other. They spikes before committing to technology,
When someone sees a component intend to continue in this fashion or choosing to keep the new, daily, stand-
Non-RTF Work
marked with a high-alarm status bar on throughout the entire project. up meetings. These must be truly lessons
the summary page, they will naturally In this article, I do not wish to indi- learned within the period, not speculations
cate that either approach is superior to on what might work in the future.
Figure 5: A Sequential Development Strategy the other. What is important here is that The third section is for anything the
Requirements both sequential and concurrent strategies team wishes to report on. It may expand
(and many combinations) can be shown on risks or highlight some particular
UI Design using the intention-completion bars. worry to which they will be paying close
attention.
Programming
Status,Targeted, Deferred,
Figure 6: A Concurrent Development Strategy Requirements
Figure 8: A Sequential Development For
Strategy
any component, the steering commit- Finally, the steering group needs to see
and Risks Cost Roll-up
Requirements tee members will want to see the follow-
UI Design how fast the money is being used. This
rategy ing at the top of the detail page:
Programming section may be presented in tabular or
UI Design
• The intention-completion bars for the burn-up form, and include staffing sizes
Programming whole component from the summary as well as budget information as desired.
Figure 9: A Concurrent Development Strategy
Figure 9: A Concurrent Development Strategy
16 CROSSTALK The Journal of Defense Software Engineering February 2006
Detail Sheet for: UI Shell
Product Manager: Jones
Figure 9: A Concurrent Devel
A Governance Model for Incremental, Concurrent, or Agile Projects