ICS 121: Mechanics of Teamwork
Overview
- Why are the mechanics of teamwork important?
- Review of the facilities of development
- Some software development teamwork use cases
- What makes a good team?
- Common teamwork breakdowns to avoid
- How to improve teamwork
Why are the mechanics of teamwork important?
- The process of software development requires detailed coordination among many people:
- Many people are needed because there are many different skills needed
- Many people are needed because there is a lot of work to do in a short time
- People periodically leave or join the team
- Detailed coordination is needed because software is fragile
- Software development includes some repetitive and tedious activities
- E.g., maintaining a set of consistent UI screens, (re)testing the system, verifying that
defects have been fixed, packaging yet another release
- If these tasks are done incorrectly or inconsistently, it leads to the need
for even more work
- These tasks should be automated whenever that is practical
- When automation is not practical, there should be clear and reliably repeatable
procedures.
Review of the facilities for development
- Developer:
- workstations, local or shared server or database
- Tester:
- workstations, local or shared server or database
- Shared collaborative infrastructure:
- Version control repository
- Issue tracking system
- Communications tools: mailing list, chat, website
- Automation servers: nightly builds, smoke tests
- Lab with samples of supported hardware and OSs
- Operations (Staging and Production):
- Servers, Database, Network infrastructure
- Figure 1
- Figure 2
Some software development teamwork use cases
- Customer demands change to use case priority
- Must update requirements documents
- Possibly change order of development activities
- Possibly change product roadmap (the set of features in each release)
- Possibly change priority of tasks in the issue tracker
- Manager adjusts resources and schedules
- Managers periodically review open issues
- They set priorities and target milestones (deadlines)
- The assign issues to human resources (developers, testers, tech writers, etc.)
- Managers get status reports from individual developers
- Manager may adjust the schedule for internal milestones
- Managers give project status report to higher-level management
- Changes to product delivery dates are negotiated among all stakeholders
- Developer works on an issue
- Developer looks at issues assigned to him/her
- Chooses one that has the soonest deadline and the highest priority
- Checks out source code from repository
- Makes requested changes
- Writes notes on the issue as he/she learns or makes decisions
- Tests the product to make sure the change worked, and there
are no regressions
- Commits the changes back to the repository and marks the issue RESOLVED
- If he/she cannot finish the issue, the remaining work can be
reassigned to another developer
- If another developer has modified the same files, a conflict
may occur and must be resolved
- Reaching a release candidate
- A release candidate is a internal version of the software that
seems good enough to release, but its quality must first be better
verified
- The team looks all open issues and decides that each can be
slipped to a later release.
- All departments review and "sign off" on the release to
indicate that they are confident in it and willing to support
it
- The release is packaged and deployed
- QA is given a release candidate to test
- QA department assigns testers to the task
- Testers work through the test plan, step by step
- Testers track all defects
- QA manager eventually "signs off" on the release, indicating that it is good enough
- QA finds a defect
- Track defect in issue tracker
- Management reviews issues and sets priorities and deadlines
- If needed, developers discuss the issue
- Developers provide estimate of effort
- Assigned developer fixes the problem and marks issue RESOLVED
- QA verifies that the issue is really resolved
- If it is not really resolved, it is marked REOPENED
- End user finds a defect
- User contacts technical support
- Tech support may offer a work-around to the user, if one is known
- Track defect in issue tracker
- Management reviews issues and sets priorities and deadlines
- If needed, developers discuss the issue
- Developers provide estimate of effort
- Assigned developer fixes the problem and marks issue RESOLVED
- QA verifies that the issue is really resolved
- If it is not really resolved, it is marked REOPENED
- QA may add a test case to their regression test suite to catch this
defect if it ever appears again
What is a good team?
- A good team
- Accomplishes stated goals (e.g., ships the product)
- Builds/maintains valuable professional relationships in and out of the team
- Enjoys working together, learns from each other, trusts each other
- Has complementary strengths to cover all needed areas
- A good team member
- Knows his/herself: strengths, weaknesses, professional philosophy
- Truly wants the team to succeed
- Follow the golden rule to pro-actively shape your team experience
- Is professionally courteous, respectful, and cooperative
- Cooperative can include being available when needed, and being flexible
- Understands how his/her goals fit the team goals
- Understands his/her role: what he/she needs to do, and why
- Knows what others are doing, and why
- Is honest and forthcoming with teammates
Common teamwork breakdowns to avoid
- Someone flakes out and lets the team down
- Be honest about your availability up front during planning
- Make sure that you understand what you have to do, don't get overwhelmed
- Make responsibilities and progress visible to everyone
- One person does all the work
- Make sure they realize that the project is too big for one person, others need to be kept in the loop so that they can do their parts
- That person should not be "stealing" other people's tasks
- The whole team is clueless about some aspect
- Assign someone to master that aspect / mitigate that risk
- Work together in a study group to all learn
- Team procrastination, or unwanted job
- Make a plan and stick to it, you have no choice
- A little friendly competition for motivation
- Every person does their share of chores, that's part of being professional
- Hard to schedule team meetings
- Use more email and issue tracking
- Meet during discussion section time slot
- Big misunderstandings
- Slow down and make sure everyone agrees on the basics
- Listen and repeat
- Write things down as tasks or documents
- Don't just meet and then work separately, try some pair programming
- Design and code review meetings
- Long critical path
- Consider parallel teamwork when you plan and design the system
- Realize when others are waiting for you, don't block their work
- Keep things simple so that other team members don't face a huge learning curve
How to improve teamwork
- Practice, experience, thoughtfulness, personal reflection
- Use tools that help keep others in the loop, track responsibilities and progress
- Capture team discussions in clear documents, or at least a message archive
- Design and code review meetings
- Consider parallelism in planning and design
- Use coding standards to take certain stylistic issues off the table
- Use external standards documents as part of requirements: precise, pre-agreed upon, unchanging
example use case templatesample test plan templateProject plan template
