Análise de Negócio numa Equipa Agile

Os processos, produtos e relações alteram-se numa equipa Agile.

Como planeamos o trabalho, entregamos o produto, representamos os requisitos, partilhamos o conhecimento, interagimos com a equipa e cliente, gerimos os requisitos em mudança e documentamos os requisitos será completamente diferente dos projectos tradicionais em Waterfall.

De facto, pass a fazer parte de uma equipa de colegas altamente colaborativos com um foco furioso em realizar valor, negociando a realização de valor em ciclos curtos e apoiando os parceiros de negócio para compreenderem o que realmente necessitam, não só no imediato, mas também conforme o produto vai aparecendo em pequenos pedaços utilizáveis.

Que muda

Os analistas de negócio devem ceder o controlo dos requisitos, a relação com o cliente e a documentação usual de requisitos. Porquê? Só porque na equipa Agile você entrega software valioso a trabalhar numas poucas semanas. E você (a sua equipa e o seu cliente) não sabem qual será exactamente o produto final mesmo até ao momento em que se começa a construí-lo, entrega-lo e obter, então, feedback sobre ele. Só então apreendemos qual é a real necessidade.

Um projecto Agile é tudo acerca de suspender o controlo durante tanto tempo quanto o possível.

Até as funções da equipa podem ser ambíguas: As especificidades podem variar, mas uma equipa Agile colabora para entregar um conjunto de requisitos a que se comprometeu. Cada membro da equipe está pronto, mesmo ansioso a fazer o que for preciso para que isso aconteça, não importa o que ditarem as responsabilidades oficiais do trabalho .

É provável que não seja o único a elicitar, analisar e especificar requisitos. A equipa está focada em entregar um software «utilizável» em ciclos curtos (iterações), assim as suas actividades podem cruzar sobre outras actividades que entusiasmam as suas competências, capacidades e interesse.

Por exemplo, é pouco provável que você se identifique ou mesmo crie e execute testes de aceitação do utilizador: a validação em cima do produto. As suas competências soft e a compreensão das dependências dos requisitos tornam-no um bom candidato para realizar o planeamento de workshops de definição do mapa de trabalhos do produto e planos de release.

Como Analista de Negócio Agile você deixou de estar preso à grande e complexa documentação de requisitos e modelos. Em vez disso, vai influenciar os seus parceiros de negócio e equipas a repensar que tipo de (e quanta) documentação é necessário. Você pode entregar a documentação em pequenos pedaços, juntamente com os pequenos e úteis pedaços de requisitos que a sua equipa de entrega em cada iteração (muitas vezes sob a forma de user stories). Você pode passar a desenvolver uma documentação leve de produto, de utilizador ou de suporte.

Novo tipo de trabalho

