Vamos falar sobre métricas Kanban?
21 de maio de 2018
Ricardo Augusto Shikota
Currently, the development of new technologies generates new needs, which lead to other technologies, thus creating an innovative cycle. Therefore, companies, teams and employees are immersed in a fast, evolutionary process that demands rapid and adequate responses. In this context, the development team needs to be prepared for requirements changes during the project. Based on the rate that requirements advance, it is a concern to keep them up to date. This scenario calls for an agile approach of requirements gathering – a set of practices used in the survey of requirements in a holistic way, emphasized in the expected behavior of the software and focused on the business value of the application.
Agile Manifest values working on software that adds value to the customer. This requires a minimum of documentation for software development. According to Angela Wick , prioritizing documentation is not agile; whenever you prioritize collaboration and use as few documents as possible, then you are using the agile requirements approach in your project.
Agile teams focus on faster delivery of feature, instead of spending months detailing system requirements. The customer no longer has to wait months to have the system available and verify if it was correctly done. After each cycle (3 weeks on average), the client receives an executable version that can be tested in its own environment. Frequent feature delivery allows customer to make more assertive decisions about the final product.
The agile approach makes the requirement elicitation much more flexible, timely, interactive, adaptable and just-in-time. Just-in-time is perhaps the word that best fits in that context; that is, delivering the requirements according to the customer’s needs and in the established timeframe.
Another very interesting and widely adopted approach in agile teams is the participation of the customer in iterations (sprints). This enables the detection of possible requirements failures during the development process and to adapt them in real time, which in turn avoids wasting time in the development process.
Nowadays, huge, over-detailed specifications tend to be much more simpler in an agile context, where documentations are direct and summarized.
However, flows, diagrams and figures are still very welcome! It is often that the development staff needs to deploy software with an expected level of quality. Just a diagram and a good conversation between Requirements Analyst and Developer and that’s it! With minimum documentation, it is usually possible to deliver what the customer wishes.
How to quickly deliver the requirements? According to Ambler (2004-2007)  the Requirements Analyst should work together with the developers on the solution modelling, so they both understand the requirements and what they are trying to build.
When the Requirements Analyst finds himself under pressure between time and quality, the greater focus tends to stay on time. So, the most common is the person in charge of the requirements to go over the documentation without much dialogue. He or she guarantees that everything is in the document which follows a template or a checklist. However, this does not help to speed-up the requirements process. On the contrary, when most of the time for requirements gathering process is spent on documentation and review and not on planning, elicitation and analysis, the longer and more painful this process is.
Consider these 5 requirements surveying activities:
Planning, eliciting, analyzing, documenting and reviewing.
How long is your team’s dedication to these activities?
Figure 1 – Slow requirements process
Figure 2 – Faster requirements process
Conforming to Angela Wick , if your team’s invested time fits more to the first chart, beware. You may be putting a lot of effort into documenting and reviewing something that might change and, therefore, is bound to rework. This may even result in more problems than benefits. Less time should be spent on documentation and review activities. Besides requiring a lot of time from the stakeholders, these activities may be unnecessary. Changes can occur at any time, even after long meetings or during testing when new requirements might be identified.
Unlike Figure 1, the second graph (Figure 2) shows how the requirements process should be in an agile team. As requirements analysts, we must change attitude in order to achieve a critical and constructive dialogue during the elicitation of requirements and analysis. In an ideal process, from an agile point of view, requirements gathering and analysis should take about 5-10% of the documentation and review phases. This is a considerable time-saving approach change that leads to reduced risk of development rework. Therefore, this process must be completely carried out before the documentation and review steps.
What really adds value is the customer’s business knowledge. It does not matter how the requirements are identified or documented, but whether the information needed to understand the solution is clear to all stakeholders involved.
The great challenge of requirement gathering is to document knowledge in a way that is useful to everyone and can be updated to keep up with constant changes.
Keep in mind: Agile is not a method, it a new way of thinking!
I thank Prof. MSc. Igor Muzetti Pereira da ICEA-UFOP for comments that greatly improved the manuscript.