My first encounter with containers in the Linux edition was greatly "burdened" with the previous experiences with virtualisation. The containers were another, after paravirtualisation, step towards making the visualization even "lighter" and less resource consuming! I thought they were. When my colleagues experimented with the duet vagrant + virtualbox I tried to experiment with Lxc and I was not especially interested with how the Lxc works – it was just "a virtual environment". A moment of "enlightenment" came after the Linux autumn 2016. I participated in workshop concerning Linux Namespaces – it was really interesting! However after the conference I put this subject aside. Sometime in 2017 I looked through the recordings from DockerConf 2015 where I found a recording called: Cgroups, namespaces, and beyond: what are containers made from? – it reminded me of the Linux Autumn and one of my post-autumnal resolutions: to look at Namespacom more closely!
A bit of practical observations of SCRUM – well, maybe not relating to the whole Framework, but only two of its aspects – the estimation and planning. I will begin with a short SCRUM reminding – well, as we all know, one of the main SCRUM artifacts is Backlog (the list of product backlogs) – this is a list of changes that are to be implemented in the product by the development team (or teams) working on it. The changes (tasks) on this list are discussed by the development team during the meeting called “refinement”, so during the meetings of ordering the list of product backlogs (however we should notice that the “refinement” is described by Scrum Guide as the “continuous process”, so the attitude towards the “ordering” can look differently in different teams; in teams that I worked with the meetings were organized once a week to discuss the backlog tasks). So, during the “refinement” the team tries to estimate the amount of work needed to implement tasks (removing the backlogs) written in the Backlog. Of course, the estimates concern the particular tasks, not the whole backlog that can be estimated only… generally (at least in theory). Here the first problem appears: how can we estimate the amount of work needed to implement a particular task?
