Alow Brasil !!!

Voltando a postar minhas idéias por aqui Uma das coisas que estavam na fila é abordar um pouco as diferenças entre um projeto com entregas de escopo ”programado”  e um projeto com entregas incrementais de software.

Acho que nos últimos meses, tivemos algumas situações bem interessantes que baseiam uma boa análise sobre este assunto. Vamos lá então.

Primeiro, é preciso conceituar os dois modelos: Entrega Cascata e Entrega Incremental.

Entrega Cascata:

Parte do principio que o projeto é dividido em fases estensas com cada uma focada numa área de conhecimento da engenharia de software. Em geral, os modelos mais comum parecem com isso:

Modelo waterfall padrão

Neste modelo, as fases do projeto são divididas e as entregas são feitas ao final de cada fase, separando-se os entregáveis geralmente em:

• Documentação funcional;
• Documentação técnica;
• Código fonte / programas;
• Plano e casos de testes;
• Evidência de testes;
• Documentação gerencial (cronogramas, WBSs, etc).

Pode-se também adotar uma estratégia de quebrar a fase de desenvolvimento em vários releases ou entregas parciais, que podem ou não ser focadas em módulos funcionais do sistema.

Este modelo apresenta alguns princípios básicos que o norteiam do início ao fim:

• O escopo é definido e desenhado no início do projeto e “não muda”. Além disso, o tempo e custo do projeto também são definidos desde o principio, baseado num processo de métrica como APF, UCP, ou outro qualquer;
• Antes da codificação, é altamente necessário que os modelos técnicos sejam fechados e provados, por meio de especificações técnicas;
• A codificação é feita sobre as especificações técnicas e funcionais escritas nas fases anteriores do projeto;
• Mudanças são tratadas como “change-requests” durante o projeto.
• O software é entregue somente após a fase de desenvolvimento, mesmo que haja modularização na etapa de desenvolvimento, o chamado “teste de integração” sempre será feito no final;

Existem outras características que até são importantes, mas não vou abordar agora, ok? Acho que essas já definem bem o modelo.

Entrega Incremental

Parte do princípio que o projeto é desenvolvido contando-se com o aprendizado funcional e técnico do cliente e das pessoas envolvidas. Possui tempo x custo fechados, mas aceita e encoraja melhorias e alterações no escopo para entregar um produto melhor ao final do projeto.

Em geral, um modelo incremental é bem parecido com isso:

Modelo padrão incremental

O projeto todo é dividido em releases e a cada entrega os envolvidos têm a chance de avaliar e dar feedback para que haja melhoria no proximo release. As disciplinas de engenharia de software são absorvidas dentro da construção de cada release, não estando em fases separadas.

Uma caracteristica muito importante neste modelo é que um time é obrigatoriamente composto por profissionais multidisciplinares, pois o trabalho é multidisciplinar.

Os princípios básicos que o norteiam este modelo são:

• Entregas incrementais de software funcionando e não somente ao final do projeto;
• Times muldisciplinares dedicados ao mesmo projeto do início ao fim;
• Feedback do cliente e usuários do sistema, vendo partes funcionais entregues a cada ciclo pequeno;
• Possibilidade de mudanças no escopo de acordo com o aprendizado obtido nas entregas;
• Alto nível de visibilidade de riscos no projeto, uma vez que eles precisam ser mitigados rapidamente para que uma entrega de software seja realizada;
• Mais foco na comunicação e menos nos documentos, uma vez que não é preciso documentar as necessidades do cliente detalhadamente, pois elas são rapidamente desenvolvidas pelo time e apresentadas ao cliente.

Também existem outras características importantes neste modelo, mas que não precisam ser ditas agora.

Bom, uma vez que conceituamos os dois mundos, vamos analisar no que isso impacta quando falamos num projeto de software:

Geralmente, tanto o cliente quanto a equipe de desenvolvimento estão acostumados a receber/entregar código-fonte e/ou programas funcionando somente no final do projeto. Isso traz uma falsa percepção de andamento, fornecida pelo famoso “%” de conclusão das tarefas.

A verdade é que enquanto não existe software funcionando, não dá pra dizer que algo no projeto andou de fato. Isso é um dos motivos para afimarmos que uma estratégia de “GANT” não serve para projetos de software.

Pois bem, as pessoas estão acostumadas a terem um projeto rodando muito bem do começo até a hora do “QA” ou ciclo de testes ao final da etapa de desenvolvimento. Com isso, o stress do projeto fica sempre para o final e a capacidade de se tomar decições corretivas ou de estabilização fica totalmente comprometida. Afinal, ficamos com pouco tempo hábil para corrigir os problemas de um projeto inteiro na hora do teste, certo?

