Contato com a Neurobox

Dairton Bassi tem uma vasta experiência com desenvolvimento de sistemas e já publicou vários artigos sobre o assunto, além da tese de mestrado defendendo suas próprias experiências com Desenvolvimento Ágil. Neste trabalho há algumas referências de sua dissertação e, portanto, foi uma das primeiras pessoas selecionadas para a tentativa de contato. Atualmente Dairton é proprietário da Neurobox, uma empresa altamente especializada em treinamentos e assessorias em métodos ágeis.

 Após vários anos de experiência com diferentes ambientes de desenvolvimento de software, foi possível perceber que os resultados de equipes que usavam práticas ágeis alinhadas com os valores ágeis eram melhores. Tive a oportunidade de estar em contato e influenciar diversas equipes de desenvolvimento de software e diversas dificuldades que elas enfrentavam foram amenizadas ou eliminadas a partir da implantação de modelos ágeis. Alguns desses problemas são: comunicação dentro da equipe e com clientes, quantidade de bugs, planejamento, melhoria técnica da equipe, entre outros.

No início houve resistência da equipe. Mudar uma metodologia de trabalho envolve mudar a cultura de uma equipe ou de uma empresa. Isso significa lidar com algumas resistências em individuais, pois as pessoas muitas vezes precisam sair de sua zona de conforto à medida que os problemas são evidenciados. Contudo, os desenvolvedores que gostam de lidar com o código, gostam e preferem a abordagem ágil porque permite que eles foquem na resolução do problema e ainda permite que aprendam mais durante o processo de desenvolvimento. 

Adotar o Desenvolvimento Ágil na Neurobox trouxe grandes vantagens, como mais flexibilidade para mudança das prioridades de negócio, valorização de aspectos técnicos e melhoria da qualidade do código, envolvimento de clientes e usuários no processo permitindo maior visibilidade do produto que está sendo construído, além da identificação de problemas e dificuldades técnicas mais cedo no processo de desenvolvimento.

 

Dairton Bassi
Fundador – Neurobox / Co-fundador – AgilCoop

< Voltar para a pesquisa


 

Contato com o Banco Central do Brasil

Ser líder de uma equipe e ter comprometimento no gerenciamento de projetos é uma tarefa que exige muito esforço para enfrentar os constantes desafios. Otávio Ottoni tem várias certificações no ramo de gerenciamento de projetos e já trabalhou como analista em quatro empresas diferentes. Atualmente Otávio trabalho no Banco Central do Brasil, utilizando metodologias ágeis para manter o Sistema de Câmbio Interbancário. Em resposta ao contato, Otávio explicou um pouco do funcionamento do Scrum e as restrições que surgiram durante a adaptação.

Aqui no Banco Central do Brasil, nós utilizamos o Scrum aplicado ao ambiente de tecnologia e de desenvolvimento que vivemos. Scrum é um framework Ágil de gestão de projetos usado para entregar aos clientes, de forma iterativa, incrementos de produto de alto valor. Scrum depende de equipes hábeis e auto-organizadas para entregar os incrementos do produto. Também depende de um cliente, ou Dono do Produto, que indique uma equipe com uma lista de funcionalidades desejadas, e que use o valor de negocio como mecanismo de priorização.

Scrum é ideal para projetos cujos requisitos mudam rapidamente ou são altamente emergentes. O trabalho a ser feito em um projeto Scrum é registrado nas Pendências do Produto (Product Backlog), que é uma lista de todos os desejos de mudança no produto. No inicio de cada incremento é feita uma Reunião de Planejamento de Incremento (Sprint Planning Meeting) na qual o Dono do Produto (Product Owner) prioriza as Pendências do Produto (Product Backlog), e a Equipe Scrum (Scrum Team) seleciona as tarefas que ela pode completar durante o próximo Incremento. Essas tarefas são então movidas das Pendências do Produto para as Pendências do Incremento.

Durante um incremento, são conduzidas curtas reuniões diárias chamadas de Scrum Diário (Daily Scrum), que ajudam a equipe a manter-se no rumo. Ao final de cada incremento a equipe demonstra a funcionalidade concluída, na Reunião de Revisão do Incremento (Sprint Review Meeting).

Sobre as vantagens em relação ao RUP e o Desenvolvimento em Cascata vou descrever algo mais prático em que vivi.

