Executando verificação de segurança...
4

Ciclo de desenvolvimento de software

Muita das vezes quem esta iniciando no desenvolvimento de software ou no caso começando a programar, pensa rapidamente em algo (ideia) e ja parte para o codigo. Nao ha problema nenhum em seguir com esse fluxo quando estamos iniciando, mas com o decorrer do tempo, acredito que isso se torna desgastante e principalmente viciante (nos niveis mais iniciais).

Mas por que? Porque entramos em um looping, ficamos desenvolvendo, desenvolvendo e desenvolvendo, sem ter pelo menos levantado (anotar) as ideias principais. E no pior dos casos, se tornamos refem desse ciclo, levando isso para o trabalho por exemplo, pegando Tasks e sem pensar duas vezes, corremos para o codigo.

Mas como podemos melhorar isso? Acredito que o ideal e ter um processo por tras de qualquer acao, mesmo que chato. Irei dar exemplos para projeto proprio e tambem para um freela.

Mas que processo e esse? Um ciclo de desevolvimento de software (serio?). Esse ciclo "basico" se consiste em 5 etapas (nao acho interessante pular nenhuma delas).

Primeira etapa: Idealizacao

  • E o surgimento da ideia, podendo ser nossa ou de um cliente. Tambem tem aquele famoso tio que tem a ideia de criar um novo Uber ou um novo Instagram no churras do domingo, por exemplo. E interessante anotar cada ponto da ideia, evitando esquecer regras ou fluxos interessantes...

Segunda etapa: Levantamento de requisitos (aqui voce DEVE especificar todas as paradinhas)

  • Voce vai levantar o que precisa ser feito e principalmente o que NAO precisa ser feito. Pensando em um freela por exemplo, devemos deixar cada requisito bem definido, evitando aquelas features que nao acabam mais.
  • Quando fazemos esse levantamento, conseguimos ter clareza de quais caminhos tomar. Evitando aquele looping que comentei mais acima. Nao devemos colocar a mao no codigo sem ter essa clareza, para ter nocao, nem falamos de codigo ainda....

Terceira etapa: Validacao (so vem para ca quando levantar os requisitos, sem eles esquece)

  • Quando e um projeto proprio, fica ate mais facil realizar a validacao, mas quando estamos com um freela por exemplo, devemos ter uma boa conversa com o cliente. Nos presumimos muito na hora de levantar os requisitos e as vezes pensamos em coisas que nao e o que o cliente estava esperando (as vezes ele nem sabe o que quer tambem), por isso que essa parte e bem importante.
  • Podemos ficar indo e voltando entre esta etapa (terceira) e a segunda etapa.

Quarta etapa: Desenvolvimento (aqui chegou a parte que nos dev gostamos, mas calma ai...)

  • Voce so vai prosseguir com essa etapa se tiver com a segunda e terceira finalizada. Principalmente a segunda se for um projeto proprio, agora para um freela, tanto a segunda quanto a terceira precisam estar BEM definidas.
  • Aqui voce vai mergulhar no desenvolvimento SEM DO (la ele), implementando cada requisito levantado na segunda etapa. Sem ficar andando para la e para ca, pois, agora temos um norte bem definido (nada de SUL, friozao pra la)...

Quinta etapa: Entrega (finalmente a entrega/finalizacao, se for um freela, podemos pensar no pagodinho hehe)

  • Aqui e simples, desenvolveu um site? Joga no ar esse trem. App? Publica ele! Projeto proprio? Mesma coisa hehe....

"Se nao sabe para onde ir, qualquer caminho serve" Maravilha no pais da Alice.

E ai, o que acha dessa ideia?

Carregando publicação patrocinada...
2

Como você valida algo que não fez? Algo que está na sua cabeça, em alguns casos não sabe se é exequível, ou mesmo que tem alguns papeis escrito algumas coisas.

Me parece que para o projeto encomendado não é validação, é aprovação dos requisitos, que dará bom resultado se souber comunicar muito bem. Se é um projeto próprio, que você não sabe se tem cliente, se é isso mesmo que ele quer, vai fazer como?

Leia sobre as Sopas Campbell no Brasil, especialmente sobre a validação no papel.

Há diversos livros de engenharia de software de autores diferentes que já validaram bem melhor o processo de ciclo de desenvolvimento. Não tem um único porque não é simples, o segredo é saber fazer dar certo mais que is passos a seem feitos, mas todos foram feitos por gente extremamente qualificada, o que não impede dar errado. Tem coisas que não precisamos reinventar a roda.

Não tem anda errado aí, mas não ajuda muito quem precisa aprender o processo de forma mais detalhada, então para o leigo eu sugiro procurar algo que explique melhor todo o processo.

S2


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

2

Achei o texto um bom ponto de partida para quem está desenvolvendo algo sozinho ou ainda não tem um caminho definido, porém quando trabalhamos em um grande projeto com uma ou mais equipes essas etapas podem sofrer "N" alterações para que o time caminhe sempre na mesma página.

Trabalhar em equipe (principalmente desenvolvedores com seus hábitos e manias esquisitas) exige que o fluxo de organização seja um consenso entre todos os pontos de vista e para mim é nesse ponto que encontramos a maior dificuldade, pois na mesma equipe podemos encontrar desenvolvedores com uma bagagem organizacional gigantesca vinda de experiencias em big techs, por exemplo, e desenvolvedores com a mesma quantidade de experiencia porém vinda daquela clássica empresa de ERP do interior do estado em que o CTO é o melhor amigo do dono e todas as tarefas precisam ser entregues magicamente dentro de prazos impossíveis, ambos terão visões totalmente diferentes de como deve ser o ciclo de desenvolvimento.

Por isso acredito que ao invés de fixar um padrão a ser seguido o ciclo de desenvolvimento ideal é aquele que a equipe como um todo conhece, acredita e confia que trará os resultados esperados, e caso não esteja trazendo esses resultados deve-se sentar com o time e realinhar os pontos que acharem necessários para atingir os resultados esperados.

Com isso, ao se perguntar "qual o melhor ciclo de desenvolvimento?" a resposta sempre será o bom e velho DEPENDE.