Agile x Design

Programação Arquitetura
#1

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?

#2

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.

#3

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 :smiley:
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, …

#4

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

#5

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

#6

[quote=urubatan]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 :smiley:
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, …[/quote]

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!

#7

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.

#8

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 …)

#9

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?

#10

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 :smiley:

#11

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…

#12

Respondendo…

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.
    [/quote]
#13

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

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.

#14

Como seriam essas interfaces entre User Stories?

#15

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

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…

#16

[quote=felipec]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?[/quote]

Em abordagens ágeis como o XP, pelo fato de não existir um papel de analista ou uma atividade chamada análise não significa que não existe análise. O XP suplementa as necessidades de análise de outra forma: TDD é uma atividade de design, Par Programming é uma atividade de design, sem contar o uso de metáforas. A diferença é que essas atividades de design são encaradas de uma maneira diferente, mas são design.

Geralmente não existe dependências técnicas a respeito das Stories. Requisitos geralmente são independentes de alguma forma. Verifique se você não está vendo uma dependência que não existe. Estive trabalhando num projeto Scrum+XP que a equipe se auto-organizava de modo que para uma mesma história podiam até 3 pessoas trabalharem juntas no código. Deixe o seu time se auto-organizar que as dependências somem. O SCRUM é bem direcionado de forma que o objetivo é que a equipe trabalhe focada sempre nos itens de maior prioridade, então, é comum que a equipe trabalhe inteira na mesma Story.

Se realmente existe a dependência bata um papo com o P.Owner e peça para ele colocar Stories não dependentes no Sprint. Converse… a chave é a comunicação.

#17