atv 2 - Marilia Vilar - Processos de Desenvolvimento de Software e Métodos Ágeis

Prévia do material em texto

Engenharia de software - Atividade 2: Pesquise sobre Processos 
Aluna: Marília Vilar Pinto Ribeiro (202010708-7) 
 
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE E MÉTODOS ÁGEIS 
 O Processo de desenvolvimento de software define um conjunto de passos, tarefas, eventos e práticas que 
devem ser seguidos por desenvolvedores de software, na produção de um sistema. Assim, o software também é 
produzido de acordo com um processo, entretanto, ele possui suas especificidades, sendo muitas vezes importante 
adapta-lo à sua realidade ao invés de utilizar métodos tradicionais. Na prática, os sistemas modernos são 
desenvolvidos em equipes, dada a sua alta complexidade, e é sobretudo nesse contexto de equipe que os processos 
se tornam extremamente importantes e eficientes, onde um ordenamento mínimo é necessário. 
Por parte das empresas, os processos de software são ferramentas importantes para que se possa coordenar, 
motivar, organizar e avaliar o trabalho de seus desenvolvedores, de forma a garantir qualidade e produtividade, e 
gerando produtos de valor para a mesma. Já para os desenvolvedores, os processos fazem com que eles tomem 
consciência das tarefas e resultados que se esperam deles, evitando inclusive que eles se sintam perdidos, trabalhando 
de forma errática e sem alinhamento com os demais membros do time. 
A característica principal dos processos ágeis é a adoção de ciclos curtos e iterativos de desenvolvimento, por 
meio dos quais um sistema é implementado de forma gradativa, começando por aquilo que é mais urgente para o 
cliente, e passando sempre pela validação do cliente a cada nova iteração. Esses ciclos normalmente são curtos, com 
duração de um mês, ou até um pouco menos, e cada iteração gera um incremento no sistema que já pode ser validado 
e testado pelos usuários finais. Assim, o sistema vai sendo construído de forma incremental, e o desenvolvimento do 
mesmo termina quando o cliente decide que todos os requisitos estão implementados. 
Os processos ágeis possuem uma menor ênfase em documentação e em planos detalhados, uma vez que nem 
sempre os requisitos do projeto estão claros logo no início. Geralmente o desenvolvimento desses processos é feito 
em times pequenos, com cerca de uma dezena de desenvolvedores, e possui ênfase em práticas “mais recentes” de 
desenvolvimento como programação em pares, testes automatizados e integração contínua. 
Todas estas características, apesar de extremamente importantes, são ainda bastante genéricas e 
abrangentes; assim, alguns métodos foram propostos para ajudar desenvolvedores a como adotarem os princípios 
ágeis na prática. No presente artigo serão explanados três principais processos de desenvolvimento: Extreme 
Programming (XP), Scrum e Kanban. 
 
