Agile x Design

Debugger Membro desde: 05/04/2007 20:42:19 Mensagens: 67 Offline

Leitura que me motivou a postar aqui:
http://www.infoq.com/news/2007/07/AgileBadForDesign

Comecei a ler sobre Scrum faz pouco tempo e XP eu já conhecia um pouco, mas ultimamente tenho dado mais atenção e tenho tentado compreender melhor para por em prática...

Minhas dúvidas...

Vamos por partes:

Em Scrum+XP, não temos uma "fase de análise" mas isso não impede de que seja feita uma análise do domínio, certo?

Um product backlog, alimentado com Users Storys pode não ter informações suficientes para modelar um sistema por completo, mas até ai, acho que não temos muitos problemas... a ideia é fazer incrementalmente, certo?

Modelamos em partes e depois vamos refatorando para incrementar o nosso modelo(foi assim que eu compreendi pelo menos, posso estar enganado)

Vamos supor, que no inicio de um projeto, eu tenho 2 user storys, que vão entrar na mesma Interaction (e que estao no backlog de um mesmo sprint) onde X depende de Y.

Eu gostaria de evitar que X esperasse por Y, se possível.

Qual seria o procedimento "mais correto" ou que vocês julgam mais adequado?

Criar uma tarefa que modelasse parcialmente o dominio(contemplando X e Y) antes de comecar a implementar das US (user storys) X e Y? Existe alguma outra solução?

Se isso não for feito, não existe o risco de ser feito um design ruin, que pensou em Y antes de X?

A mesma pergunta do post..

Como evitar que a arquitetura não fique de lado durante o desenvolvimento usando Scrum+XP?

JavaChild Membro desde: 10/01/2007 00:54:33 Mensagens: 120 Offline

Parabéns pelo tópico Felipe!!!
Estou começando com o scrum agora e tb tenho esse tipo de dúvida.

então, acho que eu faria a mesma coisa: tentaria resolver essa modelagem logo no início do meu sprint. Eu acho que apesar de X e Y serem dependentes, isso não prejudicaria o andar da iteração. Lógico, se a equipe realmente for pequena e o tamanho do sprint razoável.
Com certeza vc vai ter atividades que podem ser feitas sem a definição do modelo. Enquanto parte do seu time está fazendo essas outras atividades, uma ou duas pessoas estão vendo o domínio.
Além disso vc não vai fazer uma análise que vá demorar dias, semanas e gerará kilos de papelada...Se contar que você pode rapidamente definir parte do domínio que não irão se interagir e de boa.

na equipe que estou trabalhando, cada sprint tem 15 dias úteis que estão divididos da seguinte forma:
3 - design, ou seja, todo o design, apenas do que esta incluido neste spring entra nestes 3 dias
9 - desenvolvimento do sprint
1 - dia de integração, para aparar arestas que possam estar com problemas, ou seja, tudo o que foi desenvolvido tem que funcionar junto
2 - documentação do que foi feito e correção de bugs

não é scrum + XP, mas é Scrum

esta divisão é só para o pessoal de desenvolvimento, durante este tempo ja esta sendo escolhido o que vai entrar no próximo spring, o product backlog esta sendo atualizado, ...

O fim de semana não é descontado, Rodrigo?

é descontado sim, como eu falei, são 15 dias úteis, por tanto 3 semanas corridas

Debugger Membro desde: 05/04/2007 20:42:19 Mensagens: 67 Offline

urubatan wrote:na equipe que estou trabalhando, cada sprint tem 15 dias úteis que estão divididos da seguinte forma:
3 - design, ou seja, todo o design, apenas do que esta incluido neste spring entra nestes 3 dias
9 - desenvolvimento do sprint
1 - dia de integração, para aparar arestas que possam estar com problemas, ou seja, tudo o que foi desenvolvido tem que funcionar junto
2 - documentação do que foi feito e correção de bugs

não é scrum + XP, mas é Scrum
esta divisão é só para o pessoal de desenvolvimento, durante este tempo ja esta sendo escolhido o que vai entrar no próximo spring, o product backlog esta sendo atualizado, ...

Legal... uma curiosidade..

