Alow Brasil !!!

Post rápido para fazer uma propaganda básica, ok?

É que o Gilberto Holms, arquiteto java/soa aqui da nossa equipe na Stefanini iniciou seu blog sobre arquitetura. O cara é um monstro, simplesmente não tem o que falar dele. Pessoal costuma dizer que ele é o ser mais “ignorante” da equipe. Não sabe mesmo brincar…

Altamente recomendado para quem quiser saber um pouco mais sobre arquitetura de software em java e SOA.

Para acessar o blog é só clicar AQUI !!! Também estará nos meus links …

Grande Abraço

André Nascimento

Alow Brasil !!!

A resposta para a pergunta feita no título do artigo – segundo a minha opinião – é não. Claro que não !

Antes de discutirmos o porque dessa afirmação, acho importante estudarmos as origens das atuais medições individuais aplicadas pelos níveis gerenciais nos times de desenvolvimento de software.

Há muitos e muitos anos atrás eu já trabalhei em fábrica – uma de verdade, era de móveis de escritório – e lá era responsável por um setor de produção, o de corte de madeira. Era a primeira etapa da linha de produção. Além de liderar este setor e operar a máquina mais cara da empresa, eu fazia parte da equipe de PCP (Planejamento e Controle de Produção) da companhia.

Porque estou citando isso? Porque lá eu vivi de perto a implantação de um processo de linha de produção e de medição x análise da cadeia produtiva. É claro, que nossa indústria de desenvolvimento de software, quando decidiu aplicar os conceitos de fábrica de software tinha que trazer também vários dos processos de medição, análise e avaliação de desempenho utilizados na indústria convencional.

Funcionava mais ou menos assim:

1. As peças saiam em lote de uma máquina (por exemplo a minha) e iam para uma área de pulmão até que aquele lote fosse pego pela equipe da próxima máquina;
2. O tempo que um lote ficava parado no pulmão, era medido;
3. Assim que os operários da próxima máquina registravam a entrada do lote o tempo começava a contar e na liberação do lote tínhamos o tempo gasto nas peças;
4. Sempre que aconteciam paradas ou problemas (como a regulagem mal-feita de um centro de usinagem, por ex.), eram registradas as ocorrências pelo supervisor de linha;
5. Esse fluxo era executado para cada máquina da linha de montagem. Se não me falha a memória tínhamos cerca de 8 etapas na linha;”

Ora, este processo funcionava e ao final conseguíamos ter números importantes para melhorar nosso planejamento e controle da produção, como:

• Tempo médio para produção de um lote, para cada modelo de móvel que fabricávamos;
• Tempo médio para regulagem de cada máquina da linha, em cada turno de trabalho;
• Tempo médio de fabricação em cada etapa da linha;
• Ocorrências de manutenção, erros e outros pontos que paravam ou atrasavam a produção;
• Número de horas necessárias para fabricação de cada modelo, em cada etapa e em cada turno da fábrica;
• Finalmente, o valor gasto na produção de cada modelo, baseado é claro no número de horas e atividades gastas pelos operários;

Você percebe algumas semelhanças com indicadores de medição individuais que temos hoje em nosso mercado? Na indústria não eram medidos os times ou então a média do trabalho. Para se chegar aos números médios era necessário medir individualmente. Muitas vezes, não importava se o operário conseguia fazer uma peça de qualidade no tempo viável para entrega de um lote. Importava mais se ele estava dentro do tempo médio da produção. Já vi inclusive esses indicadores serem utilizados para demitir gente que não estava dentro da média !

Para a indústria convencional e suas linhas de produção, essa abordagem funciona de fato. Faz muito sentido esse tipo de medição e indicadores de produção. Infelizmente não é a mesma coisa para desenvolvimento de software. Os indicadores e a forma como eles são captados devem seguir outra abordagem.

Acabamos por implantar esse mesmo modelo de medições e análise e avaliações pessoais utilizado na indústria convencional e empurrando-o a força no desenvolvimento de software. O que utilizamos hoje nada mais é do que uma tentativa de medir a “produtividade” das pessoas num ambiente de desenvolvimento. Neste sentido, eu não acredito que medições individuais devam fazer parte de uma equipe ágil.

Tanto as medições individuais quanto os modelos de premiação / punição devem ser coletivos. Acho que este é um dos pontos positivos de se trabalhar num ambiente ágil.