XP - EXTREMING PROGRAMING 
XP é um método leve recomendado para desenvolver softwares com requisitos vagos ou sujeitos a 
mudanças e, sendo um método ágil, o XP possui todas as características anteriormente descritas. É importante 
destacar que XP não é um método prescritivo, que define um passo a passo detalhado. De maneira oposta, o método 
XP é definido por meio de um conjunto de valores, princípios e práticas de desenvolvimento. Assim, inicialmente ele 
é definido de forma abstrata, usando-se de valores e princípios, para que depois estes últimos possam ser 
concretizados em uma lista de práticas de desenvolvimento. 
Os valores e princípios são componentes chaves do método, pois são eles que dão sentido às práticas 
propostas, assim, se os valores e princípios não fazem parte da cultura e dos hábitos do time, não é indicado tentar 
adotar apenas as suas práticas. Segundo o XP, 3 valores principais norteiam o desenvolvimento de projetos, sendo 
inclusive valores universais para o convívio humano: 
a. Boa comunicação: para evitar e também aprender com erros; 
b. Simplicidade: todo sistema complexo e desafiador possui sistemas ou subsistemas mais simples; 
c. Feedback: dada a constante transformação nos projetos de software, todo ele possui riscos, entretanto, estar 
aberto ao feedback dos stakeholders ajuda a controla-los. 
Os valores são abstratos e universais, enquanto as práticas são procedimentos concretos e pragmáticos. É aí 
que entram os princípios, unindo esses dois extremos. 
a. Humanidade: O principal recurso de uma empresa de software são seus colaboradores; 
b. Economicidade: software é uma atividade cara, portanto necessita gerar resultados econômicos. 
c. Benefícios Mútuos: as decisões tomadas em um projeto de software têm que beneficiar múltiplos 
stakeholders: “todo negócio tem que ser bom para os dois lados” 
d. Melhorias Contínuas: nenhum processo de desenvolvimento de software é perfeito, assim, é mais seguro 
trabalhar com um sistema que vai sendo continuamente aprimorado, a cada iteração; 
e. Falhas Acontecem: falhas são esperadas em projetos de desenvolvimento de software, e elas não devem ser 
usadas para punir membros de um time. 
f. Baby Steps: O importante é garantir pequenas melhorias contínuas, num progresso seguro, testado e validado, 
do que grandes implementações com riscos de serem descartadas pelos usuários; 
g. Responsabilidade Pessoal: os desenvolvedores devem enxergar claramente a sua responsabilidade na equipe, 
sabendo que ela não pode ser transferida sem que a outra parte a aceite. 
As Práticas, por sua vez, estão organizadas em três grupos: práticas sobre o processo de desenvolvimento, 
práticas de programação e práticas de gerenciamento de projetos. 
Em XP recomenda-se um alto envolvimento dos clientes com o projeto. Assim, uma das práticas do processo 
de desenvolvimento é ter um representante dos clientes. Ele deve ser alguém com capacidade e autoridade para 
definir o que é mais urgente e importante para a empresa que está contratando o desenvolvimento do sistema, e 
sugere-se que seja uma pessoa próxima do problema, e o mais distante possível da solução. Ele é o responsável por 
escrever as histórias de usuário (representam funcionalidades do sistema através de duas ou três sentenças, usando 
sua própria linguagem), bem como por ordena-las por prioridade. Já aos desenvolvedores do time cabe definir o 
tempo necessário para implementa-las. 
Conforme dito anteriormente, métodos ágeis adotam ciclos curtos e iterativos de desenvolvimento. Assim, 
estas histórias são implementadas em iterações, que possuem uma duração fixa, normalmente de 1 a 3 semanas. A 
duração de uma história frequentemente é estimada em story points, ao invés de homens/hora, enquanto que a 
velocidade de um time é a quantidade de story points que o time consegue implementar em uma iteração. Já as 
iterações, formam ciclos mais longos, chamados de releases, de dois a três meses, por exemplo. 
 A tarefa de alocar histórias a iterações e releases é chamada de planejamento de releases, onde é definido 