Por outro lado, quando trabalhamos com desenvolvimento incremental, o stress que aconteceria no final do projeto vem para o começo. Isso é bom sob a ótica de gestão do projeto, pois temos uma tendência de melhorar a cada iteração.

MAS, nem tudo são flores. O grande problema, é que em geral o cliente não está preparado para ter stress logo no início de um projeto. Ele acaba achando que se as coisas estão ruins no começo, a tendência será sempre de piora e não de melhora.

Isso faz com que o nível de stress e desconfiança fique insuportável e em muitos casos com que a estratégia de entrega incremental fique inviável tanto para o cliente quanto para o time, pois as pessoas do time também não conseguem desenvolver um trabalho com o stress, pressão e desconfiança do cliente a todo instante.

Certa vez, ouvimos de um cliente:

“Nossa, mas vocês estão sendo transparentes demais com os problemas do projeto. Isso está errado, nós não queremos saber dos problemas de vocês. Contratamos um projeto e ele deve ser entregue, independente dos problemas…”

O fator de falha aqui está na cultura da contratação e na relação cliente x fornecedor. Se o cliente sabe do problema, automaticamente se torna responsável pela solução e ninguém quer ter problemas para resolver, mesmo que um dia eles venham puxa-lo pro buraco.

Em resumo, em alguns casos vemos que a “ilusão” de um projeto andando bem e que a falsa percepção de evolução é mais importante para o cliente do que ver software funcionando ou saber dos problemas para trata-los. Afinal, enquanto os problemas estão debaixo do tapete, fica muito mais fácil de não se comprometer e ao final jogar a culpa do fracasso no time de projeto.

Num caso como esse, deve-se repensar se realmente uma estratégia de entrega incremental agrega ao projeto. Em alguns casos, vamos ver que a única saída será o “bom e velho” Waterfall…

E você, o que pensa a respeito? Qual o melhor modelo de entregas na sua opinião?

Grande abraço !!!

André Nascimento

Alow Brasil…

Sempre existiram, existem e vão continuar existindo oportunistas em todo lugar. Em nosso país então, temos 15 por cada m². Estão em todo lugar, então… CUIDADO !!!

O que vemos hoje por aí é fantástico, chega a ser engraçado. O pior é que não é. Gostaria de apresentar o “scrum de prateleira”. A receita para fazer o seu é muito simples:

1. Pegue um cara que acha que conhece e pratica agilidade (geralmente porque fez um curso de 16 horas);
2. Junte com uma empresa (consultoria, software house, ISV, treinamento, etc), oportunista que não perde a chance de aumentar seu faturamento com um “novo produto”;
3. Acrescente uma pitada do bom e velho marketing nocivo da nossa indústria que “vende o sonho pra depois entregar um pesadelo”;
4. E, finalmente, coloque essa mistura em nosso bom e velho mercado prostituído de sempre.

Pronto, temos uma receita fantástica para o fracasso. E o pior? A culpa de tudo ao final será desse “tal de Scrum”.

A idéia que muitas empresas e pessoas possuem hoje quanto ao scrum está baseada na visão de um produto, uma caixinha que você compra numa loja, leva pra casa, abre e vive feliz. Agilidade não tem absolutamente nada a ver com essa idéia.

Experimente fazer esse teste: Procure no google algo como “scrum”. Simplesmente isso e você verá do que estou falando. A quantidade de empresas oferecendo: formação, treinamento, consultoria, etc, por aí é absurda.

O pior de tudo isso é que as pessoas estão caindo nessa! Tem gente achando que encontrou a formula mágica para todos os problemas da indústria de software, e que pra ter acesso a esse verdadeiro milagre é só fazer mesmo um curso e “ir pra cima”. Por favor, eu não estou falando que você não deva fazer um curso, ok? Ele é indispensável (desde que seja com alguém que realmente conheça agilidade). Mas, simplesmente pegar o scrum “enlatado” e colocar na sua empresa não é algo que dará resultados (pelo menos não positivos).

Muitas empresas estão com um foco total em ganhar dinheiro com o scrum hoje em dia e infelizmente prestam um desserviço a comunidade ágil. Essas empresas vêem o scrum como mais uma oferta de serviço, quando ele não é apenas isso. Ao partir para uma processo ágil você muda completamente a cultura da sua empresa, ou pelo menos da área onde se está trabalhando com agilidade.

