Alow brasil !!!

Este é mais um post básico  e seu objetivo é conceituar um pouco o que é  Scrum. Como muitas pessoas ainda me perguntam coisas como: “O que é esse tal Scrum de que você tanto fala?”, decidi escrever um pouco para aqueles que ainda não conhecem tão bem.

Se você é “agilista” ou tem “domínio” sobre o assunto, talvez não seja um post que vá te agregar muito, ok? Mas, espero que mesmo assim você possa gastar um tempo e, talvez compartilhar conosco a sua opinião.

Bom, então vamos lá:

Scrum é um framework para gerenciamento de projetos de software. Note que Scrum pode ser utilizado por outras áreas e não somente em desenvolvimento de software. Mas, este é um blog sobre tecnologia, certo? Então vamos abordar essa visão.

Falamos framework porque Scrum por si só não é um paradigma de gerenciamento. Ele é baseado num modelo chamado de Modelo Ágil de desenvolvimento de software. Quando falamos de agilidade estamos falando de vários outros pontos que se somam ao Scrum, como: Extreme Programing (XP) , por exemplo.

O nome Scrum vem de uma jogada ou formação do Rugby, onde 8 jogadores de cada time devem se encaixar para formar uma muralha. É muito importante que seja realizado um trabalho de equipe, pois se um dos jogadores na formação falhar, toda a jogada é comprometida.

Jogada Scrum do Rugby

Percebeu onde já entra a primeira grande questão num modelo ágil? O trabalho em equipe é o ponto principal e talvez o mais importante. É crucial que se tenha um olhar de time para entender o que é ser ágil e praticar no dia-a-dia.

O processo Scrum foi estabelecido por Ken Schwaber e Jeff Sutherland e está baseado no manifesto ágil, que defende os seguintes pontos:

Pessoas e suas interações mais importante do que processos e ferramentas;
Software funcionando mais importante do que documentação abrangente;
Colaborar com o cliente mais importante do que negociar contratos;
Responder as mudanças mais importante do que seguir um plano.

A idéia não é de que os itens do lado direito não sejam importantes, mas se eu tiver que escolher entre um deles vou sempre priorizar os do lado esquerdo.

Algumas pessoas de fora, que estão acostumadas a trabalhar em processos tradicionais, muitas vezes apresentam uma visão equivocada a respeito de Scrum. Abaixo temos algumas lendas que você poderá ouvir por aí:

• É um processo que não possui documentação nenhuma;
• Os “caras” gerenciam projetos com um monte de post-its;
• Jogam baralho durante o trabalho;
• É um processo que não possui gerente de projetos, logo, foi uma metodologia criada por programadores que tinham problemas com autoridade;
• Não possui cronograma. COMO GERENCIAR SEM PROJECT ? Clique aqui e saberás como
• Precisa de um time muito especialista pra funcionar direito;
• Não dá para estimar e metrificar, logo é impossível de vender;
• Meu cliente nunca irá aceitar esse negócio de “escopo variável”;
• É feito para atender projetos pequenos e não complexos;

Importante saber que essas “afirmações” acima não passam mesmo de lendas. É preciso somente um pouco mais de conhecimento sobre Scrum ou Agilidade para ver que elas não tem fundamento algum.

Acima de tudo, o Scrum é uma maneira de evidenciar problemas que acontecem no desenvolvimento de projetos de software. Ele não vai resolver seus problemas de engenharia ou de qualidade no software, mas vai oferecer mecanismos para que a equipe vá atrás de soluções para esses problemas.

Os papéis no Scrum

Papéis no Scrum

Product Owner (P.O) é o dono do produto. Ele possui a visão do retorno que o projeto trará para a empresa e para os envolvidos, logo sua missão é cuidar do Product Backlog, planejar releases, priorizar requisitos e passar ao time uma visão clara sobre os objetivos do projeto.

ScrumMaster (S.M) exerce um papel de liderança no processo, mas ele não é um gerente de projetos. O papel de S.M não possui autoridade alguma perante o P.O ou o Time. A responsabilidade do Scrum Master é manter o foco no processo, remover impedimentos da equipe e auxiliar na comunicação entre equipe e P.O.

O Time é o conjunto de pessoas que implementará o projeto. É composto por uma equipe multidisciplinar que tem a característica da auto-gestão. A responsabilidade do Time é manter a auto-gestão de suas atividades, planejar as Sprints, assumir metas com o P.O e dar feedback sobre os impedimentos para o S.M.

Então vejamos:

