Chapter 1: Starting a Projectathena.ecs.csus.edu/~buckley/CSc233/CSc233_Chapter9.pdf · process of...
Transcript of Chapter 1: Starting a Projectathena.ecs.csus.edu/~buckley/CSc233/CSc233_Chapter9.pdf · process of...
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
1
Dilbert Scott Adams
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
2
Dilbert Scott Adams
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
3
Dilbert Scott Adams
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
4
Dilbert Scott Adams
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
5
Dilbert Scott Adams
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
6
Dilbert Scott Adams
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
7
Dilbert Scott Adams
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
8
Dilbert Scott Adams
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
9
Chapter 9 – Maintaining Project Rhythm
“Any project can develop a rhythm and then maintain it. The
project manager (and project staff) has to look for obstacles and
risks and remove them (that's the defense part)…
You're working someone else's project when they cut staff,
change the delivery date, change the focus of the project, or some
other major change, and then expect you to react -- and react
well.
In my experience, once a project has started it's almost impossible
to change the project rhythm from a top-down mandate and
succeed with the project.
I have seen successes where people changed practices and were
able to change the project rhythm.”
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
10
Create automated “smoke tests”
• In software, the term smoke testing describes the process of validating code changes before the changes are checked into the product’s source tree.
• After code reviews, smoke testing is the most cost effective method for identifying and fixing defects in software.
• Smoke tests are designed to confirm that changes in the code function as expected and do not destabilize an entire build.
Note: these are not the full set of regression tests
• Goal: to keep the “build” working… don’t interrupt the rhythm.
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
11
Integration
Continuous Integration
• Write some code, compile, test, review, add to the code base (the “build”) on a daily basis (e.g. TDD)
• Run ‘smoke tests’
– Immediate feedback
• Helps team establish its rhythm
Staged integration
• Wait until a feature is “finished”, then integrate.
• A form of “continuous integration”
“Big Bang” integration
• All integration happens at the end
• You cannot tell if the project is progressing until everything is integrated
CSc 233 171 Fall 2013
A variation…
Rule: You do not “promote” to the code base until you
are ready to replace the system you are developing
• Assume your system must remain running “live”
• You can “cut” over to the new system, but users are
actively using the system every day
• Staged Integration – with continuous integration on a
“branch”
Decision is made when to integrate
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
12
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
13
Implement by feature – not architecture
• By architecture … the focus is not on whole features.
No feedback until architecture and the first feature are implemented
What Agilists try to avoid (Marick)
• Having lots of partially implemented features doesn’t give
you the feedback you need.
• You get a “big bang” when you discover that nothing
worked the way we expected it to work.”
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
14
Architecture Reflects Organization Conway’s Law
Consider a large system S that the government wants to build.
The government hires company X to build system S.
Company X has three engineering groups, E1, E2, and E3 that participate in the project.
Conway's law suggests that it is likely that the resultant system will consist of 3 major subsystems (S1, S2, S3), each built by one of the engineering groups.
More importantly, the resultant interfaces between the subsystems (S1-S2, S1-S3, S2-S3) will reflect the quality and nature of the real-world interpersonal communications between the respective engineering groups (E1-E2, E1-E3, E2-E3).
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
15
Implement Highest-Value Features First
• Leave the riskiest to later…
… unless the riskiest is also the highest-valued
feature!
• Product Backlog
“The more valuable the features are and the more
finished you can make those features…
… the more flexibility you have bought yourself and
the team for this project.”
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
16
Debugging by Feature
“ If you find yourself debugging by feature at the end of
the project consider implementing by feature from the
start. You’ll have less project disruption and a more
even rhythm.”
Rothman
Why?
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
17
Pair programming http://www.pariprogramming.com
All code to be included in a production release is created by two people working together at a single computer.
You have the security of having two people familiar with the same code.
Pair programming increases software quality without impacting time to deliver…
… in those cases where it actually works.
It is counter intuitive, but 2 people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality.
… if not, don’t do it!
With increased quality comes big savings later in the project.
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
18
The best way to pair program is to just sit side by side in
front of the monitor.
Slide the key board and mouse back and forth.
One person types and thinks tactically about the method
being created, while the other thinks strategically about
how that method fits into the class.
It takes time to get used to pair programming, so don't worry
if it feels awkward at first.
Pair Programming is NOT just keyboard work!
… and taking turns “driving”.
CSc 233 171 Fall 2013
Reviewing work
• Formal Inspection http://www.mfagan.com/pdfs/aisi1986.pdf
• Reviews follow a similar
structure:
• Michael Fagan, Defect-Free
Process
1. Planning
2. Overview
3. Preparation
4. Inspection Meeting
5. Process Improvement
6. Rework
7. Follow-up
• Buddy review
• Peer review
• Walkthrough
Different types of
reviews
19
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
20
Plan to Refactor for ease Marick
Simplify – improve – the code!
• Refactoring is a disciplined technique for restructuring an
existing body of code, altering its internal structure without
changing its external behavior.
• Its heart is a series of small behavior preserving
transformations.
• Each transformation does little, but a sequence of
transformations can produce a significant restructuring.
• Since each refactoring is small, it's less likely to go wrong.
• The system is also kept fully working after each small
refactoring, reducing the chances that a system can get seriously
broken during the restructuring.
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
21
Code Growth in Serial Lifecycle Figure 9.1
The code grows more slowly because the developers
are bulding only what they need…
… and they are refactoring as they go
Eliminates the “push” at the end to fix a huge number
of defects
Slows the degrading of design … and the difficulties
of change during maintenance.
The point?
… refactor as you go… not at the end when it is too
late.
CSc 233 171 Fall 2013
Fig 9.1 Typical growth of code in serial life cycle
“The reduction after integration is refactoring… some redesign, but mostly
refactoring…
If you don not refactor at the end or you cannot pay down your technical debt,
the code size stays high.”
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
22
Integration starts here
Start of development
Testing starts here
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
23
Defining requirements…
“Think about who is using the system and how to
develop what the user needs.”
• It is important to remember that Functional and Nonfunctional
requirements are a developers abstraction… the way we think
about requirements
Who wants that checking account? (page 178)
“… they had been focusing on the internals of the system that
they had forgotten about the people who would use the system
or be served by the system…
… It’s always the people, isn’t it?”
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
24
“The GUI is design, not requirements”
• Requirement involve identifying the major uses that
will deliver business value…
… and then the necessary functionality.
• The GUI is the design decisions necessary to deliver
this business value... to the user!
• Prototyping… wireframe representations
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
25
Use Low-Fidelity Prototyping
“Once you've learned paper prototyping, you can use it
in every project you do for the rest of your career.
I have no idea what user interface technologies will be
popular in twenty years, but I do know that I'll have to
subject those designs to usability evaluation, and that
paper prototyping will be a valuable technique for
running early studies.”
Copyright © 2003 by Jakob Nielsen
http://www.paperprototyping.com/index.html
CSc 233 171 Fall 2013
Manage It! Your Guide to Modern, Pragmatic Project
Management. Johanna Rothman
26
Usability Testing
using
Paper Prototyping
Two
Short
Videos