Principais Conceitos

Planear e estimar são duas atividades fundamentais para o sucesso de qualquer projeto, qualquer que seja o seu tamanho ou objetivos. Os planos guiam decisões de investimento, indicam o que é preciso e o que está disponível para trabalhar num projeto, numa determinada altura e se o este está no caminho certo para apresentar, no produto final, as funcionalidades requeridas. Um plano, por mais ou menos profundo que seja, pode ser difícil de cumprir e por vezes incluir erros. Trabalhar com um tem, assim, dois extremos: a equipa coloca tal esforço na elaboração do plano, que se convence que este deve dar certo; ou trabalha sem um plano definido e não é capaz de responder a questões básicas relativamente ao produto ou processo (Cohn, 2006).

Planificar é uma tentativa de encontrar uma solução ótima para a questão global de desenvolvimento do projeto, devendo a planificação ser feita de forma interativa e incremental. Este processo de planificação deve suportar a redução de risco e de incerteza, apoiar tomadas de decisão, estabelecer confiança entre os membros da equipa e promover a partilha adequada de informação. Um bom plano é, portanto, aquele que as partes interessadas consideram suficientemente confiável para ser utilizado como base para a tomada de decisões. Para cumprir da melhor forma a sua principal função este plano torna- se mais específico ao longo do tempo. Planos e cronogramas são úteis para além do processo de desenvolvimento pois influenciam áreas adjacentes ao mesmo, seja ao nível de campanhas e marketing, agendamento de atividades, lançamento de produtos, treino de utilizadores entre outros. A planificação em projetos ágeis, por sua vez, abandona o foco no plano – documentos, figuras – dando ênfase ao planeamento – atividade, processo. Assim, a planificação ágil equilibra o esforço e investimento na planificação inicial com a possibilidade de rever o plano ao longo do projeto. Esta revisão pode levar a alterações que significam, para o processo de desenvolvimento, aprendizagem ou prevenção de erro: se uma mudança for digna altera-se o cronograma. O processo de planificação permanece quando o plano fica desatualizado muito facilmente; assim, um plano é considerado ágil quando se mostra facilmente disponível para alterações. É importante ver um projeto como uma forma rápida e confiável de gerar um fluxo de novos recursos úteis e novos conhecimentos: as novas capacidades são entregues no produto e o novo conhecimento é utilizado para fazer o produto da melhor forma possível. Num projeto ágil o fluxo de novas

capacidades e conhecimentos é utilizado para orientar o trabalho em curso; uma equipa ágil sabe quando terminar mas não sabe qual vai ser o resultado entregue no final. Quando o resultado final é desconhecido, a planificação torna-se um processo de criação e revisão de metas que levam a um objetivo a longo prazo. Neste processo, é importante ter em conta que são se vê para além do horizonte e que a precisão de um plano diminuí rapidamente quando se tenta planear para além do que se pode ver. O projeto está em risco quando a sua planificação se estende para além do horizonte conhecido e não incluí folga temporal para a realização de ajustes, como tal, o plano é elabora de forma progressiva ao longo do projeto (Cohn, 2006).

Conh (2006) defende que as equipas ágeis têm três horizontes de planificação: o lançamento, a iteração e o diário. A planificação de lançamento tem como objetivo determinar uma resposta apropriada às questões de foco, cronograma e recursos de um projeto, ocorrendo no início deste mas não sendo considerado um esforço isolado. O planeamento para este horizonte deve ser atualizado ao longo do projeto, preferencialmente no início de cada iteração, para que reflita sempre as expectativas atualizadas sobre o que será incluído na versão final. A planificação de iteração é conduzida no início de cada iteração e consiste em, com base no trabalho realizado, identificar as tarefas de alta prioridade para transformar requisitos em software em funcionamento e testado. Como este planeamento lida com um horizonte mais próximo que o referido anteriormente os componentes do plano podem ser menores. Por fim, a planificação diária é realizada normalmente em reuniões rápidas com o objetivo de coordenar trabalho e esforços diários, avaliando e revendo os planos.

Equipas ágeis trabalham em conjunto mas incluem papéis específicos – proprietários, clientes, utilizadores, developers, gerentes entre outros. Assim, estas equipas trabalham em iterações curtas e tempo fixo, de forma a entregarem um produto no final de cada iteração prevista (Cohn, 2006).

Apesar das metodologias ágeis defenderem um trabalho pouco planeado, não é desprezada a existência de um plano, apesar de este não ser tão profundo e ser desenvolvido de forma diferente. Metodologias ágeis são baseadas no planeamento “Just- in-Time”: a quantidade de planificação é limitada, só aquilo que é necessário para iniciar o processo é planeado, o resto é planeado apenas quando se torna essencial. Este tipo de planificação permite um início rápido do projeto e evita esforços desnecessários, no entanto, torna mais difícil prever com precisão custos globais e cronograma do projeto (Cobb, 2011).

