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…

Após um pequeno tempo sem postar nada por aqui estou retomando aos poucos o tempo para blogar \o/ Acabei dando um tempo para pensar em alguns assuntos e organiza-los em minha cabeça. Enquanto isso é claro: Muito trabalho

Faz um tempo que penso em escrever algumas coisas sobre produtividade e ambiente de trabalho e vou começar com um assunto bem legal e controverso: Faz sentido bloquear internet em uma empresa ou área de desenvolvimento de software?

É claro que já vivenciei inúmeras situações ridículas envolvendo esse assunto, mas o que me levou a escrever sobre isso foi um fato que aconteceu hoje e me deixou refletindo por alguns bons minutos. Vou resumi-lo pra vocês:

Um desenvolvedor do meu time, que está no cliente para realizar algumas melhorias num sistema que foi desenvolvido pelo cliente me chamou no msn (ele estava no celular) com uma dúvida sobre Linq. Ele queria saber algo sobre uma clausula de filtro em particular. Eu dei uma dica de como ele poderia usar o Linq pra resolver, mas não me lembrava da sintaxe exata. Então, expliquei pra ele o conceito (eu quase nunca passo somente uma linha de código sem primeiro discutir o porque e o conceito envolvido) e disse o caminho pra resolver. Sobre a sintaxe eu falei pra ele procurar no google e aplicar… fácil certo?

Nem tanto pois a empresa em que ele estava bloqueia totalmente o acesso à internet. Nem o google é aberto pra pesquisa. E ele estava dentro de uma área de desenvolvimento de software e TI de uma gigante na área de comunicação e telefonia.

O pior é que tenho visto cada vez mais empresas do segmento de TI e desenvolvimento de software partindo para ações como essa. Podemos ver alguns níveis de bloqueio nessas empresas:

1. Redes sociais como Orkut e Facebook;
2. Sites de vídeos como youtube e cia;
3. Twitter;
4. Instant messaging como msn, G-Talk, Skype, etc;
5. Blogs e conteúdo de notícias;
6. Internet banking e emails pessoais;
7. Finalmente, bloqueio total de qualquer site inclusive google.

Pessoalmente, posso dizer que consigo “engolir” justificativas para os dois primeiros da lista. O primeiro porque eu não gosto e não vejo a mínima razão para utiliza-los no trabalho mesmo. O segundo porque em empresas onde a internet é compartilhada com muita gente (caso de onde trabalho), mesmo que a banda seja boa, streaming de video realmente quebra as pernas.

Agora, para todos os demais itens da lista eu só consigo visualizar uma coisa: Retrocesso Empresarial!!!

É interessante pensarmos em porque uma empresa chega ao extremo de bloquear todo acesso de internet de um time que desenvolve software ou trabalha com TI em geral. O que vemos pelo mercado é mais ou menos isso:

1. Internet diminui a produtividade e o foco do trabalho;
2. O profissional deve utilizar seu tempo livre para estudar e não o da empresa;
3. Não é preciso pesquisar sobre desenvolvimento na internet. Profissional bom é o que “domina” a sintaxe da linguagem;
4. Problemas de segurança, como por exemplo enviar um arquivo confidencial por email.

Vamos dar uma boa olhada em cada uma delas:

Internet diminui a produtividade e o foco do trabalho

Séra? Depende muito do ponto de vista do qual se está avaliando. Como você enxerga produtividade na sua empresa quando falamos em desenvolvimento de software? Ainda é baseada na quantidade de horas que um profissional “lança” numa atividade ou numa timesheet? Se for isso, então talvez você tenha razão e podemos parar por aqui.

A verdade é que produtividade em desenvolvimento de software não é medida pela quantidade de horas que um profissional passa sentado na frente do computador ou em quantas horas ele lança numa atividade no seu sistema de controle. Esse controle é baseado na idéia de que desenvolver software é a mesma coisa de desenvolver produtos industriais – ver post sobre o termo fábrica de software – e isso não procede. Sobre isso, vou dedicar um post para falarmos, certo?

