Software is a Team Sport

Software as a team sport. Like all other teams, it must act as a functional support system. While many teams have a Quaterback or The Driver, There is unquestionably a large number of personnel all built with specific functions to successfully deliver or accomplish the goal of the team.

No difference with software.

Programmers and sometimes management or maybe an architect are the center of attention most of the time, There is a specific need for a diverse set of skills and experiences.

Teams Require Diverse Skill Sets

Skills and Positions of Great importance for software projects:

  • Customer Management - getting buyin from shy customers
  • Project Management - clearing obsticals for programmers, not create them
  • Technical Writing - ensuring everybody is on the same page
  • QA - act on behalf of customer ensure requirements are met
  • Operation Support - put out campfires and provide guidance to users

Teams are Subsystems

Teams must function as a Cingular system to accomplish a singular goal. To that and all of the diversity that goes into making up a team must be

  • all focused in the right direction
  • each know and function their role well
  • a well thought master plan that rallys the team

HerA well-thought-out plan Must be by definition incomplete and flexible. It’s by no means implies that the Steps to the end are concrete.

Rather it is acknowledged that change will come Often only after experience. And hence agile is a great way to actually manage a project.

Teams Must Communicate and Adapt

Teams need to all be on the same page, with a central, well known place form of communication. There need to be a place to capture communication, record decisions and replay history.

Github Communications Tool

  1. Record issues to do: requirements, bugs, design and documentation
  2. Capture discussions for decisions that have been made
  3. Capture changes to code and why
  4. Capture discussions during code review
  5. files are necessary for getting everything started.

Code can not be changed with out the reasons being recorded and the results validated. Treat discussions and decisions the same way and a history really can teach a lot.