28 de set. de 2009

Produtividade e Métricas de Software – Parte I

Discutir sobre produtividade e métricas pode ser muito divertido caso tenhamos no mesmo grupo representantes dos atuais mundos do desenvolvimento de software: o tradicional e o ágil. No entanto, acredito que o debate se tornará proveitoso caso as discussões evoluam para o comum acordo entre as partes, e não para a briga de egos ou apegos filosóficos! ;-)

É muito comum observarmos que tanto o cálculo da produtividade quanto a utilização de unidades de medida em projetos de software tem gerado polêmica em reuniões, palestras e listas de discussão. O principal motivo é que a medição de determinadas informações pode gerar desperdício no processo caso seu resultado não agregue valor em atividades de planejamento, controle ou melhoria do ambiente de produção.

No dia 4 de agosto de 2009, tive a oportunidade de conduzir um encontro de análise e resolução de problemas num cliente já aderente à cultura ágil, que incorporou com sucesso ações sistemáticas de melhoria contínua nas práticas mensais de sua unidade de desenvolvimento em Porto Alegre (RS). Naquela ocasião, optamos por não utilizar nossa ferramenta padrão de investigação de cenários de melhoria (Café Kaizen), pois o interesse da discussão, proposto pelo Gerente Geral de Desenvolvimento, estava focado na seleção de métricas para a avaliação da produtividade de suas equipes de software.

O assunto foi despertado devido ao interesse crescente da alta gerência em avaliar a capacidade produtiva das equipes de desenvolvimento com a utilização de uma “unidade padrão de medida” que fosse reconhecida pelo mercado internacional de software. A justificativa dos mesmos estava no interesse por uma avaliação de benchmarking que comparasse os custos e a produtividade das equipes localizadas em diferentes regiões do Brasil.

Fiquei surpreso com o fato dos gestores estarem propondo a utilização de Pontos de Função como unidade de medida do cálculo de produtividade (sob a orientação de outros consultores), pois esta decisão entraria em choque com as atuais práticas incorporadas na empresa que já utilizam Story Points como base para a medida de tamanho de produto e produtividade das equipes.

Diante desse cenário, utilizamos a reunião para analisarmos algumas métricas comuns do desenvolvimento de software, bem como suas vantagens e desvantagens na avaliação dos resultados das equipes de desenvolvimento. Este post relata a primeira parte das reflexões que fizemos sobre este tema durante o encontro. Começarei apresentando uma reflexão sobre produtividade baseada no cálculo de linhas de código, dado que este era um tema presente no ambiente de produção do cliente e ainda persiste em muitas empresas de software pelo país.

Investigando a Unidade de Medida "Linhas de Código"

Não vou me deter muito tempo sobre este tema dado que o entendimento do mesmo já deve ter evoluído bastante em nossa comunidade de software nos últimos anos. Pelo menos isso é o que eu espero das pessoas que evoluíram junto com os avanços da nossa querida Engenharia de Software! ;-)

Vou contar duas histórias para tentar transmitir minha opinião sobre produtividade calculada com linhas de código.

Caso #1: Produtividade Negativa de um Desenvolvedor Sênior

“Certo dia, acordei com muita disposição para trabalhar. Cheguei cedo no escritório, li meus e-mails e me dirigi para a reunião diária de atualização de projeto. De volta para a minha mesa, e de posse dos requisitos funcionais que eu desenvolveria naquele dia, preparei minha IDE para começar uma jornada de trabalho que seria a mais produtiva de minha vida! Fiz o update de meu projeto para ter a certeza de que eu teria todas as alterações de código realizadas por colegas de equipe desde o último commit no repositório. Analisei as demandas e identifiquei os componentes que seriam alterados e criados no sistema. Infelizmente, meu antigo colega havia feito um “espaguetão” quando desenvolveu os componentes que eu deveria atualizar naquele dia, demonstrando total desconhecimento de nossa arquitetura e conceitos básicos de programação orientada a objetos. Fui obrigado a realizar um belo refactoring em todas aquelas classes e desenvolver novos componentes que receberiam elogios dos maiores gurus da engenharia de software. Eliminei centenas de linhas reutilizando componentes e explorando design patterns, escrevi poucos métodos e linhas de código, mantive o código padronizado e intuitivo para os próximos colegas que utilizariam o mesmo, garantindo 100% de cobertura em testes de unidade para cada componente. Passei todo o dia refatorando os componentes existentes e criando novos elementos altamente enxutos. Sabe qual foi o resultado? Entreguei três novas funcionalidades num único dia e reduzi em mais de 1.000 linhas nosso código fonte, tendo passado em todos os testes de integração! Sinto-me realizado!”.

Comentário: Nosso amigo fez tudo isso e acabou tendo uma produtividade negativa calculada em linhas de código!

Caso #2: Produtividade do Fornecedor Mal Intencionado

"Pessoal, não se esqueçam de utilizar aquele sistema gerador de código que baixamos da Internet. Ele caiu como uma luva em nosso projeto, pois aumentou consideravelmente nossa produtividade! Para atender todas as necessidades de diferentes equipes de desenvolvimento, ele insere tudo que você pode imaginar no código fonte, gerando um monte de linhas inúteis e deixando o mesmo difícil de ser analisado. Como nossa equipe é remunerada por linhas de código, ele é perfeito! A propósito, não percam tempo estudando a API do sistema. Refaçam tudo o que for necessário! Não economizem na velha técnica de 'copiar e colar'! Afinal de contas, nosso cliente está pagando pela quantidade de linhas de código que entregamos semanalmente em seu repositório de aplicações. Até na correção de bugs nós ganhamos pela manutenção das linhas que não passam nos testes de aceitação. Ainda bem que eles não sabem realizar inspeção de código, automação de testes e integração contínua!”

Comentário: A quantidade de linhas de código pode ser uma excelente medida de desempenho para quem não é produtivo ou não dá valor ao dinheiro dos outros!

Observações:

Saber o tamanho de um produto de software em função de suas linhas de código pode ser útil para o entendimento do crescimento de um repositório de controle de versões ou identificação da complexidade de um sistema legado que entrará em manutenção de melhoria ou migração de plataforma tecnológica. Não podemos negar que os riscos associados a manutenção de um sistema de 1 milhão de linhas de código é muito maior que os riscos associados a um sistema com 100.000 linhas de código. Se você estiver utilizando um bom sistema de controle de versões, essa informação pode ser facilmente obtida de seu repositório de programas.

Por outro lado, calcular a produtividade da equipe ou remunerar profissionais pelo total de linhas de código produzidas por unidade de tempo (como foi feito na grande maioria dos projetos do “bug do milênio”) é completamente insano nos dias de hoje!

Talvez você diga que pode ser uma informação útil para definir a escolha de uma linguagem de programação ou plataforma tecnológica (com qual linguagem eu desenvolvo o mesmo número de funcionalidades com menos linhas de código). No entanto, gerar poucas linhas e não ser capaz de garantir a qualidade do que foi gerado por inspeção automática de código ou integração contínua com testes automatizados pode impactar diretamente nos ganhos de produção a médio prazo.

No próximo post, medidas de tempo e pontos de função ...

8 de set. de 2009

Percepções do Agile 2009 (Chicago, USA)

