---
# System prepended metadata

title: agile_env

---

---
breaks: false
---

agile_env
=========

A concept
---------

An app that'd provide an agile development environment
    with

-  hints and automated suggestions on managing the dev process,
-  ticketing system,
-  git integration,
-  some kind of sprints that have a specific goal and state.

References
----------

References: official Scrum guide[^scrumguides],
	criticism of Scrum by Ulaş Türkmen[^notabigfan],
	monte carlo methods for scheduling by Joel Spolsky[^montecarlo],
	the "New Methodology" by Martin Fowler[^fowler]
	and wonderful talks by Robert Martin[^landthatscrumforgot],[^oop2015martin].

The inital intention was to implement the framework
    described in the official scrum guide[^scrumguides] just as is.
But it turns out some parts of the guide really lack justification.
The rest of the links elaborates on the downsides of Scrum and
    is supposed to propose some alternatives.

An excerpt from the mentioned works
-----------------------------------

#### Quantitative side

The Scrum is best characterized by Robert C. Martin[^landthatscrumforgot]
    as the principle "that every *sprint* you deliver at least *something*", some *increment*:
    you make the progress and get things done.
Kind of like a gradient descent or fix-point iteration.

A more detailed description could be as follows:
    you have a team of *devs*, *product owner* and an optional *coach* --- *scrum master*.
PO manages the backlog of user stories, prioritizes them and explains them to the rest of the team
Devs periodically do take a subset of the backlog
    thus comprising a *sprint goal* that coheres the efforts of the members of the team.
They propose a plan on how to implement it (like split stories into simple tasks).
And then they just take tasks one by one and get'em done.

Tasks and stories are usually supplied with some estimates of their time- and effort-complexity.
These estimates yield the expected amount of "Done's".
On each iteration the team *retrospects* their progress,
    comparing estimates and the actual progress,
    thus learning capacities of the team
    which in its turns allow us to set more realistic goals
    and maintain the *velocity*.

So you develop a product in *short iterations*,
    *continually adapting* to the new learned information
    about the problem and the team.
You do things in an *agile*[^manifesto] way.



| Notion   | Purpose                            |
| -------- | ---------------------              |
| Story    | A use-case or feature to implement |
| Backlog  | Prioritized list of stories        |
| Estimate | When compared to the actual outcome, tells things about the task and the team |
| Sprint   | Consolidates the efforts of the team members to deliver an increment |



#### Qualitative

That was the part 'bout "getting things done" --- a **quantitative** component.
But it doesn't really tell you anything about the development itself.
And also such an iterative process might easily get stuck
    just like the gradient descent might end up in *local minima*
    or begin constantly *overshooting* because of a too large learning rate.
    
For example if the developers' sole purpose
    was to get a bunch of "done's" or some other "points"
    and to maintain the specified *velocity*,
    there wouldn't be any reason and time for him to care about **quality**
    and you would end up with some unscalable, untestable system
    that might even need to be rewritten from scratch.

It means that the process shall be adjusted to developers needs.



[^scrumguides]: http://scrumguides.org/scrum-guide.html
[^notabigfan]: http://okigiveup.net/not-big-fan-of-scrum/
[^montecarlo]: https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/
[^fowler]: https://www.martinfowler.com/articles/newMethodology.html
[^landthatscrumforgot]: https://www.youtube.com/watch?v=hG4LH6P8Syk
[^oop2015martin]: https://www.youtube.com/watch?v=0oGpWmS0aYQ
[^manifesto]: http://agilemanifesto.org/