Se eu partir da premissa de que temos que trabalhar com profissionais adultos e responsáveis que saibam gerenciar seu próprio tempo e atividades e que temos que confiar nesses profissionais, vamos ver que é ridículo bloquear internet pensando em produtividade.

É claro que existem aqueles “profissionais” que aproveitam da empresa mais liberal e passa o dia todo vendo notícias de esporte, viagens, batendo papo, etc. Acontece que não dá pra punir 95% que faz certo, por causa de 5% que faz errado. O cara que faz isso não produz, se ele não produz é fácil aparecer. Se isso acontecer o que fazemos? Manda o cara embora e contrata outro adulto no lugar.

O profissional deve utilizar seu tempo livre para estudar e não o da empresa;

Essa é outra idéia que faz com que o índice de turnover de uma empresa bata picos do tamanho do Everest. Ora, quem disse que a empresa não deve incentivar o profissional a estudar em seu tempo de trabalho? Poxa, vamos ser sinceros: Se o cara quer enrolar ele faz isso com ou sem internet. Basta dar um elástico e/ou um clips pra ele e pronto. Não é melhor que o cidadão invista seu tempo ocioso em estudo e aprendizado?

E se não for em estudo também, qual o problema de ficar um tempo sem fazer nada? Existem estudos hoje em dia que mostram que profissionais que trabalham com atividades intelectuais precisam de um “break” para voltar a focar numa atividade. Quantas vezes já não passamos horas parados feito estátuas olhando para um código sem encontrar solução, alguém insistiu para tomar um café e depois de 20 minutos você voltou dando risadas altas pelas piadas contadas no café, sentou-se na frente da máquina e resolveu o problema na mesma hora?

Não é preciso pesquisar sobre desenvolvimento na internet. Profissional bom é o que “domina” a sintaxe da linguagem;

Nem vou me alongar muito neste tópico. Se você ainda acredita nesse tipo de coisa acho que já pode parar de ler o artigo (e o blog). Mais um pensamento totalmente baseado na idéia de que desenvolver software não é uma atividade intelectual e sim repetitiva e automatizada. #FAIL

Problemas de segurança, como por exemplo enviar um arquivo confidencial por email.

Se você trabalha em uma mega empresa do setor financeiro ou coisa do gênero, talvez pode ser possível usar essa desculpa. No geral, justificar bloqueio de internet com desculpas de segurança de informações é uma grande falácia. Tem empresa que bloqueia tanto a internet, messaging, etc, mas dá senha de banco de dados de produção pra consultor fazer deploy de madrugada. Segurança ? I don’t think so…

Hoje, algumas empresas partem para a estratégia de bloquear tudo e fazer com que cada um que precise acessar um determinado endereço (blog por exemplo), entre em contato com a área de infra ou segurança de informação e defenda o porque precisa daquele acesso. Depois de “10″ dias, “30″ assinaturas  e um caminhão de tempo perdido, o acesso é liberado e o profissional já não precisa mais daquele acesso. Lembra do primeiro item da lista: Produtividade? O que será que é mais produtivo não é mesmo?

E quem disse que é alguém da infra ou da segurança que é a melhor pessoa para ter esse controle? Acabo pensando que isso é justamente uma questão de controle mesmo. Do tipo totalmente territorial e injustificado. Se acontece na sua empresa, não se assuste

Resumindo:

Somos trabalhadores do conhecimento. Trabalhamos com uma atividade intelectual e não industrial e repetitiva. Somos totalmente forjados com conhecimento e informação. Bloquear acesso à internet neste cenário é um completo absurdo.

A empresa que ainda possui esse tipo de postura é completamente atrasada e corre o risco de ser varrida do mapa.

E você, o que pensa a respeito?

Grande abraço.

André Nascimento

Alow Brasil !!!

Gostaria de lançar uma campanha no mercado de desenvolvimento de software, é a campanha: Programa Gerente !

Trata-se de uma campanha muito simples, mas difícil de aplicar, então vamos precisar de muita colaboração de todos para que ela aconteça.

