- avoid changing the list of items to work on mid-sprint
- be firm with clients – prevent them from sneaking in new items/making changes to their requested features mid-sprint
- item priorities may change mid-sprint, but keep in mind that changes like these are disruptive
- points or man-days: YMMV
- whichever you choose, be consistent (this is a team decision)
- make sure everyone agrees on what each unit of effort stands for
- estimates are not absolute
- if one dev can finish a task in 1 day, it DOES NOT mean that two devs can finish that same task in 1/2 day
- different people have different work efficiencies
- every new member you introduce into a team increases the effort needed to keep everyone’s knowledge synced
http://www.cs.virginia.edu/~evans/greatworks/mythical.pdf
- maintain a wiki containing all relevant documents: requirements, specs, diagrams, etc
- recognize the limitations of your RDBMS
- eg, just because you can implement all your logic with stored procedures doesn’t mean you should
- prefer maintainability over optimization
- when in doubt over performance: benchmark
- make sure the build is green before you leave every day
- last-minute, hurried commits are generally a bad idea
- avoid commenting out tests just to make the build green
- outdated tests need to be updated
- if your build takes too long, you may need to remove/optimize certain parts of the build process
- automate as much of this as you can – deployment by hand is error-prone
- if you have a testing phase prior to deployment, avoid sneaking features in during testing
- if not, consider having a “no coding” period (eg, 1 day) prior to deployment (make sure the build is green)
- bugfixes, hotfixes, etc should have their own branches
- consider tagging deployed builds for future reference
- anticipate requests for long-term support
- if the original developers are still around, have them document as much about the project as they can
- and train the maintainers, if possible
- sprint retros, project retros (aka the post mortem)
- YMMV on what you need; either way, you need to document what went well, what went wrong, etc for future reference
- retros are a team affair: do not include clients/non-members
- members need to feel safe enough to be honest about what went wrong
- burnout is a result of unsustainable practices
- overtime is a last resort, not a silver bullet – remember the law of diminishing returns