• O Product Owner gerencia: Escopo, prazo (datas de entregas) e acompanha o ROI (medição e análise);
• O ScrumMaster gerencia: Processo, risco (impedimentos) e planejamento (atingir metas);
• Os Membros do Time gerenciam: Configuração, riscos, requisitos e planejamento.

Neste momento, o leitor deve estar eufórico se perguntando: Onde está o Gerente de Projetos? Pois é, lamento dizer que este papel não existe no Scrum. Pelo menos, não como definido pelo mercado hoje, certo?

Gerente padrão atual

O gerenciamento é dividido entre os membros do Time, ScrumMaster e Product Owner. Este é um ponto muito forte e é requisito para buscar a agilidade: O auto-gerenciamento.

Ao contrário das chamadas metodologias tradicionais, que seguem um modelo definido de desenvolvimento de software baseado em fases e atividades, o Scrum é um processo empírico, ou seja, você não me diz como eu devo fazer, mas somente o que quer como resultado. Depois disso, nós aprendemos durante o processo e evoluímos com este aprendizado, buscando juntos o objetivo a ser alcançado.

Um processo padrão orientado por fases e atividades pode ser parecido com o modelo abaixo:

Modelo tradicional baseado em cascata

Fala a verdade, tá acostumado com ele né? Claro, é o modelo utilizado na grande maioria dos projetos hoje em dia. Vamos falar em outro post exclusivamente dos resultados que este modelo traz ao mercado hoje.

Ao invés de etapas e atividades definidas no início do projeto, o ciclo de vída de um projeto Scrum é composto por iterações de software funcionando. O ciclo de vida é representado pela figura abaixo:

Ciclo de vída Scrum

Os Artefatos:

Bom, o Scrum não oferece listas de templates ou modelos de documentos para que você possa sair usando. No entanto existem alguns artefatos que fazem parte do dia-a-dia, vamos falar dos principais:

Product Backlog é a lista que contém os requisitos do projeto. Aqui temos todas as necessidades e/ou vontades do Product Owner para o projeto. Este é um artefato “vivo”, pois será priorizado e re-priorizado ao longo do projeto de acordo com a visão do P.O. Uma forma ágil de gerenciar e manter seu Product Backlog é por meio das user stories. Utilizando essa abordagem você verá muitos resultados interessantes em seu processo de engenharia. Mas, como já dissemos o Scrum não é um processo de engenharia então você pode utilizar o que quiser pra manter seu Product Backlog (Casos de Uso, Requisitos, Especificação, etc), desde é claro que o P.O reconheça valor nesses documentos e que eles sejam claros para o time.

Impediment List é a lista com os impedimentos do Time, na qual o S.M deverá trabalhar.

Sprint Backlog possui as atividades nas quais o Time vai atuar dentro de uma Sprint. Essas atividades são planejadas pelo Time durante a reunião de planejamento da Sprint. Este também é conhecido por ser representado pela Kanban, provavelmente um dos símbolos mais associados ao Scrum.

Exemplo de Kanban

Product e Sprint Burndown são gráficos que mostram a tendência planejada para atendimento da Sprint / Product Backlog e como o time está evoluindo diariamente no caso da Sprint e a cada Sprint no caso do projeto.

Cerimônias:

Existem também algumas cerimônias no Scrum, que marcam cada etapa no ciclo de vida. As principais:

Sprint Planning Meeting é a reunião de planejamento da Sprint. Nela o Time discutirá com o P.O sobre a meta a ser alcançada naquela Sprint e fará o planejamento de todo o trabalho que será realizado dentro da Sprint.

Daily Meeting é a reunião diária que ocorre com todos os membros do Time, S.M e P.O. Preferencialmente deve ter 15 minutos e os integrantes do Time respondem a perguntas como:

• O que fiz desde a última reunião diária;
• O que planejo fazer até a próxima;
• O que está me impedindo?

Sprint Review é a reunião de prestação de contas na finalização da Sprint. Nela todos os membros do Time apresentarão o resultado atingido na Sprint ao P.O e outros envolvidos.

Sprint Retrospective é a reunião de “lições aprendidas” que ocorre ao final de cada Sprint. Nela os membros do time respondem a perguntas como:

• O que fizemos de bom e temos que continuar fazendo?
• O que temos que mudar ou começar a fazer?
• Quem está no controle?

O Scrum não é um termo novo, ele já vem sendo utilizado para gerenciar projetos desde 1990. Então porque somente agora estamos ouvindo falar dele no mercado corporativo? Na minha opinião, a resposta mais correta é:

