Practices of Agile Development

Attitudes

• Blame doesn't fix bugs. 
  
• Don't code in isolation, do code reviews.
• Use unit tests.
• Do not code in quick and dirty ways.

Continuous Learning

• No need to be specialized on every technologies.  But need to known the industry trend.
• Share knowledge with the team.  Let everyone learn from each other.
  
• Learning new technologies may have to give up the old ones.
• Ask why and dig into the root of solution.
• Keep development cycle in a good pace.  Design -> Implementation -> Testing -> Code Review -> Release.

Customer Oriented

• Let customer do the business decisions.  Understand customers needs.
  
• Design in two phrases:
• Macro design:  Give the direction of implementations.  Not down to the details.
  
• Micro design:   Ways on solve problems during implementation.
• A good design should be correct but not precise.
• Blindly picking a framework is like having kids to save taxes.
• Don't build what you can download.
• Base on project requirement, select the right tools and technologies.
• Checked-in code (on master branch) is always ready for action.
• Never accept big-bang integration.  Should integrate codes more often.
  
• Automate QA testing.
• Get continuous feedback from customers.  Ensure the project is on the right direction.
• Release the smallest usable feature in project development life cycle.
  

Feedback

• Use unit tests to provide coding feedback.
• TDD - Write tests before writing code.
• Good design doesn't mean more classes.
• Target for simple design.
• Ensure code works on different platform (if applicable).

Agile

• Write clean code when speaks its purpose or function.
• PIE - Program Intently and Expressively.
  
• Let code speak for itself.  Comments only helps.  Don't comment to cover up.
  
• DRY - Don't Repeat Yourself.
• Carefully pick meaningful variable and method names.
• No best solution.
• Always code in clean, simple and easy for maintenance way.
• Simple is not simplistic.
• Do not use complicated design pattern unless it's absolutely necessary and with good reasons.
• Use inheritance for is-a; Use delegation for has-a or uses-a.

Daily Practice

• Don't get burn twice.  Keep a log book.
• Treat warning as an error.  Solve it.

Collaboration

• Daily short (stand) meeting (10 - 15 minutes).
• Always know what others are working on.
  
• Simple questions for everyone:
• What's yesterday achievements?
• What's today's plan?
• Any obstacles?
• Do not discuss the questions during meeting.  Details should be discussed after meeting.
  
• Meeting holds in the morning after everyone settle down.
• Advantages of daily meetings:
• Know the existing problems and progress.
• May reallocate resources if needed.
• Let everyone know what others are doing.
• May know who can provide a quick solution to a problem.
• Keep everyone in a good working pace.
• You can't code in PowerPoint.
  
• Architect should be able to code.
• Code should be reviewed and refactored if necessary.
• Every project member should shift to handle different part of the project.
• Knowledge grows when given.
• Inspire rather than given instructions.
• Code review basic check points:
• Easily readable and understandable?
• Any obvious mistakes?
• Is the code give negative effect on other functionality?
• Any repeated code?
• Can be improved or refactored?
• Unless there's obvious improvement after refactoring, do not change others code.
• Report progress and problems.