roles managers technical team leaders programmers customers database administrators instructors

29
Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Upload: hugo-summers

Post on 15-Jan-2016

218 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

RolesManagersTechnical Team LeadersProgrammersCustomersDatabase AdministratorsInstructors

Page 2: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Resumes – please email before Friday at 8am.Everyone needs to submit an informal

resumeList of CS courses takenExpected graduation dateInterested in leadership position (yes/no)Interested in being a manager (yes/no)Programming skills:

Languages Windows Programming Networks Databases

Page 3: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

ManagersProvide directionWhat are we going to do?Based on customer/market needsManage personnelKeep the team productiveRepresent Business in the Planning GameWork with customers to determine needsWrite performance evaluations

Page 4: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Team LeadersProvide technical leadershipPrincipal Advisor to managementProvides technical assistance to team

membersMakes important design decisionsRepresent Development in the Planning

Game along with the rest of the development team

Write performance evaluations

Page 5: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

ProgrammersRepresent Development in the Planning GameDesignWrite Program CodeWrite TestRefactorWrite performance evaluations

Page 6: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

CustomersMe

Page 7: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Virtual Companies (Teams)Team 1 Team 2 Team 3 Team 4

Adam L Adam N (M) David (M) Bernard

Ashley (T) Derick (T) K.J. (T) Denise

Rachel Evan Mike Kara (T)

Sarah (M) Matt Wayne Kirk (M)

Mikey

(M) Manager(T)Technical Lead* All assignments are subject to change.

Page 8: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

What Latitude to do we have as a team?Can we give our team a new name? (Yes, please do.

But use good taste.)Can we work on another project? (maybe)Can we switch team members? (maybe)Can teams cooperate? (probably, but get approval

from the instructor first.)Can we write a web application? (no)Can we write in something other than C++? (no)Can we use a different software development process?

(no)Make specific proposals. I will consider anything, but

I reserve the right to say “no.”

Page 9: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Software Development Extreme Programming

Relatively new software development processVery clearly defined roles for the development

team (Development) and the management team (Business)

Extreme Programming Explained – Embrace Change Kent Beck, 2000, 2005

An incremental software development processOne of a family of “agile” development

processesLess formal specification and design

Page 10: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Frequent ReleasesA release is software that is delivered to the

customerIn extreme programming (XP), releases are

made frequentlyReleases consist of working code, but they are

usually snapshots of works in progress.Releases allow the customer to see how the

system is developing and react to problems at early stages

Page 11: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

IterationsReleases are generally the result of a set of

iterations.Most of the planning in XP happens between

iterations.Releases are short, so iterations are even

shorter. As often as one per week

Page 12: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

The Planning GameBusiness and Development play the planning

game to determine what to do next.

Page 13: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

StoriesEach system feature is broken down to 1 or

more user "stories.”e. g., “a student drops a course,” “a use logs

in,” “the system is asked to find a specific course that fits in a given schedule.”

Page 14: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Stories on Index CardsStories are written on index cards

just enough to remember what they are. We don’t want lots of details.

Page 15: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Index card contentsname of the storydatebrief description of storynumber of "points" the story requires (cost)

estimates are not in hours, they are in points that have a consistent value

NotesAnything helpful

Page 16: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Stories are dynamic.rewrittenbroken up into smaller stories if they are too

largecombined with other stories if they are too

small.discarded

Page 17: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Three Phases of Planning GamePhases are cyclical - you will move back and

forth between the phases during the course of the game.Exploration

Determine what new things the system might do.Commitment

Decide what subset of all possible requirements to purse next

Steering Update the plan based on what Business and

Development learn

Page 18: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Exploration Determine what new things the system might

do. Moves

Write a story (Business) Estimate a story (Development) Split a story

Page 19: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

CommitmentDecide what subset of all possible requirements

to purse next.Moves

Business Sorts by Value Three piles

Essential Significant business value Nice to have

Development Sorts by Risk Three piles

Cost estimates can be precise Cost estimates can be reasonably precise Cost estimates cannot be precise

Page 20: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Commitment Moves (continued)Set Velocity

Development tells Business how fast the team can work.

Choose ScopeBusiness chooses the set of cards that will be

included in the release

Page 21: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

SteeringUpdate the plan based on what Business and

Development learnSteering Moves:

Iteration Business picks one iteration worth of the most

valuable stories to be implemented. Recovery

If Development realizes that it has overestimated its velocity, it can ask Business to specify a smaller subset of the current stories.

Page 22: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Steering Moves (continued) New Story

If Business realizes it needs a new story, Business removes stories with equivalent estimates and inserts the new story.

Reestimate If Development feels that the plan no longer

provides an accurate map of development, it can re-estimate all of the remaining stories and set velocity again.

Page 23: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Steering Moves (continued) Velocity

The number of story points we complete each iteration is our "velocity."

Our next iteration will use our current velocity for determining the number of points we can commit to for the next iteration.

Release PlanningGiven velocity, Business gets good estimates of

the cost of featuresManagers use both cost and priority to schedule

the development sequence of features.

Page 24: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Iteration Planning

Page 25: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Players are just the programmersNo management

Stories are broken in tasks Tasks are recorded on index cards

Programmers accept responsibility for tasksProgrammers estimate the time required for

each task (perfect programming days/hours) Programmers test and implement tasks

using pair programming

The Iteration Planning Game

Page 26: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Exploration PhaseWrite a taskSplit/combine a task

Iteration Planning Phases

Page 27: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Commitment PhaseAccept a task

Programmer volunteers to accept responsibility for a task Estimate a task

The programmer who has accepted responsibility for a task estimates the time required to complete it (usually in perfect days or perfect programming hours)

Set load factors What percentage of the available time will you work on your

tasks? Balancing

Determine how well the available time matches the estimated task time for each individual – redistribute as necessary

Iteration Planning Phases

Page 28: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

Steering PhaseImplement a task

Use pair programming Use test-driven development

Record ProgressKeep track how much time has been spent on each

taskRecovery

Reduce task scope of task/storyRemove non-essential tasksGet more/better helpAsk customer to defer some stories

Iteration Planning Phases

Page 29: Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors

StoriesA sprite is placed on the screen (one point)Create a sprite path (four points)A sprite walks a path (four points)A user places a tower (two points)A player purchases a tower and places it on

the screen (one point)A tower destroys a sprite (one point)