Sou terceirizado pela empresa Cast e no contrato antigo ficávamos misturados aos servidores em diversas equipes. O desempenho da equipe trabalhando em pares e principalmente a qualidade do processo e do código fonte, artefatos resultantes eram impressionante. Entretanto, o TCU forçou a mudança de pagamento de serviço terceirizado, de homem/hora para ordens de serviço contadas em pontos de função. Em uma equipe de 10 pessoas, eu e mais uma pessoa éramos da Cast e fomos para um ambiente separado da equipe. Nós continuamos com a mentalidade ágil e posso afirmar que no início foi difícil, muito por causa da distância e pelas coisas não parecerem mais tão ágeis como eram. Isso foi devido a uma documentação pesada e um processo amarrado (abertura de OS, contagem de pontos de função da cast, contagem do banco, aprovação de ambas as partes, abertura de uma nova OS para desenvolvimento, entre outras) que tínhamos que nos enquadrar. Muitas vezes uma “história” era transformada em Ordem de serviço.

Ágil possui inúmeras vantagens. Se hoje fosse iniciar uma equipe e escolher o processo, esse processo seria ágil, porém posso falar que as demandas decorrentes de um processo ágil são extremamente difíceis de mensurar, porque a contagem de pontos de função é limitada em muitos aspectos. Em todas as tarefas são realizados testes automatizados unitários e de aceitação. O sistema fica robusto e seguro, porém, consome um bom tempo para realizá-los (cerca de 65% do esforço é para fazer teste), e o ponto de função não conta esse esforço. Teste não é contado como funcionalidade, e é ignorado.

Aqui no Banco Central nós usamos Desenvolvimento Ágil há cinco anos, e o processo está em um nível de maturidade exemplar, onde muitos sistemas de uma complexidade absurda são sucessos de qualidade e desempenho.

 

Otávio Ottoni
Gerente de Projetos – Banco Central do Brasil

< Voltar para a pesquisa


Contato com a MindTek

Fundada em 2005, a empresa MindTek é uma das pioneiras nacionais em soluções e serviços em Tecnologia da Informação. A empresa trabalha com Desenvolvimento Ágil para oferecer consultoria, manutenção de softwares, outsourcing e treinamentos especializados. Marcus Hardman é Gerente de Porjetos na MindTek e explica o motivo da adoção de metodologias ágeis e o que isso trouxe de mudanças nos processos internos.

A MindTek começou a utilizar o desenvolvimento ágil como metodologia de trabalho  há um ano atrás e obtivemos excelentes resultados nos projetos de desenvolvimento e manutenção de sistemas.

Um dos principais fatores que levaram a MindTek escolher essa metodologia de trabalho foi a percepção que esta metodologia minimiza alguns dos principais riscos de projetos de desenvolvimento de software, como a mudança de escopo e prioridades por parte de clientes e problemas de comunicação e entendimento de negócio por parte da equipe.

Em relação às constantes mudanças de escopo, este risco é mitigado pela característica de entrega constante de pequenos módulos dos sistemas contratados. Assim, caso alguma necessidade de mudança seja observada pelo cliente após a homologação dos módulos entregues, a negociação de alteração de prioridade dos próximos itens a serem desenvolvidos é facilitada. Como exemplo, ao invés de serem incluídas no próximo Sprint novas funcionalidades, pode ser incluída a alteração de funcionalidades já entregues. Dessa forma, não há mudança de custo para o cliente, mas sim uma redução do escopo total. Como as entregas são realizadas de acordo com a ordem de relevância da mesma, é mais interessante corrigir funcionalidades prioritárias do que implantar novas funcionalidades menos relevantes para o negócio do cliente.

Em relação aos problemas de entendimento de negócio e comunicação por parte da equipe do projeto, estas atividades são facilitadas através da dinâmica de diminuição do tamanho do escopo no qual a equipe está desenvolvendo no momento. Em outras palavras, aumenta-se o foco da equipe nas atividades do Sprint. Como apenas o escopo mais importante está em andamento, é mais fácil gerenciar o entendimento do negócio e garantir a uniformidade e integração das atividades do Sprint. Outro fator que contribui é o “Daily Meeting”, pequenas reuniões diárias de status (10-15 minutos) onde o comprometimento de cada colaborador com o projeto é apresentado para toda a equipe, agilizando a correção de erros e garantindo que pequenos desvios de tempo não cresçam acima da capacidade da equipe de contorná-los.