Porque agora as empresas estão abrindo seus cases e experiência com métodos ágeis e isso está atraindo a atenção de desenvolvedores, gerentes e executivos. Todos querem conhecer o tal método dos “post-its”.

O que temos que levar em conta é que Scrum ou práticas ágeis em geral não se resumem apenas na utilização de Kanbans ou na realização de reuniões diárias. O mais importante não está em evidência e tem a ver com mudança cultural. É imprescindível que se tenha o foco sempre na mudança cultural e não somente nas práticas. É preciso olhar para os itens do manifesto, entendê-los e pratica-los para conseguir resultados com o processo.

O mais importante é a cultura!

Vemos muitas pessoas por aí hoje em dia dizendo-se especialistas em práticas ágeis ou Scrum mas que nem conhecem os princípios da agilidade, mantendo o foco somente nas práticas superficiais.

É claro que este post é apenas um resumo para tentar “clarear” um pouco o assunto para aqueles que ainda não tiveram contato com Scrum. Se você tem interesse em aprofundar seus conhecimentos sobre práticas ágeis ou Scrum ou sobre seu uso no mercado, entre em contato. Existem muitas pessoas no mercado que podem ajudar.

Abraços

André Nascimento

Dica rápida pessoal

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

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

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

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

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

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

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

Tela Principal do ANTS Profiler for .NET

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

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

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

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

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

Grande abraço.

André Nascimento

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

Alow Brasil !!!

E a pergunta de hoje é: O que está acontecendo com os processos de contratação de software, ou RFP (Request for Proposal)?

Digo isso, pois tenho contato com dezenas de RFPs por mês e estou ficando assustado com o que tenho visto. Os clientes não estão preocupados em conduzir um processo de contratação que os leve a atingir o seu objetivo com o projeto de software, mas sim em se proteger dos riscos e complicações da contratação e não vêem que essa atitude só gera mais riscos e prejudica o seu negócio, acima de tudo.

Antes, um cliente necessitava de um projeto e então abria algumas vagas de “bodyshop” em seu quadro, colocava uns consultores lá e os gerenciava. Com isso, assumia todo o risco pela execução do projeto. Com o tempo, os clientes – principalmente os maiores – viram que a energia gasta neste processo não compensava e que o modelo precisava mudar.

Nisso, veio o que muitos consideraram a solução para o problema: O modelo de contratação como Fábrica de Software. Pessoalmente, eu considero esse um dos maiores erros da indústria moderna de serviços de software, mas isso é assunto para outro post. Com este modelo “mágico”, as consultorias assumiriam todo o risco pelos projetos, pois estavam suportados por modelos de qualidade, processos, métricas, certificações, bla bla bla.

Bom, já vimos que este modelo não funciona, certo? Basta dar uma olhada no gráfico abaixo que representa resumidamente os últimos Chaos Reports , do grupo Standish, sobre projetos de software nos últimos anos.

Chaos Report 2009

Não vamos entrar aqui nos “porquês” desses números, também falamos disso numa outra oportunidade

O fato mais importante aqui é que o cliente procura por um modelo onde ele não tenha tantos riscos para gerenciar e por isso acaba partindo justamente para o modelo que gera esses números (tristes) aí de cima. No final, temos um perfeito ciclo vicioso que tende não cessar nunca.

A partir do momento em que o cliente que quer contratar um serviço de software, passa a tomar algumas dessas ações na RFP, o projeto já está condenado ao fracasso:

1. Fazer a famosa concorrência de preços, sem analisar questões técnicas relevantes (não só se o fornecedor tem CMMi 200, ok?): Quem fizer por menos, leva;
2. Dar um prazo extremamente ridículo para que o fornecedor responda. Afinal, se o departamento de TI com 30 pessoas dele demorou 6 meses para escrever a RFP de 5 páginas, pra quê dar mais de 5 dias para o fornecedor respondê-la, correto?
3. Fixar fatores de produtividade pra todo mundo. O famoso: Tem que fazer tudo em 8 horas por PF (Ponto por função). Ora, ainda nem se conhece a equipe, como vamos saber com qual produtividade vamos trabalhar?
4. E o pior de todos: Esconder informações importantes do fornecedor, induzindo-o ao erro.

Sobre este último item eu gostaria de falar um pouco mais. Chego a ver alguns processos que são baseados em má fé por parte do cliente, buscando esconder informações do fornecedor e induzindo-o a assumir um risco totalmente desnecessário e que no final virará prejuízo, pra TODO MUNDO.

