Improved slides development
process - proposal

Current issues

Efficiency

• front-end developer needs around 4 weeks to build a slide from scratch
• we have 4 slide makers in the team, it equals to 4 new slides per month
• with such efficiency level we can't deal with requests number predicted for near future

Stability

• developer environment is far from that it can be called "stable" and "well organized"
• spontaneous system crashes (backend & frontend)
• unstable develop branch
• pre-publish chaos
• it just does not help when you are struggling for finishing work before the deadline

Competency

• making a slide is not as easy as a pie
• slide maker has to do much more than just create a view and interaction logic
• average front-end developer can't handle this task (we have to look for people with special skills)

Complexity

• we have far too small common library of reusable components and utilities - when making the slide, developer has to create basic things first; even if they have been made already, nobody knows about it
• our internal front-end framework is not prepared for some slide-specific features and things which are coming - more and more workarounds everywhere

How slide development looks today

Front-end

Back-end

Front-end developer has to

• understand data
• understand aggregation logic
• know export abilities*
• finally - know, how to
  create the view

* does anybody know it?

Improvement proposal

Front-end

Back-end

Fetching data from DB

Creating view & interaction logic

Creating view-friendly data

Providing filtered data

Improving export

Slide makers

Creating common components

Core team?

• backend developers has to actively participate in the process of creating slide (preparing data, improving export); that work has to be planned, not ad hoc
• core team does not have to be separated team, just a people with time given for building components for everybody else, not just themselves

Make people responsible for what they can do well

Stop making people irreplacable 

• the view cannot be private property of single developer anymore - consider work splitting
• architecture design have to be consulted with the team, then documented
• structure as well as code style have to be standarized
• documentation at least for crucial parts of the code, like modules and data flow, also for not obvious or unclear concepts
• code reviews and refactors are the only way to make and keep code quality high

Plan the work

• estimate new slides not right before starting development - give a time for thinking
• decide, what parts may become common components, then split tasks between slide maker and core team
• set deadlines and synchronization points
• track progress to have a point of reference in the future
• describe each task on bugtracker

Use GitFlow truly

• feature and bugfix branches always, for everything?
• develop branch has to be stable and well-tested always (make tester's life harder? start using Pull Requests?)
• clear and commonly-known releases flow

It's happening today

• we are trying to estimate slides as a whole team
• we split work on slide between multiple developers
• we have a developer dedicated for export feature
• we are trying to create components with next slides in mind (menu, footnotes)
• we are trying to work with feature and release branches

We still do not

• plan tasks in advance, including frontend and backend  job
• make code reviews
• write documentation
• stabilize infrastructure and working with Git
• plan a time for creating common components
• keep an eye on Redmine