Caros amigos, retornei do Agile 2009 (Chicago) com algumas considerações sobre o que está acontecendo no mercado internacional de desenvolvimento de software. Dentre elas, gostaria de relatar nove que me deixaram mais frustrado do que empolgado quando comparo os fatos identificados e a situação brasileira do mercado de métodos ágeis ... Confira!
  1. No exterior, "métodos ágeis é coisa para gente experiente"! Enquanto por aqui falam que isso é coisa de "gurizada", por lá muitos dos palestrantes tinham cabelo branco ... sem contar que a maioria foi ou é líder de grandes empresas. Tive o prazer de conhecer pessoalmente um dos ex-engenheiros de software do projeto Apolo (NASA, anos 60), Mr. Jim Highsmith (atual diretor do Cutter Consortium). Sem contar com os demais gurus que lá estavam presentes ...
  2. Enquanto no Brasil quem vai nesses eventos são alunos e pessoas sem muito poder de decisão, por lá tivemos a oportunidade de sentar à mesa com gerentes e diretores da Microsoft, HP, Motorola, American Airlines, Disney, Amazon.com, ThoughtWorks, governo americano e muitas outras grandes empresas ...
  3. Enquanto no Brasil a grande maioria ainda está pensando se as metodologias ágeis realmente funcionam, por lá o que mais ouvimos foram relatos de projetos com equipes distribuídas em diversos continentes, todos com milhares de profissionais alocados nas mais diferentes partes e culturas do planeta. Ouvimos relatos de um projeto de "agilização" de uma empresa asiática com aproximadamente 40.000 profissionais ... não conheço empresa brasileira que tenha tudo isso!
  4. O modelo de gestão da Toyota (Lean) é a tendência para a grande maioria das organizações que adotam agile. Scrum e XP continuam em alta, mas é muito mais fácil adotar as práticas de gestão de times do Scrum num primeiro momento do que toda a disciplina de engenharia de software demandada pela XP. O que tem que ficar claro é que as práticas da XP acabam se tornando um caminho natural quando um time Scrum atinge seu máximo de desempenho e Lean tem que estar no sangue dos gestores e cultura da empresa ...
  5. Grandes empresas de fornecimento de serviços de software, totalmente baseadas nos princípios e práticas ágeis, já estão recusando projetos de milhões de dólares quando os mesmos estão sendo demandados com a utilização de metodologias tradicionais. O sucesso do projeto e a satisfação de todos os seus integrantes é mais importante do que a receita obtida associado ao risco do fracasso, pois o desenvolvimento ágil está mostrando maior lucratividade e fidelidade do cliente.
  6. "Coaching" é assunto sério! Assim como não é comum vermos atletas profissionais de elite treinando sem a supervisão de um excelente técnico (somente amadores treinam sem supervisão técnica), empresas de alto desempenho fazem uso indiscriminado de profissionais experientes estimulando o aprimoramento técnico de novas equipes.
  7. Não conseguimos falar de planejamento desacoplado da análise de requisitos. Além disso, como o foco das metodologias ágeis sempre foi a agregação de valor ao negócio do cliente, cada vez mais é demandada uma competência em análise de negócios para todos os integrantes da equipe de desenvolvimento envolvidos no desenvolvimento de requisitos.
  8. Representantes do PMI internacional estavam em peso no congresso, uma vez que a estratégia internacional é orientar os PMPs a aderirem a práticas que realmente funcionam em projetos de software: processo criativo e desenvolvimento orientado a auto-gestão da equipe de desenvolvimento (comunicação e liderança). Nossos PMPs terão que "se puxar" para encarar essa ...
  9. Agile 2009 (Chicago): US$ 1.800,00 de inscrição, recursos da ordem dos US$ 1,5 milhões, 1.500 participantes ... Agiles 2009 (Florianópolis): muitos dos palestrantes nacionais e internacionais do Agile Chicago, R$ 100,00 de inscrição, recursos da ordem dos R$ 100K, e se der 400 participantes é muito! Realmente, a nossa realidade é outra ... ;-(
  10. Quanto aos brasileiros falando em Chicago? Nos saimos muito bem (eu, Rafael, Alexandre, Danilo e Francisco) com nossas palestras e workshops! Ficou claro que estamos fazendo muito bem nosso dever de casa (como consultores e instrutores) e estamos cada vez mais sendo respeitados pela comunidade internacional ... só falta nosso mercado nacional perceber que "santos de casa podem fazer milagres" ... ;-)

Para mim, as metodologias ágeis serão disseminadas em nosso país quando ensinarmos nossos clientes (compradores de projetos de software), a questionarem os desperdícios existentes nos processos de seus fornecedores e avaliarem de forma objetiva a qualidade dos produtos a eles fornecidos.

Para quem não pode comparecer, confira uma matéria bem legal em vídeo feita pelo pessoal da Agile Journal.

5 de jul. de 2009

A jornada de trabalho e os desperdícios da produção de software

Considerando que a Constituição da República Federativa do Brasil prevê em seu artigo 7º, inciso XIII, que a duração de uma jornada normal de trabalho não deve ser superior a 8 horas diárias, começo a me questionar o que nossas atividades de desenvolvimento de software possuem de tão anormal para acharmos que essa carga horária seja insatisfatória para atender todas as necessidades de nossos clientes. Pode ser o excesso de demanda, a falta de profissionais, o excesso de falhas, ou qualquer outra justificativa resultante da ineficiência ou ineficácia de nossas equipes. O fato é que, considerando que a Constituição limita nossa jornada semanal em 44 horas (por incluir a manhã de sábado no horário comercial), por que precisamos ser inconstitucionais para conseguirmos atender os níveis de produtividade exigidos por nossos clientes (trabalhando até 60 horas por semana)? Talvez porque não temos a mínima idéia de onde investimos nossos esforços ou acontecem os desperdícios da nossa jornada semanal de atividades de desenvolvimento de software. Vamos analisar a natureza de nossos esforços e pensar se o que realmente precisamos é de mais gente em nossas equipes de desenvolvimento ...

Disponibilidade Semanal

Tipicamente, vejo muitos gerentes de projeto adotando uma jornada diária de 8 horas para cada profissional alocado em seus projetos de software, limitando a participação dos mesmos em 40 horas semanais (segunda à sexta). Para fins de cálculo, vou fazer o mesmo e considerar essas 40 horas como sendo 100% da disponibilidade de um membro da equipe de software para a realização do trabalho desejado. Não vou julgar se isso é bom ou ruim como premissa de planejamento, o que vou fazer é seguir as orientações de nossa Constituição e limitar o trabalho de segunda à sexta-feira.

Desperdícios das Atividades Extraordinárias

Se você é um profissional contratado para atuar no desenvolvimento e manutenção de software, qual é o principal resultado que se espera do seu trabalho? Talvez um produto de software em perfeito funcionamento, mais alguns artefatos técnicos e administrativos necessários para a manutenção do desempenho e qualidade do processo. Correto? Pois bem, agora pare e pense no percentual de horas que você gasta semanalmente em atividades que não possuem qualquer relação com os processos de desenvolvimento e manutenção de software. Para ajudá-lo, vou dar alguns exemplos:
  • Necessidades sociais ou fisiológicas (descanso, ginástica laboral, reuniões privadas, telefonemas, café, banheiro, cigarro, chats, etc.);
  • Qualquer tipo de atividade profissional não relacionada diretamente com os processos de software (reuniões administrativas, atendimento a usuários, suporte técnico, leitura de e-mail ou documentos, telefonemas, etc.).
É claro que muitas dessas atividades não são desperdícios, mas ações necessárias para a manutenção do bem estar do ser humano. No entanto, é comum exagerarmos no tempo dedicado a algumas delas, tornando parte das mesmas um total desperdício de tempo produtivo. Para dar mais uma ajuda na sua estimativa, considere que os alemães, os mais produtivos do planeta, apresentam um desperdício semanal da ordem de 11%, enquanto que os ingleses desperdiçam 22% do seu tempo. Nos EUA, algumas pesquisas indicam desperdícios da ordem dos 30% da jornada diária de trabalho.

Quanto você apostaria ser o desperdício semanal de sua equipe em atividades extraordinárias? Para fins de cálculo, vou considerar o valor dos americanos ... 30%. Logo, das 40 horas de trabalho semanal que você alocou em seu plano de projeto, restaram apenas 28 horas para você fazer realmente o que agrega valor a um produto de software! Mas isso não é tudo ...

Desperdícios da Burocracia e do Retrabalho (Muda Tipo II)

Este é um tema que, muitas vezes, me deixa chocado quando converso com alguns profissionais de empresas de software que desconhecem os desperdícios (muda, em japonês) ensinados no pensamento enxuto da Toyota. Ele está diretamente relacionado ao percentual de trabalho semanal que gastamos em atividades burocráticas e correções de falhas, pois não agregam qualquer tipo de valor ao produto final de nosso trabalho. É aquele tipo de trabalho pelo qual deveríamos desenvolver alguma alergia ou vergonha caso o praticássemos de forma sistemática em nossas empresas. Para mim, um trabalho mais nocivo que a atividade extraordinária, pois demonstra a falta de comprometimento da empresa com a qualidade do produto, do processo e satisfação do cliente. Para o modelo de gestão enxuta, ele deve ser totalmente eliminado!

Quanto você apostaria ser o desperdício semanal de sua equipe em atividades burocráticas e de retrabalho? Aqui podemos encontrar uma grande variação devido a natureza das equipes de desenvolvimento de software, mas você poderia pensar em exemplos relacionados a seis dos sete desperdícios identificados no modelo de gestão da Toyota: 1) percentual de não conformidades existentes em seu backlog de trabalho, 2) tempo gasto com excessos de produção (fazer além do necessário), 3) tempo gasto com o gerenciamento da informação (estoques dos excessos de produção), 4) tempo gasto com movimentações desnecessárias (layouts indevidos ou mudança de tarefas), 5) tempo gasto com o transporte de informações (atividades burocráticas) e 6) tempo gasto com esperas diversas (falta de sincronização dos membros da equipe). Você pode responder um valor em torno de 20%, 50% ou até mesmo 100% (já vi equipes totalmente dedicadas a correção de falhas, comprovando o total desperdício de seus profissionais devido a ineficácia de seu processo de desenvolvimento). Para você não desistir do resto da análise, pense na organização como um todo e faça uma estimativa ...

Para fins de cálculo, vou considerar os mesmos 30% das atividades extraordinárias, que é um valor otimista porém aceitável para os níveis de eficiência (excesso de atividades burocráticas) e eficácia (número de falhas a corrigir) de nossas empresas. Logo, das 28 horas de trabalho restantes do item anterior, subtrairemos 12 horas do desperdício da burocracia e do retrabalho, resultando em 16 horas disponíveis para você realmente agregar valor ao produto de software!

Será que é por isso que planejamos uma "margem de segurança" no final do cronograma de projeto? Até agora, você já pode multiplicar a duração estimada para seu projeto por um fator de 2,5 e ainda assim pode ser pouco para a realidade de sua equipe ...

