NA PR?TICA, VALE A PENA USAR MEDOLOGIAS ?GEIS?
Bom dia!
Prezados colegas,estamos tentando definir
uma metodologia de desenvolvimento de
software [Ô]formal[Ô] para a equipe.
Peço ajuda dos colegas,para esclarecer algumas dúvidas práticas
sobre [Ô]Metodologias ágeis[Ô]:
1) No [Ô]Scrum[Ô] , o normal é realizar os [Ô]testes[Ô], para todas as pequenas entregas que fazemos ao cliente.
Ou deixar-mos para fazer a fase de testes , quando o projeto tiver que ser entregue como um todo?
2) Na documentação do Scrum, deve-se documentar todas as regras de [Ô]negócio[Ô], [Ô]funcionais[Ô] ,[Ô]não funcionais[Ô]
como na documentação tradicional. Ou deve-se ater apenas as [Ô]funcionalidades[Ô] solicitadas pelo usuário?
3.) Na documentação do Scrum , devem constar informações detalhadas sobre o Banco de Dados ( Estrutura de todas
as tabelas,finalidade de cada campo,etc... ). Ou no Scrum, somente se deve documentar algo sobre o banco se isto
for indispensável?
Agradeço qualquer orientação.
Obs: Também peço dicas sobre vantagens e desvantagens, em se usar metodologias ágeis.
Prezados colegas,estamos tentando definir
uma metodologia de desenvolvimento de
software [Ô]formal[Ô] para a equipe.
Peço ajuda dos colegas,para esclarecer algumas dúvidas práticas
sobre [Ô]Metodologias ágeis[Ô]:
1) No [Ô]Scrum[Ô] , o normal é realizar os [Ô]testes[Ô], para todas as pequenas entregas que fazemos ao cliente.
Ou deixar-mos para fazer a fase de testes , quando o projeto tiver que ser entregue como um todo?
2) Na documentação do Scrum, deve-se documentar todas as regras de [Ô]negócio[Ô], [Ô]funcionais[Ô] ,[Ô]não funcionais[Ô]
como na documentação tradicional. Ou deve-se ater apenas as [Ô]funcionalidades[Ô] solicitadas pelo usuário?
3.) Na documentação do Scrum , devem constar informações detalhadas sobre o Banco de Dados ( Estrutura de todas
as tabelas,finalidade de cada campo,etc... ). Ou no Scrum, somente se deve documentar algo sobre o banco se isto
for indispensável?
Agradeço qualquer orientação.
Obs: Também peço dicas sobre vantagens e desvantagens, em se usar metodologias ágeis.
Vamos lá:
- Documentação é que nem dinheiro, quanto mais melhor. E a organização deles também é importante, separe as responsabilidades o máximo que puder e até mesmo [Ô]documentos de ligação[Ô], que são parecidos com o mapeamento de POCO.
- Pela regra mais básica do SCRUM, você deve sempre testar todas as User stories de todos os sprints. Essa é a única maneira de garantir que tudo vai estar redondinho para o cliente.
- Uma coisa importante sobre usuários é que eles [Ô]não sabem o que querem[Ô]. Eles vão quase sempre dar uma idéia genérica do que eles querem que a aplicação faça. O que deve ser construÃdo para atender essas necessidades é com você. Cada funcionalidade requisitada(User Story), pode(e quase sempre é) ser dividida em várias pequenas tasks, o que facilita deploy, testes e tudo mais. Em contra partida, tasks podem ser dependentes e uma task pode ter dependências de várias outras, impossibilitando o deploy parcial.
- Metodologias ágeis são usadas e abusadas por todos os produtores de software, ainda mais enfatizadas quando se trabalha em equipes. Não que não seja possÃvel ser feito quando se está sozinho, mas em equipes as metodologias de trabalho faz muito mais sentido.
Obviamente, isso tudo em teoria. Na prática não é sempre assim...
- Documentação é que nem dinheiro, quanto mais melhor. E a organização deles também é importante, separe as responsabilidades o máximo que puder e até mesmo [Ô]documentos de ligação[Ô], que são parecidos com o mapeamento de POCO.
- Pela regra mais básica do SCRUM, você deve sempre testar todas as User stories de todos os sprints. Essa é a única maneira de garantir que tudo vai estar redondinho para o cliente.
- Uma coisa importante sobre usuários é que eles [Ô]não sabem o que querem[Ô]. Eles vão quase sempre dar uma idéia genérica do que eles querem que a aplicação faça. O que deve ser construÃdo para atender essas necessidades é com você. Cada funcionalidade requisitada(User Story), pode(e quase sempre é) ser dividida em várias pequenas tasks, o que facilita deploy, testes e tudo mais. Em contra partida, tasks podem ser dependentes e uma task pode ter dependências de várias outras, impossibilitando o deploy parcial.
- Metodologias ágeis são usadas e abusadas por todos os produtores de software, ainda mais enfatizadas quando se trabalha em equipes. Não que não seja possÃvel ser feito quando se está sozinho, mas em equipes as metodologias de trabalho faz muito mais sentido.
Obviamente, isso tudo em teoria. Na prática não é sempre assim...
Como KERPLUNK disse, em equipe a Metodologias Ãgeis é útil, agora trabalhando sozinho eu não vejo sentido.
Eu acabei virando PJ (HomeOffice) pois minha esposa passou em um concurso público e fomos embora de Bauru mas, continuo trabalhando para a empresa em que eu estava como prestador de serviços. Temos as equipes e trabalhando com Metodologias Ãgeis. Usamos o Trello para controlar os cards e o JIRA também, esse controla as horas do tempo de desenvolvimento e temos também um quadro na parede onde ficam colados os cards que na minha opinião só serve para as outras equipes ver o que estamos fazendo já que usando o Trello e o JIRA.
Agora, tenho uns projetos em paralelo e não uso Metodologia Ãgeis.
O quadro é meio parecido com esse da imagem(KANBAN)
Eu acabei virando PJ (HomeOffice) pois minha esposa passou em um concurso público e fomos embora de Bauru mas, continuo trabalhando para a empresa em que eu estava como prestador de serviços. Temos as equipes e trabalhando com Metodologias Ãgeis. Usamos o Trello para controlar os cards e o JIRA também, esse controla as horas do tempo de desenvolvimento e temos também um quadro na parede onde ficam colados os cards que na minha opinião só serve para as outras equipes ver o que estamos fazendo já que usando o Trello e o JIRA.
Agora, tenho uns projetos em paralelo e não uso Metodologia Ãgeis.
O quadro é meio parecido com esse da imagem(KANBAN)
Citação:1) No [Ô]Scrum[Ô] , o normal é realizar os [Ô]testes[Ô], para todas as pequenas entregas que fazemos ao cliente.
Ou deixar-mos para fazer a fase de testes , quando o projeto tiver que ser entregue como um todo?
2) Na documentação do Scrum, deve-se documentar todas as regras de [Ô]negócio[Ô], [Ô]funcionais[Ô] ,[Ô]não funcionais[Ô]
como na documentação tradicional. Ou deve-se ater apenas as [Ô]funcionalidades[Ô] solicitadas pelo usuário?
3.) Na documentação do Scrum , devem constar informações detalhadas sobre o Banco de Dados ( Estrutura de todas
as tabelas,finalidade de cada campo,etc... ). Ou no Scrum, somente se deve documentar algo sobre o banco se isto
for indispensável?
Acabei não comentando isso.
Sim, na documentação tem que ter todos os itens acima.
A imagem é sobre uma documentação sobre as regras de negócio.
Adendo:
Usar todas as metodologias para quando se está sozinho não faz muito sentido. Mesmo assim, ter documentação da sua aplicação é SEMPRE uma ótima pedida. Tão importante quanto tê-las, é atualizá-las.
Usar todas as metodologias para quando se está sozinho não faz muito sentido. Mesmo assim, ter documentação da sua aplicação é SEMPRE uma ótima pedida. Tão importante quanto tê-las, é atualizá-las.
Prezados colegas,
Eu me esqueci de fazer uma pergunta importante:
No caso das metodologias ágeis (Scrum), o correto
para obter bons resultados, é fazer a equipe trabalhar
em um projeto de cada vez. Ou , usando Scrum
a [Ô]mesma equipe pode trabalhar em vários projetos
ao mesmo tempo???
Eu me esqueci de fazer uma pergunta importante:
No caso das metodologias ágeis (Scrum), o correto
para obter bons resultados, é fazer a equipe trabalhar
em um projeto de cada vez. Ou , usando Scrum
a [Ô]mesma equipe pode trabalhar em vários projetos
ao mesmo tempo???
é possÃvel trabalhar em vários projetos, desde que a documentação e conhecimento da equipe esteja alinhado com o projeto.
Pessoal,
Obrigado pelas respostas.
Obrigado pelas respostas.
Tópico encerrado , respostas não são mais permitidas