Olá pessoal!

Neste post finalizo uma pequena série de três posts sobre os processos de desenvolvimento de software mais populares da atualidade: o RUP e o Scrum. Caso você não tenha lido os dois posts anteriores, recomendo que o faça: RUP / Scrum. Neste post registro minha opinião / sentimento pessoal quanto a tais processos e como enxergo as discussões que têm surgido atualmente no mercado e na comunidade de desenvolvimento de software. Ressalto então que o está descrito excepcionalmente neste post não foi embasado por nenhuma literatura ou trabalho científico, tratando-se, portanto, de uma análise empírica pessoal. Com este post gostaria de abrir uma discussão, convidando-o a opinar sobre o assunto, postando seu comentário.

É fato que não é tarefa simples suportar um processo demorado por conta de levantamentos de negócios, seguido por um levantamento de requisitos e produção de documentações ostensivas. Com as cobranças constantes por entregas mais rápidas, os clientes vêm maior valor no produto entregue do que em um escopo bem fechado e documentado. Muitos profissionais de TI também não enxergam este valor ou deixam de enxergar com o passar do tempo, quando percebem que manter toda uma documentação produzida não é trivial ou mesmo quando são cobrados frequentemente por fins sem necessariamente justificar os meios. Além disso, existem também outros problemas que são enfrentados na maioria dos projetos, como por exemplo, a não aderência do produto entregue às reais necessidades do usuário, frequentes mudanças de escopo no decorrer do desenvolvimento, demora na entrega dos primeiros resultados e/ ou atraso na entrega do produto completo, o que taxa a área de TI como uma área muito demorada.

Eis que surge então a resposta para todos os problemas. Um processo que não define nenhuma documentação e/ou passo de modelagem e que vem a endossar esta prática que antes era apenas uma ideia ou fruto das pressões mencionadas. Um processo que privilegia os produtos entregues ante as documentações ostensivas, que proporciona entrega de resultados rápidos para o cliente, que não impõe a existência de muitos papéis específicos, sendo desta forma facilmente incorporado por qualquer time de desenvolvimento. Eis que surge o Scrum.

Diversas consultorias surgem então para explorar este que é vendido como a bala de prata, a bola da vez. Outras consultorias que vendiam outros tipos de treinamento passam a se adaptar à nova onda, para não perder market share. Completando o cenário, diversos Scrum Masters se formam e passam a influenciar comunidades, que passam a levar as ideias ágeis para suas empresas, como solução para seus problemas. Não que isso seja privilégio do Scrum. Acredito que o mesmo tenha acontecido com o RUP anteriormente e com diversas outras siglas e acrônimos que vão e vem no nosso mercado o tempo todo. Com toda essa catequização, o RUP passa a se consolidar então como um processo burocrático, antiquado, e que não atende às expectativas dos clientes.

O que não é lembrado por muitos, no entanto, é que o RUP também é um processo iterativo e incremental assim como o Scrum, de forma que com ele também é possível fazer entregas rápidas, coletando feedbacks logo no inicio do projeto, assim mitigando os riscos antecipadamente. Nada impede também que o RUP seja customizado para cada realidade. Existe, por exemplo, o RUP for small projects, que traz um apanhado mais enxuto com relação à sua versão original. Outra possibilidade ainda é criação do seu próprio processo, selecionando um conjunto de artefatos, papéis e conceitos do RUP que façam sentido para a sua organização.

Já outro ponto nas metodologias ágeis que muitas vezes é mal interpretado é quanto à ausência de especificações e/ou documentações. O manifesto ágil não diz que nenhuma documentação ou especificação deve ser feita. Ele diz apenas que o software funcionando é mais prioritário do que uma documentação abrangente. No livro “Utilizando UML e Padrões”, Craig Larman fala sobre uma abordagem de modelagem que ele chama de “modelagem ágil e desenho leve UML”. Nesta abordagem os diagramas UML são desenhados para proporcionar entendimento e comunicação ao invés de documentação. Além disso, os diagramas são feitos em quadros brancos ou folhas de aderência, de forma que eles sejam posteriormente digitalizados através de fotos e programas específicos.

Pessoalmente acredito que um levantamento inicial de requisitos e que diagramas de casos de uso ajudam bastante no entendimento e na concepção inicial de um projeto, bem como na visualização do seu tamanho e escopo. Além disso, diversos diagramas da UML também agregam com visões que são importantes para a maioria dos projetos, como por exemplo, as dependências entre componentes, a modularidade e separação de responsabilidades, demostradas pelo diagrama de componentes e a distribuição dos mesmos dentre os diversos nodes de uma arquitetura distribuída, demonstrada por um diagrama de implantação.

Qual é então o processo mais adequado para cada organização? Acredito que ambos os processos e suas variantes ou customizações podem atender às necessidades de diferentes tipos de organizações, dependendo da sua cultura, necessidade e porte. Empresas que optam pelo RUP, por sua customização ou por um processo baseado nele, normalmente possuem cultura séria / rígida, onde constantes auditorias exigem documentos e práticas registradas, possuindo também uma estrutura de profissionais robusta. Já as organizações que possuem cultura descontraída e que optam ou que só podem ter times pequenos que atendam responsabilidades específicas, normalmente melhor se adaptam ao Scrum e aos demais processos e conceitos ágeis.

E você, o que acha? A sua empresa adota um destes processos de forma satisfatória?

Olá pessoal!

Continuando a série rápida sobre engenharia de software, neste post falo um pouco sobre o Scrum. O objetivo desta série, como mencionado no post anterior, é traçar um paralelo entre os processos de desenvolvimento de sistemas mais populares: RUP e o Scrum. Caso você não tenha lido o post anterior, onde falei sobre o RUP, clique aqui.