Quais então são indicadores que fazem sentido numa equipe que trabalha sob cultura ágil? Vamos ver alguns:

1. Quantidade média de horas/pontos que o time atinge numa iteração;
2. Taxa de velocidade na implementação;
3. Número geral de erros entregues;
4. Metas alcançadas em cada iteração;
5. Satisfação do cliente /product owner (isso pode ser feito com uma pesquisa, por ex.);

Notem que estamos medindo indicadores do mesmo jeito, só que de uma forma mais superficial. Em resumo, não interessa o que cada um esteja fazendo de forma separada e sim o que o time conseguiu fazer de fato.

Então, você pode me perguntar: ” Mas isso vai deixar as pessoas acomodadas, pois ninguém estará medindo ou gerenciando o seu trabalho? “. Temos que fugir ao máximo do micro-gerenciamento e da ilusão do comando-controle se quisermos alcançar o objetivo de um time auto-gerenciável. O Scrum mesmo nos oferece alguns mecanismos para “medir” individualmente o desempenho de cada membro do time:

• Reuniões diárias;
• Sprints Reviews;
• Sprints Retrospectives;

E quanto a avaliação de desempenho individual, muitas vezes utilizada pelas empresas para aplicação de promoções de cargos e salários, também há outros mecanismos que podem ser aplicados. Pessoalmente eu nunca concordei com o formato  de avaliação de desempenho utilizado pelo mercado. Como podemos medir o desempenho isolado de uma pessoa se ela depende de outras para realizar o seu trabalho?

Esse sistema individual que temos hoje é responsável por promoções descabidas e por muitas vezes entregar o valor do trabalho de muitos para apenas uma pessoa. Então, se você ainda quer utilizar um modelo de avaliação, mas quer começar a pensar em como deixa-lo mais aderente a cultura ágil, faça o seguinte:

• Utilize os indicadores globais das equipes e projetos onde o profissional participou. Não é difícil traçar uma linha de atuação com essa abordagem;
• Para medir individualmente, nada melhor do que a velha “avaliação 360″. Neste modelo o profissional é avaliado por pessoas que trabalham com ele no dia-a-dia. Pessoalmente, acredito que essa seja uma das melhores formas de se avaliar alguém, principalmente os gestores.

O que falei foi apenas sobre indicadores de performance para profissionais / times. Ainda existem muitas outras formas de se avaliar e medir os projetos. São abordagens diferentes, medidas de forma diferente e que apresentam números diferentes, ok?

Métricas e indicadores são muito importantes, principalmente para empresas de serviços de software ou “fábricas de software”. Os clientes exigem esses números e a alta cúpula de executivos precisam disso para basear suas decisões. Agora, não dá para falar de cultura ágil e continuar medindo as pessoas da mesma forma que fazemos na indústria convencional.

Existem muitas empresas que medem tantos indicadores quanto possível e geram relatórios e books de gestão de centenas de páginas. Tudo desperdício, porque ninguém consegue analisar aquilo para tomar uma decisão na hora necessário. Os números devem ser os mais simples e diretos possíveis para possibilitar ao executivo ou mesmo ao time a tomada de decisões em tempo hábil. Para completar, indicador bom é aquele que reflete a cultura que está sendo aplicada pela empresa no projeto.

Grande abraço

André Nascimento

Alow Brasil !!!

Vou tocar num assunto delicado hoje, estou trabalhando neste post há algum tempo e como estou com uma crise de insônia terrível decidi termina-lo e publicar, ok? É um post um pouco extenso, então peço sua paciência para ler até o final

A motivação para este post, nasceu de algumas conversas com amigos e com executivos de mercado, também em algumas empresas que visitei nos últimos tempos e é claro do meu dia-a-dia de trabalho. Grande parte dessa motivação veio do fato de que existem ainda muitas empresas e pessoas que vêem este formato de “fábrica” de software como a salvação dos problemas, sendo poucos os que acabam percebendo que esse modelo criado para a indústria de software somente causou desperdício de recursos financeiros desde a sua criação.

Quero deixar claro que não estou criticando as empresas chamadas de fábrica de software, certo? Até nisso existe confusão. Os atuais fornecedores de software e serviços são denominados simplesmente de “fábricas de software”, principalmente pelos próprios clientes. Claro que você já ouviu a famosa frase: “Não vamos conseguir fazer internamente este projeto, manda pra fábrica…”

