1. Tips & Tricks for Modern
Mobile project Management
Sergey Glebov, SteelyEye ltd.

2. 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?

3. 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

4. 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

5. 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.

6. 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!

7. 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

8. Estimations – most important
part
- Typical risks in mobile
- Coefficients to calculate QA/Bugfixing efforts
- Estimating for different platforms

9. 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!

10. 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.

11. 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

12. Thanks!