fev 022018
 

Autor – Ivar Jacobson, tradução Anderson Barcat

            Para diminuir o “gap” entre Negócios e TI nós precisamos fazer com que joguem no mesmo time.  Eu comparo este time com um time de futebol, no qual os participantes não são só especialistas mas também generalistas – todos podem chutar a bola quando convocados.

O “time” Negócios+TI  deveria funcionar de uma forma similar. Apesar de ter funções especializadas, todos devem contribuir para alcançar o objetivo comum, afim de que todos possam ser bem sucedidos.

Mas eles fazem isto? Se eles fossem um time de futebol, provavelmente eles não ganhariam muitos, ou nenhum, jogo.  Estendendo esta analogia com o futebol, a área de negócios muitas vezes age como o proprietário ausente que quer que a equipe vença, mas não quer tomar o seu tempo para estar diretamente envolvido.

Ao invés disto, eles tentam “micro-gerenciar” à distância, exigindo um plano “play-by-play” detalhando quem vai marcar o gol e quando, e repreende a equipe por não aderir ao plano.  Eles dizem que vão providenciar os jogadores (representantes de negócios e “Product Owners), mas estes jogadores estão geralmente ausentes, por estar ocupados fazendo outras coisas. Como o proprietário da equipe, eles também não querem perder muito tempo para contratar os melhores jogadores e técnicos, mas eles ainda sim querem ganhar dos times que estão dispostos a gastar mais.

Mas do lado de TI, muitas vezes isto não é melhor.  Ao invés de fornecer provas convincentes que a equipe está fazendo progresso, se escondem atrás de ‘scouts’ detalhados e jargões técnicos. Eles alegam que não podem ganhar até receber os melhores uniformes, um bom campo de treino, as melhores chuteiras e um novo estádio.  Eles passam muito tempo desenvolvendo novas estratégias e ‘scouts’ e pouco tempo no campo realmente treinando. Eles exigem que o proprietário revise e aprove todas as jogadas, e se uma jogada não funciona, eles culpam o proprietário por não fornecer um bom feedback.  Você está começando a ver as conexões? Talvez o futebol e o software não sejam tão diferentes assim!  Para ser mais direto, isto é o que geralmente acontece:

 

A área de Negócios:

  •  geralmente quer ditar o preço (ou custo) e a agenda mesmo antes de realmente entender o que eles realmente precisam ou qual o problema estão solucionando.
  • é raramente responsável pelos benefícios dos negócios reivindicados  nos planos de negócios. Os planos de negócios são muitas vezes “manipulados” para justificar um projeto que a área “quer fazer” – mas o time de projetos é responsabilizado  pelas estimativas de custo e cronograma com base em uma “lista de desejos” mal concebida de recursos e em um plano de negócio “excessivamente otimista”.
  • frequentemente sente que qualquer coisa menos do que atingir todas as expectativas iniciais, não importa quão mal compreendido, é um fracasso.
  • muitas vezes não é claro sobre suas reais necessidades e tende a demandar várias coisas que não precisa.
  • quando muda de opinião sobre o que realmente eles precisam, raramente ajustam o custo e cronograma original.
  • muitas vezes não está disposta a investir muito tempo em melhor entender suas necessidades porque isto vai “tomar muito tempo”, e ainda sim a falha na entrega será considerada uma falha de TI
  • muitas vezes não está disposta a disponibilizar acesso as pessoas com maior conhecimento porque elas são consideradas muito valiosas para serem tiradas dos seus trabalhos regulares, mesmo que o custo do projeto seja maior e a necessidade de sucesso ainda maior.
  • muitas vezes se refere ao desenvolvimento de software como uma habilidade “commodity” que eles podem terceirizar para o fornecedor com menor custo. Eles não valorizam profissionais de desenvolvimento que realmente entendem os negócios deles e geralmente não estão dispostos a investir no desenvolvimento da TI da organização como um recurso estratégico.  Mas TI não é uma vítima sem culpa neste jogo:

A área de TI:

  • geralmente aceita a situação, sentindo que eles não tem poder para fazer algo a respeito. Mesmo quando eles sabem que não podem fornecer estimativas de custo e cronograma com apenas uma vaga compreensão das necessidades, eles fornecem de qualquer maneira, e essa “vaga estimativa” torna-se a medida contra a qual o projeto é responsabilizado, mesmo quando se trata de uma  suposição “mal informada”.
  • muitas vezes carece de Gerentes de TI  que entendam de fato sobre desenvolvimento de software, e muitos não tendem a ter interesse em ser melhor informados. Como resultado eles acham que as pessoas são “intercambiáveis”, que um bom processo pode compensar a falta de habilidade e experiência, e que o sucesso significa entregar o que negócios pede ao invés do que ele realmente precisa.
  • costuma medir as coisas erradas -como a produção de artefatos – ao invés de medidas como a qualidade, redução de riscos, e o progresso real medido com a execução do software testado.
  • tende a ter uma pequena participação, não estratégica, com foco em “cool technology”, que tem pouca ligação com os benefícios aos negócios. Eles não tem a confiança de negócios  para contribuir como solucionadores de problemas estratégicos, muito em virtude de que eles não demonstram que realmente entendem o negócio e como aplicar a tecnologia para criar valor nos negócios.  Eles esperam que negócios falem o que eles devem fazer ao invés de oferecer soluções.
  • a tecnologia em si é imatura e não é bem compreendida, e as decisões algumas vezes são tomadas por “modismos” e o desejo de usar a mais nova tecnologia.
  • E Finalmente, os membros do time de TI frequentemente não respeitam as contribuições uns dos outros.  Desenvolvedores abaixam o nariz para testadores e analistas de negócios. Analistas de negócios tendem a ser indiferentes sobre se o que especificaram pode mesmo ser desenvolvido (isto é um mero detalhe), e os testadores muitas vezes não tem as habilidades para fazer mais do que testes manuais, uma vez que isto requer habilidades reais de desenvolvimento.

Há realmente uma forma simples de  quebrar estas barreira para efetivamente se trabalhar como um time?  SIM, e não.  Algumas mudanças são simples no conceito mas difíceis na execução. Outras mudanças requerem que a relação entre Negócio e TI seja repensada.  O primeiro passo a dar é parar de pensar sobre Negócios como “o cliente” e TI como “o fornecedor” -  eles precisam jogar no mesmo time, juntos, para poder ganhar.

fev 102014
 

Há 2 tipos de backlog no Scrum, que são semelhantes em estrutura, mas tem propósitos e níveis de detalhamento diferentes:

  • Product Backlog
  • Sprint Backlog

O Product Backlog lista os requisitos para o projeto priorizados de acordo com o valor entregue para o cliente; este backlog é gerenciado pelo Product Owner, e é atualizado ao longo do projeto, à medida que os requisitos são descobertos e refinados. Deve conter informações suficientes para que o time consiga realizar estimativas de desenvolvimento.

No início de cada iteração (sprint), o time revisa o Product Backlog de acordo com a priorização e identifica as estórias de maior prioridade que possam ser trabalhadas naquela iteração. Estas estórias passam a compor o Sprint Backlog para a iteração em questão.

O Sprint Backlog é gerenciado pelo time do projeto e deve conter uma lista detalhada de todas as tarefas que o time precisa completar, relativas a cada estória contida na sprint.

Portanto, enquanto o Product Backlog é criado uma vez e atualizado ao longo do projeto, um novo Sprint Backlog é criado ao início de cada iteração; e enquanto o Product Backlog é tipicamente atualizado semanalmente, o Sprint Backlog é revisado e atualizado diariamente.

 

[ Este post é parte de uma série de perguntas frequentes sobre assuntos relacionados a AGILE. Para pesquisar as demais perguntas já respondidas aqui no blog da OAT, busque pela tag AGILEFAQ  e para submeter uma pergunta, envie a sua questão para o email agile@oatsolutions.com.br ]

jan 082014
 
É fato que Requisitos bem definidos dependem fortemente das técnicas empregadas durante as atividades de levantamento; por esta razão o Analista de Negócios (ou de Requisitos) deve possuir sólidos conhecimentos em diferentes técnicas que enriquecem a qualidade dos requisitos identificados, bem como aumentam a eficiência do processo de levantamento.
Neste post serão abordados alguns dos aspectos relacionados à qualidade dos Requisitos, com foco na forma de escrita dos mesmos.