O seu trabalho é, ao mesmo tempo, táctico e estratégico: você tem de entender o ponto de vista global (o mapa de visão do produto e os planos de release), mantendo ao mesmo tempo uma mão firme no agora (a iteração corrente). Tem de ter a disciplina e a flexibilidade para operar em modos múltiplos (o «agora» da iteração corrente e o «depois» das próximas iterações.

O seu trabalho será transparente. Você obterá melhores estimativas e ao trabalhar com seus companheiros da equipa multifuncional pode prever com segurança quanto o software a sua equipa pode entregar em cada iteração. A visibilidade de planeamento da iteração, as demonstrações de final de iteração, e as retrospectivas não permitem permitir nenhum esconso. Você vai sentir-se mais em controlo, já que vai ser abertamente responsável perante seu cliente, a equipe, e você próprio.

Luís Quintino

Waterfall ou Agile: Como escolher a abordagem do desenvolvimento de Software?

Os projectos de desenvolvimento de software são normalmente abordados com a utilização alternativa de dois métodos, o Waterfall ou o Agile. Ambos têm prós e contras e cada um tem defensores que salientam o valor da sua abordagem preferida. \

Vamos analisar ambos os métodos e tentar compreender qual é o melhor e sob que circunstâncias respondem à questão: Como escolher a abordagem do meu desenvolvimento de Software?

O método de Waterfall (ou de Cascata)

O método de Waterfall já é usado desde 1970 e continua a ser o mais comum. Afirma que deve ser seguido um conjunto distinto de passos através do ciclo de vida do projecto. Os passos são usualmente similares a estes:

• · Análise de Requisitos
• · Desenho
• · Implementação
• · Teste
• · Instalação
• · Manutenção

A razão pela qual é denominado o método de Waterfall (cascata) é por que cada etapa decorre a partir da prévia quando esta se conclui, descendo como uma cascata. Como uma casta flui para baixo e nunca para cima. Este método é muitas vezes considerado como «mais seguro».

O método funciona bem em ambientes comerciais em que os contratos são assinados e o dinheiro é pago. Contudo. Quando se trabalha para clientes internos, é mais difícil fazer má cara a mudanças de última hora quando são as pessoas da organização que as pedem e muitas vezes com o apoio da gestão de topo.

Prós	Contras
Documentação detalhada	Início lento.
Requisitos acordados e assinados.	Requisitos fixos difíceis de mudar.
Pode ser desenvolvido com programadores com conjunto de competências mais baixo.	Não há visibilidade do software para o cliente até que o desenvolvimento esteja concluído.
Número reduzido de defeitos através de um planeamento do desenho.	Falta de flexibilidade tornando difícil mudar de direcção.
Pontos de início e de fim definidos para cada fase, permitindo que o progresso possa ser facilmente medido	Os Clientes não estão inicialmente conscientes dos requisitos.

Método Agile

O método Agile refere-se a uma abordagem iterativa a projectos, em que os requisitos e soluções evoluem através da colaboração entre clientes e equipas de desenvolvimento. O termo está ligado a 2001 quando foi lançado o «Agile Manifesto».

Se o gestor do projecto está receoso de cometer erros frente ao cliente este não é o melhor método a adoptar. O método Agile significa que criamos resultados o mais cedo possível e vamos refinando-os através diversas iterações com o cliente. Contudo, verifica-se que alguns stakeholders encaram negativamente esta abordagem.

Assim, será que o método Agile conduz a uma mais rápida entrega de resultados? Só porque conseguimos começar a programar mais cedo não significa necessariamente que iremos terminar mais cedo. Mas, garante que o resultado final vai de encontro às expectativas e necessidades do cliente, por que , principalmente, ele consegue oferecer válidos inputs durante toda a fase desenvolvimento.

Prós	Contras
Início rápido, releases incrementais e revisões regulares e feedback do cliente.	Pode ser mal interpretado como não planeado ou indisciplinado.
Evolução dos requisitos ao longo do tempo.	Exige uma equipa de alta qualidade que possa enfrentar o cliente.
Capacidade de resposta rápida à mudança.	Necessita de um envolvimento de alto nível por parte do cliente.
Menor trabalho repetido alcançado através de teste continue envolvimento do cliente.	Falta de planos detalhados de longo prazo.
Comunicação em tempo real entre o desenvolvimento e o cliente.	Produz documentação de baixo nível.

Conclusão

Então qual é o melhor método, Waterfall ou Agile?

Nenhum…

O método que usamos depende de vários factores, tais como:

Tipo de trabalho: há um resultado claramente definido? O desenvolvimento de sites da web é criativo e adere com facilidade ao método Agile. Já o desenvolvimento de sistemas de transacções, onde existe um resultado claramente definido adapta-se melhor ao método Waterfall.

Tipo de cliente: será que o cliente está disposto a trabalhar de forma iterativa, terão tempo suficiente para rever e comentar as iterações regulares?

Ponto de vista do gestor: Será que ele favorece um método relativamente ao outro. Até que ponto é ele adaptável?

Apreciação das TI na organização: as TI são vistas como um parceiro valioso ou um mal necessário? Se o ponto de vista é o último, então utilize o método de Waterfall.

Cliente externo ou interno: o seu cliente é externo ou interno? O método Waterfall funciona bem com clientes externos para os quais é normal existir um contrato assinado, pelo contrário com os clientes internos podem forçar mudanças com base no suporte da gestão de topo.

O gestor de projecto deve seleccionar o método que melhor satisfaça as necessidades dos utilizadores. O problema surge quando existem diferenças de opinião. Neste caso, escolha o método que irá realizar o melhor resultado e faça a gestão dos desacordos.

No fim ambos os métodos podem realizar o projecto. O segredo está na gestão das expectativas do cliente e na realização de um produto de qualidade. A realidade é que quando se chega ao fim da viagem, já ninguém se importa como é que lá se chegou.

LQ

Gestão de Requisitos – Maturidade da empresa

Passei os últimos dias a acompanhar alguns colaboradores de uma empresa que pretende preparar uma equipa para um desenvolvimento de alguma dimensão e necessita de compreender as necessidades do negócio e de as acompanhar ao longo do processo. Verifiquei, com algum espanto, que se pensa possível, de forma teórica, a preparação de recursos para implementar um processo de gestão de requisitos sem um prévio suporte de experiência e um cuidado consolidado no âmbito de anteriores projectos.
Pensei então que a empresa deveria tentar conhecer o estado e a forma como até agora este tipo de necessidade é encarada e que factores poderiam ser identificados para o realizar.
Em primeiro lugar, a realidade das empresas leva-nos considerar que:

1. Todas as organizações têm pontos negros – as pessoas focam-se naquilo que fazem muito bem e tendem a estar focados nestas questões e tentam sempre evitar melhorias. Muito embora isto pareça contra-intuitivo, quando se trata da maturidade da gestão de requisitos, já que aqui temos de procurar encontrar estes pontos negros – aquilo que não fazemos bem – e resolver isso para obter verdadeiros ganhos.
   
2. A maturidade da gestão de requisitos é definida de diversas formas, de uma forma elementar como possuir um conjunto estável de modelos de documentação usados pela companhia até um processo único dentro da organização definido com os recursos adequados e devidamente apoiado.

Então como podemos definir com simplicidade a maturidade da gestão de requisitos? A maturidade de um processo é sempre acerca do grau até ao qual uma organização pode ser repetível, consistente e eficiente na sua execução.
As organizações que não têm processos definidos, ou com processos mas que não são aplicados terão níveis baixos de maturidade, tal como as organizações com processos bem descritos, institucionalizados e optimizados terão altos níveis de maturidade. A questão é que não é só o processo que é necessário já que há seis capacidades a entender.

• Processo – Aquilo que as pessoas têm de fazer.
• Técnica – Como é que as pessoas irão realizar os vários passos do processo dentro de certas variações e condições.
  
• Competência dos colaboradores – As funções, papéis e competências das pessoas e o seu alinhamento para este objectivo correntemente e nas contratações futuras.
  
• Ferramentas/Tecnologia – O suporte e automação utilizados na conclusão das actividades.
  
• Organização – A estrutura de construção dos requisitos, a infra-estrutura de apoio, os serviços oferecidos pela organização e a abordagem de gestão dos recursos.
  
• Resultados – Os documentos, resultados e produtos do trabalho necessários para realizar o processo.

As pessoas falham aqui porque não vêem todas as capacidades que devem estar presentes. Um exemplo é o de uma organização com processos bem definidos e resultados, mas com um estabelecimento elementar das competências dos colaboradores necessárias e pouca formação para construir essas capacidades. Até que ponto será efectiva esta organização? Está a definir o que as pessoas devem fazer mas não está a dar as competências a estas pessoas para realizarem adequadamente as suas tarefas.
Se acredita que a sua organização tem uma maturidade elevada, então deve analisar as seis capacidades – para ver onde estão as fraquezas. A mais frágil é aquela em que se deve concentrar.
O outro erro que as pessoas fazem é pensar que os requisitos são só documentação ou só elicitação. De fato o “processo” dos requisitos é a realização de vários processos realmente importantes como:

• Planeamento e Gestão dos Requisitos
  
• Elicitação dos Requisitos (recolha)
  
• Análise e Documentação dos Requisitos
  
• Comunicação dos Requisitos
  
• Implementação dos Requisitos

Na realidade, a organização pode considerar-se madura porque é muito boa em uma ou duas destas áreas de processo, mas poucas organizações analisam todas as áreas de processo e compreendem as suas forças e fraquezas. Sublinho, que lá por sermos bons numa coisa, não significa que todo o processo é particularmente eficiente ou controlável e isso significa que não pode ser considerado maduro.
Alcançar a maturidade na gestão dos requisitos pode parecer complicado, mas é, em primeiro lugar, tratar de ser honesto com a visão que se tem da organização e aceitar que há sempre áreas que necessitam de melhoria. A maior parte do tempo, estas melhorias são em áreas que a organização «não vê» - são pontos cegos – e, mesmo muitas vezes, é necessário trazer pessoas de fora para avaliar … tal como auditores.
Por outro lado, as organizações que tem alta maturidade têm excepções, diferenças nos custos e variações de performance – mas tendem a conseguir produzir aplicações a 40% do custo das dos seus concorrentes com baixa maturidade. Qual é o investimento em TI que retorna 40% só por se ser honesto com nós próprios?
LQ