Ressalto que nenhuma mudança é fácil de implantar. A maioria das empresas de desenvolvimento de software ainda não adotou o SCRUM, o que gera insegurança para a equipe no início. É fundamental o apoio da alta direção da empresa,assim como o alinhamento junto ao cliente, uma vez que o SCRUM aumenta o volume de trabalho de homologação das entregas por parte deste. Muitos clientes não aceitam a proposta de redução de escopo para correção de “erros”, pois consideram que a mudança de escopo nada mais é do que um erro por parte da empresa no entendimento do problema exposto.

Por fim, apesar de haver resistências no início por todas as partes envolvidas (equipe, alta direção e cliente), os resultados práticos da adoção da metodologia conseguem vencer essas barreiras. Pelo menos foi assim que aconteceu na MindTek.

 

Marcus Hardman
Gerente de Projetos – MindTek

< Voltar para a pesquisa


 

Contato com a eTecnologia

Criar e manter uma grande comunidade para o compartilhamento de apresentações e documentos sobre gestão de processos foi a ideia de Rildo Santos em criar a eTecnologia, uma empresa que oferece serviços e produtos em TI baseados na inovação, sustentabilidade e tecnologia desde 2010. Rildo Santos também trabalha com palestras sobre metodologias do Desenvolvimento Ágil e como professor de cursos de MBA e pós-graduação.

 Na minha opinião, os métodos ágeis, como o Scrum, por exemplo, trabalham com o conceito iterativo/incremental que considero fundamental para o desenvolvimento de software, já que sempre temos todas as informações ou requisitos quando começamos a desenvolver um software. Isto também possibilita entregar mais cedo software funcionando ao cliente.

Um fato que julgo importante é que o desenvolvimento de software consiste em um processo empírico (baseado no conhecimento das pessoas) e a melhor forma de controlar estes tipos de processos é a inspeção e adaptação. O foco dos métodos ágeis é entregar valor para o cliente enquanto no modelo cascata é foco é entregar o software. Para ter valor o software tem que atender as necessidades do cliente.

 

Rildo Santos
Consultor, Coach e Instrutor – eTecnologia

< Voltar para a pesquisa


 

Contato com Jim Highsmith

 Veterano em Desenvolvimento Ágil, Jim Highsmith é um dos membros da Agile Alliance e criador da metodologia ágil Adaptive Software Development (ASD), sendo um dos grandes pioneiros na criação e crescimento de técnicas ágeis nas empresas. Entrar em contato com Jim Highsmith não foi uma tarefa fácil, mas após muita persistência, ele atenciosamente retornou o e-mail expondo a sua opinião sobre a utilização do Desenvolvimento Ágil em projetos grandes.

Pergunta: Muitas pessoas dizem que o Desenvolvimento Ágil não é apropriado para grandes projetos, como ERPs e sistemas complexos. Se o Desenvolvimento Ágil é mais confiável e flexível, por que as empresas insistem em usar o Desenvolvimento em Cascata? É uma tradição ou insegurança?

O Desenvolvimento Ágil, sem dúvida, tem sido usado em vários projetos extensos. A HP, por exemplo, utilizou metodologias ágeis em um projeto de programação de um firmware, envolvendo 400 pessoas divididas em cinco locais distintos. Outras empresas também utilizaram Desenvolvimento Ágil em projetos equivalentes ou até maiores. Ao contrário do que afirmam, o Desenvolvimento Ágil também é utilizado em projetos de ERPs, mas a equipe tem que passar por uma série de adaptações para utilizá-lo neste caso. A maioria das pessoas se preocupa principalmente pelo fato de não ter usado metodologias ágeis o suficiente para sentirem-se seguras de utilizá-las em projetos grandes e sistemas distribuídos.

Apesar da minha opinião, as diferenças entre o Desenvolvimento Ágil e o Desenvolvimento em Cascata são questões extremamente abertas que dependem da perspectiva e do âmbito da equipe de desenvolvimento. Existem vários documentos e apresentações disponíveis que discutem sobre essas diferenças, e eu sempre costumo revisá-los para acompanhar a evolução da Engenharia de Software.

 

Jim Highsmith
Consultor Executivo – ThoughtWorks
Criador da metodologia ágil Adaptive Software Development (ASD)

< Voltar para a pesquisa