Quase todo dia eu vejo um gerente reclamando de que sente muita falta da “época em que programava”, porque naquela época ele não tinha que fazer tanto trabalho inútil e que tinha uma visão muito melhor do resultado daquilo que ele construia.

A situação é a seguinte: Quem está numa posição gerencial acaba passando horas (as vezes o dia todo) trabalhando feito louco, mas se alguém perguntar o que ele fez nesse tempo, muitas vezes a resposta será: NADA !!! E o pior é que verdade, as atividades de gestão são complicadas e acabam não dando visão alguma de que algo realmente ficou pronto.

Se você é um gestor, sabe exatamente do que eu estou falando. O problema é isso acaba desmotivando profissionais e causando altos níveis de stress. Outro problema óbvio é que quanto mais um líder se distancia da realidade técnica no dia-a-dia, mais ele perde. Pessoalmente, eu nunca acreditei na história de que quanto mais se cresce na carreira, menos técnico você fica. Acredito que um profissional que siga para uma posição executiva tenha que generalizar mais a sua visão, mas isso não significa que ele tenha obrigatoriamente que jogar fora seu lado técnico.

Convivo com alguns executivos hoje que acabam sendo cegos o bastante para não olhar com bons olhos outros executivos que são técnicos e especialistas. Para esses, o lado técnico precisa necessariamente morrer para que o lado “administrador” domine. Que piada !!! Os melhores executivos com quem já tive a honra de trabalhar são técnicos e a mesma coisa serve para gerentes, líderes, coordenadores, etc.

Voltando à campanha, a idéia então é muito simples: Vamos fazer com que o gerentes, coordenadores, líderes e cia participem de algum projeto – por menor que seja – programando alguma coisa. Pode ser uma tela, uma rotina, um componente, não importa. O importante é que o “chefe” se envolva na programação e na construção do produto.

Vamos iniciar com isso aqui na Stefanini, ok? Então não dá pra dizer que isso não é aplicável numa grande empresa Vamos motivar todos os gerentes de projeto e líderes a dedicar um tempo para participar de um projeto junto com o time de desenvolvimento. A idéia também é que nessa atividade ele seja apenas mais um e não vista o chapeu de gerente.

Se você é um gestor ou coisa parecida, junte-se a nós nessa campanha… recupere aquele conhecimento técnico que você perdeu quando foi para o lado gerencial e que te fazia tão feliz. Você verá como suas atividades de gestão e liderança ficarão muito mais divertidas e darão um retorno muito maior para você, equipe e para sua empresa.

Aos poucos vou atualizar o blog com os resultados dessa experiência, ok?

Grande abraço e nos desejem sorte \o/

André Nascimento

Alow Brasil !!!

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

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

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

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

Funcionava mais ou menos assim:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Grande abraço

André Nascimento

Alow Brasil !!!

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

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

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

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

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

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

O pensamento foi simples:

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

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

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

Linha de montagem industrial

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

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

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

Processo distribuído

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

Modelo tradicional baseado em cascata

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

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

Chaos Report 2009

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

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

Uso de funcionalidades em sistemas comerciais americanos

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

Gera e alimenta a segregação das equipes

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

É necessariamente baseado em documentação

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

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

A base de nosso atual processo de software

Promove uma pseudo-previsibilidade

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

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

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

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

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

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

Meros codificadores braçais

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

Possui foco em processos e não em pessoas

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

Não permite colaboração

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

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

E no final…

Relacionamento cliente x fornecedor

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

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

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

Grande abraço

André Nascimento

Fala Brasil !!!

Nos dias 12 e 13 de março realizamos  com o time do Software Delivery Center, aqui na Stefanini em São Paulo o workshop de desenvolvimento ágil com Scrum. Alguns podem estar se perguntando: “Mas você não disse que já trabalham com Scrum aí na Stefanini? Como assim?”.

Pois é, nós trabalhamos sim \o/ Mas, felizmente nos ultimos meses tivemos um crescimento bastante positivo e várias pessoas foram agregadas ao time do Software Delivery Center. Algumas delas, vieram do mercado já conhecendo alguma coisa sobre desenvolvimento ágil, outras nunca tinham sequer ouvido falar.