Isso geralmente é feito por áreas internas de TI do cliente que não estão nem um pouco preocupadas com o ROI (Return of Investiment) que aquele projeto trará para a empresa e sim em como livrar a cara deles se alguma coisa der errado no projeto.

Podemos citar alguns dos pontos que identificam claramente quando uma empresa está agindo de má fé no processo de RFP:

1. Vamos contratar apenas a codificação de vocês, logo todo o trabalho de análise e planejamento já foi realizado por nós. Você receberá todos os artefatos funcionais e técnicos e só precisará codificar. Ok, mas quando você pede para ver os artefatos para poder dimensionar o projeto a empresa sabiamente diz: Somente o vencedor da concorrência terá acesso a esses documentos. Ora, qual é o motivo disso? Coloque a cabeça para funcionar…
2. Nossa empresa trabalha com um framework de arquitetura próprio ultramegablasterJAVAplus2011… mas você só conhecerá essa oitava maravilha do mundo quando tiver ganho o contrato (assinado) e não tiver mais como voltar atrás. Aí verá que na verdade, o framework do cliente ainda usa Struts e EJB 2.0 e você não poderá mudar isso;
3. Nós também trabalhamos aqui com um modelo próprio de processo – geralmente algo que ele acha que veio do RUP – com nossos próprios artefatos entregáveis, etc. Mas você também só saberá que são 30 artefatos entregáveis quando já estiver com o contrato assinado

Ok pessoal, poderia dar mais alguns exemplos aqui. Mas acho que esses já são totalmente suficientes e muitos dos que estão lendo este post já viram isso pelo menos uma vez na vida numa RFP, certo? Então fica a pergunta:  Qual é a dos caras ? O que eles ganham com isso ? Será que o cliente ainda não vê que o maior prejudicado nisso no final será ele mesmo, que não receberá um produto bom e com qualidade?

Outros grandes culpados disso são as consultorias e fornecedores de software que visando o maior lucro e portfólio possíveis entram nesses verdadeiros Titanics e não questionam o cliente do porque o processo está sendo conduzido assim. Depois o projeto afunda, entra para as estatísticas do Gartner e Standish e fica todo mundo chorando, querendo saber o que aconteceu errado.

Contratação mal feita !

Isso precisa acabar!!! Enquanto clientes e fornecedores de TI continuarem com esse tipo de relacionamento, a coisa não vai andar.

Então, se você está do lado do cliente e está vendo isso:

1. Tente conduzir um processo de RFP justo e sem armadilhas para o seu fornecedor. Lembre-se, o dinheiro desperdiçado no final está do seu lado também;
2. Procure gerenciar melhor o ciclo de vida da contratação. Não deixe para abrir a concorrência 5 dias antes do seu dead-line de entrega do processo. Você só receberá lixo como propostas e depois não adianta reclamar que o fornecedor não entendeu o que você queria;
3. Exija que o fornecedor sente na mesa para conversar com você e entender de fato o que você quer. De preferência, peça para que ele monte uma apresentação com o que entendeu da solicitação;
4. Dê aos fornecedores toda a documentação e informação que tiver a respeito do projeto. Pra quê esconder informação, se ela só vai melhorar a asservidade que o fornecedor terá ao planejar o seu projeto;
5. Procure fazer a contratação em ciclos menores. Ao invés de contratar um projeto de um ano de uma vez, porque não contratar várias iterações e criar mecanismos de entregas parciais? Você já ouviu falar em SCRUM e contratos ágeis ? Não? Então já está na hora de conhecer

Se você está do outro lado, o do fornecedor. Tente fazer isso:

1. Nunca responda a uma RFP sem ter tido PELO MENOS uma reunião presencial com o cliente. Se ele estiver no Japão, pegue o avião e vá até lá ou faça uma conferência, ao menos;
2. Coloque pessoas capacitadas como responsáveis pelo processo. Se o cliente está pedindo uma solução em Java, não vá colocar o seu analista VB (que é mais baratinho), pra fazer o processo porque você não pode investir em pré-venda no momento. Não participe da concorrência se tiver que fazer isso, pois você está prestando um desserviço para a indústria de software;
3. Não entre em furada. Ora, a sua empresa não é instituição de caridade. Se a RFP apresenta sinais de má fé por parte do cliente, fale isso para ele. Será que o executivo da área usuário sabe o que está sendo feito pelas áreas de compras e de TI. Pois deveria, já que o $$$ sairá do bolso dele depois. Procure saber quem é o cara do $$$ e vá conversar com ele.