Bom, posto esses parâmetros, vamos então a uma definição resumida que encontrei no wikipedia:

Fábrica de Software é um conjunto de Recursos (Humanos e Materiais), Processos e Metodologias estruturados de forma semelhante àqueles das indústrias tradicionais, utilizando as melhores práticas criadas para o processo de desenvolvimento, testes e manutenções dos softwares.

Nos anos 90, quando estávamos vivenciando o ápice do processo de downsizing nas grandes companhias, passamos por um grande problema de produção nas empresas. O mercado contava com poucos profissionais especialistas e os que tinham essa especialização estavam se tornando cada vez mais caros. Por causa de vários deste problemas, pensou-se então que a saída seria “industrializar” o setor de serviços de software.

O pensamento foi simples:

1. O maior índice de trabalho que temos está na codificação de programas;
2. então precisamos de um número altíssimo de profissionais e estes precisam ser baratos;
3. como precisam ser baratos precisamos tornar suas atividades o mais manuais possíveis e eles devem estar pouco envolvidos com questões de negócio;
4. para conseguirmos isso precisamos de modelos e processos focados em atividades e de certificações destes processos.

Ora, no século passado tivemos um problema parecido com este, como ele foi resolvido? Com a criação da linha de montagem de Ford. A idéia básica era a de que muitas pessoas, distribuídas em funções e realizando operações repetitivas conseguiriam criar um produto semi-acabado ou até mesmo acabado. Era verdade que conseguiu-se com este modelo chegar ao impressionante tempo de 98 minutos para se fabricar um carro.

Pronto, temos então a linha de raciocínio que nos levou à criação do que foi em minha humilde opinião um dos maiores erros na história do setor de serviços de TI e desenvolvimento de software: A Fábrica de Software.

Linha de montagem industrial

Imaginou-se no início que a solução então seria segregar as atividades de desenvolvimento de software em várias áreas distintas, sendo as principais:

• Análise de negócio;
• Análisa técnica / modelagem;
• Codificação dos programas;
• Testes

Pronto, com essa divisão clara de “fases” e “disciplinas” num projeto de software ficava muito mais fácil de industrializar o processo, pois poderíamos então fazer qualquer uma dessas fases com pessoas diferentes, em locais diferentes, tudo orientado por um único processo. O modelo derivado deste pensamento pode ser expresso da seguinte forma:

Processo distribuído

Para sustentar essa fantástica “linha de produção”, o mercado teve que se basear totalmente num modelo de engenharia que já era adotado na era dos mainframes, o famoso processo Waterfall, ou cascata.

Modelo tradicional baseado em cascata

O processo Waterfall foi importante para a manutenção do modelo fabril porque dá uma idéia muito parecida com uma linha de montagem e não oferece o que chamamos de retro-alimentação em seu ciclo de vida. A idéia é de cada fase seja executada de forma separada, em momentos diferentes e por profissionais diferentes, alimentando com isso a segregação dos profissionais e baseando-se exclusivamente nos processos e na documentação.

Ok! Já vimos como este modelo foi criado, certo? Agora vamos analisar um pouco como está o mercado depois de quase 2 décadas da implantação deste modelo.

Chaos Report 2009

Você já deve conhecer esse relatório, não conhece? Já falamos sobre ele em outro post. O chaos report do standish group demonstra de forma muito clara como caminha o mercado de desenvolvimento de projetos de software. O leitor pode estar se perguntando: Mas o Chaos não diz que esses resultados são causados pelo modelo de fábrica de software. Com certeza, realmente não menciona, mas menciona problemas que foram causados por este processo e principalmente pela abordagem waterfall nos projetos de software.

Outro estudo que você já deve conhecer é o de que entregamos hoje em dia apenas 20% de funcionalidades que realmente serão utilizadas pelos usuários finais dos sistemas. Podemos ver este resultado na imagem abaixo:

Uso de funcionalidades em sistemas comerciais americanos

Consigo abordar alguns pontos cruciais para afirmar que o modelo chamado de Fábrica de Software não funciona. Vamos a alguns deles:

Gera e alimenta a segregação das equipes

