--- 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/