Não adianta tentar corrigir somente os processos de software, incrementar a qualidade, tornar o desenvolvedor mais produtivo, se o projeto continua a ser contratado de forma errada!!! Lembre disso: “Um projeto mal contratado já nasce fracassado”.

Abs

André Nascimento

Alow Brasil !!!

Bom, como já disse no primeiro post, essa é a segunda investida em meu blog técnico, certo? A verdade é que eu havia colocado meia dúzia de posts neste blog e nunca dei muita atenção pra ele. Deixei de postar muita coisa interessante que aconteceu comigo em 2008 e 2009.

Sendo assim, o objetivo deste post é fazer um resumo das apresentações que fiz e/ou eventos dos quais participei nos anos de 2008 e 2009. Acho isso importante para conceituar um pouco minha atuação na empresa que estou hoje, ok? É só um resumo mesmo, vou falar apenas sobre os mais relevantes…

Bom, em 2008 fui apresentando ao conceito de metodologias ágeis enquanto estava gerenciando uma equipe de fábrica num grande projeto para o setor de varejo. Fiz o curso de SCRUM com o Rodrigo Yoshima da Aspercom edesde então comecei a estudar a fundo o assunto.

Começando a aplicar neste cliente, vimos que estava dando resultado e que a coisa estava indo pra melhor no projeto. Então, eu e Tuca decidimos fazer uma apresentação sobre agilidade para o vice presidente de serviços da Stefanini.

Dessa apresentação nasceu uma iniciativa na empresa, que embora tímida (até hoje) foi uma grande vitória, pelo histórico de processos e projetos que a empresa já possuia.

Uma semana depois dessa apresentação, fui enviado para falar de SCRUM num evento chamado INFO CIO Meeting, que aconteceu em Punta Del Este no Uruguai. Neste evento estavam reunidos cerca de 80 CIOs das maiores empresas brasileiras.

Alguns pontos importantes deste evento:
– Agilidade ainda era um assunto ainda novo para 90% dos CIOs que estavam lá;
– Fiz a apresentação padrão de SCRUM, ou seja, destacando tudo que há de ruim num modelo waterfall, mesmo assim houve pouquíssima resistência;
– Em sua grande parte, os CIOs ficaram muito interessados no modelo e isso gerou muitas outras oportunidades posteriores de apresentações particulares que fiz depois do evento;
– O feedback dos CIOs ao presidente da Stefanini (que estava no evento) foi muito positivo, o que nos deu uma liberdade maior para tocar as coisas depois.

O grande desafio depois deste evento é o mesmo que temos até hoje: VENDER AGILIDADE na prática é mais difícil do que na teoria, pois envolve uma mudança de paradigma total, não só do CIO mas da empresa toda que está comprando. Mas, isso é assunto pra outro post, certo?

O INFO CIO Meeting em 2008 foi o ponto de partida. Depois disso vieram muitas apresentações sobre Agile e Scrum, depois disso sobre Cloud Computing e SaaS (área pela qual também sou responsável hoje na empresa)…

Em resumo, gostaria de ressaltar o que mais me chamou atenção neste conjunto de eventos e apresentações onde falei sobre agilidade e deixar algumas dicas:

– Falar de agilidade para executivo de alto escalão não é difícil, pois geralmente ele é o cara que sente as dores dos modelos atuais de desenvolvimento de software. Provavelmente ele apoiará o modelo ágil logo no início, mas é bem provável que desacelere bastante quando as coisas começarem a passar pela área operacional;
– Um escritório de projetos (PMO), raramente apoiará a adoção de agilidade numa empresa. Não estou generalizando nada aqui, ok? Mas, pela experiência este definitivamente não é o publico que você deve buscar para falar e convencer sobre agilidade. Então: Não comece por aí !!!
– Quando falar sobre agilidade tente envolver a área usuária do cliente, ou seja: Quem assina o cheque. Se o discurso ficar apenas na área de TI a coisa não vai pra frente. Afinal, geralmente o cara de TI quer empurrar o problema pra você (fornecedor), para que não sobre pra ele quando algo der errado… e vai dar !!!
– Agilidade quanto é implementada numa equipe interna da empresa avança muito rápido e tende a dar resultados mais rápidos também. Falar de agilidade com outsourcing é um desafio bem maior.
– A grande maioria dos “gerentes”, por mais PMP que ele seja, já foi desenvolvedor um dia (pelo menos). Ao falar com esse pessoal tente despertar o lado preocupado com a qualidade do trabalho e com o resultado. Acredite: Esse lado ainda está lá e é muito importante quando falamos de agilidade !!!

