Desenvolvimento e interação ágil com desenvolvedores

5

Eu li em alguns blogs que, como parte do desenvolvimento ágil, o proprietário do produto interage de perto com os desenvolvedores para declarar seus requisitos e encontrar uma solução. No entanto, no caso de um grande projeto (em termos de número de aplicativos envolvidos) envolvendo vários sistemas, isso é possível? O projeto não deve ter um analista de negócios / designer de soluções para capturar os requisitos adequadamente e chegar a uma solução que determine como o requisito pode ser atendido e quais sistemas devem fazer qual atividade?

    
por Punter Vicky 12.02.2013 / 20:17
fonte

2 respostas

3

"Product Owner" é um termo do Scrum, que é apenas uma forma de Agile. O Scrum é realmente projetado em torno da noção de pequenas equipes de sete mais ou menos dois, que fazem todo o desenvolvimento e teste da solução do projeto. A equipe trabalharia com um Product Owner, que é dono do que entra no projeto e o que não é.

Para escalar o Scrum, as organizações formaram o que é conhecido como um Scrum de Scrums, onde há inúmeras equipes, cada uma do tamanho mencionado acima, e cada uma com um Product Owner. Um representante de cada equipe (ou possivelmente o Product Owner) participa como membro de uma espécie de meta-equipe, que coordena o que as equipes individuais estão fazendo. Essa equipe teria seu próprio Product Owner, proprietário da solução maior. Em um projeto enorme, pode haver outro nível (um Scrum de Scrums of Scrums), mas isso é realmente arriscado.

Você poderia seguir esse modelo, dando a cada sistema uma equipe e um PO, e depois coordenando entre as OPs. Ou você pode tentar uma abordagem Agile diferente, como Kanban ou Crystal.

    
por 12.02.2013 / 21:03
fonte
1
O projeto não deve ter um analista de negócios / designer de soluções para capturar os requisitos adequadamente e chegar a uma solução que determine como o requisito pode ser atendido e quais sistemas devem fazer qual atividade?

em>

Em um alto nível, sim, mas a frase "capturar os requisitos corretamente" chama minha atenção. O proprietário do produto conhece os requisitos no nível mais alto. Corretamente.
Eles não são definidos em muitos detalhes porque, com o Agile, você executa a implementação com código e demos reais. Da mesma forma, para "quais sistemas fazem o quê", isso não é definido em um nível de detalhes até que seja realmente construído e possa ser visto. Nesse ponto, o usuário / proprietário / empresa do produto refinará seus requisitos.

    
por 25.11.2016 / 21:36
fonte