quais das histórias serão implementadas nas iterações da release. A partir daí as iterações podem iniciar, começando 
pelo planejamento da iteração, onde as histórias daquela iteração serão decompostas em tarefas que serão alocadas 
para os desenvolvedores, para que as mesmas possam finalmente ser implementadas. 
Uma iteração termina quando todas a suas histórias estiverem implementadas e validadas pelo representante 
dos clientes, e assim o time pode passar pelo processo novamente, para a nova iteração. O projeto, como um todo, 
termina quando o representante dos clientes decide que as histórias já implementadas são suficientes e que não há 
mais nada de relevante que deva ser implementado. 
XP é um método que dá grande importância a tarefas de programação e produção de código. Assim, o método 
também propôs um novo conjunto de práticas de programação, incluindo programação em pares, testes 
automatizados, desenvolvimento dirigido por testes (TDD), builds automatizados, integração contínua, etc. A maioria 
dessas práticas passou a ser largamente adotada pela indústria de software e hoje são praticamente obrigatórias na 
maioria dos projetos, inclusive naquelesque não usam um método ágil. 
Segundo estudo conduzido em 2010 por Laurie Williams, professora da Universidade da Carolina do Norte, no 
ranqueamento de práticas ágeis mais importantes as três primeiras empatadas foram: integração contínua, iterações 
curtas e definição de critérios para tarefas. A primeira é que os desenvolvedores devem integrar seu código sempre, 
se possível todos os dias. O objetivo é evitar que desenvolvedores passem muito tempo trabalhando localmente, em 
suas tarefas, sem integrar o código, o que pode gerar muitos conflitos. Para isto, costuma-se ainda usar um serviço de 
integração contínua. A segunda é que as interações tenham menos de 30 dias para um melhor feedback e adaptações 
ao projeto. E por fim, a definição de critérios para tarefas concluídas, que deve ser combinado com todos os membros 
do time para evitar que códigos de baixa qualidade sejam entregues apressadamente apenas para que consigam mover 
suas tarefas para a coluna concluído. 
Dentre as práticas de gerenciamento de projetos destacam-se o ambiente de trabalho e contratos com 
escopo aberto. O projeto deve ser desenvolvido com um time pequeno, normalmente menos de 10 desenvolvedores, 
com jornadas de trabalho sustentáveis (sempre próxima a 40 horas), onde todos eles devem estar dedicados ao 
projeto, evitando-se times fracionados. Ademais, eles devem trabalhar em uma mesma sala, facilitando a comunicação 
e o feedback, e tendo um espaço de trabalho informativo com cartazes, histórias e seus estados, em que o time tenha 
a visualização do trabalho que está sendo realizado. 
Um dos princípios do Manifesto Ágil é “colaboração com o cliente, mais do que negociação de contratos”, 
assim, métodos ágeis em geral são mais compatíveis com contratos de escopo aberto, que prezam pela comunicação 
e feedback entre contratada e contratante. Neste tipo de contrato, o pagamento é calculado por hora trabalhada e o 
cliente define as histórias e faz a validação delas ao final de cada iteração, e o contrato pode ser rescindido ou renovado 
após um certo número de meses. 
 