Em minha opinião, o foco deve ser nas pessoas, sempre. A mecânica do processo por si só não vai resolver problema nenhum, é nas pessoas que devemos investir. O processo e a mecânica são meros coadjuvantes. Tentar utilizar/vender scrum sem entender isso é um grande tiro de 12 atrás da nuca

Por isso é que temos um número absurdo de pessoas fazendo reuniões diárias e pendurando pseudo-kanbans nas paredes e se dizendo especialistas em scrum ou em agilidade. Se está funcionando pra você, ótimo \o/ O problema é quando não funciona, não é? Neste momento teremos um novo e grande culpado: o SCRUM.

Se quiser adotar práticas ágeis na sua empresa ou equipe, por favor, não passe na loja. Esqueça o “produto” scrum na prateleira e não dê atenção para ele. Primeiro, leve para casa os princípios da cultura ágil e tente pratica-los. Nessa prática, o scrum te ajudará com algumas dicas e processos, nada mais !

Se continuarmos a pensar em agilidade como um produto de prateleira, teremos uma triste verdade daqui a pouco tempo…

Futuro com o Scrum de Prateleira

Leituras que podem colaborar:

• O que matou o Rup pode matar o Agile – Rodrigo Yoshima.
• Eu não uso Scrum porque Scrum não funciona – Tucaz.

Grande abraço

André Nascimento

Há algum tempo venho observando e registrando alguns fatores culturais envolvidos nas relações cliente x fornecedor, empresa x empregado, etc.

Semana passada, enquanto estava em Belo Horizonte e participava de uma apresentação sobre desenvolvimento ágil e scrum para um cliente americano aqui da Stefanini - a HNI Corporation – percebi o quanto esses fatores influenciam em nosso trabalho e principalmente na adoção de um aproach ágil para o desenvolvimento de software.

Vamos começar com essa imagem, que acredito que todos já devem ter visto em alguma apresentação sobre desenvolvimento ágil:

O Iceberg do Scrum

Quem está acostumado a falar sobre agilidade sabe que ela representa a visão de um processo ágil e sua adoção, onde temos:

O topo do iceberg, que representa o que todo mundo vê no scrum como mais importante,

• Processos – Ciclo, cerimônias, etc;
• Papéis – Product owner, Scrummaster, Time, etc;
• Ferramentas – Kanban, gráficos, etc

E a parte de baixo do iceberg que representa o que realmente importa e abrange um processo ágil,

• Auto gerenciamento;
• Comprometimento de todos;
• Comunicação aberta;
• Mudança cultural.

Desde o ano de 2008 tenho feito muitas apresentações sobre agilidade para os mais diversos públicos, desde equipes de desenvolvimento até CIOs e CEOs de empresas aqui no Brasil. Essa imagem do iceberg reflete muito o nosso cenário para adoção de agilidade. Quando falamos sobre a avalanche de mudança cultural que uma abordagem ágil oferece para a empresa todos ficam bem preocupados (principalmente executivos).

O que me chamou muita a atenção no caso da HNI é que eles viram a realidade diária deles na parte de baixo do iceberg. Ao final da apresentação o CIO da empresa nos disse bem animado: “Fantástico, já temos toda a base do iceberg e nem sabemos o que é Scrum. Agora só precisamos pensar em como e onde utilizarmos o processo para melhorar mais os nossos projetos”. Confesso que fiquei chocado…

Depois de ter digerido um pouco melhor a apresentação e seu impacto, cheguei a conclusão (meio que óbvia), de que o mercado brasileiro ainda precisa de um bom tempo para acreditar em desenvolvimento ágil e implementa-lo de fato. Hoje, temos uma cultura no desenvolvimento de projetos de software que está muito longe de ser colaborativa e auto-gerenciável.

Se pensarmos em nossos modelos de contratação – podemos começar vendo a questão sobre RFPs – já podemos ver que a coisa toda é direcionada para desviar dos problemas, antes mesmo de que aconteçam. Quase ninguém está interessado em fazer software com qualidade, porque a área ainda é tida como “buraco negro” das empresas, que só sugam recursos e não devolvem nada.

A verdade é que a grande maioria das empresas pensa no Scrum apenas como mais uma oferta de serviço: “Está na moda, então vamos botar no menú e ver o quanto vende…” Poucas pessoas e empresas estão interessadas na mudança cultural que é inerente a agilidade, como: Tratar profissionais como pessoas, incentivar o auto-gerenciamento, abolir o comando-controle, abrir mão da visão industrial de software, etc.

