Project Management
Download
Report
Transcript Project Management
Team Formation
Dr. Tallman
ECE297 Tutorials, Jan 21 & Jan 23
• Your team will meet your Communication
Instructor (CI) and schedule a weekly 30minute meeting beginning the following week.
• Wed, Jan 21, 1-3pm, students go to GB404
• Fri, Jan 23, 9-11am, students go to GB412
• Fri, Jan 23, 3-5pm, students go to GB412
• If you do not have a full team formed by these
dates, come to your scheduled tutorial, and
Dr. Tallman will assist you.
Team Formation &
Performance
ECE 297
Four Stages of a Team
• By Bruce Tuckman, Psychology Professor
You are here!
1. Forming
– Picking team, getting to know each other
2. Storming
– Figuring out who does what & how, often contentious
3. Norming
Want to get here (or beyond)
– Team has figured out who does what, members
understand and accountable for their roles
4. Performing
– Only high-performance teams reach this stage;
continuous improvement, open discussion, high trust
High-Performing Teams
• Open discussion
– Tell it like it is!
– Don’t let things fester
– But be constructive
• Transparency
– If you’re behind or some of your code doesn’t work,
say so clearly
– Don’t hide or evade
• Accountability
– Take responsibility for your part of the project
– Own your mistakes, delays, etc. and find a solution
• Trust
– Helped by all the above
– Plus spend time working together (in person!)
Team Status Meeting
• Two per week: 1 with CI & 1 with TA
– Typical industry practice: weekly team meeting
– With written status (usually wiki)
– Good meetings help make good teams
• Show transparency and accountability
– Concise statement of what is done and not done
– Clear (single person) ownership of various tasks
• With a target completion date
• Leverage the CI & TA’s expertise
– Mentors are valuable ask questions
Team wiki
• Team’s memory and to-do list
– Key data
– What’s done
– What’s next
• Can have lots of detailed data
– If so, add a summary for weekly CI & TA meeting
• Should have email with initial password
– Change it!
• Your wiki: for your team, TA and CI
• Wiki Quick Start Guide
• Go to 297 wiki
Coding in a Team
Coding Productively in a Team
• Want
– Parallel development multiple team
members working at once
– Without getting in each others way / wasting
work
• How?
“Adding manpower to a late software project
makes it later.”
-- Fred Brooks
1. Split Up Functionality
• Work in different files or functions
Feature 1
Feature 2
svn update
f2.cpp
f1.cpp
builds
prog.exe
builds
tests
svn commit
prog.exe
tests
Features Not Totally Independent?
Feature 1
More communication
during planning &
coding
Common Feature 2
svn update
f1.cpp common
builds
prog.exe
f2.cpp common
builds
tests
svn commit
Frequent commits
more important.
Continuous integration!
prog.exe
tests
Coding Routine
1.
2.
3.
4.
5.
svn update to latest code
fix a bug, or enhance a feature, or …
build
test
What if someone else
changed repository code?
svn commit
svn update
build
test
then re-try svn commit
Update/Commit Often
• Continuous integration
– Otherwise can run out of time at the end
• Easier to move tasks between team
members
– Don’t have a lot of new code in one team
member’s working copy only
• But don’t break the build
– Do not commit broken code
• Won’t compile
• Or breaks previously working tests
– Halts development by other team members
2. Split Development and Test
• Test & debug is massively parallel
– Can add many people, even late in project, and get gains
Developing new
features
Testing &
Debugging
3. Pair Programming
• One computer, two
programmers
– Driver:
• Writing code
• Focus on details
– Navigator:
• Reading code, giving feedback
• Focus on strategy: “What if there’s a NULL ptr”?
– Switch roles frequently
– Talk a lot
– Stop when you get tired
• Pair Programming Tutorial
Pair Programming
• Two people writing one thing: productive?
1. Less code written
• But higher quality
• Saves debugging & future issues
image: llewellynfalco.blogspot.com
2. Helps a team become cohesive
3. Grows expertise of team members mentoring
4. Helps team members read each others code
• Most studies say more productive for new
teams, and/or one programmer not expert
Project Management
Waterfall Development
Changes cheap
Does not really work
for complex projects
no one can plan
well enough!
Changes expensive
• Up front planning
• Phases: concept to detailed implementation
• Motivation: early changes cheaper
Iterative/Agile Development
Plan, but quickly
Later parts of the plan more coarse
Prototype
Refine
Test &
Evaluate
Includes end-user /
customer evaluation
One Flavour of “Agile”: Scrum
image: ecomcanada.org
• Choose features for 21-day sprint
• Team meets each day for 15 min scrum
• End of each sprint working SW for customer
Big Projects
• Altera:
+
$200 M
State of the art
for 2 years!
• Plan as far ahead as you can, but don’t paralyze yourself
– Plan gets coarse as you go out in time
• Have measurable milestones
–
–
–
–
3 year project need to break up schedule
Hold people to these milestones!
Clear must have features
Everything else: nice to have
• Get something working and improve still iterative
– Define quantitative metrics, and measure constantly
• Weekly status meeting
– wiki, crisp reporting
– Big picture progress toward milestones
21
Project Management: Schedule
Work Completed vs. Time
Project Completion
100%
90%
80%
No Milestones
Milestones
70%
60%
50%
40%
30%
20%
10%
0%
0%
20%
40%
60%
Project Time Elapsed
22
80%
100%
Design: Prototype Early
• Not having a working system is very dangerous
– Don’t know when/if the system will work
– Engineers can’t test their work in the whole system
– Don’t know where the problem areas to improve / optimize will be
•
•
•
•
Get something simple working
Test & Measure
Add features / Improve problem areas
Repeat
• Keep it simple!
– Use simplest approach that works
23
Can be HW + SW
Case Study:
Background
My PhD thesis: new CAD System for FPGAs
Results best published to date
Commercial interest
Formed company to commercialize
4 people initially
First customer was Altera
10 months to produce a new placement and routing system for
Altera’s chips
Aggressive goal: 10X better than current system
25
Place and Route Example
26
Managing Complexity
Have: 25,000 lines of C code
Don’t target Altera’s chips or deal with full complexities of
commercial chips
Have to write a lot more code
Maybe C++ would be better long-term?
If we re-write now, much easier than re-writing later
But, extra work and we had more experience in C
27
Design: Limit Scope!
Stick with C
Project already complex, full of uncertainties, tight schedule
Don’t add more complexity and work
Not right time to become expert in new language
Customer doesn’t care what language we use: wants better placement
and routing results
Solve the problems you need to, and skip the rest
Several companies have destroyed themselves trying to
move to the “next big programming language”
28
Project Management
Created fairly detailed schedule
What would each person work on
How long would each task take
Added 50% extra time for each task for problems / unknowns
Defined measurable milestones
Every 3 months, we had a specific test to show more of the project
worked
Otherwise we didn’t get paid by Altera
Schedule & milestones were crucial focus
29
Measure Something Quantitative
Best way to spiral and track a project: measure
Define quantitative metrics
Then measure them throughout the project
Right Track CAD: measured
Circuit Speed
Compile Time
Fraction of circuits that completed
30
3 numbers made it clear where we stood at all times
Everyone measured on all important changes
“You cannot improve what you cannot measure”
Outcome
Hit all milestones, except first (2 weeks late)
Focused!
CAD system exceeded expectations
30X less runtime
38% faster circuits
Altera replaced their P & R engine with the prototype
Started simple, measured where to improve
Some simple algorithms still in current Quartus II didn’t need
more!
31
Case Study: Quartus (First
Version)
Background
Altera had highly successful CAD system:
Max+PlusII
Decided to do a complete re-write to a new CAD
system
Quartus
Started ~1995 - 1996
Goals:
C++ (not C)
Cleaner, more extensible code
Allow multiple engineers to collaborate on a project easily
Allow fast, “incremental” recompiles
33
Complexity
Quartus was complex
Re-write of multi-million line software system
New language (C++), engineers not as familiar with it
Object-oriented design became a goal
Features that no one knew exactly how to implement (incremental
recompile, workgroup computing) were considered key
Hadn’t defined how to measure these features either
34
Planning and Prototyping
No working prototype for much of the project
Spent a year planning, with no coding
Too much Waterfall paralysis
35
Scheduling & Measuring
Schedules repeatedly missed
Task list not detailed enough
Too much complexity
Didn’t see lateness and scale back soon enough
Lack of clear milestones
Not measuring quantitative metrics toward the real goal
True key goal:
Stable CAD system that optimized well
Ready for the next chip (APEX 20K) when silicon available
Everything else secondary
36
Outcome
Software not ready in time for chip
Software rushed to market
Not stable enough, didn’t optimize well enough
Very bad customer experiences
Lost sales: $billions!
Rewrote & renamed later versions:
Now very good!
37
Case Study: Parallel
Placement
38
The FPGA Compile Time Challenge
(CPU speed)
39
Chip size growing more rapidly than CPU speed
How to keep CAD tool runtime under control?
Parallel Background
1 million line placement & routing system
Complex algorithms & code
Excellent quality results
Need to add new features & chips regularly
Academic parallel placement work
Mostly non-deterministic (results change every run)
Much simpler algorithms
40
The Approach
Keep it simple!
Minimize code to make parallel
Measure to find key code
10,000 lines of code out of 1 million
Use very few parallel primitives
Threads, mutexes
Must be deterministic
No race conditions; always get same answer
Much easier to debug & test
Leverage tools
Dynamic: Intel thread checker
Static: wrote tool to find thread-unsafe code
41
Results
~4X speed-up on 8 CPUs
Stable: ~2 customer bugs, both in first 2 releases
Another parallel effort at Altera (timing engine)
Created rich set of APIs first
Decided on parallel approach without measuring
Failed! APIs buggy & parallel approach not fast
42