how we work

15
HOW WE WORK

Upload: senfino

Post on 11-Aug-2014

833 views

Category:

Business


2 download

DESCRIPTION

We work with great clients to develop their ideas. To do it properly we use trustworthy methods and techniques. After years of refining our process we want to share it with you.

TRANSCRIPT

Page 1: How we work

HOW WE WORK

Page 2: How we work

We work with great clients to develop their ideas. To do it properly we use trustworthy methods and techniques. After years of refining

our process we want to share it with you.

HI! WE ARE SENFINO SOFTWARE HOUSE

Page 3: How we work

We want to create great products with you. To do this you have to know some of our lingo, understand the process, what requirements, sprints

and backlog are and how much involvement we need from you.Then we can focus on development.

WHAT WE NEED FROM YOU (APART FROM MONEY, OF COURSE)

Page 4: How we work

WE HAVE A DEAL! REQUIREMENTS WORKSHOPS

We use Tom & Kai Gilb methods

to understand and compose

true requirements of the

project. Check out gilb.com!

MUTUAL UNDERSTANDING KICK OFF! DEVELOPMENT

THE PROCESS

Page 5: How we work

„We want iBeacons in our product” is easy to say, but are you certain that it is the best solution? During workshops we

deconstruct a product’s wishlist to fully understand what business purpose you want to adress and what’s the optimal way to do it.

Bottom line - good requirements save money and speed up development.

REQUIREMENTS

Page 6: How we work

SPRINT 0 SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4 SPRINT 5 SPRINT 6

Sprint 0 - the first week is intended to

test and validate assumptions. For

example: are we sure that this technology

will be the fastest way to a public version?

Start! Deadline!

Usually, a sprint is a one week long development „episode”.

Page 7: How we work

SPRINT 0 SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4 SPRINT 5 SPRINT 6

Lets say that here’s where you set a deadline for a public beta of your app - this action signifies a „fixed time project”). Things not always go

smooth but deadlines are deadlines, can’t negotiate with them :)!

To deliver a product on time we need to have variable scope. Scope is defined by identifying most important features (implemented first) and „nice to have” features (can be done in a future release). An organized

document with features is called a backlog

Start! Deadline!

Page 8: How we work

DEFINING WHAT IS MOST IMPORTANT NOW !

The business environment can change rapidly. Thanks to agile methodology we can painlessly adjust to it, change the order of

features and give you the biggest business value for your money.

Example: Let’s say we’re developing a mobile chatting app for your startup.

You saw a rival app with a geolocation sharing feature and you cannot go public

without it right now. During the next review you ask us to add this feature to the top

of the backlog. During our internal planning we assess its difficulty and give it a place

in the backlog, according to your market battle strategy. !

Of course, during this process something else has to go lower on the list and/or will

not be in this release - but it’s infinitely better than a brief that’s carved in stone,

resulting in stressful change requests.

MOST IMPORTANT FEATURE

VERY IMPORTANT FEATURE

NICE TO HAVE FEATURE

MARKET WINNING FEATURE!

this is a backlog

Page 9: How we work

MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY SATURDAY SUNDAY

USER TESTS

USER TESTS

TESTS REPORT

SPRINT PLANNING

CLIENT MEETING

DEV

DAILY SCRUM

DEV DEV DEV

CODE REVIEW

SPRINT REVIEW

CLIENT MEETING

TEST RELEASE

CLIENT INTERACTION DEVELOPMENT TEAM WORK QUALITY ASSURENCE WORK

DAILY SCRUM DAILY SCRUM

This is how our sprint looks like under the hood

Page 10: How we work

CLIENT INTERACTION DEVELOPMENT TEAM WORK QUALITY ASSURENCE WORK

MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY SATURDAY SUNDAY

USER TESTS

USER TESTS

TESTS REPORT

SPRINT PLANNING

DEV

DAILY SCRUM

DEV DEV DEV

CODE REVIEW

SPRINT REVIEW

TEST RELEASE

DAILY SCRUM DAILY SCRUM

CLIENT MEETING

CLIENT MEETING

This is important for you as a client. Here, we (as a software

house) need your opinion about project progress. As you can

see we meet (or confcall) twice a week. This could be

intensive but it pays off big time in the future.

Page 11: How we work

WHOLE PACKAGE

We think that the best way to develop apps is to have all competences under one roof.

A holistic approach will save you money because there is no additional

communication overhead with other teams or freelancers.

!Under one price, you get a developer with a complete supporting team (researcher, designer, UX designer, tester and client

service helping him produce good code.

Page 12: How we work

The cost of sprints depends on team members involvement. For example, sometimes it’s better to start Android development one sprint later than iOS to sort out potential problems with APIs. You always know the average cost of sprints. It’s easy to estimate how

much additional a month of our work will cost.

COST OF SPRINTS

Page 13: How we work

SPRINT 0 SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4DEV TEAM

IOS DEV

ANDROID DEV

BACKEND DEV

5 5 5 5

5 5 5 5

5 5 5 5

15 10 15 15 5

Average sprint cost: 15 Overall cost: 60

Page 14: How we work

1. Good requirements save money and speed up development, 2. Fixed time means variable scope of project, 3. Sprints are usually week-long episodes of work, 4. Backlog is a structurized list of product features, 5. All competences in one place shrink communication overhead, 6. Developers must have supporting teams to create good code, 7. Avarage sprint cost helps to estimate future development.

RECAP