Project and Build Management

Bart Massey 2013-11-18

Overview

• Project Management
• Build and Configuration Management

Project Management: The Textbook Perspective

• Coding standards and practices

• Scheduling and estimation

• Measurement and control

• Programmers as people

• Managing your manager

Scheduling and Estimation

• Problem: Scheduling must, by definition, happen too early

• Various solutions have been proposed / used:

  • "Experience" (no)
  • Predictive modeling
  • Modeling and simulation
  • Forego scheduling and work "on the fly"
  • No good if there are deadlines or resource constraints

    Predictive Modeling

• Large histories of characteristics and outcomes of SW projects is compiled

• A predictor model is built based on history

• The predictor model is then applied to new projects

• Most famous, probably best: COCOMO2

Detail Scheduling

• Traditional scheduling approach is via a "CPM chart" or "Gantt chart":

  • Collect tasks to be done to fine granularity
  • Note dependencies between tasks
  • Note resource usage of tasks (mostly people)
  • Build a schedule (software helps here)
  • Note critical path, slack

• Problem: Only know detailed end tasks at end

• Problem: Lots of work
• Opportunity: Regression to the mean
• Opportunity: Fewer lost tasks

Measurement and Control

• First principle (not in book): Only measure something if you intend to use the measurement

• Measuring can be harder than it looks

• Control must be small, and results measured carefully (no controls, no time for experiments)

• Remember that measurement is overhead

Programmers As People

• Perhaps most important section in book

• Applies to colleagues, bosses as well as reports

• Human foibles can be planned for

Programmer Efficiency

• Going to vary widely (10x?)

• Going to be way less than 100%

• Going faster usually loses because rework

• Culture is especially important because programmer social fail

Work Environment

• Work environment matters hugely

  • Physical
  • Cultural

• Tons of information on how to improve

• Doesn't have to be top-down improvement

"Managing Your Manager"

• Managers are people too

  • May be too non-technical
  • May be out of date
  • May be personality-defective
  • May be desperately unhappy managing

• Like any kind of diagnostic problem solving

  • Figure out what the error is
  • Do propagation
  • Make a plan
  • Execute the plan

• Don't quit willy-nilly, and do find another job first

Configuration management

• Idea: Have software under control always

  • Use people + tools to have SW that

  • Is composed of known pieces in known ways

  • Is as high-quality as can be reasonably achieved

  • Is "future-proofed" against change in the world

  • Old School: CCB; New Wave: Tool-based

• It's all about changes: different practices for different project phases

• It's not just SW

  • Tool versions and machine configurations
  • Backups

Build management

• Everybody automates build and deployment now

  • Maybe make, maybe very sophisticated build tools

  • Tools like Jenkins that provide "continuous integration"

  • Automated testing

  • Automated packaging, maybe delivery

• Goal: Achieve CM, QA, V&V on a fine-grained basis without much human overhead

• Learn to work with this stuff

  • Learn to use Git
  • Write the build scripts
  • Write the unit tests

This Class Is Not A Team Project Class

• Note that the practices advocated for in this lecture are almost all useful regardless of project and team size

• YMMV