Porque 15 dias e não 30? Você ve quais vantagens em um sprint de 15 dias?
(forças ocultas me fazem escrever "sprint" o tempo todo errado ahuehua..)
Valeu!

eu acho mais interessante iterações de até 15 dias. menos cansativo, menos riscos nas integrações e equipe mais participativa com reuniões evolutivas e entre outros benefícios. Atualmente não estamos trabalhando em cima disto, mas está sendo um mdc pretendido.

JavaChild Membro desde: 03/08/2005 15:06:13 Mensagens: 147 Offline

Um lance legal, que aproxima o cliente do sistema (durante o desenvolvimento), foi isso aqui:
http://www.lixo.org/archives/2007/02/08/how-would-you-improve-this-page/
(acho qeu desfoquei um pouco o post, mas ...)

urubatan wrote:é descontado sim, como eu falei, são 15 dias úteis, por tanto 3 semanas corridas

Ah, tá! Não prestei atenção no úteis... Foi mal!

Nunca trabalhei com Scrum, infelizmente, mas não seria mais interessante um tempo de interação menor? 10 dia úteis, por exemplo? Quais seriam as dificuldades para se trabalhar assim?

acho que se estivessemos trabalhando com Scrum + XP por exemplo, acho que um sprint menor seria mais indicado, mas como não é o caso, e precisamos do tempo de design no inicio do sprint, acho que 15 dias úteis ficou um bom tempo ...
Mas não fui eu quem definiu isto, estou como developer na equipe apenas

JavaChild Membro desde: 10/01/2007 00:54:33 Mensagens: 120 Offline

Acho que a duração do sprint é muito relativa.
Se você tem dúvidas de qual é melhor, teste!!!
Faça o primeiro sprint com 3 semanas, o outro com 2 semanas, o próximo com 4...
Dessa forma vc consegue ver qual é a melhor duração para a sua equipe. Além disso, depende do projeto..

Na minha empresa usamos 2 semanas. Pq os projetos são menores e as pequenas entregas têm um conteúdo reduzido.

Importante ressaltar que deve haver um intervalo entre os sprints...Um sprint suga muito a equipe..No final de cada sprint um dia de tranquilidade..

Respondendo...

felipec wrote:
Vamos supor, que no inicio de um projeto, eu tenho 2 user storys, que vão entrar na mesma Iteration (e que estao no backlog de um mesmo sprint) onde X depende de Y.

Eu gostaria de evitar que X esperasse por Y, se possível.

Qual seria o procedimento "mais correto" ou que vocês julgam mais adequado?

Vejo a princípio duas opções:
- Criar interfaces entre as User Stories
- Reescrevê-las de tal forma que seja mais natural desenvolvê-las sequencialmente.

luciene.silva wrote:Acho que a duração do sprint é muito relativa.
Se você tem dúvidas de qual é melhor, teste!!!

Você está certa. Métodos ágeis são empíricos por natureza, então siga o lema "Inspect, Adapt":
- Comece fazendo o sprint com x dias (contando úteis ou não, fica a seu critério)
- Ao final, faça uma retrospectiva do que deu certo e errado
- Modifique se necessário

Minha experiência é que cada equipe e cada projeto se adapta melhor a um modelo de iterações diferentes. Um fator que eu costumo verificar pra definir o tamanho do sprint é quantas vezes é preciso mudar o planejamento dentro do sprint. Se isso ocorre frequentemente, provavelmente o sprint está muito longo. Se nunca ocorre, pode ser que o sprint possa ser esticado.

Debugger Membro desde: 05/04/2007 20:42:19 Mensagens: 67 Offline

s4nchez wrote:
Vejo a princípio duas opções:
- Criar interfaces entre as User Stories
- Reescrevê-las de tal forma que seja mais natural desenvolvê-las sequencialmente.

Como seriam essas interfaces entre User Stories?

Interface entre user story seria algo parecido com o que você falou:

Criar uma tarefa que modelasse parcialmente o dominio(contemplando X e Y) antes de comecar a implementar das US (user storys) X e Y?

Só sugiro que se perca o mínimo de tempo possível nesta modelagem e faça com que quem implemente X e Y se comunique o quanto for preciso...

Notícias, artigos e o maior fórum brasileiro sobre Java