O fato de dividir o projeto em fases => etapas => atividades, executadas por equipes diferentes que não se comunicam ou se comunicam pouco é nocivo para um projeto de software. As pessoas das pontas, que trabalham com o desenvolvimento do projeto não possuem contato com o cliente ou usuário final pois, uma vez que as fases de análise são terminadas a documentação funcional é enviada para a “fábrica” e só tem retorno quando o software está “pronto”.

É necessariamente baseado em documentação

O processo de fábrica tem a obrigação de se basear em documentação, já que não possui comunicação fluente entre os membros da equipe e principalmente com o cliente. Cada fase executada deve conter inúmeros documentos que descrevem como o software deve ser construído. Já trabalhei em projetos com processos em que tínhamos que entregar 32 artefatos de documentação ao longo do desenvolvimento. Esse número muitas vezes representava até 70% do esforço gasto no projeto. Sabe quanto tempo gastávamos com processos de qualidade e testes? Pois é, não sobrava tempo, muito menos dinheiro…

Outro ponto é que a empresa de fábrica precisa se basear nos documentos para se proteger do processo de contratação imposto pelo modelo de escopo fechado. Se aceitar alterações durante o projeto e elas não estiverem documentadas, o fornecedor terá que pagar a conta.

A base de nosso atual processo de software

Promove uma pseudo-previsibilidade

Como medimos o andamento de um projeto de fábrica? Com a famosa coluninha de % completo do project, certo? Se o projeto é separado em fases extensas e executado num modelo distribuído de fábrica essa prática torna-se indispensável. Agora a pergunta: Como podemos dizer que um projeto andou 50% se não temos uma unica linha de código escrita? Ainda não mostramos nada ao cliente, somente protótipos e documentos de requisitos.

Mudanças naturais decorrentes de um projeto são tratadas como alteração de escopo

Como já citei no item 2 as empresas precisam se basear no tal escopo fixo para executar o projeto. Qualquer alteração que ocorra durante seu desenvolvimento deverá ser tratada como mudança de escopo e negociada (paga), a parte. Se levarmos em consideração a cultura de punição que temos hoje para quem não consegue dimensionar um projeto de software com 100% de assertividade – tanto nos fornecedores quanto nos clientes – veremos que as mudanças ficarão engavetadas, engordando as estatísticas de funcionalidades entregues e não utilizadas.

Parte do pressuposto de que o desenvolvedor é simplesmente um operário

Ora, se todas as atividades que precisam de raciocínio já foram realizadas pelos analistas de negócio, arquitetos e analistas de sistemas nas fases de levantamento e definição do projeto então não só precisaremos do cara que escreve o código. É a atividade repetitiva de que fala o modelo fabril criado por Ford.

Este talvez seja o ponto onde a fábrica se saiu pior. Com este pensamento as empresas lotaram suas “fábricas” com estagiários e profissionais Jrs, realmente acreditando que codificar é simplesmente uma atividade braçal, e que o conhecimento especialista está nas mãos dos analistas, arquitetos, etc. Este modelo gerou, inclusive, a idéia de carreira que temos no mercado hoje (trataremos disso em outro post).

Meros codificadores braçais

Com essa atitude o mercado acabou gerando desenvolvedores de software que estão condicionados a receberem uma especificação detalhada e escrever código. A verdade é que temos um número absurdo de profissionais medíocres nas empresas. Pessoalmente acho que grande parte disso se deve ao fato de que limitamos estes profissionais com um modelo onde o programador deve ser burro e não onde unimos a solução com o desenvolvimento da aplicação.

Possui foco em processos e não em pessoas

Quando pensamos em fábrica de software somos levados a acreditar que neste modelo a dependência das pessoas é menor. A verdade é que isso não passa de marketing e é uma grande mentira! Um dos sonhos vendidos pelo modelo de fábrica é que o processo é mais importante e que ele suportará a ausência de qualquer pessoa. Afinal temos tudo muito bem documentado. Ora, sempre seremos dependentes de boas pessoas num projeto de software e para isso não importa o processo. Nunca acredite numa empresa que fale o contrário!

Não permite colaboração

