Team Formation Dr. Tallman. ECE297 Tutorials, Jan 21 & Jan 23 Your team will meet your Communication...
-
Upload
paul-parsons -
Category
Documents
-
view
218 -
download
0
Transcript of Team Formation Dr. Tallman. ECE297 Tutorials, Jan 21 & Jan 23 Your team will meet your Communication...
Team Formation
Dr. Tallman
ECE297 Tutorials, Jan 21 & Jan 23
• Your team will meet your Communication Instructor (CI) and schedule a weekly 30-minute 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
1. Forming– Picking team, getting to know each other
2. Storming– Figuring out who does what & how, often contentious
3. Norming– 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
You are here!
Want to get here (or beyond)
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
f1.cpp f2.cpp
builds
testsprog.exe
builds
testsprog.exe
svn update
svn commit
Features Not Totally Independent?
Feature 1 Feature 2
f1.cpp f2.cpp
builds
testsprog.exe
builds
testsprog.exe
svn update
svn commit
common
CommonMore communication
during planning & coding
common
Frequent commits more important.
Continuous integration!
Coding Routine
1. svn update to latest code
2. fix a bug, or enhance a feature, or …
3. build
4. test
5. svn commitWhat if someone else changed repository code?
svn updatebuildtestthen 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
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
image: llewellynfalco.blogspot.com
Project Management
Waterfall Development
• Up front planning• Phases: concept to detailed implementation• Motivation: early changes cheaper
Changes cheap
Changes expensive
Does not really work for complex projects no one can plan
well enough!
Iterative/Agile Development
Test & Evaluate
Refine
Prototype
Includes end-user / customer evaluation
Plan, but quicklyLater parts of the plan more coarse
One Flavour of “Agile”: Scrum
• Choose features for 21-day sprint• Team meets each day for 15 min scrum• End of each sprint working SW for customer
image: ecomcanada.org
21
Big Projects
• Altera:
• 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
+$200 M
State of the art for 2 years!
22
Project Management: Schedule
Work Completed vs. Time
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
0% 20% 40% 60% 80% 100%
Project Time Elapsed
Pro
jec
t C
om
ple
tio
n No Milestones
Milestones
23
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
Can be HW + SW
Case Study:Case Study:
25
BackgroundBackground
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
26
Place and Route ExamplePlace and Route Example
27
Managing ComplexityManaging 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
28
Design: Limit Scope!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”
29
Project ManagementProject 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
30
Measure Something QuantitativeMeasure 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
3 numbers made it clear where we stood at all times Everyone measured on all important changes
“You cannot improve what you cannot measure”
OutcomeOutcome
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)Case Study: Quartus (First Version)
33
BackgroundBackground
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
34
ComplexityComplexity
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
35
Planning and PrototypingPlanning and Prototyping
No working prototype for much of the project Spent a year planning, with no coding
- Too much Waterfall paralysis
36
Scheduling & MeasuringScheduling & 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
37
OutcomeOutcome
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!
Case Study: Parallel PlacementCase Study: Parallel Placement
38
39
The FPGA Compile Time ChallengeThe FPGA Compile Time Challenge
Chip size growing more rapidly than CPU speed How to keep CAD tool runtime under control?
(CPU speed)
40
Parallel BackgroundParallel 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
41
The ApproachThe 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
42
ResultsResults
~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