Cobb (2011) defende que as metodologias ágeis incluem tipicamente cinco níveis de planeamento. O primeiro, “Vision”, incluí definir metas e objetivos que o projeto deve realizar, marcado pela atividade “declaração de elevador” que deve dar informações sobre: para quem, quem, nome e categoria do produto, característica diferenciadora, alternativa competitiva e grau de diferenciação; “RoadMap” incluí quebrar a visão em partes para descrever a funcionalidade global requerida, que será entregue ao longo do tempo. Cada versão torna-se um subconjunto da funcionalidade geral, entregue de forma incremental, assim, descreve-se as características de funcionalidade do sistema que serão concluídas em cada entrega aproximadamente quando cada versão será entregue. “Release” implica dividir cada versão em interações para descrever como funcionalidade necessária para cada versão desenvolvida de forma incremental. “Iteraction” implica definir tarefas a serem executadas durante a iteração seguinte para desenvolver as funcionalidades previstas. A este nível são também atribuídas tarefas a membros da equipa para conclusão. Por fim “Daily” incluí rever o progresso e identificar e resolver obstáculos que possam estar a impedir o progresso. Nestes níveis denota-se uma diferença de precisão na sua definição e detalhe, sendo este maior na fase diária e menor na fase de visão.

Equipas ágeis separam estimativas de tamanho de projetos – características, requisitos, funcionalidades desejadas - e estimativas de duração de projetos – horário, cronograma (Cohn, 2006).

User Stories são uma ferramenta utilizada para definir requisitos; são frases que contêm informações suficientes para produzir uma estimativa razoável do esforço necessário para desenvolver determinada funcionalidade. Assumem normalmente a sintaxe “As a – type of user – I want to - goal – so that – reason -” (Cobb, 2011). User Stories são utilizadas, no contexto de projetos ágeis para fazer estimativas de esforço através das Story Points que são unidades de medida para expressar o tamanho total de uma User Story. Quando a estimativa é feita através destas unidades é feita uma atribuição de um valor a cada ponto, sendo importante a sua relatividade. Assim, o número de Story Points associados a cada User Story determina a sua dimensão global, ou seja, a quantidade de esforço que deve estar envolvido no desenvolvimento de definida característica. Quanto maior for o seu grau de complexidade relativa ao seu desenvolvimento maior será o risco inerente. Para começar esta planificação de relatividade através de Story Points existem duas opções: considerar a menor unidade de desenvolvimento, como 1 Story Point, ou considerar uma tarefa média atribuindo-lhe um valor médio da escala. Todas as restantes tarefas são caracterizadas de

forma comparativa, mesmo que não estejam totalmente definidas é necessário associar-lhes uma estimativa (Cohn, 2006).

A velocidade é a medida da taxa de progresso da equipa por interação. No final de cada interação uma equipa pode olhar para as tarefas que já concluiu e calcular a sua velocidade de cumprimento. Story Points são uma estimativa do tamanho do trabalho a ser executado, assim, a duração de um projeto é tanto estimada como derivada. Num projeto de software o tempo ideal é diferente do tempo decorrido, devido à sobrecarga natural que a equipa experimenta diariamente: para além de tarefas relacionadas com o projeto existem desvios de produtividade como a resposta a um email, o contacto com um fornecedor, umas ou reunião. O multitasking amplia a diferença entre o tempo ideal e decorrido, por vezes a comutação de tarefas leva à perda da eficácia (Cohn, 2006).

Ideal Days é uma técnica de estimativa do tamanho de um projeto através do tempo necessário para desenvolver, testar e aceitar determinado projeto, não considerando necessário atentar o impacto e sobrecarga ambiental em que a equipa trabalha. Quando estas considerações são ignoradas Ideal Days expressa o número de dias ideias para realizar uma tarefa, sendo esta convertida numa estimativa de velocidade ou duração (Cohn, 2006).

As estimativas não são criadas por um único elemento da equipa ágil e são tanto melhores quanto derivadas da colaboração entre a equipa; como não se tem conhecimento sobre quem realizará determinada tarefa, é útil uma partilha livre de opinião. Estas estimativas devem ser feitas numa escala pré-definida e não linear – 1,2,3,4,5 e 8 ou 1,2,3,4 e 8. Recursos maiores e que podem apenas ser implementados posteriormente, podem sem associados a números maiores como 12, 20, 40 ou 100; algumas equipas podem também optar pela utilização do valor 0. Assim, para chegar à estimativa final conta-se com a opinião de especialistas, analogias e formas criativas - como planeamento poker (Cohn, 2006).