Isso se inicia na contratação. O cliente não quer colaborar com o fornecedor e joga em seu colo todo o risco na contratação. Podemos analisar isso claramente nos processos de RFP que temos no mercado e até já falei isso em outro post. Como o fornecedor sabe que vai ficar com todo este risco, vai basear todo o desenvolvimento do projeto em documentos para que não tenha que assumir os problemas financeiros que certamente vão acontecer.

Neste modelo não há como se ter colaboração entre cliente e fornecedor, pois não há espaço para negociação no momento de mudanças. Sabemos que um projeto de software possui mudanças e que elas devem ser acomodadas e não negociadas. Mas para isso é preciso uma postura de colaboração, que não é compatível com o modelo de fábrica de software.

E no final…

Relacionamento cliente x fornecedor

Por todos este pontos e por diversos outros que podemos citar é que acredito que o modelo de fábrica de software está falido e que rapidamente chegará ao final. Este modelo vai amadurecer e evoluir naturalmente para outros modelos mais adequados ao desenvolvimento de projetos de software. Creio que a evolução natural será para o outsourcing baseado em processos colaborativos.

Nestes modelos, os riscos são compartilhados e as decisões tomadas em conjunto: Cliente x Fornecedor. Todos entendem que é melhor uma relação de ganha x ganha.

Podemos pensar em formas diferentes e mais efetivas para se desenvolver software e criar produtos melhores para as áreas de negócio nas empresas. Este é o nosso objetivo.

Grande abraço

André Nascimento

Alow Brasil !!!

Nos dias 22 e 23 de fevereiro estive em Porto Alegre ministrando um workshop de Scrum e práticas ágeis no estúdio de games Ubisoft Brasil.

O pessoal já conhecia algumas práticas ágeis pois um de seus produtores havia participado de outro workshop e levado o conceito para dentro da empresa.

Algumas coisas que a equipe já utilizava no dia-a-dia:

• Entregas parciais de funcionalidades de um produto;
• Planejamento com todos os membros do time, envolvendo sempre pessoas das áreas de: Criação e arte, design e programação;
• Kanban para alinhar as atividades do time e comunicar ao pessoal sobre o andamento dos projetos;
• Reuniões diárias;
• Manutenção de um Product Backlog;

O objetivo era alinhar o conhecimento de todos os membros da equipe e fortalecer as bases do Scrum e da agilidade, pois nem todos tinham uma idéia clara dos princípios ou do porque realizavam algumas das cerimônias.

Decidimos então fazer um workshop muito baseado nos princípios  ágeis, abordando pontos como:

• Origem do Scrum e as principais diferenças com os processos tradicionais;
• Papéis e suas responsabilidades;
• Ciclo de vida e dia-a-dia de uma equipe ágil;
• Artefatos e cerimônias;

Tivemos cerca de 30 pessoas no treinamento, entre elas: Designers, programadores, produtores e testers. Todo o time do estúdio participou o/

Pessoal da Ubisoft no workshop Agile em POA.

Conseguimos tirar muito proveito do workshop, principalmente nas discussões com o pessoal. Foram levantadas questões pertinentes ao desenvolvimento ágil no cenário da Ubisoft –  desenvolvimento de games.

Existem várias particularidades que a área de games possui para a utilização de práticas ágeis e são grandes os desafios que essas particularidades impõe. Algumas coisas interessantes que discutimos:

1. Quem é o melhor Product Owner para o desenvolvimento de um jogo? Existem inúmeras pessoas envolvidas na criação, direcionamento e estudo do game. Difícil escolher somente uma pessoa para fazer isso;
2. Neste cenário é difícil contar com uma equipe totalmente multidisciplinar, pois é muito comum a existência de especialistas. Exemplo: Uma estória envolve criação, design e programação. Como um programador de física vai “meter o bico” numa estimativa de design e vice-versa na hora do planning poker?
3. Existem critérios de aceite bastante subjetivos. Exemplo: Eu espero que esse jogador pule e que isso seja divertido :S. Subjetivo, não?

Existiram vários outros pontos em que paramos, pensamos, discutimos e chegamos a algumas conclusões muito interessantes. No final, duas coisas ficara bem claras:

1. Processos ágeis se encaixam totalmente na cultura e realidade de uma empresa que faz jogos, muito mais do que qualquer outro processo tradicional �/
2. É preciso muito trabalho, dedicação e criatividade de todo o time para implementar práticas ágeis e adaptar alguns pontos que não fazem sentido utilizar.