Quer saber por que eu escrevi que esse tema me deixa chocado quando converso com alguns profissionais de outras empresas? Porque diversas vezes ouço afirmações do tipo:

  • "Não existe software sem falhas ..."
  • "Não tem problema se a equipe de desenvolvimento produzir falhas, nossa equipe de testes poderá detectá-las antes mesmo de entregarmos o produto para o cliente ..."
  • "Temos uma equipe de manutenção dedicada somente à correção de falhas ..."
  • "Todas as falhas detectadas na fase de testes são registradas e gerenciadas num sistema de controle de não conformidades, cujas correções serão planejadas a fim de serem incorporadas em releases futuros ..."
  • "Toda essa burocracia é necessária devido ao nível de complexidade de nossa empresa ... "
Desperdícios das Ineficiências Operacionais (Muda Tipo I)

Este é outro assunto controverso, pois trata de todas as atividades que não agregam diretamente valor sobre o produto de software (funcionalidades percebidas pelo cliente), mas que não podem ser eliminadas do processo pois estão relacionadas a práticas de engenharia de produto, engenharia de sistemas, engenharia de software e gerência de projetos. Ele está diretamente relacionado a um dos sete desperdícios do pensamento enxuto que fala da necessidade de um processamento adicional devido às ineficiências operacionais de nossa organização. A família Poppendieck faz referência a este desperdício como sendo resultante de um déficit tecnológico, que também pode ser entendido como limitações na capacidade de processamento da equipe.

Costumo dizer que se não podemos nos livrar dessas práticas, pois elas são intrínsecas da natureza do nosso trabalho, devemos realizá-las no menor tempo possível, pois não resultam em produto de software potencialmente entregável ao cliente. Ou seja, quanto mais tempo eu me dedicar a estas atividades (perceba que os outros seis desperdícios ainda assombrarão este tipo de atividade), menos tempo eu terei para produzir o software desejado. Estas atividades podem ser tanto de apoio e gestão quanto de preparação de ambientes e investigação de novas tecnologias.

Por que este assunto é controverso? Vou dar alguns exemplos de atividades que geram desperdícios por ineficiência operacional e você tira suas conclusões:

  • Captação e Análise de Requisitos - existem técnicas de comunicação humana que podem diminuir consideravelmente o tempo de realização dessas atividades;
  • Especificação e Validação de Requisitos - existem padrões de documentação, baseados em arranjos logísticos da produção Just in Time (JIT), que podem triplicar a capacidade produtiva de uma equipe de software;
  • Planejamento de Projeto - existem técnicas extremamente simples, baseadas no balanceamento da produção e na capacidade produtiva da equipe, que permitem estimar o tempo e o esforço necessários para a execução do projeto;
  • Controle de Projeto - é possível desenvolver equipes autogerenciadas;
  • Inspeção da Qualidade de Código - existem ferramentas de software que inspecionam de forma automatizada a qualidade do código fonte gerado por todos os membros da equipe;
  • Testes de Unidade e de Sistema - existem ferramentas que automatizam a realização dos mais diferentes tipos de testes para comprovar tanto a eficácia quanto a eficiência de sua aplicação;
  • Integração e Deployment - existem ferramentas que podem automatizar o "empacotamento e entrega" do produto de software em ambientes de produção complexos;
  • Setups de Ambientes de Trabalho - existem ferramentas de análise, design, codificação, testes e implantação que permitem realizar de forma rápida e efetiva as atividades de desenvolvimento, manutenção e operação de software;
  • E muitos outros exemplos!
Veja bem como é delicado definirmos um nível ótimo de esforço para esse tipo de atividade, pois a ausência ou o excesso das mesmas pode aumentar consideravelmente os riscos e a duração do projeto de software. Quanto você apostaria ser o desperdício semanal de sua equipe em atividades de apoio, gestão, preparação de ambientes e investigação de problemas e novas tecnologias? Aqui também podemos encontrar uma grande variação devido a natureza das equipes de desenvolvimento. Como nos restam dois dias de trabalho, segundo o saldo do item anterior, vou considerar 50% da disponibilidade produtiva remanescente (8 horas), representando 20% do tempo total gasto numa jornada semanal de trabalho.

Agregação de Valor

Por fim, concluimos a análise dos desperdícios com um percentual de nossa alocação semanal disponível para a produção e entrega do produto de software: 20% de nosso tempo (ou um dia de trabalho)! Mas que tipo de atividade realmente agrega valor ao produto de software? Aquela que, quanto mais fizermos com total qualidade, mais funcionalidades serão entregues na saída de nosso processo (sem a necessidade de retrabalho). Ou seja, a codificação do software em si e a produção dos testes automatizados necessários para a garantia da qualidade do que será agregado ao sistema.

Mas a criação dos testes agrega valor ao produto? Sim, pois dependendo da forma como você assume a elaboração dos testes, você estará fazendo simultaneamente a análise e o design daquilo que deve ser codificado (Test Driven Development, TDD), diminuindo consideravelmente tempo e esforço necessários na saída do processo (testes). Afinal, qual "gabarito" devo utilizar como referência para inspecionar e aprovar os componentes que pretendo integrar no produto de software? Se nossa equipe produzir continuamente componentes com falha zero, qual o valor agregado dos testes no final do processo?

Achou pouco tempo para desenvolver testes, componentes e funcionalidades? Se você fizer uma dinâmica com sua equipe de desenvolvimento e pedir para o grupo desenhar um mapa de fluxo de valor do cenário atual de sua organização, é bem possível que possa encontrar uma eficiência de processo (valor agregado) da ordem dos 10%. Organizações de alta maturidade relacionada ao pensamento enxuto costumam apresentar eficiências próximas a 50%.

Como sair deste cenário

Em sânscrito, a palavra "Samsara" é bem conhecida na maioria das tradições filosóficas da Índia (como o Hinduísmo, o Budismo e o Jainismo), e representa o fluxo incessante de renascimentos através dos mundos, mais especificamente, no mundo do sofrimento. No contexto de nosso ambiente de negócios, representaria o fluxo incessante de projetos de desenvolvimento e manutenção de software realizados com altos níveis de desperdício, principalmente de retrabalhos e burocracias que nada agregam ao produto desejado por nossos clientes.

O modelo de gestão enxuta (Lean) ensina métodos para a libertação desse tipo de sofrimento (desperdícios) e a conquista da felicidade mediante o desenvolvimento de equipes altamente eficientes e eficazes capazes de entregar um produto de software em pleno funcionamento, numa fração dos prazos convencionais de nossa indústria, e com uma qualidade inimaginável para nossos profissionais dos dias de hoje. A mágica está na busca contínua e incessante de melhores formas de fazer o trabalho diário, tendo sempre como foco a redução dos desperdícios. Só que, para isso, é necessário alocar um pouco do tempo escasso da jornada semanal de trabalho em atividades de desenvolvimento de competências e melhoria contínua, como a realização de grupos de Kaizen, por exemplo.

Assim como muitas filosofias orientais consideram ilusório procurar a felicidade em meio à ignorância, longe da prática da autodisciplina e do aperfeiçoamento pessoal, é ilusório acreditar que alcançaremos altos níveis de maturidade organizacional (não estou me referindo aqueles do CMMI ou MPS.BR) longe do desenvolvimento do ser humano, focando somente em ferramentas e processos. Decidir aumentar a produtividade com o aumento puro e simples do número de profissionais da equipe de desenvolvimento também é ilusório, pois acaba gerando retrabalho em diferentes aspectos e demandando ainda mais atividades de apoio e gestão, todas relacionadas a desperdícios no processo.

Aqui vão algumas dicas de por onde você pode começar o caminho da mudança e da conquista da verdadeira eficiência e eficácia do processo de software:
  1. Negocie com os membros de sua equipe a alocação de, pelo menos, 1h de atividades semanais focadas em melhoria de produtos e processos, dentro do escopo das Atividades Extraordinárias (são somente 2% daquela fatia dos 30%);
  2. Aprenda a enxergar os desperdícios de seu processo e a reconhecer as burocracias desnecessárias com a realização de workshops de Mapeamento de Fluxo de Valor (peça ajuda a algum profissional especializado);
  3. Incentive a consolidação de uma cultura de qualidade total na equipe de desenvolvimento, começando pela redução periódica dos níveis de falhas detectados nos produtos entregues ao cliente;
  4. Promova a análise periódica dos problemas, identificando suas causas raízes e os recursos que irão promover a conquista do cenário desejado (resolução dos problemas) - faça isso com a criação de grupos de Kaizen;
  5. Adote novas tecnologias se as atuais dificultam a eliminação dos desperdícios e a melhoria do processo organizacional;
  6. Acredite que sua equipe tem competência para trilhar este caminho caso conte com a ajuda de um orientador (coach ou sensei) capacitado.
Para concluir, apresento um diagrama que costumo incluir em meus cursos de capacitação profissional quando discuto os problemas que trato neste post. Ele mostra qual o foco dos ciclos de Kaizen na organização de software e como a redução dos desperdícios pode triplicar a capacidade de sua empresa.


Nota: Para quem tiver interesse, um excelente livro que trata da redução dos desperdícios segundo o modelo de gestão Toyota é Aprendendo a Enxergar, de Mike Rother e John Shook, 2000.