Tenho notado com o passar do tempo que até mesmo as pessoas que dizem conhecer bem sobre agilidade, de fato, conhecem pouco. Isso claro é porque poucas pessoas entendem e conseguem colocar em prática questões culturais de agilidade. Há aqueles que tentam, mas acabam esbarrando em chefes/gerentes/diretores que não querem nem saber. O ponto positivo nessa equipe é que o “chefe” já está bem convencido, eheheh.

Como tivemos esse aumento significativo em pouco tempo (cerca de 25 pessoas nos ultimos 4 meses), decidimos que já era hora de realizar um workshop decente com todo mundo. Eu estava começando a ficar preocupado com um pessoal mais novo que olhava para os Kanbans e não entendiam nada, ou pior, achava que Scrum se resume aos Kanbans :S

Falando rapidamente sobre o workshop, tivemos todos os membros da equipe presentes nos dois dias (ok, tivemos 1 ou 2 ausências). O formato foi o mesmo que utilizamos em clientes da Stefanini, claro, focado no dia-a-dia da equipe. Como estou com o “chapeu” de gestor desse povo, acredito que foi mais fácil realizar o workshop pois estou com eles todos os dias e sei bastante coisa do que se passa com o time.

O fato de trabalharmos juntos não diminiu as discussões, opiniões e pontos de vista do pessoal. Isso é o que eu considero um dos maiores ganhos que temos vivido com agilidade por aqui: Todo mundo tem voz e a opinião de todo mundo conta!

Tivemos mais uma vez a dinâmica da fábrica de aviões (fantástica). Realmente é um dos pontos fortes do workshop!

Vou compartilhar algumas fotos do workshop com vocês. Em breve vou organizar meu Flickr, prometo

Equipe do Software Delivery Center da Stefanini

Pessoal na sala do workshop

Dominando a "padoca" da esquina na hora do almoço.

Algo parecido com um "gerente". I don't think so!

Ok! Nem só de trabalho vive o homem. Happy Hour após o workshop!

Mais uma do Happy!

O principal ganho que tivemos com este workshop foi ver que o pessoal entendeu o que realmente é importante em trabalhar com agilidade e scrum. Claro, nem todos ainda acordaram, ainda não temos o resultado que queremos, mas sinto que estamos no caminho. O importante é que tentamos colocar em prática os princípios da agilidade em nosso dia-a-dia e isso está refletindo positivamente em nossos projetos.

Espero que daqui há 1 ou 2 meses tenhamos que parar novamente todo mundo para um novo workshop sobre agilidade.

Até lá! 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

Alow brasil !!!

O título desse post já diz muita coisa, certo? Vamos falar um pouquinho sobre certificações.

Em primeiro lugar, quero que você leve em conta que eu nada tenho contra certificações. Mas, quero levantar algumas  questões que julgo importantes.

Então, vamos lá.

Todos sabemos que nosso mercado chegou a um estágio de incrível prostituição e um dos grandes responsáveis por isso são as grandes consultorias de serviços. Elas incentivaram as piores práticas de gestão de pessoas, que hoje infelizmente são seguidas também pelas médias e pequenas empresas de serviços. Todo mundo é recurso, não é?

Já convivemos com o termo “certificação” há algum tempo em nossa área. Não vou resgatar a história lá atrás, tudo bem? Mas, se levarmos em conta, de uns anos pra cá tivemos o que podemos chamar de um “boom” nos modelos de certificação e no número de profissionais certificados.

Você já deve ter visto muitas vezes anúncios de emprego exigindo um profissional certificado, ou mesmo quando foi pedir uma promoção que precisava de mais certificações para demonstrar seu domínio sobre o assunto.

O fato é que o mercado de consultorias valoriza e muito um profissional que possui certificações e cada vez mais exigem isso.

No entanto, existem dois tipos de profissionais que se certificam. Vamos olhar cada um deles:

O cara que domina um assunto, tem experiência e se certifica para homologar este conhecimento – Este é o cara que faz justiça as suas certificações. Ele possui experiência prática em todos os níveis abordados pela sua certificação e não é somente um vendedor de tecnologia ou produto. Se chamado para resolver um problema demonstrará que realmente é um especialista no assunto e mesmo que não domine todas as técnicas possíveis para resolver um problema, usará seu perfil investigativo para aprender novas formas e no fim vai dar um jeito.

O cara que estudou o assunto a fundo, leu muito material e foi fazer a prova – Este profissional participa de fóruns de discussão, faz diversas apresentações nos mais importantes eventos da comunidade e adora exibir seus títulos a qualquer momento (quem não adora assinar Fulano de Tal, PMP por exemplo?), e quando chamado para resolver um problema, já carrega seu fantástico notebook com kilos de material com propagandas. O problema é que esse cara geralmente não tem experiência prática com o assunto. Ele gosta muito de ler, mas não consegue resolver um problema simples. Além do que, passa tanto tempo se dedicando as apresentações que faz que acaba não tendo tempo para participar da entrega de um projeto de verdade.

Infelizmente, o segundo tipo de profissional está dominando o mercado atual. Não são raros os casos em que conhecemos profissionais com “baldes” de certificações que não justificam nada. A qualidade de seus trabalhos é completamente medíocre.

Mais uma vez vemos que o próprio mercado é um dos grandes culpados disso. Ora, como avaliamos os profissionais hoje? Isso é assunto para mais um post, mas para resumir: Não temos gente qualificada para selecionar os profissionais hoje em dia e a certificação ajuda muito neste trabalho.

Vamos pegar como exemplo uma das certificações que está na moda: A tal de ScrumMaster. Este é um exemplo perfeito de certificação que não serve pra nada. Desculpe-me os CSTs, ok?

Outro dia, realizando uma apresentação numa empresa ouvi o seguinte comentário:

“Ah, conheço um cara muito especialista em Scrum, ele é um Scrum Master certificado”.

Para se tornar ScrumMaster até há pouco tempo era só participar de um treinamento de 16 horas com um CST e receber o certificado. Que especialidade há nisso? Pelo amor do bom Deus!  Este tipo de certificação é uma das coisas que autorizam pessoas totalmente desqualificadas a falar de um assunto para o mercado e se mostrarem como especialistas de algo que pouco entendem, fora aquilo que leram num livro.

Outro exemplo que podemos ver na comunidade de desenvolvimento de software: Quantas vezes já precisamos aqui na empresa de ajuda de especialistas e corremos atrás de profissionais certificados, com títulos, etc. Nenhuma vez consegui trazer aqui um “especialista” que conhecesse muito mais do que a minha própria equipe.

Com tudo isso, gostaria que você pensasse um pouco sobre a importância de ser realmente certificado em algo. É um titulo importante. De fato, os grandes profissionais com quem trabalhei e que eram realmente especialistas, não tinham nenhuma certificação.

Para finalizar, gostaria de compartilhar algo sobre o processo de seleção que fazemos aqui na empresa. Nós não nos importamos nem um pouco se o profissional tem ou não certificações. Peço ao RH da empresa que não coloque nada relacionado a certificações ou mesmo a formação acadêmica quando mandamos uma vaga para o mercado.

Agora, se o candidato coloca em seu CV aquela lista gigante de certificações, com certeza ele terá um trabalho bem grande para justificar seu conhecimento para o pessoal que vai entrevistá-lo. Exemplos:

• Se o cara diz que tem meia dúzia de certificações em desenvolvimento da microsoft ele tem que saber descrever como é que o framework .NET funciona;
• Se o cara diz que tem certificação Oracle, ele tem que saber dizer quais são os 5 passos que a engine do banco faz quando vai processar uma procedure;
• Se o cara diz dominar todos os design patterns do GoF e etc, ele terá que citar quais deles já utilizou num projeto e que problema foi resolvido com eles. Geralmente não aceitamos nada de MVC ou DTO, ok?

E então: Qual será a sua próxima certificação?

Links interessantes:

Cuidado com os especialistas

Abs

André Nascimento

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

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