O SCRUM essencial

O termo Desenvolvimento Iterativo e Incremental descreve uma categoria de metodologias para desenvolvimento de software em que o sistema cresce incrementalmente através de ciclos completos de desenvolvimento.

Os métodos de desenvolvimento agile de software são um grupo de metodologias iterativas específicas que combinam interacções relativamente curtas com refinação evolucionária dos requisitos, planos e metas ao longo de cada interacção subsequente.

Aparentemente as metodologias agile e iterativas tem mais baixo risco que os métodos com o estilo Waterfall, em que todo o planeamento e o desenho é feito antes do desenvolvimento.

Scrum

O SCRUM é uma das mais simples metodologias agile e provou já ser altamente efectivo para quer o desenvolvimento de software quer o desenvolvimento de produtos mais genéricos. O SCRUM é muitas vezes utilizado no desenvolvimento de produtos financeiros.

Baseia-se na ideia que durante um projecto os clientes irão com a maior das certezas mudar de ideias acerca do que querem e necessitam. Para enfrentar isto, um projecto Scrum avança numa série de interacções curtas cada uma das quais realiza um conjunto incremental de melhorias ao produto.

Scrum faz a mediação entre resultados e funcionalidades operáveis. Isto permite ao cliente receber um produto operável mais cedo e permite que o projecto mude os seus requisitos de acordo com as necessidades em mudança.

A metodologia oferece um conjunto de práticas e funções pré-definidas que são adoptadas pela equipa para maximizar as capacidades da equipa para entregar com rapidez e responder aos requisitos mudados e emergentes.

A Equipa Scrum

Uma equipa Scrum é normalmente Transfuncional e consiste em cerca de 5 a 9 pessoas, mas pode ser muito maior. A equipa tem a responsabilidade de entregar o produto. O Scrum encoraja a localização de todos os membros da equipa e a comunicação verbal entre todos.

Existem algumas funções específicas no Scrum:

O ScrumMaster

Os projectos Scrum são geridos com um estilo de gestão muito flexível e requerem gestores de projecto com experiência específica na gestão de projectos agile. A função de gestão de projecto é não tradicional, já que o ScrumMaster é, em primeiro lugar, um facilitador que institui regras acordadas, remove impedimentos ao progresso e garante que a equipa se mantém focada.

As equipas Scrum são auto-organizadas. O ScrumMaster não é o líder da equipa e actua como um buffer entre a equipa e quaisquer influências que a distraem

Proprietário do Produto

O Proprietário do Produto representa o cliente e assegura que a Equipa Scrum trabalha nas «coisas certas» numa perspectiva de negócio. O Proprietário do Produto escrever «estórias» centradas no cliente que são uma ou duas frases que em linguagem de negócio descrevem uma funcionalidade específica do produto. Estas são então implementadas pela equipa Scrum.

Stakeholders

Estas são as pessoas para quem o projecto irá produzir os resultados acordados. Eles só estão envolvidos directamente no processo durante as revisões do progresso realizado.

"Sprints" e "Backlogs"

O trabalho é compartimentado em pequenas parcelas de cerca de duas semanas de duração. Denominadas «Sprints». Durante cada Sprint, a equipa cria um incremento completo do produto tendo como resultado um produto potencialmente entregável.

O conjunto de funcionalidades que são incluídas em cada Sprint decorre de um conjunto de requisitos de alto nível do trabalho a ser feito, conhecido como «backlog do produto». Este contém descrições genéricas de todas as funcionalidades desejadas para o produto novo ou actualizado, priorizadas em termos do seu valor projectado para o negócio, bem como com estimativas do esforço necessário para as realizar.

Quais os itens específicos do backlog que são incluídos no Sprint é determinado durante uma reunião de planeamento anterior ao Sprint. Durante esta reunião, o Proprietário do Produto informa a equipa sobre os itens do Backlog do Produto que querem que sejam completados. A equipa determina então a quanto se pode comprometer durante o próximo Sprint, o que passa a ser o «backlog do Sprint» do próximo Sprint.

Durante o curso do Sprint, não é permitido a ninguém alterar o backlog do Sprint, o que significa que os requisitos estão congelados para aquele Sprint. Depois do Sprint ser concluído, a equipa demonstra o produto para o Proprietário do Produto. A equipa pode cancelar um sprint se sentir que não são capazes de alcançar os objectivos do Sprint e stakeholders externos podem também cancelar o Sprint se se manifestarem circunstâncias externas que negam o valor para proceder com este. Se um Sprint termina anormalmente, o próximo passo será conduzir uma reunião de planeamento para um novo Sprint, onde é revista a razão da terminação.

Um quadro apresentado publicamente é usado para mostrar o trabalho remanescente para o Sprint corrente. Isto é denominado um gráfico de Sprint burndown e deve ser actualizado todos os dias para oferecer visibilidade ao progresso realizado.

Transitar para o Scrum

A transição dos métodos tradicionais de trabalho para o Scrum é relativamente transparente. Pode haver benefícios em envolver um formador experimentado em Scrum para assistir na formação e implementação.

O Scrum trabalha muito bem à sua maneira é também é um excelente primeiro passo se se pretender introduzir conceitos agile na organização visto ser simples e focar-se numa gestão de projecto a alto nível.

Tradução e adaptação de artigo de Chris Young

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

Conhecer os custos de um projecto não é suficiente!

Para se poder compreender o verdadeiro valor de um projecto e decidir se o levamos a cabo ou não (ou mesmo até, em primeiro lugar, iniciá-lo) não é muito útil considerar unicamente os custos. Se os benefícios excedem os custos então não há razão porque os custos não podem aumentar. O que é importante é que os benefícios continuem a exceder os custos.

Quando a organização pretende verificar se estes componentes se mantêm em desequilíbrio é porque pretende validar a realização.

Quando analisamos os custos torna-se vital que também verifiquemos os benefícios. Nós temos coisas chamadas centros de custo onde todos os custos relevantes são acumulados e mantidos e inevitavelmente debruçamo-nos sobre eles, analisamo-los e revemo-los, etc. E então o que fazemos com os benefícios? Quando foi a última vez que ouvimos falar de um centro de benefícios?

O que precisa então ser conhecido acerca destes benefícios que podem vir a ocorrer num futuro incerto? A próxima vez que estiver num projecto pense acerca do que pode ser necessário registar destes benefícios, para garantir que são compreendidos de forma adequada a poderem ser reconciliados com os custos. Sugeria o seguinte:

• Descrição do Benefício – uma narrativa que nos ajude a compreender o âmbito daquilo que esperamos obter.
• Quando é expectável ocorrer o benefício e qual o período durante o qual se realizará – os benefícios são raramente óbvios de forma imediata. Taxa Interna de Retorno, Valor Líquido Presente, Payback e outros indicadores financeiros trabalham tão bem com benefícios como com custos.
• Medir a realização do benefício e como será obtida – como iremos medir o verdadeiro valor e particularmente como é que o poderemos medir. Não se esqueça de fazer uma avaliação do «estado actual» já que todas as melhorias devem ser medidas em relação com alguma coisa.
• Que custos estão directamente associados com os benefícios em questão.
• Qual o projecto que irá realizar os outputs que permitirão obter os benefícios.
• Que riscos podem estar associados com o caminho de obtenção do benefício.
• Quem irá ser responsável e proprietário da realização dos benefícios.

Se registamos os benefícios desde o início estaremos em boa posição para validarmos as razões para o projecto e aptos a demonstrar a sua viabilidade.