A questão é muito mais séria e complicada do que pensamos, pois as diferenças culturais são realmente muito grandes e pesadas. Estou pensando seriamente se um dia saberemos no mercado brasileiro o que é agilidade de verdade. É necessário abrir mão de muita coisa que se vê como essencial para aproveitar o valor dos princípios ágeis.

Esse pensamento me leva a algumas questões, quase que existenciais como:

1. O que precisamos fazer para ser ágeis de verdade no Brasil?
2. Como incentivar mudanças culturais nas empresas e provar que elas trazem resultados melhores do que as abordagens tradicionais?
3. Como destruir o enraizamento de um modelo de mais de anos num país como o Brasil?
4. Como convencer executivos sobre auto-gerenciamento num país onde profissionais ainda compram atestados médicos para não serem descontados por uma falta?

Em minha opinião, ainda temos muitas questões que precisam ser formuladas e respondidas.

Até a próxima, grande abraço !!!

André Nascimento

Ok pessoal, post rápido e direto…

Você não fica chateado quando vê alguém falando de pessoas como simples recursos da empresa?

Não estou aqui para questionar (por enquanto), a disciplina de recursos humanos ou os processos atuais de gerenciamento de pessoas.

Veja bem, o problema não é utilizar o termo recursos humanos, mas sim tratar as pessoas como simples recursos !!!

Estamos cansados de ver gente s que se diz líder, tratar as pessoas como mais um recurso da empresa, como se fosse: computadores, mesas e cadeiras.

A palavra recurso está diretamente ligada a questão de números e indicadores de uma empresa, ou seja: metas, custos, rentabilidade, diferencial competitivo, etc… Neste contexto trata-se a pessoa como simples recurso comparado aos demais de uma cadeia produtiva, como: máquinas, móveis e coisas do gênero. Dessa forma, a pessoa é vista como algo descartável e que pode ser substituída, movida ou excluída da cadeia a qualquer momento, visando sempre as questões financeiras da empresa. Ou seja, o velho e bom Lucro.

Já a palavra pessoa está muito mais ligada ao lado humanista da relação empresa x profissional. Quando falamos em gestão de pessoas estamos dando outro foco ao processo e à relação.

Ora, uma pessoa não é um simples objeto como uma máquina, que pode ser substituída visando um aumento da margem de rentabilidade ou então porque a empresa comprou um modelo melhor.

Uma pessoa é dotada de inteligência, pensamentos e sentimentos; tem vida própria; família e amigos e objetivos pessoais e profissionais que devem ser vistos e considerados pela empresa.

Então não é só uma questão de qual palavra vamos usar, mas sim do sentido que estamos dando a essa relação: Empresa x Profissional.

Quem nunca ouviu uma frase parecida com essa:

“Então pessoal, se o recurso não se adequar ao processo teremos que substituí-lo…”,

ou então:

“Temos que garantir que os recursos atendam aos prazos e expectativas do projeto…”,

ou ainda pior:

“A equipe já está conosco há algum tempo e o salário está alto. É hora de renovar nossos recursos. Precisamos de renovação !!! “

Afinal, recursos podem ser substituídos a qualquer momento, certo? Eles são exatamente iguais a uma mesa ou cadeira… Então, liga ali no 0800 e pede pra entregar mais uns 10 aí pra gente :S

A melhor parte é talvez o fato de que o cara que usa essa terminologia de recurso para se referenciar a uma pessoa, acha que está de fato atualizado com as melhores práticas em gestão de pessoas. Apenas por usar a difícil palavra: Recurso.

E a pior de todas é ver que tem muita empresa por aí se dizendo ágil, mas ainda utilizando o termo recurso para as pessoas, e tratando seus profissionais como meros recursos.

Galerinha: O primeiro item do manifesto ágil é ?

Resources and interactions over processes and tools (???)

Não !!! o correto é:

Individuals and interactions over processes and tools !!!

Temos que entender que as pessoas são importantes peças numa organização. Seja ela uma fábrica de carros, de móveis ou empresa de serviços de TI.

Se você é daqueles gerentes que só enxergam o recurso é porque talvez seja hora de conversar e interagir mais com as pessoas que o cercam…Tente isso e com certeza você verá a grande diferente que uma simples palavra pode fazer

Pare de administrar somente números e você conseguirá gerenciar pessoas, tornando-se um verdadeiro líder !!!

Quem sabe assim você passe a fazer parte de um time campeão…

Grande abraço !!!

André Nascimento