21 de jun. de 2009

Compreender a natureza dos requisitos pode estimular a adoção de metodologias ágeis

Na semana passada (quinta e sexta-feira), tive a oportunidade de conhecer a bela cidade de La Plata, na Argentina, graças ao convite que recebi do Centro Superior para el Procesamiento de la Información (CeSPI) da Universidade Nacional de La Plata (UNLP) para realizar uma edição "in company" do curso Requisitos de Software: Princípios e Práticas para Equipes Ágeis.

Foram dois dias muito agradáveis de teoria e prática garantidos por uma equipe bem participativa formada por 30 profissionais pertencentes ao CeSPI e ao Laboratório de Investigación en Nuevas Tecnologías Informáticas (LINTI). A turma era formada basicamente por gerentes de projeto, analistas de negócio e de sistemas, desenvolvedores e testadores, sendo que somente 20% dos participantes demonstrou conhecimento prévio dos princípios e práticas ágeis (um dos grupos está iniciando a adoção de Scrum).

Antes de continuar com o post, vou aproveitar a oportunidade para registrar meus cordiais agradecimentos a todo o pessoal da UNLP que esteve envolvido na realização do curso, em especial Alejandra, Christian e Juan, pois não economizaram cordialidade e atenção durante o período em que lá estive. ¡Muchas gracias por todo!
Pois bem, nesta última edição, tive a oportunidade de comprovar uma idéia que vinha se formando em minha mente nos últimos eventos - a de que o despertar do interesse pelas metodologias ágeis pode ser feito mediante o correto ensino da verdadeira origem dos requisitos de software: a mente humana!

"Me pareció muy inovador pensar los temas
desde el ser humano y no desde la tecnología."
Dalila, CESPI/UNLP

Todos sabem que os requisitos de negócio, de processo, de sistema e de projeto iniciam nas necessidades e desejos da mente humana. Porém, o que a maioria não sabe é como explorar esse fato com modelos objetivos de percepção, informação, decisão e atitude, gerando resultados ainda mais positivos em seus ambientes de negócio. As metodologias ágeis seguem um manifesto que fortalece os indivíduos e suas interações mais que processos e ferramentas, motivo pelo qual todo e qualquer profissional que atue na promoção ou implantação dessas metodologias deve entender alguns princípios básicos da natureza humana a fim de fortalecer a adoção dessa nova cultura e a percepção das verdadeiras necessidades dos projetos de software.

Minhas duas últimas turmas de requisitos de software realizadas na Argentina (Buenos Aires, com 39 alunos, e La Plata, com 30) eram formadas, em sua maioria (> 75%), por pessoas que desconheciam os princípios e práticas das Metodologias Ágeis, mesmo com o título do curso remetendo o foco para o treinamento de "equipes ágeis". Diante desse resultado, o que pude observar é que aqueles que adotam as práticas ágeis no seu dia-a-dia recorrem ao curso para conhecer novas técnicas, questionar dúvidas e aprimorar suas competências, enquanto que aqueles que desconhecem as metodologias recorrem ao curso para saber como nossas equipes ágeis tratam dos diversos aspectos da Engenharia de Requisitos, procurando respostas para a necessidade de simplificação de seus atuais ambientes de trabalho.

"El instructor mostró una versión distinta en muchos aspectos
muy interesante para ser aplicada en el trabajo diário."
Alejandra, CESPI/UNLP

A estratégia que adotei para ensinar requisitos de software à equipes ágeis, e que está provocando mudanças até mesmo na mente daqueles que adotam outras metodologias, pode ser resumida nos seguintes pontos:
  1. Apresentar estatísticas que evidenciem que o principal problema no processo de desenvolvimento de software ainda está relacionado com a forma como são tratados os diversos aspectos dos requisitos de software;
  2. Apresentar o modelo tradicional da Engenharia de Requisitos (captação, análise, especificação, validação e gerência) e questionar como e quando essas atividades são realizadas durante a história do projeto;
  3. Apresentar modelos de percepção e tomadas de decisão da mente humana e demonstrar como tudo o que percebemos da realidade depende da forma como as informações chegam e são armazendas em nossa mente (já discuti que o "Mapa Não é o Território" num post anterior);
  4. Apresentar conceitos e práticas que comprovam que a comunicação escrita pode ser utilizada de forma eficaz quando se tem consciência de que ela é um mapa que orienta a navegação durante nossa jornada (requisitos, por exemplo) e não o objetivo da jornada em si (o software, por exemplo);
  5. Demonstrar que a origem de muitos requisitos de produto e projeto de software pode estar associada a riscos quando sua essência está relacionada a necessidades básicas de segurança e reconhecimento do ser humano (pirâmide de Maslow) e não a melhoria do processo de negócio em si;
  6. Demonstrar que a origem de muitos requisitos de produto e projeto de software pode estar associada a riscos devido a crenças e valores limitantes que sustentam incapacidades e comportamentos indevidos do ser humano;
  7. Demonstrar que, em ambientes empresariais, todo e qualquer projeto faz parte da realização de uma estratégia de transformação de um processo organizacional, e que um produto de software deve sustentar essa transformação, motivo pelo qual os profissionais que atuam com requisitos devem conhecer os elementos do processo de negócio;
  8. Demonstrar como a transformação do processo de negócio pode ser descrita de forma sintetizada, utilizando um modelo de raciocínio baseado na resolução de problemas (Project Story);
  9. Demonstrar como as atividades do processo de negócio (Temas) podem ser alvo de análise na decomposição do problema, simplificando o cálculo do retorno de investimento em projetos de software;
  10. Demonstrar como o entendimento dos cinco princípios do pensamento enxuto (Valor, Fluxo de Valor, Fluxo Contínuo, Produção Puxada e Perfeição) pode mudar completamente a forma como desenvolvemos e gerenciamos os requisitos de software e justificar a utilização das User Stories;
  11. Apresentar as User Stories como um modelo de informações que permite o registro dos requisitos de software de forma aderente ao pensamento enxuto, garantindo a criação de mapas simplificados que nos conduzem ao verdadeiro destino de forma objetiva e segura (planejamento quantitativo e validação objetiva do trabalho realizado);
  12. Demosntrar como esse modelo de informações pode ser utilizado de forma efetiva em atividades de planejamento e controle de projetos de software;
  13. Demonstrar como podemos nos beneficiar da mudança de percepção sobre as atividades de gerenciamento de requisitos, passando a atuar no controle de estoques e na eliminação do trabalho inacabado em todas as fases de desenvolvimento de produto.
Ou seja, adotei uma estratégia top-down que inicia na mente humana, passa pela compreensão dos elementos do processo de negócio, avalia as necessidades de transformação dos resultados organizacionais, ressalta a importância da criação de anticorpos em nosso organismo para atuarem contra requisitos descabidos, e simplifica a compreensão do que deve ser documentado e mantido em nossos estoques de requisitos. O resultado tem sido o reconhecimento de que a cultura ágil tem fundamentos fortes e deve ser adotada por qualquer organização que almeje níveis superiores de qualidade e produtividade em suas equipes de software.

Para aqueles que gostam de metáforas, gostaria de fazer uma analogia entre os requisitos de software e a filosofia zen-budista (originada aproximadamente em 500 d.C., 1.000 anos depois da morte de Buda), que enfatiza permanentemente que "as palavras são um meio e não o fim em si (a iluminação)", motivo pelo qual muitos mestres preferem a prática na compreensão da verdade (aprender fazendo) e criticam os debates filosóficos na transmissão dos ensinamentos. Leia a história abaixo (clique para ampliar a figura) e descubra porque os requisitos nada mais são que o dedo que aponta para a lua!


2 de jun. de 2009

O Fim de uma Era ... e o que podemos aprender com a GM

Pois é ... na última segunda-feira, dia 31 de maio de 2009, a primeira empresa verdadeiramente moderna da indústria automobilística, recriada em 1920 pelo gênio Alfred Sloan, e totalmente gerenciada por números até os dias de hoje, pediu concordata. Esse fato foi analisado pelo guru dos Sistemas de Produção Enxuta, James P. Womack (criador do termo Lean), na última newsletter (02/06/2009) publicada pelo Lean Enterprise Institute sob o título "The End of an Era". Para Womack, esse dia marca o fim de uma discussão que persistia há mais de 30 anos, desde o começo do declínio da GM na recessão de 79. Ele diz que "Finalmente, o David derrubou o Golias, exatamente quando o Golias estava começado a prestar atenção na mensagem da gestão enxuta".

Analise bem este cenário:

  1. A GM possuia fábricas competitivas em termos de produtividade e qualidade;
  2. A GM possuia um processo de desenvolvimento de produto competitivo;
  3. A GM estava consolidando um sistema de produção global consistente, baseado nos princípios e práticas do Lean Manufacturing, mesmo depois de falhar por uns 15 anos na adoção do modelo com o apoio da própria Toyota (vide NUMMI);
  4. O modelo de gestão enxuta estava sendo adotado em todos os processos da empresa, até mesmo nos processos administrativos e de negócio.

