Isso é ágil? Scrum Como melhorar a agilidade?

4

Isso é ágil ? Scrum ? Alguma sugestão sobre como isso pode ser mais ágil nas circunstâncias? Quais pontos são positivos e quais podem ser melhorados?

  • O produto é desenvolvido para um cliente que irá revendê-lo enquanto nos paga royalties.
  • A equipe não consegue falar diretamente com o usuário final. Apenas para o revendedor.
  • Um documento de requisitos do produto foi criado antes de iniciar o desenvolvimento.
  • Os requisitos são rígidos e não mudam.
  • Um cronograma de entrega foi acordado com marcos como "alfa", "beta" etc. e recursos / horários associados a esses marcos.
  • Todos os desenvolvedores da equipe Scrum se reportam ao proprietário do produto, um gerente de software.
  • Os testadores no relatório da equipe para um gerente de controle de qualidade.
  • O proprietário do produto direcionou a equipe para determinadas tarefas técnicas de alto risco. A saída dessas tarefas não é utilizável pelo usuário final, mas sim alguma tecnologia / código que eventualmente será usada no produto.
  • O proprietário do produto criou um registro posterior com base nos requisitos.
  • O proprietário do produto não pode responder a algumas perguntas sobre o produto. Ele se refere a outros ou aos requisitos documentados.
  • A equipe passa pelos movimentos do Scrum. Daily Scrum, Sprint Planning, Retrospectiva, etc. Há um ScrumMaster.
  • A cada sprint, o proprietário do produto e o gerenciamento decidem em quais itens da lista de pendências a equipe trabalha.
  • Existe um gráfico de burndown. Quadro Scrum com histórias e tarefas. As estimativas sobre esses vêm da equipe.
  • A equipe se senta em um piso aberto "bull bull" compartilhado com outras equipes, todas visíveis e audíveis. Há ruído entre equipes e há tráfego de pedestres ao redor da área da equipe.
  • A equipe pode ser solicitada a participar de várias reuniões não diretamente relacionadas às metas do sprint.
  • Existem pressões para selecionar determinadas soluções técnicas. Algumas ferramentas e processos são obrigatórios.
por Christine Agilera 22.08.2011 / 04:06
fonte

4 respostas

16

Parece que você pegou alguns itens sofisticados do desenvolvimento ágil, colocou-os no processo de cascata e agora você o chama de ágil.

The product is developed for a customer who will re-sell it while paying us royalty.

Tudo bem.

The team does not get to talk directly to the end user. Only to the reseller.

Está tudo bem. O proprietário do produto conversa com o revendedor e coleta os requisitos.

A product requirements document was created before starting development.

Isso não está certo. Eu não vi o projeto onde o conjunto de requisitos definido pode ser definido antecipadamente. Mude o seu documento de requisitos de produto para visão de produto (curta) com algum conjunto inicial de requisitos que estão sujeitos a alterações.

The requirements are rigid and do not change.

Isso não está certo e você verá no futuro que isso também não é verdade.

A delivery schedule was agreed on with milestones such as "alpha", "beta" etc. and features/times attached to those milestones.

Isso não está certo. A programação real será visível a partir do progresso da equipe. Você pode fazer marcos gerais, mas atribuir um conjunto exato de recursos que serão implementados nesses marcos não é ágil. Isso pode mudar durante o desenvolvimento.

All developers on the Scrum team report to the product owner, a software manager.

Isso não está certo. Eu não diria que os desenvolvedores reportam ao proprietário do produto. O processo de scrum mantém a visibilidade do processo, mas os desenvolvedores não relatam nada, exceto reuniões regulares. É responsabilidade do product owner estar em contato com uma equipe e como participante ativo ver o progresso em si.

Testers on the team report to a QA manager.

Isso não está certo. Os testadores devem fazer parte da equipe de desenvolvimento porque a história do usuário não é feita até que seja testada (deve haver um teste automatizado para validar os critérios de aceitação). Pode haver um controle de qualidade separado, mas é um nível adicional de testes complexos e geralmente é feito no lado do cliente (mas não tem que ser) para validar que o SW faz o que o cliente espera e o feedback é coletado como novos itens de backlog ou bugs itens de lista de pendências concluídos existentes.

Separar o QA completo fora da equipe de desenvolvimento leva a quebrar todo o propósito da definição de feito. Alguns QAs devem fazer parte da equipe e essa parte não está relacionada a nenhum gerente de QA - essa parte está comprometida com a equipe de desenvolvimento.

The product owner has directed the team towards certain high risk technical tasks. The output of those tasks is not usable by the end user but rather some technology/code that will eventually be used in the product.

Isso acontece em todos os projetos, mas deve fazer parte de algum item de backlog do produto que segmenta o usuário final. Ele pode ser incluído diretamente no item do backlog implementado na iteração atual ou pode ser incluído como um pico (prova de conceito) para esclarecer a complexidade de algum item de lista de pendências que deve ser implementado no futuro.

The product owner has created a backlog based on the requirements.

Esta é uma obrigação.

The product owner is unable to answer some questions regarding the product. He refers to others or to the documented requirements.

Isso não está certo. É tarefa do dono do produto saber as respostas. Ele tem uma responsabilidade e ele deve tomar decisões. Se ele não souber responder, ele deve encontrá-lo o mais rápido possível.

The team goes through the motions of Scrum. Daily Scrum, Sprint Planning, Retrospective etc. There is a ScrumMaster.

Está tudo bem, mas isso não significa que a equipe esteja fazendo Scrum.

Every sprint the product owner and management decide what backlog items the team works on.

Isso definitivamente não é OK. O proprietário e a gerência do produto podem fazer prioridades, mas o comprometimento (seleção dos itens mais priorizados) é responsabilidade das equipes.

