SDD - Spec Driven Development. Unindo REQUISITOS e DESENVOLVIMENTO
O "recado" de hoje é para o pessoal de REQUISITOS/FUNCIONAL e amigos POs: Prestem muita atenção a esta abordagem, minha aposta é que seja o futuro da nossa profissão.
Essa é TOTALMENTE NOVA para mim... PORÉM, por incrível que pareça, eu já fiz, mesmo sem saber que era isso o que eu estava fazendo... E, até posso dizer que tenho ampla experiência...
Vou colocar na fila para estudar mais a fundo e trazer mais "mastigado".... Sei que o pessoal de REQUISITOS/FUNCIONAL PRECISA aprender isso para anteontem... Não jogem fora o que fizeram a vida toda, especialmente você, que vem de Especificações Funcionais completas, de escrita de Casos de Uso, etc... Quem trabalhou na era do detalhamento está beeem na frente. Fica por aqui que eu vou explicar enquanto aprendo...
DEVS PRECISAM VER ISSO TAMBÉM!!! Pois vejo o trabalho em PARCERIA, não é substituição do trabalho de um pelo outro e vice-versa, mas, sim, uma colaboração. Não creio que para esta abordagem haja uma escolha/exclusão, mas uma união e mais um terceiro elemento a fazer o trabalho braçal: A IA.
.E, mais uma vez, reforço: É IMPRESCINDÍVEL ter uma boa redação, saber se comunicar por escrito de forma coesa e clara. Saber organizar as ideias não importando quem é o destinatário, seja um humano ou um algorítmo...
.Estudem, antes de mais nada, Engenharia de Requisitos, pratiquem detalhamento, refinem suas técnicas de discovery, ou, dado que sou RAIZ, de LEVANTAMENTO de requisitos. Ah, sim, e de redação. Saber se expressar com clareza é primordial para um bom "processo" SDD.
.ANTES de começar na prática, reencontrem a raiz, a base de tudo: A Engenharia de Requisitos. Peguem aquele velho livro de fundamentos da faculdade ou da pós que ficou esquecido na gaveta e relembrem os pontos principais. Nunca foi tão útil ter uma base sólida para o trabalho que é desenvolvido.
.Aliás, um parêntese: Nessa minha "longa estrada da vida", vi coisas do "arco da velha", de falta mesmo de conhecimento do básico de requisitos. De algo que foi para "passar", mas que não ficou na mente. Resultado? Muita falta de qualidade não apenas na definição, mas no detalhamento... Resultado 2? Funcionalidades "capengas".
.Da mesma maneira que nos projetos "normais" de desenvolvimento, uma ótima definição das regras de negócio e requisitos é o que define uma boa qualidade do restante da cadeia, principalmente, desenvolvimento e testes.
.Então, para início de conversa, a primeira impressão que tive foi essa: É preciso dar uma voltinha na essência, na base de tudo isso. Deixá-la fortalecida, pois sem isso o que é construído "acima" será capenga.
Seguirei nesta linha, mesmo já tendo uma base forte. E, conforme prometido ontem, trazer os insights que eu for tendo conforme for avançando.
.Fique por aqui que sempre vai ter novidades sobre SDD.