Por que então a GM quebrou desse jeito? Simples! Porque todo esse movimento de renovação da gestão organizacional começou tarde demais! Na concordata, a GM mostrou para todos que ela não era lucrativa nem que ela sabia fazer gestão. Como assim? Que absurdo falar que uma empresa do tamanho da GM não sabia gerenciar seu próprio negócio! Pois é, Womack fala que o problema não estava na gestão dos números, uma vez que toda a Alta Direção era proveniente da área de finanças. O problema estava na concepção equivocada sobre qual o papel da gerência diante da organização e da sociedade. Em termos mais simples, podemos ter uma idéia do que ele quer dizer fazendo as seguintes perguntas:

  • Cadê o novo Sloan?
  • Onde está aquele líder capaz de repensar a missão da empresa e sua forma de gestão a fim de torná-la mais uma vez relevante para os americanos?
  • Mesmo que encontremos um líder, será que ele terá liberdade para tratar dos problemas e reconstruir a glória original da empresa com idéias inovadoras?
  • Será que as crenças arraigadas daquela gestão fria e calculista, que empurrou a empresa para o precipício, não irá impor barreiras para um novo modelo de gestão organizacional?

Sloan reconstruiu a GM no começo do século XX vendendo o "sonho americano" do carro luxuoso, o sonho do Cadillac. Só que o atual sonho dos americanos, e da grande maioria da população mundial, é do carro ecológico, barato e de baixo consumo de combustível, preferencialmente feito à base de energia limpa. Que mercado resta então para a GM diante de um atraso tecnológico no desenvolvimento dessa categoria de automóveis? O que fazer diante da concorrência que já possui automóveis rodando nas estradas alimentados por hydrogênio e eletricidade? Quanto a isso, só o tempo dirá ...

Pensem agora na área de software ... será que os 30 anos de debates aos quais Womack se refere (entre modelos de gestão industrial) começaram para nós na publicação do Manifesto Ágil, em 2001, ou na publicação do Objectory por Ivar Jacobson, em 1988 (primeira versão do modelo que viria a se transformar no RUP, em 1998). Pois bem, já faz 20 anos desde a disseminação do modelo de Use Cases e muita gente ainda não sabe como isso funciona! Sem falar naquelas pessoas que não compreendem ou não querem compreender (conheço várias) o paradigma de orientação à objetos ... Em 30 anos, a indústria automobilística evoluiu tanto a tecnologia e os requisitos mínimos de desempenho, segurança e conforto que até mesmo um carro popular da atualidade pode superar diversos modelos de luxo da década de 70 (na relação custo x benefício). Nossa área evoluiu consideravelmente nos últimos 5 anos, mas ainda muitos de nossos representantes permanecem consumindo modelos e tecnologias defasadas, sem nem passar pela mente termos como Releases, Sprints, TDD, Refactoring, Continuous Integration, Retrospectives, etc.

O que podemos pensar de tudo isso se compararmos essa "nova era" da indústria automobilística ou da gestão industrial com a revolução do desenvolvimento de software promovida pelos Métodos Ágeis? Será que em 2031, 30 anos após a publicação do Manifesto Ágil, os modelos tradicionais de gestão que conhecemos ainda estarão presentes em nossas empresas? Ou a queda de alguns impérios (como diversas fábricas de software que atuam estritamente com base no modelo taylorista de gestão empresarial) fará com que uma nova visão da gestão criativa do desenvolvimento de software consolide nossa nova era?

O que sei é que também precisaremos de líderes! Precisaremos de "gerentes" criados dentro de ambientes baseados numa cultura enxuta! Baseados numa cultura de excelência focada no ensino, aprendizagem e auto-gestão. Se começarmos agora, talvez em 2020 possamos colher os primeiros frutos na nova geração ... nossos novos líderes de projetos de software!

Por fim, Womack deixa claro em sua carta que até mesmo a Toyota não escapa da crítica diante dos resultados negativos que apresentou nesta última crise financeira. Ela cresceu mais rápido do que sua capacidade de desenvolver novos gerentes competentes para manter a cultura Lean e desvirtuou sua estratégia de crescimento para se tornar a maior organização da indústria automobilística, perdendo o ideal de ser a melhor organização para a solução dos problemas de seus clientes. Essas ações foram contraditórias ao próprio pensamento Lean e repercutiram nos últimos resultados financeiros da empresa.

Que lições podemos aprender de tudo isso?

  1. Não devemos deixar para amanhã o que podemos e devemos começar ainda hoje!
  2. O que parece lindo por fora pode estar podre por dentro ...
  3. Mesmo os mestres podem cometer erros em momentos difíceis ...
  4. É difícil transmitir arte, filosofia e sabedoria para nossas futuras gerações ...
  5. Adote um modelo vencedor para sua vida e não perca o foco na realização desse modelo!

Desejo muito sucesso para todos vocês!

27 de mai. de 2009

Jornada T@rgetTrust de Metodologias Ágeis

Caro(a) amigo(a),

Se você é daquelas pessoas que ainda não ouviu falar de métodos ágeis ou gostaria de esclarecer diversas dúvidas que ainda pairam sobre sua cabeça sobre esse assunto que virou febre nas últimas conferências, revistas e listas de discussão, se inscreva na I Jornada T@rgetTrust de Metodologias Ágeis. Este evento será realizado no dia 9 de Junho, terça-feira, no Auditório da Assespro, localizado no Tecnopuc, o maior Parque Científico e Tecnológico da América Latina.

Neste evento, Daniel Wildt, Guilherme Lacerda e eu, apresentaremos um "pout-pourri" de diversos temas, estimulando a participação de todos e desafiando as crenças arraigadas das abordagens tradicionais de desenvolvimento de software.

Confira a programação abaixo e venha tomar um café conosco naquela tarde!

[]´s

Parzianello

Jornada T@rgetTrust de Metodologias Ágeis

Venha compreender a origem, os princípios e as práticas da mais nova
tendência mundial do mercado de software!

Data, Horário e Local

9 de Junho de 2009
Horário: das 13h30min às 18h30min
Tecnopuc - Auditório Assespro

Investimento

R$ 120,00 por pessoa até 29/05/09
Acima de 3 inscrições 10% de descontoINTRODUÇÃO

Apresentação

As Metodologias Ágeis deixaram de ser apenas o sonho de muitos gurus da Engenharia de Software e passaram a ser a realidade de muitas empresas que adotaram seus princípios e valores como estratégia de sobrevivência diante da crise econômica mundial. As Metodologias Ágeis procuram garantir a satisfação do cliente mediante a entrega rápida e contínua de software em funcionamento, promovendo a cooperação entre os profissionais de negócio (equipe do cliente) e de produto (equipe de software), a excelência técnica em todos os níveis e a rápida adaptação às mudanças do ambiente de trabalho.

As Metodologias Ágeis exigem dos profissionais de software uma grande maturidade para lidar com a formação de times auto-gerenciáveis e a busca contínua da perfeição de pessoas, ferramentas e métodos. Por tratar diretamente dos aspectos humanos do desenvolvimento de software, são incompreendidas e alvo de críticas infundadas de profissionais que desconhecem a evolução dos modelos de gestão organizacional.

Quem deve participar

As empresas e profissionais da área de software que procuram orientação sobre como aderir aos conceitos e práticas das principais Metodologias Ágeis existentes no mercado.

O que iremos apresentar

Programamos para você uma tarde repleta de informações e debates com a participação dos principais expoentes da comunidade gaúcha de Métodos Ágeis. Serão abordados os seguintes temas que compõem a essência da mudança cultural exigida para o novo profissional que desenvolve software:

  • História, Princípios e Valores das Metodologias Ágeis
  • O Pensamento Enxuto (Lean) como Base para a Cultura Ágil
  • O Gerenciamento de Projetos com Scrum
  • A Engenharia de Software com Extreme Programming
  • A Engenharia de Requisitos em Ambientes Ágeis

Como vamos realizar

13:00 - 13:30 Recepção
13:30 - 13:45 Abertura T@rgetTrust
13:45 - 14:30 Introdução
14:30 - 15:15 Pensamento Enxuto
15:15 - 16:00 Scrum
16:00 - 16:30 Coffee-Break
16:30 - 17:15 Extreme Programming
17:15 - 18:00 Requisitos de Software
18:00 - 18:30 Debates e Encerramento

O que você irá ganhar

  • 5 horas de atividades, incluindo coffee-break
  • Material didático
  • Material de apoio
  • Certificado de Participação

Facilitadores

