One man team

• Zero-Communication Overhead
• Know all aspects of codebase
• Usually have lower quality
  • No peer pressure to stop doing dirty hack. Code become patchy and messy.

Agile Team

• Product Backlog (Tickets)
  • Feature request
  • Describe ‘what to build’, but not ‘how to build’
• What is Sprint?
  • The collection of work (tickets) to be done in a certain timeframe.
  • The timeframe can be 1 week, 2 weeks or even 1 month.
  • Each member was assigned some tickets.
  • Some tickets are unassigned, members who finish their work before the end can pick them.
  • Only deploy at the end of sprint.
  • If member cannot finish the task, they have to communicate before the end of sprint
• Sprint planning
  • Before the end of sprint, team need to pick important tasks for the next sprint
  • Use “Story point” to measure complexity, not time
    • Because different engineer need different amount of time to finish it.
• Stand-up meetings (SCRUM Meetings)
  • 10-15 minute
  • Answer 3 questions:
    • What did you do yesterday?
    • What are you going to work on today?
    • Is anything preventing you from getting what you need to done?
  • Another meeting may be scheduled if follow up is needed.
• Task Boards
  • Each one have at most one task at the same time.
  • Keep track tasks in different stagings, such as
    • To do
    • In progress
    • Finished
  • Having a real board can help in stand up meeting.
• Headphones mean: Don’t bother me
• Best Practices
  • “The stuff that is generally accepted as a good idea in the long run, even if it is a bit of a pain to implement in the short run.”
• Test Driven Development
  • More people work in the same project -> # of code increase fast -> software complexity grow fast -> engineer don’t know the big picture in detail -> new code easy to break other’s work
  • Use test to verify the code is working
• Continuous Integration
  • Run test automatically before integration.
• Continuous Deployment
  • Automatically deploy to production once code is accepted
• Pair Programming
  • One person code, another give alternative and suggestion.
  • Switch position from time to time.
  • As a junior developer, it is good to see how other code, to learn thing you don’t know.
• Code Review
  • To identify issues hasn’t thought about by the person who write the code.
  • Person who review should not involved in writing the code.
• Code Style Guides

Some questions to ask by developers during interview

1. Do you use test driven development? If so, dive in and find out more specifics of how they write tests.
2. Do you have continuous integration or deployment setup?
3. How do you feel about pair programming?
4. Do you follow a certain coding style guide?
5. How do you conduct code reviews?

Review

The Story point concept assume the difficulty of a task is the same for all engineers. It ignores the fact that knowledge need to be transfer if a new engineer take over the task.

Reference: Get off Your Horse and Stop Coding like a Cowboy.