Upload
dneprciklumevents
View
476
Download
0
Tags:
Embed Size (px)
Citation preview
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!