DANIEL WILDT - É um profissional de tecnologia da informação com 10 anos de experiência profissional. Atua em uma empresa brasileira como CIO. Certificações: SCJP/SCEA Part 1, JBuilder, Delphi/Delphi.NET, ITIL V3 Foundations, Scrum Master (CSM). Atua como Coach para adoção de Metodologias Ágeis desde 2004, focando em Lean Development, Scrum, eXtreme Programming e Feature Driven Development. Ensina programação, Metodologias Ágeis e Qualidade de Software na FACENSA (http://www.facensa.com.br). Atividades em comunidades de prática com o Grupo de Usuários Delphi do RS (http://www.dug-rs.org), Grupo de Usuários de Metodologias Ágeis do RS ( http://www.guma-rs.org), Comunidade de Ensino e Aprendizado do portaljava.net (http://edu-gelc.dev.java.net) e projeto JEDI (Java Education and Development Initiative) como responsável na implantação e disseminação do mesmo no Rio Grande do Sul.

GUILHERME LACERDA - É Mestre em Sistemas de Informação, área de Engenharia de Software, pela UFRGS. Dedica-se atualmente em atividades de consultoria e treinamento em Engenharia de Software e Metodologias Ágeis. Coordenador do Curso de Sistemas de Informação da FACENSA. Professor Universitário de Graduação (FACENSA, UniRitter) e Pós-Graduação (UniRitter). Atuou como diretor de tecnologia de uma empresa do ramo de software livre e open source durante 9 anos. Pioneiro em Metodologias Ágeis no Brasil, onde atua desde 2001, com especial ênfase em Lean, SCRUM e eXtreme Programming. Palestrante em dezenas de eventos nacionais e internacionais sobre o tema. Participou da revisão técnica do livro "eXtreme Programming Explained", do Kent Beck, lançado em 2004 pela Bookman. Fundador do XP-RS/GUMA, onde atua na vice-coordenação. Editor do Portal InfoQ, edição Brasil.

LUIZ CLÁUDIO PARZIANELLO - Formado em Engenharia Eletrônica pela PUCRS e Mestre em Sistemas Eletrônicos pela POLI/USP. Possui 25 anos de experiência em informática, tendo dedicado os últimos 10 anos a atividades de treinamento e consultoria em Melhoria de Processos de Software. Estuda e implementa metodologias ágeis desde 2003, dando ênfase a Lean Management, Scrum, Extreme Programming e Engenharia de Requisitos. Tem atuado como consultor e instrutor para diversas organizações no Brasil e no Exterior. É vice-coordenador do Grupo de Usuários de Métodos Ágeis da SUCESU-RS e palestrante da Conferência Internacional Agile 2009, em Chicago.

Para mais informações, ligue para (51) 3325-2596 ou mande e-mail para atendimento@targettrust.com.br.

25 de mai. de 2009

Relatos de Buenos Aires

De volta à Porto Alegre, relato aqui minhas impressões sobre como foi o curso Requisitos de Software: Conceitos e Práticas para Equipes Ágeis.

Primeiramente, gostaria de registrar a grande surpresa que tive com a presença de 39 alunos de diversas empresas públicas e privadas da região, sendo a maioria de empresas de grande porte como Movistar Telefónica, Ministério de Educación, Centro Superior para el Procesamiento de la Información de la Universidad de la Plata, T-Systems, Maypun, entre outras. Dentre os perfis observados, existiam alguns poucos desenvolvedores e testadores, porém muitos analistas, gerentes de projeto, arquitetos de software e consultores.

Pois bem, dos 39 alunos, somente 5 conheciam e utilizavam algumas práticas ágeis em sua equipes. Os demais eram provenientes da corrente tradicional do desenvolvimento de software. O resultado foi um curso extremamente provocante e desafiador, pois eu tinha na turma consultores de gerência de projetos (PMI) e melhoria de processos (CMMI).

Fiquei contente de poder voltar à mesma sala em que eu havia sido aluno de Mary e Tom Poppendieck no ano passado, no curso Lean Software Development (Agiles 2008), só que agora era eu quem estava na posição de instrutor. Pois bem, tirando a enorme diferença da qualidade dos instrutores (hehehe! seria ridículo eu me comparar aos Poppendieck!), eu tive uma vantagem de alunos que se transformou num transtorno para todos, dado que a sala só comportava um máximo de 28 alunos sentados confortavelmente e tínhamos 39! Fiquei com pena de algumas pessoas amontoadas, sem contar com o calor que passamos diante de um ar condicionado que não dava muita vazão a toda essa demanda ...

Tirando esses e outros percalços logísticos, que na minha opinião afetaram a qualidade do evento, consegui conquistar uma grande turma de céticos e deixá-los encantados com uma nova forma de captar, analisar, especificar, validar e gerenciar requisitos:

  • Iniciei com minha aula introdutória sobre percepção humana e mapas mentais, e como as fragilidades dos requisitos estão diretamente relacionadas às necessidades de Maslow e crenças formadas por filtros sociais, individuais, generalizações, deleções e distorções. Como sempre, todos ficam chocados com a verdadeira origem de nossos problemas ...
  • Passei pela identificação dos elementos básicos de um processo de negócio para tratá-los como o real problema do desenvolvimento de software, apresentando meu modelo de Project Story. Outra vez, o A3 Problem-Solving Report tem se mostrado muito efetivo neste aspecto.
  • Apresentei conceitos e práticas relacionadas às User Stories, como técnicas linguisticas para se escrever boas histórias e estimar o tamanho relativo das mesmas. Ficou claro para muita gente que a User Story é poderosa e deve ser utilizada antes de partirmos para um modelo mais sofisticado de Use Case.
  • Discutimos os aspectos do planejamento a partir dos pressupostos de Sprint e Velocidade da Equipe, bem como da decomposição do problema em temas de negócio.
  • Por fim, apresentei como o gerenciamento de requisitos pode ser feito para sustentar uma logística de requisitos baseada no modelo Just-in-Time.

Depois de 12h de atividades (exposição e prática), conquistamos os seguintes resultados na avaliação dos alunos: 100% dos alunos considerou alta a competência do instrutor, quase 80% reclamou da falta de material de apoio (não imprimiram minha apostila!), 90% reclamou da sala de treinamento (Hotel Bauen) e 64% achou que o curso deveria ter sido feito com uma duração de 16h (minha carga horária original). Mesmo assim, com todos esses problemas, conseguimos um percentual de aprovação (alto desempenho) de 95% dos alunos, o que me deixou muito feliz. Em breve, repetirei esse curso para a comunidade acadêmica da Universidad de La Plata e o mercado empresarial de Córdoba.

Por fim, gostaria de agradecer a acolhida dos colegas argentinos e parabenizar o grande interesse dos mesmos pela capacitação profissional em Métodos Ágeis e Engenharia de Requisitos, dois temas primordiais para qualquer empresa que trabalhe com desenvolvimento de software e queira se adequar às novas demandas do novo mercado de informática.

Um Dica Final ... Se você for à Buenos Aires e ficar hospedado pelas redondezas da Corrientes com a Callao, não deixe de comer um bife de chorizo ao molho de mostarda acompanhado de uma bela taça de vinho Malbec no restaurante Niña Bonita ... sem comentários!

18 de mai. de 2009

Requisitos de Software: Conceitos e Práticas para Equipes Ágeis

Depois de participar do grande evento que foi o Ágiles 2008, na Argentina, retorno à Buenos Aires nesta quarta-feira para ministrar o curso "Requisitos de Software: Conceitos e Práticas para Equipes Ágeis".

Nesta edição, com 12h de duração, terei a oportunidade de abordar um pouco mais de conteúdo do que sua primeira edição apresentada no Porto Alegre Agil Weekend (sempre ministrei o Programa de Capacitação em Engenharia de Requisitos com 40h). Dentre o conteúdo a ser abordado nesta edição, destaco:

  1. Human Mind, com foco em modelos de percepção, pensamento e mudança;
  2. Problem Identification, abordando fontes de requisitos, escopo de processo, projeto e produto;
  3. Project Story, um modelo de captação e registro de requisitos de projeto baseado na ferramenta A3 Problem-Solving Report da Toyota;
  4. User Stories, como base para a definição dos requisitos funcionais de produto e agregação de valor ao negócio por meio dos Business Themes;
  5. Project Planning, e como é possível realizar um planejamento mais realista tendo como premissa os requisitos de produto e a capacidade da equipe;
  6. Requirements Management, sendo abordado de forma exclusiva com base nos princípios da gestão Just-in-Time e de práticas de 5S.
Para quem quiser saber mais sobre o conteúdo programático deste curso, que deverá ser consolidado em jornadas de 16h no Programa de Capacitação em Metodologias Ágeis, a ser lançado pela TargetTrust ainda neste semestre, amplie o Mapa Mental exibido abaixo.

SOBRE O CURSO:

Requerimientos de Software: Conceptos y Prácticas para Equipos Ágiles
Fundación para el Desarrollo de las Nuevas Tecnologías
De 21 a 22/05/2009, Hotel Bauen, Buenos Aires, Argentina

Apoio Sociedad Argentina de Informática (SADIO)
Mais informações em
http://www.funtec.org.ar/cursos.html

15 de mai. de 2009

From Vision Statement to Product Backlog

Foi publicada no SlideShare a apresentação que fiz dia 14/05/2009 no Scrum Gathering Brazil. Faça o download dos templates da Project Story e do Product Scope do http://www.scribd.com/parzianello.

7 de mai. de 2009

Deus era agilista?

Antes de iniciar meu texto, gostaria de comunicar que este post é resultado de uma leitura da introdução do livro “A Estratégia da Genialidade - Vol.1”, de Robert Dilts, que faz uma análise da estrutura lingüística utilizada no livro Gênesis da Bíblia Sagrada. O texto não possui nenhuma conotação religiosa e mantém total respeito ao referido texto.

“Quero saber como Deus criou o mundo. Não estou
interessado neste ou naquele fenômeno, ou no espectro
deste ou daquele elemento; quero conhecer os
seus pensamentos; o resto são detalhes.”
Albert Einstein

Na introdução do livro citado acima, Robert Dilts escreve:

As palavras poderosas e emocionantes do Gênesis nos contam a história da criação em vários níveis. Além de descrever o que foi criado, está descrito o processo de como foi criado. Ali vemos a descrição “dos pensamentos de Deus” sob a forma de uma estratégia criativa que possui uma estrutura específica. Trata-se de uma estratégia que inclui um certo número de etapas que se desenvolvem em um ciclo contínuo que se retroalimenta.

Interessante! Segundo as observações de Dilts, a criação do mundo, pelo o que está escrito na Bíblia Sagrada, foi feita por um processo iterativo incremental! E continua:

A criação começa a partir de uma distinção – da criação de uma diferença. Este primeiro ato leva a outro e em seguida a outro e depois a outro – cada idéia estabelecendo o potencial para a próxima. Cada ato de criação inclui a reiteração de um ciclo que compreende três processos fundamentais:

1) Conceitualização: “E disse Deus: Haja ...”
2) Implantação: “E Deus fez ...”
3) Avaliação: “E viu Deus que era bom.”

