Segey Glebov tips and tricks for modern mobile project management

Tips & Tricks for Modern Mobile project Management

Sergey Glebov, SteelyEye ltd.

What it's 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 you're 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 – don't bury your project in process

Corner cases

- Blitzkrieg. Most likely, it's a port from 1 mobile platform to another. 100% clarity, low budget, needs to be released yesterday.

- Trench War. You're 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 it's a port – establish a direct contact with customer engineering

- Don't touch anything!

Trench War

- Take a deep breath. Maybe, even another one

- Study a book about agile processes

- Explain to customer, that scrum isn't faster or cheaper

- Actually, you won't 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. You're 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 didn't try before, like connecting non-standard devices to BT

- And don't forget all good old-fashioned risks!

Coefficients

- A lot of people estimate additional efforts (management, QA) as some K * development time. It's sane, but one shouldn't forget to tune K accordingly

- Average QA coefficient used is around 0.3. You don't need to tune it if you're writing for different platforms (Android & iPhone f. e.), but if you're 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.

- Bugfixing is usually close to QA

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 won't differ

- All that would differ is risks

Thanks!