There is a burndown chart. Scrum board with stories and tasks. The estimates on those come from the team.

Tudo bem.

The team sits in an open floor "bull pen" shared with other teams, all visible and audible. There is cross-team noise and there is foot traffic around the team area.

É responsabilidade do Scrum Master acabar com isso se a equipe sentir que reduz sua produtividade.

The team may be required to attend various meetings not directly related to the goals of the sprint.

Está tudo bem, o tempo perdido nessas reuniões resultará em comprometimento menor (a equipe fará menos trabalho real). Cabe ao Scrum master / management reduzir essas reuniões para aumentar a velocidade da equipe.

There are pressures to select certain technical solutions. Some tools and processes are mandated.

Isso está parcialmente OK. Pode haver requisitos não-funcionais para ferramentas e arquitetura, e pode haver processos definidos, mas a implementação final depende da equipe.

    
por 22.08.2011 / 10:54
fonte
6

Parece uma mini-queda em vez de uma abordagem totalmente ágil

Isso pode estar dividindo cabelos

Embora na superfície pareça uma abordagem ágil, acredito que tenha mais em comum com a "mini-cascata". Os projetos da Mini-Waterfall assumem que todos (ou a maioria) dos requisitos podem ser compreendidos antes que os projetos possam ser criados e que a codificação siga cada iteração ou "fase".

Isso requer um alto grau de certeza em relação aos requisitos. O Agile assume que todos os requisitos não são conhecidos até que uma versão funcional do sistema seja criada.

Time boxing vs. correção de recursos

Agile tende a ser "time boxed" (usando a metáfora Triângulo de Ferro de tempo / características / custo). Waterfall tende a ser mais "feature fixed".

Problemas com o fornecimento de mini-cascata

O problema com a entrega de "mini-waterfall" para o cliente é que geralmente eles não conseguem o que querem. Depois de dar uma olhada no software de trabalho, eles percebem tarde demais que o que disseram colocar no documento de requisitos não era o que eles queriam dizer.

O cliente pode alterar os requisitos depois de ver o software em funcionamento

Isso acontece o tempo todo, esteja preparado para fazer alterações em suas fases posteriores para atender a mudanças nos requisitos. Isso pode mudar a maneira como você aborda o design da estrutura, caso esteja esperando mudanças em seus requisitos.

Alguns conselhos para tornar isso mais ágil

If you want to stop thinking mini-waterfall and start thinking Agile…

stop thinking about building software serially, and start thinking about doing it in parallel. Stop thinking in terms of:

* Step 1: Get the requirements
* Step 2: Design the solution
* Step 3: Develop the solution
* Step 4: Test

Start thinking in terms of:

* Step 1: Figure out the first thing the user wants
* Step 2: Build a small piece, making sure it is right
* Step 3: Check with the user to see how to make it better
* Step 4: Continue until user is happy
    
por 22.08.2011 / 10:53
fonte
2

Um documento de requisitos do produto foi criado antes de iniciar o desenvolvimento. E então você constrói o projeto usando Scrum e Sprints.

É um desenvolvimento iterativo e incremental e não muito ágil.

Alguns dos chamados projetos scrum têm um documento de requisitos (PRD) escrito primeiro e também um projeto de interface do usuário feito antecipadamente, embora eles não tenham requisitos rígidos.

No mínimo, para o Agile, além do que você está fazendo, no sprint end demo O proprietário do produto, os clientes e a equipe devem fornecer feedback e o PO deve ter a capacidade de alterar os requisitos com base nesse feedback. Além disso, a equipe deve ser auto-organizadora.

    
por 15.09.2011 / 03:23
fonte
0

Não. Isto não é Scrum, nem é Agile. Especificamente:

The requirements are rigid and do not change.

O Scrum foi desenvolvido para facilitar a alteração dos requisitos. Você pode ter um projeto Scrum em que os requisitos permaneçam inalterados, mas você não pode entrar em um projeto Scrum com a restrição de que eles não podem mudar.

A delivery schedule was agreed on with milestones such as "alpha", "beta" etc. and features/times attached to those milestones.

Isso não seria possível em um projeto real do Scrum.

All developers on the Scrum team report to the product owner, a software manager. Testers on the team report to a QA manager.

Isso é um problema se a questão de "quem gerencia quem" atrapalha a sinergia da equipe. O fato de ser mencionado aqui é provavelmente uma indicação de que isso está acontecendo.

The product owner has created a backlog based on the requirements.

Uma das regras fundamentais do Scrum é que qualquer pessoa pode adicionar qualquer coisa ao backlog a qualquer momento. O backlog é uma coisa viva e fluida que representa o conhecimento em evolução das pessoas envolvidas no projeto.

The product owner is unable to answer some questions regarding the product. He refers to others or to the documented requirements.

Esta é uma grande bandeira vermelha que não é Scrum. O PO é a única pessoa na organização com PROPRIEDADE do produto. Ele pode tomar todas as decisões sobre os resultados do projeto. Se ele não pode, então você tem a pessoa errada no papel PO.

Every sprint the product owner and management decide what backlog items the team works on.

Este é o maior problema. No Scrum, o PO obtém para decidir quais são as prioridades relativas dos itens no backlog, a Equipe tem o direito exclusivo de fornecer estimativas e decidir quantos itens serão trabalhados em cada Sprint. Ninguém está autorizado a informar ao Time quantos itens estarão no Sprint.

Isso parece um desenvolvimento incremental, mas não é iterativo. Iterativo implica que você reavalie o projeto, o conjunto de recursos, os requisitos, o design e a programação de entrega no início de cada iteração - colocando-o na frente do cliente e trabalhando o que você aprendeu no projeto.

    
por 09.11.2011 / 02:22
fonte

Tags