Entrevista com Ricardo Almeida na TDC 2008
Publicado por Vinicius Manhães Teles há aproximadamente 1 mês.
Abaixo mais uma entrevista realizada no dia 26 de julho de 2008, na TDC 2008. Desta vez foi com o Ricardo Almeida:
Blog da Improve It 
Palestra de Modelagem Ágil, de Manoel Pimentel, na TDC 2008
Publicado por Vinicius Manhães Teles há 2 meses.
O vídeo abaixo contém a maior parte da palestra sobre Modelagem Ágil, do Manoel Pimentel, realizada no dia 26 de julho de 2008, na TDC 2008.
Debate sobre Metodologias Ágeis na TDC 2008
Publicado por Vinicius Manhães Teles há 2 meses.
O vídeo abaixo contém a maior parte do debate sobre Metodologias Ágeis, realizada no dia 26 de julho de 2008, na TDC 2008.
Palestra de Extreme Programming na TDC 2008
Publicado por Vinicius Manhães Teles há 2 meses.
O vídeo abaixo é da minha apresentação sobre Extreme Programming, realizada no dia 26 de julho de 2008, na TDC 2008.
Link direto para o vídeo.
Download .flv
Download .m4v
Nos últimos anos, ministrei palestras de XP em mais de uma centena de lugares diferentes, sendo a maioria no Brasil e alguns na Europa. O objetivo nunca foi ensinar cada detalhe do XP em apenas uma hora, mas apenas inspirar o público a estudá-lo melhor. Aprendi que é necessário mexer com as emoções para que cada pessoa presente saia da sua zona de conforto e procure conhecer melhor o XP quando voltar para casa. Isso explica a maneira pouquíssimo usual como a apresentação começa. Não fique chateado com o que você verá no início, saiba que este pequeno teatro, é apenas para prender a atenção do público, deixando-o inquieto e desconfortável.
Alguns de vocês já assistiram minha apresentação pessoalmente, mas talvez não tenham conseguido levar um amigo ou o chefe. Bem, agora as coisas ficaram mais fáceis. É só enviar o link deste post para quem você quiser. Mas, cuidado com a mensagem que você estará passando ao fazer isso. Veja o vídeo e você entenderá. :-)
PS: Ainda não dá para ver este vídeo no iPhone. Devido ao tamanho, não pude colocá-lo no YouTube. Minhas tentativas com o Google Video também não deram certo. A qualidade fica bem prejudicada, apesar de eu ter feito inúmeros experimentos, com diversos tipos de encoding. Embora eu não tenha gostado da qualidade, vou fazer o upload para o Google Video, para que haja uma alternativa para vocês verem o vídeo no iPhone (vídeos do Google Video funcionam no cliente YouTube do iPhone).
PS2: Embora eu tenha usado o Vimeo para o vídeo anterior, que também era grande e não podia ser colocado no YouTube e embora o Vimeo tenha a melhor interface de uso, na minha opinião, eu acabei migrando para o Viddler. Este último eu conheci através da palestra do Gary, na SEED3 (que aliás eu filmei e pretendo publicar). Tenho que concordar com ele que o Viddler é uma das melhores opções. Não só porque eu posso colocar vídeos de qualquer tamanho, com ótima qualidade, mas também porque é possível "etiquetar" cada etapa do vídeo. Com isso, você consegue saber rapidamente os assuntos tratados passando o mouse sobre os pontinhos que aparecem na barra de progresso. E, o que é melhor, você pode pular diretamente para os assuntos que mais te interessam.
Documentação Ágil
Publicado por Vinicius Manhães Teles há 2 meses.
Documentação é assunto que as pessoas vivem me perguntando nas palestras sobre XP. Por exemplo, como fica a documentação em um projeto XP, ou em qualquer metodologia ágil?
O vídeo abaixo é uma tentativa de responder esta questão.
Documentação Ágil from Vinicius Teles on Vimeo.
PS: Amigos com iPhone, não fiquem bravos comigo. Eu sei que vocês preferem que o vídeo esteja no YouTube, para que possam ver no iPhone. Mas, dessa vez ainda não deu. Este vídeo ficou um pouco maior do que eu gostaria, de modo que ultrapassa o limite de upload do YouTube. Uma alternativa é usar o Google Video, que permite vídeos maiores, e você também consegue ver através do cliente YouTube do iPhone. Eu tentei fazer upload para o Google Vídeo, mas ainda não ficou legal. Então, vou continuar tentando obter um resultado satisfatório no Google Video, e assim que alcançar, eu coloco o link aqui no blog. Mas, para adiantar, já estou publicando o vídeo no Vimeo.
Entrevista com Rodrigo Yoshima da Aspercom
Publicado por Vinicius Manhães Teles há 2 meses.
Durante a TDC 2008 tive a oportunidade de entrevistar vários agilistas que estavam por lá. A partir de hoje vou colocar essas entrevistas no ar, começando pela do Rodrigo Yoshima, da Aspercom:
Rodrigo, muito obrigado pela entrevista. Desejo muito sucesso nos treinamentos e consultorias em desenvolvimento ágil.
Aqui está o link direto para o vídeo.
Novos rumos em 2008
Publicado por Vinicius Manhães Teles há 10 meses.
Resumo para aqueles que não terão tempo, nem disposição, para ler todo o post: a partir de 2008 a Improve It não irá mais prover serviços de treinamento, mentoring ou qualquer outro tipo de consultoria em desenvolvimento ágil. Continuamos acreditando fortemente nos métodos ágeis de desenvolvimento de software, mas o foco dos nossos negócios passará a ser o desenvolvimento de produtos.
O recado está dado. Provavelmente não é o que a maioria das pessoas espera de nós neste fim-de-ano, então, para quem estiver com tempo, a explicação segue abaixo. Senta que lá vem história.
A Improve It está completando seis anos. Iniciou suas operações no final de 2001 e, como qualquer outra empresa, precisa gerar lucro continuamente para manter-se viva. É possível montar um negócio lucrativo prestando serviços, ou apostando em produtos, ou fazendo as duas coisas. Logo no início, optamos por serviços.
Decidimos por serviços porque não tínhamos porte para investir em produtos no início. Produtos demandam tempo e investimento para serem criados, nutridos e promovidos. Serviço é diferente. Dependendo de seu networking e de suas habilidades, é possível começar a oferecer serviços em um dia e no seguinte já ter algum cliente. E foi exatamente o que aconteceu. Fechamos nosso primeiro trabalho rapidamente. Nossos primeiros clientes eram nossos amigos.
De lá para cá, sempre focamos exclusivamente na prestação de serviços, embora eu sempre tivesse algumas preocupações quanto a isso. A razão é simples: serviço não escala tão bem quanto produto. Em outras palavras, é possível ganhar bastante dinheiro com um produto, sem necessariamente ter uma quantidade enorme de pessoas na empresa. Exemplo óbvio é a 37signals. Eles conseguem crescer em faturamento, sem aumentar significativamente o número de pessoas. Lamentavelmente é difícil ou inviável fazer isso com serviços.
Para aumentar os ganhos oferecendo serviços, quase sempre é necessário ter muita gente. Veja à volta as empresas de TI que mais ganham dinheiro com serviços. Elas são enormes e têm um batalhão de funcionários. Isso me incomoda bastante, porque naturalmente desejo que a empresa cresça em faturamento e, sobretudo, lucro. Mas, não gostaria de ter que elevar significativamente a quantidade de pessoas. Pessoalmente, detesto empresas grandes. A última coisa que desejo para a Improve It é que ela cresça muito no número de pessoas.
O negócio que temos atualmente é saudável e, se decidíssemos continuar na mesma direção, provavelmente continuaria crescendo. Entretanto, estes seis anos me fizeram aprender algumas coisas. Em primeiro lugar, uma empresa precisa buscar negócios sustentáveis. Ou seja, precisa encontrar alguma forma de gerar receita continuamente, mês após mês.
Prestar serviços de consultoria, mentoring e treinamento é bom, mas não é tão sustentável quanto eu gostaria. A verdade é que ao longo do tempo, vivenciamos muitos altos e baixos. Às vezes, tínhamos vários trabalhos em um mês, às vezes passávamos meses sem trabalho algum. Cada vez os trabalhos se tornam mais constantes, mas, ainda assim, há muita volatilidade e imprevisibilidade na capacidade de gerar receitas. Além disso, a base de clientes é sempre pequena, o que significa que bastam um ou dois interromperem seus respectivos serviços, para gerar impactos significativos sobre nossas receitas.
Nestes seis anos, houve dois momentos que foram mais estáveis para nós. O primeiro aconteceu em 2003. Fizemos um projeto XP de pouco mais de um ano com a Vale. Foi um ótimo projeto em todos os aspectos. Além disso, foi lucrativo e nos manteve vivos durante um bom tempo. O segundo momento está ocorrendo agora, quando estamos envolvidos no Projeto Lucidus. Este é um projeto de 18 meses e ainda há metade dele pela frente.
Como se pode observar, em seis anos, apenas um terço do tempo estivemos envolvidos com negócios razoavelmente sustentáveis. Na maior parte do tempo, trabalhamos para sobreviver, como a maioria das pequenas empresas no Brasil.
No último ano e meio, passamos por algumas transformações que me fizeram refletir muito sobre a possibilidade de, finalmente, começar a direcionar os negócios para a área de produtos, ao invés de serviços. Ano passado, comecei a me envolver com o Rails. Quanto mais eu estudava e praticava, mais ficava claro para mim que havia uma oportunidade fantástica diante de nós. O Rails permite fazer muito mais, com muito menos. Além de tudo, é extremamente prazeroso trabalhar com ele. Isso é ótimo, mas não é suficiente.
Até meados do ano passado a Improve It era composta apenas por mim. Embora ela tenha sido fundada por três pessoas, meus sócios decidiram abandonar o negócio em 2004, alguns meses após o término do projeto da Vale. Na época, eles concluíram que dificilmente conseguiríamos fechar novos negócios, sobretudo do porte do que havíamos tido na Vale. Então, ambos decidiram coletar a parte que lhes cabia nos resultados financeiros do projeto e saíram da Improve It com o objetivo de trabalhar no funcionalismo público.
Na época tínhamos alguns funcionários e um escritório no centro do Rio. Não tive outra escolha, senão fechar o escritório, dispensar todas as pessoas e recolher-me ao conforto do meu lar. Fechar a Improve It não era e nunca foi uma opção para mim. Se eu fizesse isso, provavelmente teria que voltar a trabalhar em alguma empresa grande, ou, pior ainda, virar funcionário público em algum lugar. Esta última opção eu considero impensável, por inúmeras razões pessoais. Não fui feito para trabalhar nem em empresas grandes, nem em empresas públicas. Não importa o quanto elas paguem, meu perfil não casa com o delas. Então, o melhor que eu tinha a fazer era manter o negócio vivo, custe o que custasse.
De 2004 em diante, fiz inúmeros trabalhos de treinamento e mentoring em XP. Em 2006, voltei a contratar. Primeiro veio o Tapajós e logo depois o Marcelo. Este último, partiu logo em seguida para uma temporada de um ano nos EUA. Acabou de retornar. De lá para cá, vieram também o Felipe, o Leandro e o Rafael. Bons produtos precisam de pessoas talentosas para criá-los e é exatamente isso o que temos aqui. Somos cinco pessoas experientes, com muito conhecimento no que fazemos e muito talento. Nós não apenas sabemos como fazer. Nós sabemos fazer bem feito. E isso é essencial se quisermos fazer produtos bem sucedidos.
Outro pré-requisito fundamental é ter capital. Produtos demandam investimentos. É preciso colocar dinheiro antecipadamente, para que se possa criar algo que gere mais dinheiro futuramente (se tudo der certo). Quando começamos, não tínhamos muito capital. Mas, seis anos depois, temos o suficiente para investir durante algum tempo. Além disso, temos um projeto em andamento que continuará ajudando a pagar as contas por um bom tempo. Portanto, não há melhor momento para começar a trilhar novos rumos do que agora. Só falta um último detalhe, o mais difícil de todos.
Para que nós pudéssemos finalmente nos dedicar a produtos era preciso vencer a última barreira, aquela que eu carregava comigo o tempo todo. Eu teria que arrumar a coragem para deixar o passado para trás, ou seja, abandonar tudo o que viemos fazendo até aqui. Essa parte é bem mais difícil do que parece.
Estes últimos seis anos foram quase completamente dedicados a serviços na área de desenvolvimento ágil. Começamos muito cedo. Fomos pioneiros no Brasil e nos envolvemos nisso de maneira extraordinária. Meu envolvimento pessoal, em particular, foi notável. Fiz tudo o que eu podia para disseminar as técnicas ágeis no Brasil. Há cinco anos, fundei o XP Rio com mais três colegas. Ao longo dos anos, promovemos dezenas de reuniões presenciais e incontáveis debates na lista. Na UFRJ, passei a dar aulas de XP na graduação desde 2002. Foram seis turmas de XP entre 2002 e 2006. Tudo o que eu fiz na UFRJ até hoje foi voluntário. Nunca ganhei nenhum centavo pelas aulas. Nestes seis anos, fiz mais de cem palestras sobre desenvolvimento ágil no Brasil e no exterior, quase todas de graça. Viajei para lugares distantes, passei horas em ônibus e aviões para poder levar estes conceitos a pessoas que estivessem nas capitais, no interior, seja onde for. Em 2004, lancei meu livro que até hoje é o único escrito no Brasil sobre XP. Em 2002, participei do primeiro XP Brasil e em 2004, patrocinei o segundo XP Brasil. Paguei um quantia significativa que ajudou a trazer para o Brasil pessoas incríveis, como Mary e Tom Poppendieck e Scott Ambler. Em todos estes anos, é difícil contar a quantidade de mensagens que troquei nas listas. Algumas eram verdadeiros artigos, explicando detalhadamente cada aspecto do que fazíamos usando XP e outras técnicas. Aliás, também escrevi vários artigos em revistas, sites e, sobretudo, no próprio site da Improve It. Mais recentemente, estive pessoalmente envolvido na produção de inúmeros podcasts.
Diante de tudo o que eu fiz até hoje, não é muito fácil mudar. Primeiro porque a simples idéia de deixar tudo isso para trás é assustadora. Desenvolvimento ágil é algo que eu conheço profundamente. Poucas pessoas no Brasil têm vivência semelhante nesta área. Por isso, sou bastante procurado. É difícil passar um dia sem que haja uma mensagem de alguém querendo uma palestra, ou um curso, ou uma ajuda. E este é outro ponto que dificulta muito a mudança. Tem sempre alguma coisa para fazer aqui e ali. Alguma coisa que vai render um dinheirinho, mas não é o que vai resolver a nossa vida. Não é o que vai tornar o nosso negócio sustentável. Mas, é sempre atrativo, pois é algo no curto prazo.
Felizmente (ou infelizmente) algumas coisas começaram a acontecer no cenário ágil nacional, que não me deixaram particularmente feliz e que têm servido para me empurrar ainda mais para novos caminhos. Até o início de 2006, desenvolvimento ágil no Brasil era sinônimo de XP. Pouca gente conhecia outros métodos ágeis. Isso felizmente começou a mudar. Começaram a aparecer pessoas interessadas em estudar, divulgar e prover serviços em Scrum, FDD e Lean. Isso foi excelente, exceto por alguns detalhes.
Algumas pessoas passaram a atacar o XP como forma de vender as idéias de outros métodos ágeis. Isso me deixou particularmente chocado, não apenas pelo incômodo de ver algo que funciona imensamente bem ser difamado, mas sobretudo pelo tamanho da mediocridade e da burrice! A comunidade ágil no Brasil ainda é muito pequena diante do comunidade nacional de desenvolvimento de software. Todos nós lutamos por um mesmo ideal: deixar para trás os métodos tradicionais de desenvolvimento e caminhar na direção de algo que acreditamos ser mais humano, mais racional, que simplesmente funciona melhor, por uma fração do tempo e dos custos tradicionais. Nosso "inimigo" é o mundo tradicional. Se ainda somos um grupo pequeno, lutando para mudar o status quo estabelecido, qual o sentido de brigar entre nós mesmos? Qual o sentido de promover uma metodologia ágil através da difamação de uma outra? Enfim, comecei a ver estas coisas acontecendo e isso me entristeceu profundamente. É notável o quanto algumas pessoas conseguem ser pequenas, medíocres. Ao invés da união, a desagregação. Estratégia brilhante!
O passo seguinte também foi muito interessante. No final de 2006, fui procurado pelo Boris Gloger, da Sprint It para estabelecer uma parceria com o objetivo de promover o Scrum no Brasil através dos treinamentos de Certified Scrum Master (CSM). O Boris veio ao Rio, eu o levei para visitar alguns clientes e para fazer uma apresentação sobre Scrum no XP Rio. Foi ótimo contar com uma pessoa nova para reforçar alguns conceitos que já estávamos cansados de repetir por aqui. É sempre bom ter outra pessoa que possa falar dos assuntos, ainda que sejam os mesmos, de uma forma diferente.
Ficamos por aí, pois eu nunca tive interesse em me associar com nada que tivesse a ver com qualquer tipo de certificação na área de software. Ainda mais a CSM, que é notoriamente anti-ética e quase infantil. Para ser um CSM, basta pagar uma boa grana e passar dois dias em uma sala de aula. Não há provas, não há nada. Pagou e esteve presente, o certificado é seu. Parabéns! Eu nunca conheci nenhuma certificação na área de desenvolvimento de software que não fosse nociva, mas esta além de ter esta mesma propriedade, ainda consegue ser uma afronta à inteligência das pessoas.
Note que esta não é uma crítica ao Scrum. Longe disso. Trata-se de uma metodologia excepcional. É tão boa que faz parte do XP. O XP herdou toda a parte de gestão e planejamento do Scrum. Nós usamos isso o tempo todo, há anos e eu posso garantir: funciona muito bem! O que o Scrum tem para oferecer é absolutamente eficaz para desenvolvimento de software e para praticamente qualquer outra área do conhecimento. A minha crítica não é quanto ao Scrum, é quanto à certificação. Já falei muito sobre esta questão em outras oportunidades, então, não vou me alongar. Voltando ao caso do Boris, fiz o possível para ajudá-lo a promover o treinamento de CSM, mas nunca pela certificação, apenas pelo treinamento, que é ótimo. Em todos os casos em que eu ajudei a divulgar, deixei isso muito claro: vá pelo treinamento, mas não pela certificação, que não vale nada.
Um ano se passou e uma coisa interessante começou a acontecer. Scrum virou uma febre. Surgiram inúmeros cursos de Scrum pelo Brasil e isso é ótimo. Muitas empresas passaram a querer ouvir sobre desenvolvimento ágil através do Scrum e isso é ótimo. Gestores passaram a se interessar por desenvolvimento ágil através do Scrum e isto é excepcional. Percebi que, possivelmente, avançamos mais em desenvolvimento ágil no Brasil com Scrum, em um ano, do que em todos os anos anteriores com o XP. Por que será?
Em primeiro lugar, é necessário destacar o mérito comercial daqueles que foram alguns dos principais responsáveis por disseminar o Scrum no Brasil neste ano que termina. Juan Bernabo e Boris Gloger fizeram um excelente trabalho. Conheço o Juan pessoalmente, considero um amigo e admiro bastante. Nós pensamos de maneira muito parecida em vários pontos, exceto, naturalmente, na questão da certificação. Mas, isso não é nenhum problema. O Juan fez um trabalho belíssimo ao longo deste último ano e vem lutando para promover as técnicas ágeis no Brasil. Não é o único, mas passou a ter um papel excepcional ao longo deste último ano. Seu talento comercial também tem sido muito importante.
Na ascensão do Scrum, há também um segundo fator: os termos usados. A palavra Scrum é desconhecida no nosso vocabulário. Não apenas é uma palavra em inglês, como é também uma palavra que pouca gente sabe o que significa, mesmo em inglês. Isso é muito bom. Na verdade, isso é ótimo, pois não cria nenhuma resistência. Aliás, cria até uma certa curiosidade: o que será que siginifica Scrum? Como se isso não fosse suficiente, a metodologia é inteiramente regida por termos em inglês: sprint, scrum master, product backlog, sprint planning meeting etc. No Brasil, isto é perfeito. Quanto mais termos em inglês, melhor em se tratando de venda. Aqui as pessoas sempre acham que o que vem de fora é bom e o que é brasileiro é ruim. Então, nada melhor que termos em inglês e um nome que não gera resistências, ao contrário do Extreme Programming. Este último, não poderia ser pior. Consegue juntar duas coisas que dão arrepio nas pessoas: extremo e programação. Só pode ser ruim! :-) Quem não conhece, não quer conhecer e, para piorar, ainda aproveita para criar os mais diversos tipos de FUDs. Nessa linha, alguns assuntos são verdadeiros clássicos, como programação em par e documentação. Aliás, minha paciência para lidar com estes e outros FUDs já se esgotou.
Por fim, na questão do Scrum, a parte mais importante de todas: a certificação. Do ponto de vista comercial, aqui no Brasil, a certificação é uma jogada de mestre. As pessoas buscam, cada vez mais, todo tipo de selinho que puderem encontrar no mercado para colocar em seus currículos. É uma cultura insana, mas absolutamente pervasiva. Vai de pessoas a empresas. Todos estão atrás de um selo. Neste sentido, o Scrum dá as pessoas aquilo que elas querem. Querem poder ir para um curso de dois dias e poder sair de lá enchendo a boca para dizer: agora eu sou um Certified Scrum Master. Aliás, que expressão linda. Em apenas três palavras, temos um certified e um master. Normalmente, ser certified ou master em qualquer coisa já seria bom demais. Mas, a certificação de Scrum vai além. Por que ser uma coisa ou outra, quando é possível ser as duas: certified E master? Brilhante! É como dizer que uma pessoa não é apenas boa. É boa ao quadrado. É como dizer que você é ultra super powerful Yoda Ninja. Ou seja, o cara. E para ser tudo isso, basta passar dois dias fazendo um curso. A isca perfeita!
Neste ano que passou, vi coisas impressionantes relacionadas à questão da certificação. Talvez o mais bizarro tenha sido ver pessoas que eu conheço, que têm experiência de anos com métodos ágeis, correndo desesperadamente para trasformar-se em Certified Scrum Masters. Os caras pagaram uma nota, não para aprender o que eles já estavam carecas de saber e praticar, mas para, ao final, receber o selinho! Impressionante. É claro que alguma coisa nova eles devem ter aprendido, mas...
Volto a repetir, esta não é uma crítica ao Scrum, que é excepcional. É uma crítica à mediocridade das pessoas, à incrível necessidade que elas têm de um selinho como forma de dizer ao mundo que são "alguma coisa". Comercialmente, Scrum é brilhante justamente porque dá às pessoas exatamente o que elas querem: a oportunidade de pagar caro, para obter mais um selinho e, assim, deixar o currículo com mais uma sigla. Aliás, não só o currículo. Tem gente que conseguiu herdar o pedantismo hercúleo dos PMPs, os quais assinam seus emails com um ", PMP" ao lado de seus nomes. Agora temos também o ", CSM". Certamente isso se inspira nos doutores, que após uma jornada colossal pelo mundo acadêmico, finalmente podem assinar seus nomes com um ", PhD" ao lado. Para um doutor, isso já é pedante, mas para um PMP, cujo mérito não se compara ao de um doutor, isso é ridículo. Para um CSM... bem, deixa para lá.
À medida que este ano termina, algumas coisas ficam claras para mim. Primeiro, é preciso admitir que comercialmente XP é muito ruim. Há uma resistência enorme ao seu uso, baseada nas mais diversas interpretações equivocadas. A maioria das pessoas não sabe o que é, mas pelo nome, é melhor nem saber mesmo. Com certeza não é coisa boa. Segundo, não tem certificação, o que é um pecado capital neste país. Terceiro, demanda das pessoas, das equipes, das empresas, um nível de atitude social e comportamental que parece ser avançado demais para o pensamento pequenino que reina nas empresas brasileiras, com raras exceções.
Fico muito feliz com o avanço do desenvolvimento ágil no Brasil, seja ele através do Scrum, XP, FDD, Lean, ou qualquer outro método ágil. Nada do que comentei acima sobre o Scrum foi um fator determinante na decisão que estamos tomando neste momento. Foram apenas questões que nos ajudaram a refletir e compreender melhor o contexto em que estamos inseridos. Se continuássemos apostando apenas no XP, com certeza continuaríamos tendo espaço no mercado, como temos tido até hoje, só não teríamos um negócio tão sustentável quando gostaríamos.
A razão básica pela qual estamos mudando de rumos é o real desejo de buscar um futuro mais sustentável para a Improve It. Neste sentido, é inevitável pensar sobre o modelo da 37signals. Sem dúvidas esta empresa é, atualmente, nossa principal inspiração. Acreditamos ter as pessoas, o talento e o capital necessário para começar. Precisaremos de muito mais do que isso ao longo do caminho. Mas, por enquanto, precisamos apenas começar e é exatamente o que estamos fazendo agora. Adoraria poder fazer as duas coisas: continuar prestando serviços e, em paralelo, desenvolver produtos. Parece uma ótima idéia. Na prática, entretanto, descobrimos, a duras penas, que não dá. Somos poucos, temos tempo e recursos limitados. É preciso escolher e focar. Então, o foco é atender os clientes que já estão conosco e trabalhar em produtos. Novos clientes de serviços na área de desenvolvimento ágil não serão mais aceitos.
Na área de produtos, nos concentraremos em produtos web, cujo modelo de cobrança seja através de assinatura e que seja destinado a pessoas físicas, profissionais liberais e pequenos negócios. Por inúmeras razões, não queremos ter grandes empresas como clientes. Nosso objetivo é ter muitos clientes pequenos e, assim, pulverizar nossa fonte de receitas.
Já estamos trabalhando em um primeiro produto, mas só comentaremos sobre ele quando já estiver mais próximo ao seu lançamento. Em todo caso, os clientes potenciais não são da área de TI, portanto, vocês provavelmente irão conhecer o produto, mas dificilmente irão usá-lo. Trata-se de outro público-alvo, bastante diferente.
O site da Improve It sofrerá alguns ajustes nas próximas semanas. Como ele é uma referência bastante acessada por quem procura informações sobre desenvolvimento ágil, sobretudo XP, continuará no ar com todo o material que lá se encontra. Porém, faremos algumas mudanças com o objetivo de não mais promover os serviços que oferecemos atualmente e deixar claro que estamos saindo deste segmento.
Muito obrigado a todos os que estiveram envolvidos conosco até aqui. Foi bom estar com vocês, mas estamos arrumando as malas e, a partir de 2008, nossa jornada segue em outra direção. Aos que permanecem nesta estrada, desejamos muito sucesso e um 2008 de grandes realizações. Que os métodos ágeis avancem rapidamente pelo Brasil!
Improvecast 21: entrevista com Demetrius Nunes
Publicado por Vinicius Manhães Teles há 12 meses.
Na última quarta-feira entrevistei Demetrius Nunes para o Improvecast 21. Demetrius atua como Gerente de Projetos no Grupo de Tecnologia em Computação Gráfica da PUC-Rio, o TecGraf. Lá ele utiliza Scrum e práticas de outras metodologias ágeis, tais como Extreme Programming e Lean Software Development. Demetrius também desenvolve usando Ruby on Rails e foi um dos primeiros desenvolvedores Rails do Rio de Janeiro. Ele é autor do act as taggable e será um dos palestrantes do Rio on Rails.
Veja o Improvecast 21.
Improvecast 17: Entrevista com Bruno Siqueira na Série Experiências Ágeis
Publicado por Vinicius Manhães Teles há aproximadamente 1 ano.
Há pouco mais de um mês eu e minha esposa fomos a uma festa onde encontramos com um velho amigo em comum, Bruno Siqueira. Embora o Bruno, minha esposa e eu tenhamos todos formação na área de TI, nós nos conhecemos em outro contexto completamente diferente: a dança de salão. Então, raramente conversamos com o Bruno sobre Informática. Porém, dessa vez acabamos falando um pouco sobre isso e fiquei sabendo que ele tinha saído, há pouco tempo, de uma empresa que implantou ISO, MPS.BR e CMMI. Hoje em dia ele trabalha com Scrum. Uma mudança significativa que, obviamente, merecia ser discutida em um novo Improvecast.
Clavius Tales, da Fortes Informática, falou, no último podcast, sobre a experiência de ter passado pelo MPS.BR e depois abandoná-lo em prol do XP. Dessa vez é o Bruno que conta como foi deixar para traz ISO, MPS.BR e CMMI. Atualmente, ele trabalha com Scrum no Tecgraf, Grupo de Tecnologia em Computação Gráfica, criado em 1987 em parceria com o Cenpes (Centro de Pesquisas da Petrobras).
Nessa entrevista, Bruno afirma que aprendeu bastante com os modelos de qualidade, mas depois de ter a oportunidade de trabalhar com Scrum, acredita que está obtendo resultados iguais ou superiores ao que tinha antes, porém com maior velocidade e muito menos esforço. Se depender dele, modelos de qualidade, tais como o que ele tinha que usar no passado, permanecerão sendo apenas parte do seu passado.
Esses foram alguns dos assuntos tratados no Improvecast 17:
- Você trabalhou durante alguns anos em uma empresa que passou pela implantação da ISO, MPS.BR nível F e CMMI nível 3. Na sua opinião, o que motivou a empresa a buscar essas certificações?
- Quando você foi trabalhar nessa empresa, qual era o tamanho da equipe de desenvolvimento?
- Qual o perfil das pessoas?
- Que tipo de projeto vocês estavam fazendo?
- Que plataforma de desenvolvimento era utilizada?
- Qual foi o primeiro modelo adotado?
- Quanto tempo levou a adoção da ISO?
- Qual era a participação dos desenvolvedores no que se referia à ISO?
- O que é o TABA e para que você o utilizava?
- Qual foi o modelo adotado a seguir?
- Quanto tempo levou a adoção do MPS.BR?
- Qual foi a participação dos desenvolvedores durante o processo de implantação do MPS.BR?
- Em que o MPS.BR afetou a vida de vocês?
- Em que o MPS.BR contribuiu para a melhoria da qualidade dos sistemas.
- Como o MPS.BR afetava a motivação dos desenvolvedores?
- Qual a sua visão sobre a avaliação do MPS.BR? O que você observou?
- Depois do MPS.BR, veio o CMMI, certo?
- Quanto tempo durou a implantação?
- O que você identificou de diferente na implantação do CMMI, em relação ao MPS.BR?
- Qual a sua visão sobre a avaliação do CMMI? O que você observou?
- Quais os benefícios, para a empresa, que você identificou com a implantação desses modelos?
- Quais os benefícios, para você, como desenvolvedor?
- Como eram tratadas as mudanças nesses modelos?
- O avaliador tem que ser um exímio desenvolvedor de software para se tornar um avaliador?
- Modelos como o MPS.BR e o CMMI são complexos. Desenvolvimento de software, pela sua natureza, já é uma atividade bastante complexa. É correto tentar atacar essa complexidade intrínseca com mais complexidade?
- Você enxerga alguma situação em que modelos de maturidade como esses sejam realmente válidos?
- Recentemente, Marcos Pereira, desenvolvedor de software do Recife, nos concedeu um depoimento sobre a implantação do MPS.BR na empresa em que trabalha. Entre outras coisas, ele relatou:
- Dezoito meses gastos para obter o nível G.
- Pouca ou nenhuma participação dos desenvolvedores.
- Dezoito meses com grande preocupação com o processo, muito artefato para alimentar o processo, porém na visão dele, pouca contribuição para desenvolver software melhor.
- Outra coisa que ele observou é que quem define o processo não vive as conseqüências dele.
- Além disso, quem tem que seguir o processo, conhece pouco dele, portanto, sente dificuldades em propor melhorias.
- Ele também relatou que houve alta rotatividade dos desenvolvedores durante a implantação do MPS.BR. Ou seja, o MPS.BR, ao menos na empresa dele, não ajudou a reter pessoas.
- Dificuldade e lentidão para incorporar mudanças.
- Ele se queixou de que o processo não era voltado para tratar do aspecto humano do desenvolvimento. Segundo ele, o objetivo era sempre alimentar o processo, ao invés de alavancar o potencial das pessoas.
- Comitê formado por gerentes e pessoas da área de qualidade. Não havia desenvolvedores envolvidos. Pouquíssima participação dos desenvolvedores ao longo da definição do processo.
- Burocracia impele as pessoas a não mudarem de rumo. Então, como atingir qualidade? Na Toyota, por exemplo, qualidade é obtida através de melhoria contínua, ou seja, milhões de pequenas mudanças sendo feitas continuamente. Mas, que incentivos as pessoas têm para mudar em um ambiente considerado burocrático?
- Você também teve essas percepções trabalhando com esses modelos de qualidade?
- Por que você saiu da empresa que usava os modelos de qualidade?
- Agora que você está no Tecgraf, trabalhando com Scrum, quais as principais diferenças?
- Qual o tamanho das iterações?
- Vocês têm feito as reuniões diárias?
- Vocês têm um quadro com post its?
- Então trata-se de uma equipe autogerenciável, certo?
- Lá vocês estão trabalhando com desenvolvimento orientado a testes?
- Como é o processo de integração contínua?
- Na sua opinião, quais são as principais diferenças entre a filosofia por trás do MPS.BR e a das abordagens ágeis?
- O que mudou com a sua ida para o Tecgraf em termos de satisfação pessoal?
- Qual a sua percepção sobre a qualidade do seu trabalho?
- Você voltaria a trabalhar na empresa anterior?
- Você acha que é necessário ter uma avaliação para se produzir software com qualidade?
Improvecast 14: Entrevista com Guilherme Silveira na Série Experiências Ágeis
Publicado por Vinicius Manhães Teles há aproximadamente 1 ano.
Acaba de ser publicado o Improvecast 14 no qual entrevistei Guilherme Silveira, Sócio da Caelum. Guilherme contou sobre as experiências de utilização do Extreme Programming na Caelum e sobre o Curso de Scrum promovido em parceria com Alexandre Magno.
Esses foram alguns dos assuntos tratados no podcast:
- O que é a Caelum e em que áreas ela atua?
- Como foi seu primeiro contato com o XP?
- Qual foi sua impressão inicial sobre o XP?
- Qual foi o impacto do XP em um primeiro projeto, para uma equipe que já fazia testes unitários e já usava algumas praticas?
- Qual foi o impacto do segundo projeto XP, que começou recentemente?
- O que você notou de diferente entre a teoria e a prática?
- Qual a avaliação que você faz da importância de um coach para a implantação do XP?
- Quais foram os principais benefícios que você identificou no XP, assim que começou a trabalhar com ele?
- Você poderia falar um pouco sobre seu ambiente de desenvolvimento?
- Qual o tamanho da equipe?
- Qual o tamanho das iterações?
- Que práticas do XP estão sendo usadas?
- Qual você considera mais fácil?
- Qual é a mais difícil e por que?
- Como vocês fazem a estimativa das histórias?
- Como vocês configuraram o ambiente visual e informativo de vocês?
- Quais os gráficos que vocês utilizam para acompanhamento do projeto?
- Como utilizam a prática de desenvolvimento orientado a testes?
- Como os eventuais bugs são tratados?
- Como vocês têm utilizado a programação em par?
- Como é feito o processo de integração contínua?
- Como vocês utilizam retrospectivas durante o desenvolvimento?
- Quais foram as principais dificuldades que vocês enfrentaram até o momento?
- Como está o relacionamento dos membros da equipe, com o uso do XP?
- Como está o relacionamento com os clientes do projeto?
- Por favor, fale um pouco sobre o Curso de Scrum oferecido pela Caelum.
- Quais são seus planos para o futuro em relação às metodologias ágeis?
