Which project management and software development methodology is best suited for iPhone Development? Are there any documentation templates available which documents an iPhone Development project?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
A software methodology is simply a tool that helps you make sure you got the job done right. You don't have to follow any formal methodology to create great software on any platform. In short, the platform doesn't dictate the process or methodology you use.
Instead of going to a menu of methodologies, take some time to understand your particular project. There will be challenges that your project faces that are not necessarily addressed or spelled out in any off the shelf methodology. You will need to tailor the process to your situation. For example, if you need to coordinate art assets and development assets, you need to adjust things so that both of those teams will deliver the right resources at the right times.
While I favor agile methodologies, my "brand" of agile is not any one of the off the shelf variety. I've incorporated good practices from both agile backgrounds and more formal CMMI or IEEE backgrounds. The important aspects are deciding:
All this assumes you will have basic source control management and issue/bug/feature tracking tools installed in your environment. Whether you use a particular brand of agile/formal processes or you come up with your own process, these are the minimum required elements of successful engineering. You need to be able to roll back certain changes while preserving all others (source control management), and you need to be able to make sure you close every bug you found. There are free tools available to take care of both of those aspects, so there is definitely no excuse not to.
I don't see why any management methodology couldn't apply to iOS development. It's just development, the fact that it's for a highly hyped platform doesn't really change the basics of the work.
The iOS methodology employed at my company appears to be "we can't tell you what we want until you show us something for us to dislike, and we're shocked (shocked!) that you won't be meeting the deadline." Not so different from developing for other platforms, eh? ;-)