In the company that we work, we have not yet adopted a final methodology to use, and we are thinking of the next projects to adopt agile development.
What would an agile process look like? Do I need to create a requirements document with full specification in detail or can I describe it in a readme.md and use user stories to generate our interactions with Scrum?
Agile Manifesto value the following items:
Individuals and interaction between them rather than processes and tools
Software in operation rather than comprehensive documentation
Collaboration with the customer rather than contract negotiation
Responding to changes rather than following a plan
It is important to make it clear that the items on the right are no longer needed, they are only less important than the items on the left.
The manifesto still has its principles , but the main idea behind it is to work at the points where the most conventional models fail.
Put aside very specific documentation (which often says how the programmer should do his job), encourage communication between team members to the maximum daily), understand what the customer wants and have constant feedback and embrace constant changes , whether changes in requirements or changes to bring improvements to the team.
Trying to answer your question: It does not matter how you will do your documentation , just do not waste much time on it . Worry more about understanding what the customer wants and showing this to the rest of the team (even if it is necessary to put the team and client in the same room) user stories format, a Word document, a text file or several Post-its organized by the room.
As I mentioned before, the Agile Manifesto presents several principles and all of this may seem very abstract on paper.
So I highly recommend watching these videos about Extreme Programming , Vinícius Teles in the TDC of 2008. I'm not recommending you to apply Extreme Programming, but I think Vinícius's explanation (and its great and hilarious analogies) can help you a lot, just as you have already helped me.
First and foremost, whether or not you opt for the agile development methodology, I believe your project should have the requirements specification documentation, however minimal, without much detail.
Contrary to what many think, what agile methodology is in " skip, or shrink " the annoying part of "documentation", agile development is not this .
Briefly speaking, agile development, the scrum for example, consists of picking up the project as a whole, and breaking it down into parts, as we call Sprints, which is a particular time we'll develop a "deliverable" application and deliver to the customer. Sprint is generally recommended to last about 2 to 4 weeks, this is divided into smaller stories, these stories will be divided into even smaller activities, preferably that can be developed and finalized by a developer in a day, if it takes more than one day? See if you can break it into two or more activities.
Among other details, scrum exists the culture of meetings or ceremonies as they are known, daily ceremonies, review and retrospective. And scrum roles, such as the PO (product owner), Scrum Master, and Time (developers) .
For more details, I recommend:
An Agile development process is one that observes the Agile Manifesto , that is: respect your values and apply your principles in pursuit of your goal .
And the goal is given by the first principle of the Manifesto:
Satisfy the customer through the early and continuous delivery of valuable software.
It may be difficult or even unfeasible to print all the values and principles of the Manifesto in the formalization of a process, so it is hoped that the result will be obtained from the assimilation of the Manifesto as a philosophy or culture , rather than respect for detailed formal processes. After all, the Manifesto itself "values more individuals and interactions than processes and tools."
This, which is the first value of the Manifesto, should not be used as an argument for not using any process, since the Manifesto itself was born from processes that were already used by its authors at the time.
The most famous examples of agile processes are Scrum and Extreme Programming , each of which is quite open and full of gaps that allow optimization for each environment each environment). Scrum focuses more on the project management level and XP delves deeper into software engineering by promoting agile practices as TDD and Continuous Integration .
There are, of course, many other Agile processes and every day someone else creates one.
You can also create your own. Strictly, it is enough to respect the values and apply the principles through practices and behaviors, focusing on "customer satisfaction through the early and continuous delivery of valuable software."
As for the detail of how the documentation should be, the Manifesto also talks about this:
We value more working software than comprehensive documentation.
Then your Agile process should look at this value as well.
In short , a requirement to implement an Agile process, whether market or proprietary, is to study and assimilate the Manifesto, accepting it in its essence.
I've written an article in my #
Implementing agile methodology in a company that was not born like this is not easy. It requires breaking paradigms and a radical change in culture and even structure.
What happens in most cases is the company claiming to be agile, but simply not being, contrary to all the concepts and rules of all agile manuals.
To be agile the company first needs to change its culture, adjust its structure if necessary and then ensure that the development team is independent (this is the hard part).
From my experience, I tell you that this migration is not easy or fast. Perhaps, it is even unviable, because it depends on a number of factors that go beyond the development frontier (it involves other leaders from other areas).
But it pays to be agile. Today the market asks for it. Whoever can deliver value to the customer in less time comes out ahead of the competition. Good luck!
