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



2

Dilbert Scott Adams

CSc 233 171 Fall 2013



3

Dilbert Scott Adams

CSc 233 171 Fall 2013



4

Dilbert Scott Adams

CSc 233 171 Fall 2013



5

Dilbert Scott Adams

CSc 233 171 Fall 2013



6

Dilbert Scott Adams

CSc 233 171 Fall 2013



7

Dilbert Scott Adams

CSc 233 171 Fall 2013



8

Dilbert Scott Adams

CSc 233 171 Fall 2013



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



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



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



12

CSc 233 171 Fall 2013



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



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



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



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



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.

http://www.extremeprogramming.org/index.html

CSc 233 171 Fall 2013



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”.

http://www.extremeprogramming.org/index.html

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

http://www.mfagan.com/pdfs/aisi1986.pdf

Reviews_Types_Intro.ppt




CSc 233 171 Fall 2013



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



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.”



22

Integration starts here

Start of development

Testing starts here

CSc 233 171 Fall 2013



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



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



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

http://www.paperprototyping.com/index.html

CSc 233 171 Fall 2013



26

Usability Testing

using

Paper Prototyping

Two

Short

Videos

chapter 1: starting a projectathena.ecs.csus.edu/~buckley/csc233/csc233_chapter9.pdf · process of...

Documents