Assim como o RUP, o Scrum também é um processo de desenvolvimento de sistemas iterativo e incremental, porém, é voltado ao que se chama de desenvolvimento ágil de software, que por sua vez é fundamentado pelo manifesto ágil. O manifesto ágil foi concebido por dezessete pessoas de extrema influência na área de engenharia de software, sendo que dentre eles destacam-se: Martin Fowler, Alistair Cockburne Kent Beck. Quatro valores fundamentais formam a base do manifesto ágil:

• Os indivíduos e suas interações acima de procedimentos e ferramentas;
• O funcionamento do software acima de documentação abrangente;
• A colaboração dos clientes acima da negociação de contratos;
• A capacidade de resposta à mudanças acima de um plano pré-estabelecido;

Percebe-se então uma grande diferença entre os valores que formam a base do RUP e os do Scrum, sendo que uma das principais é o fato de que as documentações permeiam o RUP de ponta a ponta enquanto que no Scrum, em sua essência, pouca ou nenhuma documentação é produzida. Além disso, outra grande diferença, como bem lembrado pelo colega Alessandro Brito em uma discussão, é que o Scrum não define o que fazer em cada situação, o que o classifica como um processo não prescribente.

Vamos então a alguns detalhes. No Scrum, todo o conjunto de requisitos do usuário é conhecido como Product Backlog. Nele há a introdução do conceito de Sprint, que se refere a uma iteração de implementação completa de um ou mais itens do Product Backlog, que são entregues e validados pelo cliente ao seu término. O conjunto de itens selecionados para implementação em uma sprint é denominado Sprint Backlog. As sprints normalmente têm duração de duas a quatro semanas, de forma que o cliente tenha contato com as primeiras funcionalidades do sistema logo no inicio do seu desenvolvimento – o que é bem característico de processos iterativos e incrementais, assim como o RUP. Veja na figura a seguir a ilustração do processo descrito.

No Scrum também é empregado o que se chama de Daily Mettings, onde todos os participantes do time de desenvolvimento do projeto participam de uma breve reunião, apontando os seus progressos e/ou seus impeditivos, de forma que os riscos possam ser mitigados logo no momento em que surgem. Além disso, são também realizadas reuniões de planejamento das próximas sprints e de retrospectivas das sprints finalizadas, onde são verificadas as lições aprendidas, de forma que eventuais problemas não se repitam ao longo do projeto.

Situados ambos os processos, surgem algumas questões, como por exemplo: qual processo é mais adequado para a minha empresa ou para o meu time de desenvolvimento e quais são as tendências atuais? Estas são questões que abordarei no próximo post, onde finalizarei esta pequena série. Até lá!

Olá pessoal!

Neste série rápida relacionada à engenharia de software vou descrever brevemente dois processos de desenvolvimento de software. Um é o RUP (que vem perdendo espaço para as novas tendências “ágeis”) e o outro é a bola da vez, o Scrum. Ao término, devo traçar uma conclusão com relação aos dois processos e às atuais tendências.

Neste post em específico começarei pelo RUP. O RUP é um processo de desenvolvimento de software concebido inicialmente por uma organização denominada Rational (que utilizou como base um processo anterior denominado UP – Unified Process) e adquirido posteriormente pela IBM, tendo seu nome alterado para IRUP (IBM Rational Unified Process).

O processo consiste em uma abordagem iterativa e incremental, onde são definidas entregas sucessivas ao longo da execução do projeto. Tal modelo se opõe a abordagem tradicional cascata (waterfall),  onde a entrega ocorre apenas ao término do projeto. Seis melhores práticas formam a base deste processo:

• Desenvolvimento iterativo;
• Gerenciamento de requisitos;
• Uso de arquitetura baseada em componentes;
• Modelagem visual;
• Verificação da qualidade;
• Controle de mudanças;

Dentre diversas definições, o estabelecimento de papéis (funções) e artefatos (itens que são produzidos ao longo do projeto) fazem parte do RUP, definindo claramente, desta forma, as atribuições em um time e os itens que são entregues por ele. O RUP propõe uma abordagem com quatro fases e nove disciplinas, conforme pode ser observado na figura a seguir (conhecida popularmente como “Gráfico das Baleias”).

Como benefícios de uma abordagem iterativa e incremental espera-se:

– Redução de custos com retrabalho e aumento da aderência do produto entregue às necessidades do usuário: À medida que pequenas partes do produto são entregues, o cliente tem a oportunidade de avaliar e fornecer um feedback à equipe de desenvolvimento, de forma que o produto final seja mais aderente aos seus requisitos.

– Aceleração do tempo de desenvolvimento do projeto como um todo: devido ao fato de que a equipe trabalha de forma mais eficiente quando se busca resultados de escopo pequeno e claro.

O RUP é comumente utilizado em grandes organizações, pois, em sua forma original (sem customizações), implica na produção de diversas documentações – o que o faz levar a fama de “burocrático” – e na existência de conhecimentos específicos (atribuições de alguns papeis) que nem sempre são viáveis em organizações menores. Para suprir estas deficiências, ou excessos, existe uma versão simplificada do RUP denominada “RUP for Small Projects”. Existem ainda organizações que criam seu próprio processo de desenvolvimento utilizando-se de práticas, conceitos e até mesmo artefatos definidos pelo RUP. Estes processos, no entanto, são mais aderentes às suas necessidades e as suas realidades.

Ultimamente pouco se tem ouvido falar a respeito do RUP, pois, como mencionado anteriormente, a moda agora é “ser ágil”. Até o próximo post, onde falarei sobre o Scrum!