Term
| what is Rapid Development? |
|
Definition
| A philosophy and practical application of project management that leads to an optimal outcome |
|
|
Term
| What can you control in a production? |
|
Definition
1.Money/Cost
2. Time/Schedule
3. Quality/Product Features |
|
|
Term
| Using Rapid Development, production can be optimized for: |
|
Definition
-Lowest Defect rate
-Fastest Execution Speeds
-Greatest User Acceptance
-Best Maintainability
-Lowest Cost
-Shortest Development Schedule |
|
|
Term
| What are the video game specific things that production can be optimized for with Rapid Development? |
|
Definition
-Best Quality Assets
-newest game effects
-Fastest framerate
-Lowest Minimum Spec (Like WoW) |
|
|
Term
| What happens if we do things the usual way? |
|
Definition
-Massive cost and schedule overruns
-Low quality
-Cancelled Projects
-High Turnover and burnout
-Friction between stakeholders, developers, and customers
-It is always painful! |
|
|
Term
| Rapid Development is HARD because it requires what two things? |
|
Definition
|
|
Term
| What were some of the problems that led to mickey's Death March? |
|
Definition
-Went to QA too early
-Didn't really schedule, instead they set an arbitrary time limit
-All of the code was developed separately and led to massive amounts of code errors |
|
|
Term
| Four Pillars of Rapid Development: |
|
Definition
1. Avoid Classic Mistakes
2. Development Fundamentals
3. Risk management
4. Schedule Oriented Practices |
|
|
Term
| What leads to the best possible schedule (AKA Rapid Development)? |
|
Definition
| Following the four pillars! |
|
|
Term
| What is associated with Development Fundamentals (The Second Pillar of Rapid Development)? |
|
Definition
-Estimation and scheduling
-tracking and measurement
-Requirements, design, and implementation
-QA and testing |
|
|
Term
| What is a side effect of Development Fundamentals? |
|
Definition
|
|
Term
| Development fundamentals must be _____. |
|
Definition
|
|
Term
| Having a perfect schedule is useless when: |
|
Definition
| Bad risk management leads your project to mcsplsoion two weeks before beta |
|
|
Term
| How can you manage schedule related risks? |
|
Definition
-Risk Identification
-Risk Analysis
-Risk Prioritization
-Risk Control |
|
|
Term
| What are the four dimensions of development speed? |
|
Definition
1. People
2. Process
3. Product Definition
4. Technology |
|
|
Term
| Productivity of individuals with equal experience can vary: |
|
Definition
|
|
Term
| Productivity of teams with unequal experience can vary |
|
Definition
|
|
Term
| Productivity of teams with equal experience can vary |
|
Definition
|
|
Term
| Productivity is a function of a team's: |
|
Definition
-Make-up
-Training
-Motivation
-Management |
|
|
Term
| What are the five principles of Development Staffing? |
|
Definition
1. Hire top talent
2. Job matching
3. Career Progression
4. Team Balance
5. Misfit elimination |
|
|
Term
| The process dimension focuses on: |
|
Definition
| Management of process and work flow, leverage of roadblocks |
|
|
Term
|
Definition
|
|
Term
| For good workflow you need: |
|
Definition
1. Simplicity
2. Avoid arbitrary processes |
|
|
Term
|
Definition
1. Do it right the first time (duh)
2. Doing it twice costs more! (Double Duh)
3. Fixing it later in the dev cycle costs SIGNIFICANTLY MORE |
|
|
Term
| Bugs found at the end of the project: |
|
Definition
| Are exponentially harder to fix |
|
|
Term
|
Definition
|
|
Term
| What can help with better QA? |
|
Definition
|
|
Term
| Which perspective should we view projects? |
|
Definition
| From the customer's! (IE customers, management, marketing) |
|
|
Term
| What may make the customer more comfortable? |
|
Definition
Methods other than just handing over the finished project:
-Throw-away prototyping
-Evolutionary Delivery
-Stage Release |
|
|
Term
|
Definition
|
|
Term
| what may add exponentially to your schedule? |
|
Definition
|
|
Term
| T/F: Always embrace as many firsts as you can |
|
Definition
| F: Avoid too many "firsts" |
|
|
Term
| Before using new technology: |
|
Definition
| Weight the advantages and disadvantages first! |
|
|
Term
| when is not the time to introduce new tools? |
|
Definition
| In the middle of production |
|
|
Term
| What % increase in staff is needed to meet a 25% reduction in schedule? |
|
Definition
|
|
Term
| How much would costs increase by adding 75% more people to the team? |
|
Definition
| 31% for 25% schedule reduction |
|
|
Term
| What are the processes of Code Like Hell? |
|
Definition
1. Hire only rock stars
2. Grant total autonomy
3. Ask team for total commitment
4. Motivate team to an extreme degree (trips, bonuses)
5. mandatory hours (Death marching) |
|
|
Term
| Why does Code Like Hell fail? |
|
Definition
1. Success is out =of managements hands
2. Long (and short) term motivation problems
3. It's unpredictable
4. Ignorant stakeholders mistake accidental success as "the Way It's Done!"
5. Extravagant waste of resources |
|
|
Term
| Potential advantages of Code Like Hell |
|
Definition
1. new companies on shoestring budgets can get every bit of productivity out of employees
2. Can take quick advantage of marketing oppurtunities |
|
|
Term
| Most projects overshoot their estimated schedule by: |
|
Definition
|
|
Term
| The foundation of rapid development: |
|
Definition
| Accurate schedule estimates |
|
|
Term
| You cannot estimate the cost of a project until: |
|
Definition
| Each feature is understood in detail |
|
|
Term
| Causes of an overly optimistic schedule: |
|
Definition
1. There is an external, immovable deadline
2. Manager refuses to accept a range estimate and makes plans based on the single-point, "best case" estimate
3. Managers/developers deliberately underestimate the project to submit a winning bid
4. Developers underestimate an interesting project in order to get funding to work on it
5. Manager believes that developers will work harder if the schedule is ambitious
6. The project begins with a realistic schedule, but new features are added and before long the project has an overly optimistic schedule
7. The project is simply estimated poorly |
|
|
Term
| Effects of overly optimistic schedules |
|
Definition
• Poor quality project planning - not enough staff or experienced staff or time to develop
• Deviation from plan when a problem hits
• Under-scoped project
• Unfocused project - "schedule politics"
• Poor customer relations - unpleasant surprises
• Premature convergence - shouldn't happen until project is feature-complete and stable |
|
|
Term
| Steps in project Estimation |
|
Definition
1. Estimate project size
-Lines of Code
-Number of Assets
-Sets of features
2. Estimation effort (in person-months)
3. Estimate schedule |
|
|
Term
|
Definition
• Never make an off the cuff estimate
• Plan time to do an estimate
• Use data from previous projects
• Use developer-based estimates
• Estimate walkthrough (low or high detail)
• Don't omit common tasks
• Use multiple methods |
|
|
Term
| How often does getting behind happen? |
|
Definition
|
|
Term
|
Definition
1. Don't throw out the schedule
2. Adjust the schedule based on the new information: see where you stand
3. Decide whether existing tasks need significant estimate modification
-Additive for a one time, expected problem
-Multiplicative for consistent under-estimation
4. look for trends
-Is a person always late?
-Is a particular task always long? |
|
|
Term
| In the second case study, what did the team do right? |
|
Definition
-Listed out all mistakes the company had made before
- Made a list of risks
- Made realistic scheduling goals
-They created a prioritized list of features
-Turned down good ideas that would have cost them more time. |
|
|