Bora lá pessoal… era só um resumo e já tá ficando grande demais !!! Se quiser saber mais sobre esses eventos e palestras email-me !!!

Grande Abraço

Alow !!!

Bom, antes de me apresentar quero dizer que essa é minha segunda tentativa de levar um blog a sério. Felizmente, estou bastante empolgado dessa vez então vai dar certo : ) Tanto que dessa vez já fiz a coisa direito, registrei domínio, etc, etc, etc…

Agora vamos para as apresentações:

Meu nome é André Nascimento, tenho 28 anos e sou casado há 11 anos e tenho 3 filhos. Eu nasci no interior de São Paulo, em Santa Bárbara d’Oeste e estou em São Paulo há mais ou menos 6 anos. Comecei a trabalhar com tecnologia há uns 8 anos, com suporte e redes de computadores… depois migrei para desenvolvimento de software, área com a qual (graças a Deus), trabalho até hoje.

Desde antes de trabalhar com TI eu já estudava por conta e tinha um interesse muito grande por desenvolvimento de software. Gostava de ler alguns livros sobre VB e outras linguagens da época. Meu primeiro contato com computadores foi com um MSX, aquele de cartucho que tinha o programa LOGO (o da tartaruguinha, esse mesmo).

Quando comecei a trabalhar com desenvolvimento, iniciei com Visual Basic naturalmente e passei para PHP, depois tive um contato rápido (muito rápido) com Delphi e depois já passei ao Java. Tive uma base muito boa na faculdade que cursei em Americana, o Unisal . Posso dizer que aprendi realmente a trabalhar com ponteiros, listas e árvores nas aulas que tive lá.

Na época da faculdade me envolvi bastante com desenvolvimento em C para linux, inclusive com a comunidade linux. Fundamos na faculdade uma ong de inclusão digital e software livre e fizemos dezenas de eventos, etc.

Trabalhei com java por uns 3 anos, depois comecei a trabalhar com plataforma microsoft e posso dizer que fiquei nela, por enquanto.

Na área de desenvolvimento, já fui programador nessa plataformas que citei; analista de sistemas e de negócios; aprendi a trabalhar e conhecer bem UML; sou arquiteto de software em plataforma microsoft. Posso dizer que me tornei uma pessoa multidisciplinar e tento preservar isso até hoje.

Atualmente, trabalho como líder executivo (prefiro a palavra líder a gerente) na Stefanini IT Solutions e faço parte de um time de aproximadamente 30 pessoas. Sou responsável pela área de desenvolvimento de software em São Paulo e pelas iniciativas em desenvolvimento Ágil (Agile e Scrum) e também por Cloud Computing (SaaS, IaaS e PaaS) a nível global da empresa.

Na Stefanini, tenho trabalhado bastante para mostrar para a companhia e para os clientes, quais são os benefícios de se trabalhar com processos ágeis de desenvolvimento de software e com o desenvolvimento empírico. Essa é minha atual missão, evangelizar desenvolvedores, gerentes e executivos do mercado de TI. Além disso, tenho perseguido o sonho de formar um time auto-gerenciável, disciplinado e comprometido com os resultados. Acho que estamos no caminho !!! Posso dizer que conto com um time muito bom e sou grato a isso. Alias, se quiser conhecer mais sobre nosso trabalho, pode acessar nosso blog.

Agora, acho legal falar do objetivo do blog né? Vamos lá:

Alguns amigos e membros da comunidade, tem blogs sobre assuntos do momento, novidades, etc… Neste momento, estou pensando em tomar um caminho um pouco diferente. Eu quero passar um pouco de experiências sobre desenvolvimento de software que aprendi nos meus anos de mercado. Algumas coisas serão básicas, outras não, outras serão novidades. Mas com certeza, vou tentar sempre contribuir com o melhor !!!

Alguns assuntos que eu acredito que você poderá ver por aqui:

– Orientação a Objetos;
– Boas práticas de desenvolvimento;
– Dicas de plataforma .NET;
– Agilidade e SCRUM;
– Arquitetura de software;
– SaaS e Cloud;
– Alguns desabafos (normal, não é?).

É isso aí… acho que para um post de apresentação estamos bem. As informações estarão também resumidas no about me… \o/

Grande abraço !!!