SCRUM 
É um método ágil, iterativo e incremental para gerenciamento de projetos, proposto em 1995, e é o mais 
conhecido e utilizado dentre os métodos ágeis. Enquando o XP é voltado exclusivamente para projetos de 
desenvolvimento de software, o método Scrum é voltado para gerenciamento de projetos, tendo um foco mais amplo, 
onde não necessariamente os projetos necessitam ser de desenvolvimento de software. Desta forma, diferentemente 
do XP, este método não propõe nenhuma prática de programação. O Scrum é definido através de de um conjunto 
preciso de papéis, artefatos e eventos. 
Há três papéis dentro de um time scrum: um Dono de Produto (Product Owner/PO), um Scrum Master e de 
três a nove desenvolvedores, possuindo todos eles, o mesmo nível hierárquico. Ademais, esses times são cross-
funcionais (ou multidisciplinares), devendo possuir nele todos os especialistas necessários para desenvolver o produto, 
e são também auto organizáveis, tendo autonomia para decidir como e por quem as histórias serão implementadas. 
O Dono do produto (PO) tem exatamente o mesmo papel do Representante dos Clientes em XP, devendo 
possuir a visão do produto que será construído, sendo responsável por escrever as histórias dos usuários, estando 
sempre disponível para tirar dúvidas do time sobre elas. Já o Scrum Master é um papel característico e único de Scrum. 
Ele não é um gerente de projeto tradicional, não sendo o líder do time, mas sim sendo o especialista em scrum do 
time, com a responsabilidade de garantir que as regras do método estão sendo seguidas. Por sua vez, os 
Desenvolvedores são os especialistas necessários para desenvolver o produto. Eles tomam todas as decisões técnicas 
do projeto e são responsáveis por estimar o tamanho das histórias definidas pelo PO, usando uma unidade como story 
points. 
Em Scrum, os dois artefatos principais são o Backlog do Produto e o Backlog do Sprint e os principais eventos 
são sprints e o planejamento de sprints. Scrum é um método iterativo, onde uma sequência se repete: 
1. PO faz o backlog de produto: uma lista dinâmica de histórias, ordenada por prioridades, com uma descrição 
resumida das funcionalidades que devem ser implementadas no projeto. 
2. Se inicia o Sprint (máx 1mês): cada iteração leva o nome de “sprint”, onde o time começa a trabalhar na 
implementação das tarefas do backlog. Ao final de cada sprint, deve-se entregar um produto potencialmente 
pronto para entrar em produção. Durante a Sprint, tem-se vários eventos e artefatos: 
a. Planejamento da Sprint (máx 8h): evento que marca o início da Sprint, onde o time gera o backlog do Sprint 
(PO escolhe as histórias daquela Sprint e os devs determinam as tarefas e o tempo delas) 
b. Reuniões diárias (15min): reunião em pé, onde cada desenvolvedor responde 3 perguntas: 
o que fez no dia anterior; o que pretende fazer no dia seguinte; se está enfrentando algum 
problema/impedimento na sua tarefa. O objetivo dessas reuniões é melhorar a comunicação entre os membros 
do time, fazendo com que eles compartilhem o andamento do projeto. 
c. Quadro Scrum: quadro anexado ao lado do Backlog do Sprint, possuindo as colunas das tarefas a fazer, em 
andamento e as finalizadas. Este quadro deve estar fixado em local visível ao time. 
d. Gráfico de Burndown: gráfico com curva declinante que mostra, a cada dia do sprint, quantas horas são 
necessárias para se implementar as tarefas que ainda não estão concluídas 
3. Revisão do Sprint (máx 4h): o time demonstra, ao vivo, o resultado da sprint (o produto) para os clientes, e o PO 
pode aprovar ou não as histórias do Sprint. Aquelas não aprovadas ou não concluídas durante aquela Sprint devem 
voltar para o backlog do produto para serem trabalhadas posteriormente. 
4. Retrospectiva (máx 3h): reunião para o time refletir sobre o sprint que está terminando e identificar pontos de 
melhorias no processo, nas pessoas, nos relacionamentos e nas ferramentas utilizadas. 
5. O ciclo se repete, dando início ao próximo Sprint (passo 2). 
Uma característica marcante de todos os eventos Scrum é terem uma duração bem definida, que é o “time-
box da atividade”. O objetivo de se fixar time boxes é criar um fluxo contínuo de trabalho, bem como fomentar o 
compromisso da equipe com o sucesso do sprint e evitar a perda de foco. A duração entre parênteses acima são os 
time-box normalmente recomendados dos eventos scrum, levando em consideração um Sprint de 1 mês, que é o valor 
máximo recomendado de um Sprint. Se o sprint for menor, o time-box sugerido deve ser também menor. 
 
KANBAM 
A palavra kanban significa “cartão visual” ou “cartão de sinalização”. Esse nome ficou altamente associado ao 
processo de produção just-in-time usado em fábricas japonesas, onde os cartões eram usados para controlar o fluxo 
de produção em uma linha de montagem. Entretanto, em desenvolvimento de software, Kanban foi usado pela 
primeira vez na Microsoft, em 2004, onde, segundo David Anderson, “Kanban é um método que ajuda times de 
desenvolvimento a trabalhar em ritmo sustentável, eliminando desperdício, entregando valor com frequência e 
fomentando uma cultura de melhorias contínuas”. 
Kanban é mais simples do que Scrum, não possuindo de forma rígida nenhum dos eventos e nem dos papéis 
de Scrum, e o único artefato em comum é o quadro de tarefas (Quadro Scrum que é denominado aqui de Quadro 
Kanban), no qual está incluído o Backlog do Produto. 
O Quadro Kanban é dividido em colunas, sendo a primeira o backlog do produto, onde os usuários escreveram 
as histórias que nele estão, e as demais colunas são os passos que devem ser seguidos para transformar uma história 
do usuário em uma funcionalidade executável. Um exemplo é que essas outras colunas sejam os passos de: 
Especificação, Implementação e Revisão de Código. A ideia, portanto, é que as histórias sejam processadas passo a 
passo, da esquerda para a direita, como em uma linha demontagem. 
Ademais, cada coluna é dividida em duas sub-colunas: “em execução” e “concluídas”, assim, as tarefas 
concluídas em um passo estão aguardando serem puxadas, por um membro do time, para o próximo passo, daí Kanban 
ser chamado de um sistema pull. Times Kanban, assim como times Scrum, também são auto-organizáveis (têm 
autonomia para definir qual tarefa vai ser puxada para o próximo passo) e cross-funcionais (devem incluir membros 
capazes de realizar todos os passos do Quadro). 
 