Ficou muito claro para mim que o processo de criação do mundo, segundo a Bíblia Sagrada, está baseado num processo semelhante ao Scrum, pois contempla: Sprints com prazo fixo de 1 dia de duração (cada ato de criação se passa em um dia), um Product Backlog priorizado no início de cada Sprint (conceitualização), a realização do Sprint Backlog em cada dia (implantação) e a revisão daquilo que foi feito num Sprint Review. Só que considerando a onipotência e a onipresença de Deus, ele atuou em seu projeto como Product Owner, Scrum Master e Team Member, simultaneamente. Outro detalhe é que não há um detalhamento de requisitos no começo do processo, o que implica um projeto de natureza Just-in-Time (estoque zero). Para completar, Dilts expõe sua visão final do processo, que ao meu ver serve para descrever a forma criativa que procuramos adotar nas metodologias ágeis:

Cada ciclo provoca uma sucessão de idéias cada vez mais pessoais e refinadas. Com cada um dos ciclos, a idéia assume cada vez mais vida própria – ela é capaz de criar, multiplicar e sustentar outras idéias. A expressão maior reflete o processo do Criador de tal maneira que é capaz de abastecer todas as outras criações enquanto se multiplica.

Uma bela descrição do desenvolvimento ágil! Não é verdade?
Criar todo o mundo em 6 dias e descansar no 7º realmente foi uma obra divina!

Para aqueles que ficaram curiosos sobre o que está escrito no Gênesis, este é um livro de autoria desconhecida, porém atribuída a Moisés na tradição judaico-cristã. Ele deve ter sido escrito por volta dos anos 1450-1410 a.C., para descrever o princípio de tudo. É o primeiro livro da Bíblia Sagrada. Transcrevo o texto do Gênesis extraído do site http://www.bibliaonline.com.br/, onde fica claro que, no momento da criação do homem à Sua imagem e semelhança, estavam sendo concebidos os verdadeiros Usuários de toda a criação! ;-)

Gênesis 1:1 – 2:3

No princípio criou Deus os céus e a terra. E a terra era sem forma e vazia; e havia trevas sobre a face do abismo; e o Espírito de Deus se movia sobre a face das águas. E disse Deus: Haja luz; e houve luz. E viu Deus que era boa a luz; e fez Deus separação entre a luz e as trevas. E Deus chamou à luz Dia; e às trevas chamou Noite. E foi a tarde e a manhã, o dia primeiro.

E disse Deus: Haja uma expansão no meio das águas, e haja separação entre águas e águas. E fez Deus a expansão, e fez separação entre as águas que estavam debaixo da expansão e as águas que estavam sobre a expansão; e assim foi. E chamou Deus à expansão Céus, e foi a tarde e a manhã, o dia segundo.

E disse Deus: Ajuntem-se as águas debaixo dos céus num lugar; e apareça a porção seca; e assim foi. E chamou Deus à porção seca Terra; e ao ajuntamento das águas chamou Mares; e viu Deus que era bom. E disse Deus: Produza a terra erva verde, erva que dê semente, árvore frutífera que dê fruto segundo a sua espécie, cuja semente está nela sobre a terra; e assim foi. E a terra produziu erva, erva dando semente conforme a sua espécie, e a árvore frutífera, cuja semente está nela conforme a sua espécie; e viu Deus que era bom. E foi a tarde e a manhã, o dia terceiro.

E disse Deus: Haja luminares na expansão dos céus, para haver separação entre o dia e a noite; e sejam eles para sinais e para tempos determinados e para dias e anos. E sejam para luminares na expansão dos céus, para iluminar a terra; e assim foi. E fez Deus os dois grandes luminares: o luminar maior para governar o dia, e o luminar menor para governar a noite; e fez as estrelas. E Deus os pôs na expansão dos céus para iluminar a terra, E para governar o dia e a noite, e para fazer separação entre a luz e as trevas; e viu Deus que era bom. E foi a tarde e a manhã, o dia quarto.

E disse Deus: Produzam as águas abundantemente répteis de alma vivente; e voem as aves sobre a face da expansão dos céus. E Deus criou as grandes baleias, e todo o réptil de alma vivente que as águas abundantemente produziram conforme as suas espécies; e toda a ave de asas conforme a sua espécie; e viu Deus que era bom. E Deus os abençoou, dizendo: Frutificai e multiplicai-vos, e enchei as águas nos mares; e as aves se multipliquem na terra. E foi a tarde e a manhã, o dia quinto.

E disse Deus: Produza a terra alma vivente conforme a sua espécie; gado, e répteis e feras da terra conforme a sua espécie; e assim foi. E fez Deus as feras da terra conforme a sua espécie, e o gado conforme a sua espécie, e todo o réptil da terra conforme a sua espécie; e viu Deus que era bom.

E disse Deus: Façamos o homem à nossa imagem, conforme a nossa semelhança; e domine sobre os peixes do mar, e sobre as aves dos céus, e sobre o gado, e sobre toda a terra, e sobre todo o réptil que se move sobre a terra. E criou Deus o homem à sua imagem: à imagem de Deus o criou; homem e mulher os criou. E Deus os abençoou, e Deus lhes disse: Frutificai e multiplicai-vos, e enchei a terra, e sujeitai-a; e dominai sobre os peixes do mar e sobre as aves dos céus, e sobre todo o animal que se move sobre a terra.

E disse Deus: Eis que vos tenho dado toda a erva que dê semente, que está sobre a face de toda a terra; e toda a árvore, em que há fruto que dê semente, ser-vos-á para mantimento. E a todo o animal da terra, e a toda a ave dos céus, e a todo o réptil da terra, em que há alma vivente, toda a erva verde será para mantimento; e assim foi. E viu Deus tudo quanto tinha feito, e eis que era muito bom; e foi a tarde e a manhã, o dia sexto.

Assim os céus, a terra e todo o seu exército foram acabados. E havendo Deus acabado no dia sétimo a obra que fizera, descansou no sétimo dia de toda a sua obra, que tinha feito. E abençoou Deus o dia sétimo, e o santificou; porque nele descansou de toda a sua obra que Deus criara e fizera.

5 de mai. de 2009

Scrum é um framework?

Segue mais um email para a lista Scrum-Brasil que acredito ter se tornado um post para este blog! Ele inicia com a pergunta do colega Rodrigo Yoshima: Quando dizemos Scrum é um Framework, o quenecessariamente queremos dizer com isso?

Vou tentar dar uma pequena contribuição para esta discussão ... ;-)
  1. Scrum é um método de gerenciamento de projetos;
  2. Tipicamente, de projetos de desenvolvimento de produto (Product Backlog);
  3. Scrum tem como foco principal a entrega de valor para o cliente (Product Owner);
  4. Para tanto, explora a auto-gestão da equipe (Scrum Team);
  5. A equipe deve manter altos níveis de comunicação e colaboração;
  6. Scrum é baseado em muitos princípios e práticas do Lean Thinking;
  7. Por essa razão, exige um fluxo de valor do tipo Just-in-Time (JIT);
  8. Por ser JIT, trabalha com pequenos intervalos de produção (Sprints);
  9. Devido a isso, faz entregas frequentes com estoques reduzidos;
  10. Por ter estoques reduzidos, traz os problemas à tona;
  11. Uma vez que problemas podem surgir, um líder deve procurar contorná-los (Scrum Master);
  12. Os problemas são discutidos diariamente com a equipe (Daily Scrum);
  13. Bem como a evolução do produto (Burndown Chart);
  14. O produto evolui de forma dinâmica, de acordo com os interesses do cliente (Sprint Backlog);
  15. E equipe se compromete com os resultados do projeto (Sprint Planning);
  16. Os resultados obtidos são avaliados durante as entregas parciais do produto (Sprint Review);
  17. E uma análise crítica dos resultados é feita após cada entrega (Restrospective);
  18. E todo o processo reinicia até chegarmos ao produto desejado.

