Tonight I was asked some high-level questions about development process. I wound up responding w/ enough material that I thought I'd share the thoughts here for broader consumption.
Hey guys,Please feel free to ignore this email but I'd extremely appreciate some advice if you have a couple of minutes. I am trying to compare best practices for teams over 10 programmers to determine what software development methodology has been the most productive for your company but at the same most fun for your team. If you have time I'd appreciate answers to the following:1) Software Development Process used (i.e. Scrum, XP, custom)
"agile" (no scrum)... weekly iterations/sprints (no standup). have driven/done xp (pair programming mix) as well; I'd only go this (xp/pairing) route again if I were in a more supportive ecosystem (e.g. SF).
2) Do you track # of hours programmers work in a project?
never. bad idea IMO.
3) Do you have a QA team, if so how many?
no. though I've considered one or two QA folks... it'd definitely be nice to objectively do white/black box testing outside of dev. we're pretty close to TDD, so we've convinced ourselves we "don't need it." I go back and forth.
4) How often is your release cycle?
we deliver code to production once a week.
5) Who is allowed to deploy code into production?
we rotate who does the deploy (everyone on the team, including me, is capable of doing it). we run a shared responsibilty/exposure shop in order to reduce/eliminate the "john's the only one who knows that code/process" scenarios. my general philosophy here is if you're not hiring engineers that you don't trust well enough to do a deploy... you're liking hiring the wrong folks.
6) What project management tools do you use?
http://pivotaltracker.com . in the spirit of agile... we're very light on process/tools. never document something in more than one place (e.g. in the "story"), and even then be light.
7) How accurate are your release predictions?
eh. having tried (as mgr and individual contributor) everything under the sun... I no longer believe numbers folks toss out ("we're 90% on time" etc). I've found everyone's (mine included) numbers are BS, and if you dig into what actually transpired after the release... enough corners were cut, enough brilliant engineering ideas employed, and enough requirements were relaxed during the release cycle, that you never end up with what you started with anyway, so the A to B comparison and judgement of "on-time" is never valid. your mileage will vary though. it all comes down to the "unit"... the "team"... their cohesiveness, experience working together and trustworthiness amongst eachother. that said, if you handed me a green teem of folks that never worked together, I'd drive it agile-style with one to two week iterations/sprits (and production deploy) cycles with goal-level commitments (e.g. team committing to having x y and z done by date 'a'... and working as hard as they can to meet that commitment).