Com o objetivo de garantir um ritmo sustentável de trabalho, evitando a sobrecarga de trabalho, e 
consequentemente que as tarefas sejam entregues com qualidade inferior, o Kanban propõe o Limite WIP, que é o 
limite máximo de cartões presentes em cada passo. 
O objetivo da fase de especificação é exatamente transformar uma história em uma lista de tarefas. Assim, 
na especificação “em execução” temos as histórias, que após serem transformadas em tarefas, irão para a subcoluna 
“concluídas”, onde costuma-se representar as tarefas resultantes da especificação de uma mesma história em uma 
mesma linha. O WIP do passo especificação considera a quantidade de histórias (e não de tarefas) na especificação, 
assim, seguindo o padrão anteriormente descrito: 
WIP Especificação >= histórias da 1ª subcoluna + nº linhas na 2ª subcoluna 
O WIP Implementação >= tarefas 1ª subcoluna + tarefas 2ª subcoluna 
WIP Revisão >= tarefas 1ª coluna (já que não há sentido impor limite para tarefas revisadas) 
Esses limites WIP podem ser definidos de forma empírica, baseados na experiência do time, ou então podem 
ser calculados, como através da Lei de Little, que na prática não é tão simples de ser aplicada. 
 
CONSIDERAÇÕES FINAIS 
Normalmente, Kanbam é mais adequado para times mais maduros, enquanto Scrum é um processo bastante 
intenso que gera uma "fadiga" a médio prazo, assim, na prática, uma boa possibilidade é iniciar com Scrum e depois 
migrar para Kanban. É importante destacar que a experimentação é bastante importante para implementação de 
métodos ágeis, não devendo o time ficar preso ao “by the book”. 
Sistemas de qualquer área podem se beneficiar de pelo menos algumas das práticas propostas por métodos 
ágeis. Lembrando que métodos ágeis é diferente de apenas seguir scrum ou kanbam, por exemplo. Há duas práticas 
ágeis que são atualmente adotadas na grande maioria de projetos de software: Times pequenos, que facilitam a 
sincronização entre seus membros, e as Iterações/Sprints, mesmo que com duração adaptáveis à realidade do projeto, 
às vezes bem maior do que a recomendada em métodos ágeis. 
Por outro lado, é importante reconhecer que existem práticas que não são recomendadas para determinados 
tipos de sistemas, organizações e contextos. Por exemplo, em sistemas de Missão Crítica onde qualquer erro pode 
ser fatal, o ritmo de desenvolvimento é mais lento, e assim o uso de métodos e práticas ágeis é menos natural, uma 
vez que se deve ter atenção a requisitos detalhados e certificações. 
Um outro caso em que a implementação de métodos ágeis pode ser dispensável é nos sistemas casuais, 
desenvolvidos por 1-2 pessoas, que possuem um custo de falhas muito pequeno, então os processos de software 
tornam-se menos importantes nele. Em compensação, nos Sistemas Business, que envolvem praticamente todos os 
outros sistemas (mais diversos sistemas de informação como financeiros, logística, recursos humanos, comércio 
eletrônico, aplicativos móveis, IDEs, etc), os métodos ágeis se destacam e se mostram bastante eficazes.