Por que eu escrevi esses 18 pressupostos? Porque muitos deles são diretrizes para o planejamento do meu processo de desenvolvimento. O Scrum não é um método prescritivo ao extremo, como é o RUP, que entrega até os templates de como você deve escrever cada artefato. Tanto um quanto o outro eu posso considerar como frameworks de processo, dado que a instância de cada um será diferente em cada empresa onde eles forem implantados. No entanto, tanto um quanto outro não abrem mão de suas diretrizes "obrigatórias", como no caso do Scrum com: Sprint de prazo fixo (2 a 4 semanas), um único Product Backlog (que muita gente ainda desconhece o poder de uma User Story), Daily Meeting (que muita gente não faz), Sprint Planning e Review (que muita gente não sabe como conduzir), Retrospectives (que muita gente não tem no sangue a melhoria contínua), Burndown Chart (que muita gente ainda tem alergia a métricas e indicadores de desempenho). Nestes itens, não há flexibilidade. A flexibilidade que existe é na exploração do processo criativo para o desenvolvimento do melhor produto, no melhor tempo e no melhor custo, a fim de atender as necessidades de meu cliente.

Ou seja, da mesma forma que um framework MVC tem dentre suas diretrizes obrigatórias a construção das classes GUI na estrutura V do modelo (se você colocar no M vai deturpar o modelo e prejudicar a manutenção e o controle do sistema), o Scrum possui essas características. Se seu sistema foi desenvolvido com base nesse framwork (MVC), mantendo total aderência às suas diretrizes obrigatórias, pode-se dizer que o sistema é uma instância do modelo MVC. Se seu processo de desenvolvimento de software foi planejado com base no framework Scrum, mantendo total aderências às diretrizes obrigatórias, pode-se dizer que o processo é uma instância do modelo Scrum. Conclusão: o Scrum é um framework!

3 de mai. de 2009

Brazil Scrum Gathering 2009

Pessoal! Estarei na próxima semana apresentando um trabalho inédito no Brazil Scrum Gathering 2009, em São Paulo. Nele, vou apresentar, pela primeira vez, um modelo de "Project Story" que estou concebendo para definir de forma rápida e efetiva o escopo de um projeto de software. É uma idéia que tem dado certo de trabalhar com um template de Project Charter com estruturas semelhantes à User Story.

Espero vê-los por lá!!
--------------------------

RESUMO DO TRABALHO
From Vision Statement to Product Backlog:
An Effective Way to Quickly Develop Project and Product Requirements


Wednesday, 13 May 2009 from 11:15 to 12:30

Product Backlog (PB) is a high-level description about what have to be done in a project performed with Scrum. It is well known that PB has to be written (or specified) by the Product Owner (PO), who knows the business rules and what software requirements have to be developed. The problem in this case is that sometimes neither PO nor team members know how to structure a mind process to develop project and product requirements. A systemic view of the business context and the NLP S.C.O.R.E. Model can help a Scrum team to quickly develop a useful PB based on User Stories. In this talk, we will show how to combine these assumptions to develop in PO and team members new communication skills for better working with software requirements.

TOPIC:

Most Neuro-Linguistic Programming (NLP) is oriented around defining a present state and a desired state, and then identifying and applying a technique that will hopefully help someone get to their desired state. The S.C.O.R.E. Model enriches that description by adding a few more simple distinctions. The letters stand for Symptoms, Causes, Outcomes, Resources and Effects. These elements represent the minimum amount of information that needs to be addressed by any process of change. We will show how to think about software as a “resource” that provides desirable “effects” in a business environment, improving process “outcomes” by eliminating the “causes” of undesirable “symptoms”. The User Story framework showed to be powerful when developing a PB based on these assumptions.

OBJECTIVES:
  1. How to use a systemic view (process thinking) to understand the project scope?
  2. How to use the S.C.O.R.E. Model to write a simple and powerful business plan for the project?
  3. How to challenge software requirements with the User Story framework?

18 de abr. de 2009

A Evolução do Pensamento Enxuto

Escrevendo uma resposta para a lista de discussões Scrum-Brasil, descobri que o texto ficou relativamente longo e adequado para se transformar num post em meu blog. Portanto, fiz algumas pequenas transformações para transcrevê-lo para meu cantinho de reflexões ... Espero que aprecie o texto. []´s Luiz
---------

Já faz algum tempo que passei adotar com êxito a seguinte estrutura conceitual em minhas atividades de consultoria e treinamento em ambientes de software complexos, até mesmo durante o tempo que coordenei uma unidade de sistemas totalmente heterogênea com equipes Progress, SAP, Oracle, Java, SOA, etc.:
  1. Lean Thinking no pensamento estratégico, a fim de transformar continuamente a cultura da organização de software;
  2. Scrum no pensamento tático, a fim de promover o trabalho em equipe, a autogestão e o foco em valor e fluxo de valor nos projetos de software;
  3. Extreme Programming no pensamento operacional, a fim de promover a excelência técnica e a perfeição do produto de software.

Pois bem, eu e mais outros colegas aqui de Porto Alegre, que também seguem esse modelo (conheço poucos), sabemos que Scrum e XP são aderentes aos princípios e práticas do Lean Product Development (vejam que eu não mencionei Lean Software Development pois este é uma variante do primeiro), motivo pelo qual temos nos aproximado cada vez mais das experiências e práticas dos modelos de gestão industrial (entenda Eng. Produção).

Na lista de discussões do Yahoo "Lean Development" vocês poderão observar que um grupo de pesquisadores internacionais formou uma força tarefa para visitar a Toyota no Japão a fim de dar continuidade à tradução do único modelo que deu certo na indústria automobilística (projeto, desenvolvimento e produção de automóveis) e que atualmente é seguido por todos os "sistemistas" (fornecedores) integrados nas cadeias logísticas dos grandes fabricantes. Por aqui, Brasil, estamos fazendo o mesmo, participando de cursos, seminários e conferências da indústria para realizarmos a tradução mental do modelo para a nossa área que é o desenvolvimento de software. Frente a isso, deixo os seguintes comentários sobre esta discussão:

  1. Workshop Gestão Lean Manufacturing, O Guia para Excelência
    http://www.exithum.com.br/workshop.html

    Estive presente na edição de Bento Gonçalves, RS (um grande polo de fábricas de móveis do RS), um evento apoiado pelo SINDIMÓVEIS para as fábricas que estão procurando dar uma guinada no modelo de gestão a fim de evitar os desperdícios e ganhar a liderança neste mercado. Você acha que Sprint Backlog, Burndown Chart e mais outras ferramentas simples, não eletrônicas, não fazem parte do modelo de gestão enxuta da Toyota? Acho que você se surprenderia de ver e ouvir princípios e práticas do Scrum (defendidos sob o modelo Lean, para mim, a origem de tudo) sendo aplicados nesta área industrial. Além deles, representantes de empresas como Pirelli, GKN e Continental (todas automobilísticas) relataram a seguinte frase: "Não temos mais como nos sustentar no mercado sem um sistema de gestão Lean!". Além deles, pasmem!, um representante de uma grande construtora chamada Melnick Even apresentou o grande sucesso de adoção do mesmo modelo (usando Kanbans para um sistema puxado/JIT, ciclos curtos de produção, gestão à vista, autogestão, etc.).
  2. Minha humilde opinião quanto a "Já está na hora de vocês pararem com isso, já começa a pegar mal, já é complicado hoje conseguir como um guia no desenvolvimento de softwares, imagina tentar gerenciar algo completamente diferente."

    Já está na hora de algumas pessoas pararem de falar sobre aquilo que não dominam ou não possuem experiência. Começa a pegar mal a demonstração de falta de conhecimento do grande movimento que está sendo realizado, e com êxito na maioria dos casos, para a migração dos princípios e práticas da gestão Lean para todas as áreas de serviço. Quem adota este modelo acaba observando que, às vezes, passa a ser necessário deminitir ou substituir gente que não aceita os valores intrínsecos da cultura (quando o programa realmente tem um forte sponsor e é implantado de cima para baixo), indo até contra os próprios valores da cultura de fortalecer e respeitar as pessoas. O ponto é que, se eu posso triplicar minha capacidade produtiva e aumentar a qualidade de meu produto, com o mesmo número de recursos disponíveis atualmente, pq vou dar chance ao azar deixando que retardatários atrapalhem meu processo de mudança?

Pense nisso ... pense que todas as empresas que atualmente possuem um nível aceitável de aderência ao modelo Lean já atuaram no modelo artesanal, já passaram pela produção em massa, e agora vivem com a mentalidade de melhoria contínua ininterrupta em todas as suas atividades ... e todas convergem para modelos de gestão de projetos muito semelhantes àquele definido em métodos como Scrum, XP, FDD, Cristal, etc.

Se tiveres oportunidade de vir à Porto Alegre no próximo fim de semana, para participar do Porto Alegre Agile Weekend (http://sites.google.com/site/agileweekend/), poderá assistir ao vivo a palestra de um dos diretores do PMI-RS falando sobre a forte tendência do PMI para os valores e práticas ágeis nos novos modelos ...