O permanente desafio de aumentar a qualidade e a produtividade do desenvolvimento de software
Em 29 abril de 2010 tive a oportunidade de participar do seminário Fábricas de Software, organizado peal Recriando Educação & Estratégia em parceria com a Sucesu-SP Sociedade de Usuários de Informática e Telecomunicações – São Paulo. Esse seminário foi organizado em quatro palestras, conforme descrito abaixo. Compartilho aqui um breve resumo que capturei de cada palestra:
Imagem disponível em http://www.recriandoonline.com.br/fsoft/
1. Cenários e Tendências para as Fábricas de Software: Uma Visão das Principais Mudanças de Paradigma que estão Ocorrendo. Palestrante: Aguinaldo Aragon Fernandes
Na abertura o palestrante destacou a importância do uso de controles para uma Fábrica de Software traçando um paralelo com a indústria automobilística. Em seguida comentou sobre qual seria o real valor das certificações como o CMMI, ressaltando os desafios que a cultura brasileira impõe na adoção desses modelos, e como as empresas que possuem essas certificações pouco se beneficiam delas. Comentou-se sobre a queda atual na procura por esse tipo de certificação.
Foi apresentada uma breve revisão do conceito de Fábricas de Software, o qual atualmente passa por uma evolução de Fábrica de Código para Fábrica de Projetos, e a necessidade das Fábricas possuírem processos customizados para os diferentes tipos de demandas que ela recebe (desenvolvimento Java, .NET, Cobol, etc). O palestrante abordou também as dificuldades que as Fábricas enfrentam decorrentes da falta de contato com as áreas de negócio, frequentes mudanças de escopo e especificações funcionais pobres.
Abordou-se a realidade das empresas atuais que necessitam de entregas de software em prazos cada vez mais reduzidos e o risco imposto pelas áreas de negócio à área de TI ao gerarem esse tipo de demanda. Destacou-se a necessidade da área de TI de melhor gerir os riscos desses tipos de demandas, visando à qualidade das entregas.
O palestrante apresentou a “regra de ouro” para o modelo de custo e operação de uma Fábrica de Software: demanda constante, remuneração do capital investido maior que a taxa Selic e havendo sazonalidade de demandas, essas devem ser tratadas como projetos e não no modelo de Fábrica.
Foram apresentadas as metodologias de desenvolvimento que as Fábricas tem a disposição, onde o XP aparece como a mais simples e o RUP como mais complexo. O uso de metodologias ágeis pelas Fábricas de Software deve ser utilizada desde que possa haver uma proximidade com o cliente, ainda assim com alto risco na operação. Foi destacada a baixa maturidade dos compradores dos serviços de Fábrica de Software: falta de uma boa documentação de requisitos, alteração de escopo, falta de gerência de configuração (já citados no segundo parágrafo)
Foi abordado sobre a dificuldade de operação de uma Fábrica de Testes, que na verdade acaba funcionando como alocação de “body shop”. Citou-se também a instrução normativa 4 (IN_4) do setor público federal que proíbe a contratação de “body shop” para serviços de TI, visando frear essa prática no setor público. Ainda no setor público, comentou-se da não obrigatoriedade de certificações como CMMI e PMP para prestação de serviços a esse setor, em decorrência de não serem certificações de institutos nacionais.
2. Uma Abordagem Prática sobre a Utilização de um Painel de Indicadores para Medir o Desempenho de Uma Fábrica de Software: O que fazer? Como fazer? Quais indicadores selecionar? Palestrante: Ivan Luizio Magalhães
O Ivan antes de iniciar a palestra fez alguns comentários para colocar suas opniões em relação à palestra anterior:
Comentou sobre o mau uso do termo “Fábrica de Software” tanto por fornecedores quanto pelos clientes, que em muitas vezes o termo é utilizado para ocultar o “body shop”. Destacou ainda a importância de se separar os papéis de Fábrica de Software e Fábrica de Testes, para que nas suas palavras “para que o vampiro não cuide do próprio sangue”.
Apresentou o conceito de “Application Management”, e a necessidade das especializações das Fábricas de Software: Fábrica de Componentes, Fábrica de Sustentação, Fábrica de Projetos, etc, cada uma com sua competência própria. Muitas vezes uma Fábrica que exercer os diversos papéis e acaba falhando nisso. Introduziu brevemente o conceito de BPO que retira o papel de TI das organizações, terceirizando processo e sistemas, apresentando apenas uma fatura no final do mês para o contratante.
A palestra teve início então com a definição do conceito de engenharia de desempenho, que visa demonstrar como a TI agrega valor ao negócio, baseada em processos de medição, controle, entendimento do processo e aperfeiçoamento do mesmo. A engenharia de desempenho ajuda ainda a “ter um negócio que faz TI bem, para que a área de negócio possa fazer bom uso da TI”.
Foi comentado sobre a baixa qualidade da gestão dos processos de uma Fábrica de Software e da necessidade de um software de ERP para TI. O Ivan citou site http://www.erp4it.com/erp4it/ que trabalha esse conceito. A implantação desse conceito em uma empresa promete um ganho de 30% para a área de TI.
Apresentou-se a predição em 2000 feita pela Microsoft que em 2007 um programador ASP #C custaria a metade do valor de um programador Java. Com isso do ponto de vista econômico o Java é uma solução morta para Fábricas de Software. O Ivan destacou a necessidade atual do uso de estatísticas para predição do futuro, e não apenas controle estatístico dos processos.
Sobre a panacéia de indicadores e métricas que muitas vezes dominam as empresas, foi comentado que “nem tudo que tem valor pode ser medido, mas nem tudo que pode ser medido tem valor: exemplo – ponto de função. Qual valor para o negócio agrega-se com o uso de pontos de função para estimativas de projetos de desenvolvimento de software?
Em seguida foi apresentada a filosofia do Strategic Activity System:
Gerenciar por objetivos: Defina indicadores-chave de desempenho. Estabeleça metas de desempenho
Gerenciar por exceções: Calcule o valor dos indicadores chave e compare com o planejado. Notifique os tomadores de decisão das exceções.
Gerenciar por fatos: Analise as exceções baseado em fatos. Tome ações imediatas de correção de desempenho
Gerenciar a evolução contínua: Revise todo o processo de tomada de decisão. Padronize o que for validado.
O Ivan fez um paralelo entre o painel de instrumentos que um piloto de avião tem a sua disposição e a necessidade de um gerente construir o seu próprio painel de instrumentos (“executive dashboard”). A partir daí colocou a importância de começar um dashboard da forma certa, orientando os indicadores pelos objetivos estratégicos da empresa.
Foi definido os conceitos de medida, métricas e indicadores e os benefícios de se utilizar indicadores de cota máxima, visando sempre demonstrar o sucesso e não o fracasso. Deve-se priorizar os indicadores essenciais e críticos, sendo que as metas devem ser realistas, exequíveis, desafiadora, comparáveis e claras. Foi citado o site www.smlab.de . Um indicador deve sempre dizer o que se deve fazer com os seus resultados, e um painel de indicadores deve exibir no máximo seis indicadores por vez.
3. Gestão de Pessoas em Fábricas de Software: Desafios e Oportunidades. Palestrante: Bruno Guiçardi.
A palestra foi iniciada com a apresentação da empresa CI&T, que o Bruno estava representando. Ele comentou sobre o índice de desemprego no Brasil de 7,6% e que considerando-se a baixa qualificação no Brasil, pode-se considerar a partir dessa taxa, uma situação de “pleno emprego”. Segundo o Bruno, há no mercado nacional uma demanda de 50.000 novos trabalhadores por ano na área de TI, sendo que as faculdades formam aproximadamente essa mesma quantidade de profissionais. Entretanto o que preocupa é a baixa qualidade dessa formação, o que demanda que as empresas definam planos de capacitação para seus recém contratados.
Ainda sobre a realidade do mercado brasileiro, foi informado que apenas 13% dos formados na área de TI estariam preparados para trabalhar, sem necessidade de uma capacitação pela empresa contratante. Num exame de seleção aplicado para 60 formandos de faculdades de 1ª linha, obtem-se um aprovação de 55, enquanto esse mesmo exame aplicado para os formandos de outras faculdades pode resultar em apenas uma aprovação.
O Bruno destacou a importância do líder de projeto declarando-o como o “elemento dourado da equipe”, pois alem de servir como modelo para a equipe, é ele quem garante a execução dos projetos e a entrega na data prevista. Nesse contexto destacou a necessidade de profundos conhecimentos técnicos necessários para um líder de equipe.
Citou-se que as pessoas gostam de trabalhar em times vencedores (o Palmeiras foi citado como exemplo atual de um time que nenhum jogador gostaria de trabalhar)
Foi apresentada uma iniciativa da CI&T associada com mais empresas para atrair e capacitar recem formados, materializada através do site www.descobrindotalentos.com.br
A palestra foi encerrada com o Bruno explicando a adoção da “transformação lean” aplicada na sua empresa, onde destacou a importância do engajamento das pessoas antes do “roll-out” de um projeto.
4. Fábricas de Software e Fábricas de Testes: Complementaridade ou Convergência? Palestrante: Marta Fuzioka.
A Marta iniciou a palestra com a apresentação da empresa Atos Origin, com destaque para os serviços da empresa destinado a gestão de eventos olímpicos.
Destacou as vantagens de uma Fábrica de Software no que tange a volumes e produtividade, e apresentou uma pirâmide de custo x produtividade onde se vê um balanceamento entre os tipos de profissionais juniores, plenos e seniores. Apresentou os diversos custos indiretos de uma Fábrica de Software, como utilização do espaço físico, desktops, licenças de software, etc.
Continuou a apresentação discutindo o modelo V de verificação e validação e sobre os conflitos de interesses existentes entre as Fábricas de Software e Fábrica de Testes: enquanto uma tem abordagem construtiva a outra tem abordagem destrutiva (conflito desenvolvedor x testador)
Detacou-se a importância da Gerência da Configuração para a área de testes e dos problemas de terminologia da área de testes, (já discutida em um artigo desse blog). Comentou sobre como o indiano é metódico e apenas faz o que foi definido, sem dar pareceres sobre o que foi definido, enquanto que a cultura brasileira tem mais jogo de cintura, o que muitas vezes compromete a adoção de modelos de maturidade de desenvolvimento de software.
Abordou-se aspectos de testes orientados a riscos e comentou que o risco do teste baseado em riscos, é o risco do analistas de testes não identificar corretamente os riscos.
A Marta finalizou a palestra apresentando a convergência quanto às necessidades de negócios entre as Fábricas de Software e de Testes (redução de tempo e dos riscos, tecnologias, etc) e também a sua complementaridade (Fabrica de Software – criação e inovação ; Fábrica de Testes – identificar defeitos no software)
…………………………………………………………………………………………………………………………………………………
É isso o que consegui registrar das palestras, que foram todas de alto nível com discussões muito úteis para o dia a dia de quem tem o desafio de construir software com prazos e custos reduzidos e com qualidade ilimitada de software.
Related posts:
@Sidney
Ufa… o esclarecimento, realmente esclareceu as coisas para mim.
Em se tratando de testes funcionais, os profissionais de Teste de Software podem ser muito mais eficazes que os desenvolvedores, por vários motivos, desde a psicologia até o conhecimento especializado que tais profissionais têm. Por isso, concordo que uma equipe independente, possa ser a melhor escolha em vários contextos. Mas é bom deixar claro que uma equipe independente pode atuar tanto junto com os desenvolvedores, como separado (a minha preferência é atuação próxima ao desenvolvedor).
É interessante destacar, que os profissionais de teste podem ser responsáveis por vários outros tipos de testes, que executam o software avaliando várias características que o mesmo deve ter (ISO 9126).
Mas mesmo assim, eu acho que tais frases não são felizes, pois podem ser facilmente mal interpretadas (como eu mesmo fiz).
Abraços! E muito obrigado pelo esclarecimento e atenção Sidney!
Prezado Fábricio, precisamos contextualizar alguns pontos do artigo em decorrência dos seus comentários:
Quanto à frase provocativa do Ivan “para que o vampiro não cuide do próprio sangue”, seguida do meu comentário de “quem constrói não deve testar”, estão dentro de um contexto de testes funcionais. Logicamente entendo que seja de responsabilidade do desenvolvedor os testes unitários e de integração, e que é saudável ter uma equipe independente para projetar e executar os casos de testes funcionais. Concordo também com você que “testar faz parte do processo de desenvolvimento e do aprendizado. A questão que as frases trazem para a discussão é apenas quem faz os testes funcionais: o próprio desenvolvedor (ou a própria fábrica que construiu o software)ou uma equipe(ou fábrica) independentes. O que lhe parece?
Para finalizar, sobre a frase “ o XP aparece como a mais simples e o RUP como o mais complexo” essa frase foi colocada em um contexto de “peso da metodologia”, ou o quanto cada uma é mais ou menos burocrática. Daí o entendimento de que o XP seja mais leve e simples e o RUP mais pesado e burocrático.
Obrigado pelo comentário, e espero ter esclarecido os pontos que você abordou.
Sidney,
Primeiramente, parabéns pelo ótimo relato do evento!
Mas eu tenho opiniões totalmente contrárias do que alguns dos palestrantes falaram, e até acho algumas das frases verdadeiras imaturidades.
Por exemplo, a frase “para que o vampiro não cuide do próprio sangue”, que depois você comentou sobre “quem constroi não deve testar”. Na minha opinião, isso é uma verdadeira besteira! Quem fala uma coisa dessa não tem o mínimo senso de desenvolvimento de software. Testar FAZ parte do processo de desenvolvimento! Testar FAZ parte do processo de aprendizado!
Lendo uma frase dessa, imagino que a pessoa não tem nem conhecimento sobre teste de unidade e integração. E ainda acha que “XP aparece como a mais simples e o RUP como mais complexo”, em se tratando de metodologia de desenvolvimento. Uma pessoa que concorda com essa frase, nunca irá realmente usar XP, ela pode até falar que usa, mas na verdade não usa!
Bem é isso, eu até pensei em não comentar nada, mas acho legal expor uma opinião bem contrária.
Sinta-se à vontade em responder na mesma moeda (hehe)
Abraços!
Eduardo a questão sobre as Fábricas de Software e de Testes foram abordadas nas palestras do Ivan e da Marta, sendo que a palestra da Marta tinha o tema com foco nesse assunto.
O Ivan citou uma frase que me chamou a atenção: “Destacou ainda a importância de se separar os papéis de Fábrica de Software e Fábrica de Testes, para que nas suas palavras “para que o vampiro não cuide do próprio sangue”. Acho que essa frase traduz bem tudo aquilo que já lemos sobre “quem constroi não deve testar”.
Na palestra da Marta ela colocou a visão de papéis complementares entre as duas Fábricas, destacando também que esses papéis sejam desempenhados com independência.
Minha percepção é que tem muita Fábrica de Software que se propõe a fazer de tudo: construir código, testar unitariamente, testar funcionalmente, dar sustentação ao software, etc. Essa questão foi abordada na palestra do Ivan, que destacou a importância de especialização dos papéis das Fábricas de Software.
Muito interessante o seminário!
E parabéns pelo post!
Em relação à palestra que abordou a convivência de Fábricas de Software e de Testes, qual a conclusão sobre a necessidade de independência entre elas?
Foi discutida a hipótese de uma mesma empresa desempenhar os dois papéis, desde que contando com equipes totalmente independentes em termos de gerência imediata?
Frequentemente vemos editais de licitação que impedem que um mesmo fornecedor desenvolva e teste. Mas como garantir de fato essa independência quando as empresas interagem em diversos contratos diferentes, num mercado extremamente dinâmico e integrado? Essa necessidade foi confirmada nas discussões?