What its all about?- What differs mobile project from ordinary one?- Is there a process silver bullet?- What kind of projects happen in mobile?- How to estimate?
Mobile Project – is it different? Ordinary projects are small Many projects are ports or somehow based on existing software – opposite to “brand new” QA specifics – lots of devices, automation is problematic Multiplatform is more a rule then an exception Levels of requirements clarity vary greatly
Process People love scrum, people talk about scrum – should I use it everywhere? Or RUP will do? – First, you need to realize, what type of the project youre working on – Then, what kind of customer do you have Ok, what then? – Use simplified models. When you want to get to market quick, have low budget – dont bury your project in process
Corner cases - Blitzkrieg. Most likely, its a port from 1 mobile platform to another. 100% clarity, low budget, needs to be released yesterday. - Trench War. Youre doing a “Dream Project” of your customer, which seems to own an oil rig.
Blitzcrieg Processes- Take 1-2 developers and a good QA- Give them a 100% clear target- Supply them with source control, bugtrack and coffee- Ideally – if its a port – establish a direct contact with customer engineering- Dont touch anything!
Trench War- Take a deep breath. Maybe, even another one- Study a book about agile processes- Explain to customer, that scrum isnt faster or cheaper- Actually, you wont hit the deadline. Trust me- Take care about issue tracking/warboard- Once you see customer can take no more, start cutting scope
Estimations – most important part- Typical risks in mobile- Coefficients to calculate QA/Bugfixing efforts- Estimating for different platforms
Typical Risks- Innovations. Youre going to use complex gestures? Display objects, relaying on accelerometer? Add time- Low requirement clarity to the moment of estimation- Unknown or broad device list- Usage of device capabilities you didnt try before, like connecting non-standard devices to BT- And dont forget all good old-fashioned risks!
Coefficients- A lot of people estimate additional efforts (management, QA) as some K * development time. Its sane, but one shouldnt forget to tune K accordingly- Average QA coefficient used is around 0.3. You dont need to tune it if youre writing for different platforms (Android & iPhone f. e.), but if youre targeting multiple similar platforms – all iphones f. e. - rise it.- Average BA coefficient is 0.2 – to make a detailed spec and give some minor support.
Different platforms- Companies race to make development more and more easy and intuitive- An intuitive summary – if target platform has got required capability at all, development times wont differ- All that would differ is risks