O workshop contou com várias dinâmicas, que demonstraram na prática como funciona trabalhar com agilidade no dia-a-dia. A melhor delas foi a da fábrica de aviões, todos gostaram muito Alias, deirxo meus agradecimentos aos grandes Flávio Steffens de Casto e Rafael Prikladnicki que, levando muito a sério o sentido de comunidade disponibilizaram a dinâmica criada por eles. Parabéns, tanto pela dinâmica quanto pelo compartilhamento Srs.

Pessoal tentando criar o protótipo do avião!

Testando o protótipo

Ao final, fizemos uma retrospectiva sobre o workshop e o pessoal deu um feedback muito positivo. Como ponto negativo, os designers e artistas pediram para eu não mencionar tanto assuntos de programação no “próximo” workshop num estúdio de games. My bad pessoal, mas pedi um desconto por ser da área de software e tudo ficou bem.

Muito obrigado a todos da Ubisoft que participaram do workshop. Espero que vocês tenham sucesso no dia-a-dia com práticas ágeis !!!

Referências:

Se você quiser saber mais a respeito de processos ágeis na indústria de games, segue um livro interessante:

Amazon: Agile Game Development With Scrum

Youtube: EVE Online Fanfest 2009 – Scrum & Agile

EVE Online Fanfest 2009 – Scrum & Agile

Abraços

André Nascimento

Dica rápida pessoal

Se você é um desenvolvedor/analista/arquiteto em plataforma microsoft .net então compensa gastar um minutinho na leitura.

Faz um tempo que conheci essa ferramenta e queria postar algo aqui para quem estiver interessado. Trata-se do ANTS Performance Profiler, uma ferramenta da Red Gate para ajudar na análise e medição do seu código com relação a performance da aplicação.

O próprio Visual Studio nos dá excelentes ferramentas para analisar e refatorar nosso código em busca de performance, mas, o que eu gostei particularmente no ANTS é na facilidade de utilização e na coerência dos resultados.

O ANTS possui várias ferramentas muito simples de usar e oferece ganhos significativos para você que é desenvolvedor e está num projeto solo ou para você que é arquiteto pensando em como provar uma arquitetura ou modelo para o próximo projeto.

Você pode baixar uma versão trial no site da Red Gate e experimentar por 14 dias todas as funcionalidades da ferramenta.

A idéia é muito simples: Você aponta para um site que está publicado em sua rede local, ou mesmo para a pasta onde seu projeto web está “deploiado”. No caso da pasta, o próprio ANTS vai iniciar um application server (cassini) e carregar sua aplicação. Enquanto você navega pela sua página, o ANTS vai registrando um gráfico de recursos da aplicação. Este gráfico contém contadores que são totalmente configuráveis (processador, memória, IO, etc).

Ao encontrar picos de utilização, você pode selecionar a área na time-line com o mouse. Automaticamente, o ANTS mostrará o código implementado com todos os métodos e quais são os candidatos a estarem causando o problema. Podemos ver na imagem abaixo, um exemplo da análise:

Tela Principal do ANTS Profiler for .NET

Além de aplicações web, você também pode utilizar o profiler para desktops, fazendo a análise diretamente dos arquivos executáveis.

Eu já utilizei o ANTS em um projeto crítico de performance e ele me ajudou muito. Só na primeira utilização, conseguimos melhorar a performance de uma página home em quase 60%. Então recomendo fortemente que vocêteste e comece a utilizar por uns dias. Se gostar, vale a pena o preço.

A idéia é você utilize uma ferramenta de profiler e se preocupe com a performance do seu código no dia-a-dia, a cada linha de código escrita. Muitos desenvolvedores só pensam na performance de sua aplicação quando terminam de desenvolver todo o código e passam o sistema para a “fase de validação”. Quando o sistema é colocado no ambiente do cliente ou num ambiente de testes preparado com infraestrutura e dados reais. Só que aí, descobre-se que aquele design de arquitetura lindo que você leu num livro e colocou no projeto está fazendo com que um tela do sistema leve 5 minutos para carregar.

Podemos classificar isso como um AntiPattern (desenvolve, testa, “tuna”), mas vamos falar sobre isso em outro artigo

Enquanto isso, espero que o ANTS ajude a todos vocês como me ajudou.

Grande abraço.

André Nascimento