If we step away for a moment from software development and we try to define what uncertainty is, as a concept, we may come up with tons of definitions and synonyms, starting from the obvious, lack of certainty, but also we could go through terms like vagueness, unknown, unobservability, stochastic(random), undefined, unstable, variable, undetermined, unreliable, insecure, doubtful, ambiguous,… all of these terms are states that we cannot describe or outcomes that we cannot predict. Therefore, we can assume that the uncertainty for every situation is determined by two categories:
Scrum master: promoter of the theory, practices, rules, and values of scrum.
Companies didn’t want to use scrum, it was never the goal. Companies try to figure out how to build the right thing at the right time for their customers. They are after customer satisfaction but it turned out that predefining the release dates, trying to land on predetermined targets, defining previous big designs upfront,… it used to work, but now, simply it does not work anymore.
Successful companies are turning into empiricism, observing behaviours and outcomes, inspecting what is going on and making frequent adaptations. …
User story: Informal description of a feature of a software system
In agile, a user story is a functional increment of the software, agreed with the customer or with the product owner. Each user story must contribute adding value to the product. When writing a user story we must specify for who is made, what is done, and why it is done, explaining the business value added. Defining good user stories affects directly to every stage of the story lifecycle that we are going to visit after.
There is an assessment you can perform to your user stories to evaluate…
Software Quality: Not only working software, but also well-crafted software
Just like every other myth, there is a scary story behind it. The story in this case is this software project that a certain company started. After months of thinking and planning, the directors of the project finally got the budget to kick off. They started hiring people to begin with this business idea that will make them millionaires.
At the beginning, there were only a few people there, and like every beginning, this was a sweet phase. Everybody was happy and extremely motivated. All the members of the team…
Team: NOT just a group of people working together.
The software industry has changed a lot in the last years, well… actually, it changed a lot since it started, and it may change a little more until it reaches a proper level of maturity. We (as industry) have problems understanding these fast paced changes, so it becomes a real challenge to react properly to it.
The most important thing about software development is the communication between humans, between the members of a team primarily and secondly with customers. The later we cannot control how it is done and organized, but…
Agile: able to move quickly and easily.
Almost 20 years ago, in 2001, few software developers got together in a ski resort in the mountains of Utah to discuss software development methods. The 17 people there were: Kent Beck, Ward Cunningham, Dave Thomas, Jeff Sutherland, Ken Schwaber, Jim Highsmith, Alistair Cockburn, Robert C. Martin, Mike Beedle, Arie van Bennekum, Martin Fowler, James Grenning, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, and Steve Mellor.
As an action to turn away from the documented driven, regulated, planned and micromanaged methodologies to develop software widely used, all these ̶c̶e̶l̶e̶b̶r̶i̶t̶i̶e̶s̶ developers were related…
Code Smell: An indicator of a design principle violation
What are code smells?
The term was popularized by Kent Beck in the late 90s and its usage increased after appearing in the well known Martin Fowler’s book Refactoring. Code smells are indicators that something may be wrong in a piece of code. They are not a problem just because they are a smell, a deeper analysis is needed to determine if there is a problem or not.
In order to clarify, let’s see what code smells are not?