viernes, 28 de junio de 2019

The software development methodology adopted at work


Currently, at work, I think because we haven’t had a big project, we all (the members of the development team) know some stuff and steps that have to be followed during the software development process, but even if it is some certain methodology, we don’t have a well-defined methodology.

Until this point this has been working fine, I think because of the talented members of the team, but if the company continue to grow on, and we start to develop some bigger projects, we should not keep working in the same way, otherwise, in the future every person will have (and know how to work with) his own methodology, and not even two people will be able to work in the same project in a productive way, because each of them will have a different point of view of something I think should be a common thing among the software development team, in other words, in the future we won’t be able to deal with the same situation anymore.

So, we definitely have to define (in a clearer way) a methodology, the question is, what kind of methodology should we define and adopt in order to increase the team’s synergy and productivity?

For what I’ve seen and read until now, I think we shouldn’t adopt a static methodology to apply to every project in the future, because each of them has its own characteristics which affect the way the dev team faces it. Then, our new well defined methodology should be dynamic, so it can be adapted to every new project in the future, generating a kind of new version of it in every project.

It’s very important that the new methodology defines in a clear way the roles of every person of the software development team, the function of each of them and how they are related with each other in order to increase our productivity and the quality of our products.

Also, in some kind of way, our new methodology has to be a solid template for the software development process, where we can clearly identify every process that the dev team have to follow, every artifact that must be generated, the software versioning policies, the way of defining the deadlines, the quality assurance policies, the releasing policies, etc.

I hope we can adopt a methodology with the characteristics described above and that it starts to change (in a good way) the way we currently develop our software products.