|
|
|
|
(Sep 2)
Yesterday I was asked what software practices I was passionate about. It's not a question I've tried to answer in a while and I think it was worthwhile to consider the topic for a moment. What do I (or you!) care about?
- Continuous Integration- If you've heard me speak or read this blog, you've probably heard me mention CI. It's the best way I know to provide developers with feedback quickly, and a tighter feedback loop is the best way I know to learn. Hudson has tons of mindshare these days, but Cruise Control is still my favorite. At the end of the day, use something! CI is a great gateway practice that can lead to full-scale agile adoption down the road.
- Test Automation- This is another way to tighten the feedback loop. If you cover your code with an automated test, and it's run in your continuous integration system, any breaks or problems are caught very, very quickly. Also, please note that I said automated tests, not unit tests. There's nothing wrong with unit tests. In fact, they're awesome, but too many teams only write unit tests. Put both API level, package level, and integration tests in your toolbox. Then you'll be able to test anything, anytime, anywhere.
- Daily Meetings- Get together every day and discuss what you did yesterday, what problems you encountered, and what you'll do today. This short (1 minute per person) meeting is a great way to share information, keep everyone on track, and build team camaraderie.
- Time Boxed Iterations- Providing smaller goals, 1 to 2 weeks, for your team to hit is a great way to avoid "10,000 feature syndrome," as well as quickly spotting teams that can't deliver. A time box helps introduce a false sense of urgency for developers as well as stakeholders. "We'd love to add that cool new feature, but we're in the middle of an iteration. Can we put that in the next iteration? It starts in a week."
- Peer Code Reviews- I do like pair programming, but for me it's a periodic practice. A peer code review is an everyday practice. Before you check in code, you explain it, and show it, to one other person. This keeps us honest (no one wants to explain bad code to a coworker), and also shares system knowledge with the entire team. A quick and fast one-on-one code review is a great way to keep someone from getting too far off course.
I could type a few more, but this week/months/year has been insanely, overwhelmingly busy for me. So instead, I'll ask you to continue the list. What practices are you passionate about, and why? Put them in your blog and send me a list. I'll post a follow-up blog entry when I have a few interesting posts!
Category: Agile
|
|
|
|
|