What would an Agile Development Process look like?

Asked

Viewed 440 times

19

In the company I work, we have not adopted a final methodology to use, and we are thinking of adopting agile development in the next projects.

What would an agile process look like? I need to create a requirement document with every specification in detail or can I describe in a readme.md and use user stories to generate our interactions with Scrum?

  • I believe it is "history" - http://wp.clicrbs.com.br/sualingua/2009/05/06/a-triste-historia-estoria/

5 answers

10

The Agile Manifesto values the following items:

Individuals and interaction between them more than processes and tools

Software in operation more than comprehensive documentation

Collaboration with the customer more than contract negotiation

Respond to changes more than following a plan

It is important to make it clear that items on the right are no longer needed, they are only less important than items on the left.

The manifest still has its principles, but the main idea behind it is to work on the points where conventional models fail the most.

Set aside very specific documentation (that often tell how the programmer should do their job), stimulate communication between team members to the maximum (with daily meetings), understand what the customer wants and have constant feedback and embrace constant change, changes in requirements or changes to bring improvements to the team.

Trying to answer your question: no matter how you make your documentation, just don’t waste much time on it. Worry more about understand what the customer wants and make it clear to the rest of the team (even if it is necessary to put the team and the client in the same room), either in the form of user stories, in 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 this may seem very abstract on paper.

So I highly recommend that you watch these videos about Extreme Programming, of Vinícius Teles in the 2008 TDC. I am not recommending that you apply Extreme Programming, but I think that explanation of Vinicius (and his great and hilarious analogies) can help you a lot, as they have already helped me.

  • Thanks! I’ll see for sure!

8

firstly, whether or not opting for the agile development methodology, I believe that your project, should have the documentation of requirements specification, no matter how small, without many details.

Contrary to what many think, which agile methodology is in "jump, or decrease" the part about the boring "documentation", agile development is not that.

Briefly speaking, agile development, Raw for example, consists in taking the project as a whole, and dividing it into parts, as we call Sprints, which is a certain time where we will develop a "deliverable" application and deliver to the customer. Sprint usually and is recommended to last about 2 to 4 weeks, this are divided into smaller stories, these stories will be divided into smaller activities yet, preferably that can be developed and finalized by a developer in one day, if it takes more than a day? See if you can break it into two or more activities.

Among other details, on Scrum there is the culture of meetings or ceremonies as are known, daily ceremonies, review and retrospective. And also the roles of the Scrum, like the PO (product Owner), Scrum Master and Team (developers).

For more details, I recommend:

http://desenvolvimentoagil.com.br/scrum/

  • 1

    Would a data model be interesting before developing a software?

  • Absolutely yes @Kevin. But it is possible to design and develop a data model without a minimum system specification?

  • 1

    No. I’m trying to come up with a simple model that has a useful amount of information for creating the software. I was thinking of having the requirements document as a document that would explain what the software is and what it does, along with the data model and user stories to describe the backlogs products.

  • Yeah, it’s a good one, you’re going the right way. Following this sequence of making the requirements document without having to for many details, then the data model, and then dividing it into stories and so emerge the details that before had not thought. For example in the requirements document you only define that there will be a user registration to log into the system, and later you detail more for example, the user will use a username or email for authentication?

  • 1

    I get it, I like that kind of approach. There is no bureaucratic thing about just starting software development with all the necessary documentation. Have the minimum to develop and add details throughout the development. One thing I wondered, since the attributes as you mentioned in the example would be added later, would it be a good idea to add the data model ? I use Visual Studio and it allows me to reverse engineer (generate the data model from the classes).

  • 1

    For, I think it would be better to have a data model before starting the project (for other people who are not fully up to the requirements will not have the notion of what is needed), or I detail this in the requirements document and do reverse engineering?

Show 1 more comment

3

An Agile development process is one that observes the Agile Manifesto, that is: respects its values and applies its principles in search of his goal.

And the goal is given by the first principle of the Manifesto:

Satisfy Customer through Early and Continuous Delivery of Valuable Software.

It may be difficult or even impossible to print all the values and principles of the Manifesto in the formalization of a process, so it is expected that the result will be obtained from the assimilation of the Manifesto as a philosophy or culture, more 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 not to use any process, because the Manifesto itself was born from processes that were already employed by its authors at the time.

The most famous examples of Agile processes are the Scrum and the Extreme Programming, each of them very open and full of gaps that allow them to be optimized for each environment (or worsened for each environment). Scrum focuses more on the level of project management 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 each day someone creates one more.

You can also create yours. Strictly speaking, just 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 software running than comprehensive documentation.

So 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.

  • Would an agile process be to develop software quickly? This is what I understand when I read about Agile Development.

  • 1

    @drmcarvalho No, it wouldn’t be. There may be other ways or other reasons for software to be developed fast. An Agile process is one that applies the Manifesto. Of course, delivering the right software and earlier is the big goal, but it is only Agile if the goal is pursued through the philosophy of the Manifesto.

2

I wrote an article in my Linkedin about this, I believe it can be useful for you based on the first part of your question.

You want to implement agile development or are simply running away from cascading development?

Implementing agile methodology in a company that was not born this way is not easy. It requires paradigm breaking and a radical change in culture and even structure.

What happens in most cases is the company claims to be agile, but simply not to be, contrary to all the concepts and rules of all the manuals on agile.

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 hardest part).

From my own experience, I tell you that this migration is neither easy nor fast. Perhaps, it is even impractical, because it depends on a number of factors that go beyond the development frontier (it involves other leaders in other areas).

But, it is worth trying to be agile. Today the market asks for it. Who can deliver value to the customer in less time leaves in front of the competition. Good luck!

1

Kevin,

I’ll leave some links to the content needed for you to learn about agile.

Read this manifesto that will help you a lot(the site is kind of retro, but is the best source for this your inquiry): https://www.manifestoagil.com.br/

Start with the principles: https://www.manifestoagil.com.br/principios.html

When you finish this study I recommend you to use an agile framework. I will recommend SCRUM. You have contributed a lot to my project and today our deliveries generate much more value to the customer.

Official website with the SCRUM guide: https://www.scrumguides.org/scrum-guide.html this material is great and can help you get a certification if you are interested.

Hugs

Browser other questions tagged

You are not signed in. Login or sign up in order to post.