gerencia « Fragmental

Archive for the ‘gerencia’ Category

Minhas Propostas para a Agile Brazil 2010

Saturday, February 27th, 2010

Acabo de submeter algumas atividades para o Agile Brazil 2010, evento que se realizará em Junho em Porto Alegre. Pelo que entendi, as propostas serão avaliadas pelo comitê organizador do evento.

As propostas estão disponíveis no site e o público pode fazer comentários. Minhas submissões:

Líder Técnico - O Ex-Arquiteto virou Faz-Tudo!

Ele era o centro das atenções. Nenhuma classe era criada sem a sua aprovação. Nenhuma biblioteca era introduzida sem que ele homologasse. Nada entrava ou saía sem a sua verificação. Seus diagramas formavam o livro sagrado do sistema, se o sistema não reflete o diagrama então os desenvolvedores devem ser punidos, obviamente eles não entender seu Grande Plano para Tudo™.

E daí veio este tal de agile. Não apenas introduziu práticas de qualidade duvidosa (duas pessoas, um computador? Sério?) mas também quer eliminar seu papel de visionário. Como um time poderia funcionar sem a visão inpiradora? Como um mero desenvolvedor pode decidir o que é melhor para um projeto onde são investidos milhões?

Pior ainda, o que o líder faz agora que não existem mais diagramas para desenhar?

Arrumando a Casa Após a Festa: Saindo do Pseudo-Agile

Tudo parecia muito simples. Os cartões vão na parede, os times se auto-gerenciam, o tal do Product Owner escreve nos cartões, o time faz retrospectiva… Tantos casos de sucesso por aí, tantos sorrisos e tapinhas nas costas…

Por que está dando tão errado aqui? Por que está fazendo da minha vida um inferno? Por que meu time não está aumentou a produtividade? Por que meus produtos continuam sendo uma porcaria? Por que parece que ninguém sabe o que está acontecendo?

Este é o saco de dúvidas que tenho encontrado por aí.

A maioria vai achar que basta seguirmos os 12 passos do programa e, eventualmente, as coisas vão entrar nos eixos. A maioria acha que basta demitir os gerentes de projeto e colocar coisas coloridas na parede. A maioria acha que basta escrever testes e seu código vai ter qualidade. A maioria acha que basta quebrar casos de uso em histórias e você terá melhor comunicação.

A maioria vai falhar miseravelmente.

Nos últimos anos tenho gasto uma boa parte do meu tempo tentando fazer clientes entender que não importa a cor do cartão na parede, não importa a sua plataforma de desenvolvimento, não importa se você usa cruise ou hudson, não importa se retrospectivas são quinzenais ou mensais… a única coisa que importa nesses tais métodos ágeis é termos ciclos de feedback curto.

Nesta sessão vamos conversar sobre alguns cenários, todos baseados em projetos reais, e no que pode ser feito para tirar o pseudo do seu agile.

E, além das duas palestras, o Rodrigo Yoshima me convidou para ajudá-lo no seu workshop de modelagem:

Reconheça! Você não sabe modelar! Iniciando Projetos Ágeis

Neste workshop prático vamos simular o planejamento inicial de um projeto ágil utilizando as mais variadas técnicas de modelagem como Domain-Driven Design, CRC Cards, User Stories, Paper Prototyping e Brainstorming.

Ajude o cliente a compreender melhor o problema, melhorando seu planejamento e auxiliando as suas estimativas. Um bom modelo ou protótipo serve como uma simplificação de algo complexo, uma abstração útil para o desenvolvimento do projeto. Em projetos ágeis a modelagem está presente, porém, ao invés de uma modelagem solitária numa ferramenta UML, equipes ágeis inovam em colaboração, usando artefatos simples numa dinâmica divertida.

Posted in brasil, comunidade, engenharia, eventos, fragmental, gerencia, metodologias, palestras, testes | 1 Comment »

Domain-Driven Bolovo, Passando Conhecimento e etc.

Monday, January 18th, 2010

Segue uma seqüência ~~aleatória~~ quase coesa de pensamentos que me vieram a cabeça enquanto esperava meu vôo para Salvador.

Paulo Silveira surgiu com o termo BOLOVO, usado para indicar uma arquitetura baseada em VOs e BOs, enquanto preparávamos os slides para nossa apresentação em conjunto no JustJava em 2007.

Arquitetura Java em 2007 (Java Architecture in 2007)

View more documents from Phillip Calçado.

O artigo original sobre BOs e VOs fala basicamente sobre como a arquitetura proposta por EJBs na especificação antiga (2.x) prejudicou o entendimento da comunidade em geral sobre como criar a aquitetura de uma aplicação.

Três anos se passaram mas o artigo ainda recebe um numero de acessos razoável –e eu vivo prometendo que vou atualizá-lo. A última vez que tive que escrever um EJB 2.x foi em 2007, desde então –talvez por sorte- nunca mais entrei em um projeto que usasse estas aberrações. Muitos programadores de hoje em dia começaram suas carreiras na época que EJB já estava morrendo e nunca tiveram o desprazer de lidar com esta porcaria. É de se esperar que estas pessoas, tendo estado sempre cercado por IoC, DDD e técnicas bem razoáveis, iria olhar para um artigo como o que escrevi da mesma forma que eu olho para um livro de linguagem de máquina para Apple II –interessante no contexto histórico mas quase que apenas uma curiosidade.

Vira e mexe, entretanto, eu sou lembrado do porque o artigo ainda recebe tantas visitas todo dia. Os programadores mais novos podem não ter sido influenciados pelos problemas dos EJBs mas ele ainda foram ensinados à programar de uma só maneira: código procedural.

Quando estava preparando a primeira iteração do workshop de Domain-Driven Design que faço em parceria com a Caelum eu escrevi um texto para explicitar meu raciocínio sobre como Domain-Driven Design se difere de Orientação a Objetos. No workshop em si eu dediquei boa parte da manhã falando sobre este tema.

E por quê? Porque da mesma maneira que as pessoas utilizavam os conceitos de EJB completamente fora de contexto o mesmo está acontecendo com Domain-Driven Design. É bem comum, em uma conferencia ou algo do tipo, alguém vir conversar comigo sobre como a empresa dele está eliminando todos os BOs e VOs. No meio da conversa a pessoa começa a me explicar a arquitetura e eu vejo que praticamente o que eles fizeram foi renomear UsuarioBO para UsuarioService e UsuarioVO para Usuario. Repositórios, então… estes são tão mal utilizados que deram origem à vários textos aqui:

Independente do uso de DDD e seus padrões ou não eu realmente esperaria que, em 2010, as pessoas já houvessem entendido como objetos deveriam ser criados. A quantidade de material disponível gratuitamente na Internet e em múltiplos idiomas é ridiculamente grande.

Me levou muito tempo para entender que não importa a quantidade de material disponível. Em minha experiência, a maneira mais eficiente de introduzir estes conceitos é programação em par. Quando um cliente me chama para introduzir estes conceitos em seu time eu sempre tenho que tentar explicar porque isso não pode ser apenas um treinamento. Ë difícil de entender porque eu posso treinar alguém em algo complexo como uma linguagem de programação mas não em uma técnica com mais de 40 anos que exige como pré-requisito nada mais que conceitos lógicos básicos. Eu, pessoalmente, não faço a menor idéia do porque as coisas são assim, só sei que o são.

Normalmente eu começo o trabalho com uma apresentação rápida, apenas para tentar fazer as pessoas entenderem o que diabos eu vou tentar fazer. Um exemplo de uma destas apresentações:

Expressive Design (in 20 minutes)

View more documents from Phillip Calçado.

E logo depois começamos a parear. O ideal é termos pelo menos 1 coach para cada dois pares, mas nem sempre este número é viável. Quando a quantidade de pessoas exceed muito a quantidade de coachs a melhor solução parece ser pareamento promíscuo, mudando os pares em intervalos bem curtos de tempo.

Nestes últimos anos eu tive diversas oportunidades de reencontrar clientes e parceiros depois da conclusão do projeto ou treinamento. Na minha experiência os times que tiveram apenas treinamento retêm apenas uma ou outra coisa do todo, eles entendem o todo mas não conseguem aplicar na prática –e aí mora o perigo do Domain-Driven BOLOVO. Os times onde utilizei coaching como meio de transmissão de conhecimento tendem a ser o contrario: eles usam as técnicas no dia-a-dia mas não entendem o todo. Ao não entender o todo eles não conseguem evoluir alem do que o que lhes foi passado durante aquele período.

É de se esperar que o primeiro grupo seja mais valioso para um empregador. Na prática, entretanto, não parece ser o caso. Um treinamento, um livro, etc. podem curar a deficiência do segundo grupo e tendem a ser bem mais baratos e eficientes que gastar dinheiro com um consultor que cobra por hora. O grande benefício que o consultor vai te trazer é que ele sabe –ou deveria- como utilizar aqueles conceitos na prática. O melhor uso do consultor neste caso é trabalhar com o time no dia-a-dia e realizar pequenas sessões de treinamento –no meu caso geralmente isso significa 20 minutos por semana- conforme necessário.

Posted in arquitetura, brasil, comunidade, cursos, domain.driven.design, engenharia, fragmental, fragmental.tw, gerencia, negocios, orientacao.a.objetos, palestras, programando, thoughtworks | 4 Comments »

Sem Surpresas no Showcase!

Thursday, December 3rd, 2009

Existem muitas coisas que só se aprender na prática, depois de apanhar muito. Uma das coisas que eu –creio que- aprendi desta forma é como lidar com um showcase (ou Sprint Review, se você insiste).

Um showcase acontece geralmente no último dia de uma iteração. Ele serve para que o time apresente aos interessados –usuários, patrocinadores, pessoas não diretamente envolvidas no projeto, etc.- o que foi feito nesta iteração.

Eu costuma lidar como showcases como o momento onde o time e o usuário interagiam, onde o usuário via o produto final como um todo, dava feedback para o time e aprovava ou rejeitava histórias.

Péssima idéia. Todos os pontos acima são extremamente importantes mas eles não devem acontecer durante o showcase e sim durante toda a iteração.

O maior problema ao utilizar o showcase como único/principal ponto de interação é que você acaba tendo um big-bang feedback. Ao invés de colher feedback iterativamente no decorrer do período, de uma maneira que o time possa agir para consertar possíveis problemas, você recebe feedback em lote sobre tudo que foi feito naquela iteração de uma só vez. Não só isso pode significar excesso de informação bem como certamente vai frustrar o time e, principalmente, o usuário já que quando o feedback chega já é o fim da iteração e tarde demais para agir. Fica para a próxima.

E um problema parecido é o planejamento em big-bang, coisa que muita gente faz no seu Iteration Planning Meeting (IPM, ou Sprint Planning I & II se você realmente vai continuar insistindo). Em muitas equipes que conheço este é basicamente o único momento onde se planeja e prioriza uma iteração.

Combinando os dois problemas você tem um cenário extremamente frustrante: o usuário faz um grande planejamento, sai por duas semanas e volta para ver se seu plano foi cumprido. Se o time não conseguiu fazer tudo que ali estava definido o usuário fica frustrado e começa a desconfiar de tudo e de todos. Este tipo de situação é péssimo para qualquer tipo de empresa mas para nós, consultores, ele é simplesmente inaceitável.

O que eu aprendi com os mais experientes gerentes de projetos que já trabalhei é que em um showcase não podem haver surpresas. O cliente deve dar feedback sobre cada história e acontecimento individualmente, e durante a iteração. Na minha palestra no Rio mês passado eu falei brevemente sobre o “modelo do sanduíche”, melhor explicado aqui. Esta é a melhor maneira que eu conheço para ter certeza de que não haverão surpresas durante o desenvolvimento: para cada história -individualmente!- o usuário planeja junto com o time o que vai ser feito e depois verifica e aprova ou rejeita o resultado.

É claro que isto funciona melhor quando o cliente está presente o tempo todo, mas isto não é estritamente necessário. Se você possui um cliente fisicamente distante pode procurar outras maneiras de receber feedback frequente, coisas simples como fazer deploy constante para um servidor e mandar um email para o usuário pedindo para ele testar uma nova história neste ambiente. Só tenha certeza que seu usuário viu, aprovou e está ciente dos possíveis problemas e eventuais workarounds antes do showcase. É melhor isso do que criar um banho de sangue quinzenal.

Um showcase deve ter foco em mostrar para todas as partes interessadas o progresso feito, nunca em aprovar ou rejeitar histórias. Re-lembre a todos de onde viemos, onde estamos e para onde vamos. É claro que num projeto sadio sempre vai haver feedback vindo de múltiplas partes durante esta sessão, e isto é bom, mas um showcase não deve ter foco em receber feedback mas sim mostrar a evolução do projeto.

Existe todo um movimento de pessoas que prega que iterações são ruins. Um dos argumentos utilizados por esta escola de pensamento é exatamente de que o feedback em uma iteração tende a ficar apenas nos intervalos, não sendo frequente o suficiente. As pessoas vão para um modelo sem iterações e dizem que estão “livres da cerimônia” e que agora feedback e valor fluem o tempo todo. Bom, talvez o problema não seja com iterações em si mas sim na maneira como você as modela…

Posted in brasil, gerencia, metodologias, palestras, rio, thoughtworks | 2 Comments »

Preparações e Desculpas Esfarrapadas

Monday, October 26th, 2009

Para variar, a desculpa para não ter escrito mais frequentemente é a preparação requerida para a viagem ao Brasil. Eu sei que é uma desculpa esfarrapada mas infelizmente esta etapa envolve mais do que fechar malas e comprar canguru de pelúcia para as sobrinhas, meus últimos dois projetos requereram muita atenção e neste exato momento eu estou finalizando os últimos detalhes de um deles.

Isso fez com que meus planos se alterassem um pouco. Infelizmente não vou ter tanto tempo quanto gostaria para encontrar pessoas, especialmente fora do Rio. Ainda vou em alguns lugares mas nada perto do que tinha em mente antes.

Sobre o evento, acho difícil haver alguém que ainda não tenha esbarrado com um dos banners ou coisa parecida sobre o Caelum Day. A programação está bem interessante e promete ser um dia útil e divertido.

Minha apresentação vai focar no que eu mais tenho feito nestes últimos dois anos: fazer com que times de desenvolvimento saiam do marasmo e comecem a entregar. Não me venha com essa história de “minha metodologia não deixa”, “meu chefe é mau”, etc., todo lugar tem problemas e as coisas dependem de você. A apresentação possui dicas e fundamentos técnicos mas sem vontade nada vai pra frente.

E para, refletir de maneira bem realista o clima da indústria de desenvolvimento de software, este ano eu escolhi mais uma vez filmes de terror para servir de pano de fundo (e comic relief). Ao contrário do ano passado, entretanto, eu escolhi um filme em específico. O primeiro comentário quem acertar o filme baseado na capa da apresentação abaixo ganha… algo… que eu ainda vou decidir:

As inscrições ainda estão abertas aqui.

Para o workshop de Domain-Driven Design não há mais vagas –mas existe uma lista de espera.

Algumas pessoas ficaram curiosas porque escrevi no meu blog em inglês que acho o assunto (DDD) tedioso. Existe uma enorme demanda de cursos sobre o tema e o Paulo Silveira e eu decimnos que valia a pena realizar mais uma rodada dos cursos. Eu continuo usando Domain-Driven Design em meus projetos e textos, mas o assunto já está meio batido e mastigado.

Na minha opinião, DDD deveria ser parte de um curso maior sobre design em geral, um workshop específico tem relevância quando o assunto é novidade mas perde o apelo quando a técnica começa a ser utilizada por mais gente. Tenho lido mais sobre outras coisas e, se tudo der certo, vamos ver se em 2010 eu consigo aposentar o workshop de DDD e partir para estas novas coisas.

Bom, por enquanto é isso. Nos vemos semana que vem.

Posted in brasil, comunidade, cursos, domain.driven.design, engenharia, eventos, fragmental, fragmental.tw, gerencia, metodologias, negocios, palestras, programando, rio, testes | 5 Comments »

Refletindo sobre Tendências

Friday, July 10th, 2009

Recentemente muita gente tem me procurado nos instant messengers da vida para perguntar sobre tendências. Existe uma idéia no Brasil de que quem está de for a “traz as novidades”. Isso podia ser verdade antes da Internet mas agora as coisas se espalham com tanta velocidade que em muitos aspectos o Brasil está muito na frente da Austrália.

Mas existe o outro lado que é o trabalho na ThoughtWorks. Os projetos que nós enfrentamos geralmente começam da mesma maneira que os que qualquer consultoria, de três letrinhas ou três pessoas, enfrenta. O diferencial que faz ser um lugar interessante para se trabalhar é o que acontece durante o projeto.

O que segue neste post é uma amarrado de impressões pessoais sobre os últimos doze meses, tanto sobre a Austrália quanto o que sei de outros escritórios. Se ele não for coeso ou fácil de ler eu peço desculpas mas encare como um braindump.

Os projetos para bancos e empresas do mercado financeiro em geral continuam bem parecidos. Em 2007 houve uma euforia em torno da bolha econômica e muitos projetos megalomaníacos –e, por conseqüência, extremamente interessantes do ponto de vista técnico- apareceram mas a crise os tirou do baralho nos tempos recentes. Os bancos estão gastando menos e buscando fazer mais dinheiro reutilizando a estrutura existente. A maioria dos projetos que eu tenho conhecimento dentro de bancos é para estender uma determinada oferta para novos clientes ou é para migrar de uma plataforma legada para algo menos dispendioso.

O interessante sobre o “legado dispendioso”, dentro e fora de bancos, é que muitas vezes ele se trata de coisinhas como WebSphere, Aqualogic, Biztalk, Tibco e produtos parecidos. Apos gastar rios de dinheiro implantando estes e não ver nenhum centavo de retorno real muitos dos grandes estão migrando para plataformas mais eficientes, quase sempre baseadas em software livre. Hoje em dia são comuns projetos de migração de Websphere para Jetty ou de BizTalk para serviços RESTful usando IIS, JSON e ASP.Net MVC, por exemplo.

Na parte de aplicações para Internet, onde geralmente eu me envolvo mais, as coisas também têm mudado bastante. Basicamente os projetos têm se dividido em startups e legado. As startups aparecem com um problema e algum montante de dinheiro. A plataforma mais utilizada para atender estes cenários é Ruby on Rails, geralmente fazendo deployment em algum serviço de Cloud Computing.

Cloud Computing é um tópico extremamente relevante tanto para ThoughtWorks quanto nos nossos clientes. Uma das coisas interessantes que fizemos no início do ano foi trabalhar junto com o Google no lançamento da AppEngine em Java (e outras linguagens).

As empresas com legado de Internet são sempre interessantes. Geralmente elas são algum grande prestador de serviço na área de mídia e possuem um ou mais websites antigos que têm aquela arquitetura manjada de rodar em um Weblogic ou Tomcat com um Apache de front-end. O problema é que hoje em dia o numero de usuários é muito superior e a velocidade com que funcionalidades têm que ser adicionadas e alteradas é muito maior. Após entender que os Googles e Facebooks da vida não usam Java EE e não pagam licença para a IBM as empresas estão desesperadas para atingir o mesmo nível de eficiência.

O que temos feito nesta área é utilizar a já citada Cloud Computing para realizar tarefas que não precisam ser executadas dentro do firewall (de crawling até rodar teste de carga), refatorar aplicações grandes para atingir escalabilidade horizontal e simplificar processos de deployment e gerenciamento de recursos.

Na área mais de programação em si as coisas não têm sido lá muito excitantes. As plataformas em específico não têm nenhuma novidade marcante mas a programação poliglota é uma realidade. Até hoje todos os projetos que tive alguma participação dentro da ThoughtWorks utilizavam mais de uma linguagem de programação (já descontando Bash e JavaScript).

Uma surpresa agradável foi a que tive no meu projeto atual, em que voltei a programar em .Net após 3 anos afastado. A maioria das coisas que eu realmente não gostava sobre C# e seu ecossistema foram removidos (exceto Windows e Visual Studio, duas peças que eu considero de qualidade inferior). A Microsoft continua enfiando frameworks e ferramentas terríveis pela guela dos seus clientes (MSBuild? TFS? WCF? WTF?!?) mas no geral as coisas estão bem melhores.

Em termos de livros sobre programação eu tenho me focado quase que exclusivamente nos conceitos presentes em linguagens e paradigmas de programação. Esta é a lista de livros relacionados que eu li desde que cheguei aqui:

Esta é a fila dos que faltam:

(fora os que ainda estão no meu carrinho de compras na Amazon. Livro na Austrália é ridiculamente caro)

Na parte de gerenciamento de projetos e metodologias as coisas estão engraçadas. Tem horas que a euforia anima, tem hora que dá náusea. Eu acho que o Bellware resumiu muito bem:

early agile adopters were looking for a way to do things better. later adopters are just trying to do agile, thus the failures

Eu vim para a ThoughtWorks para ver como é que quem introduz métodos ágeis há anos trabalha. Nos últimos meses eu trabalhei com pessoas que fazem isto há mais de dez anos e em empresas que adotaram agile antes de eu saber que ele existia. O que eu aprendi neste período inicial é exatamente o descrito acima: quando seu objetivo é ser ágil você falha, quando seu objetivo é sempre melhorar você tem chances de sucesso.

Todos os projetos que participei foram bem sucedidos? Depende de para quem você pergunta. Mesmo os clientes mais difíceis que tive acabaram ficando satisfeitos no final mas muitos projetos que participei (e o número de projetos é bem maior que o número de clientes) foram executados de uma maneira que o time não ficou satisfeito. Eu acho que neste caso é perspectiva. Como a maioria dos projetos são um fracasso colossal basta ter algum nível de sucesso que o projeto vira referência. O time, em compensação, tem um critério de sucesso muito mais alto e não considera o projeto como bem-sucedido.

É claro que no fim das contas o que vale mais é a opinião do cliente –tanto porque o problema dele foi solucionado bem como porque é ele quem paga a conta no final- mas eu já vi diversos problemas decorrentes deste tipo de coisa. De builds que começaram em 10 minutos e terminaram em duas horas de duração até um time que perde 50% do seu tempo corrigindo defeitos por falta de uma suíte de testes decente. Os problemas podem não ser grandes para aquele projeto em específico mas não prestar atenção há eles é mortal em médio prazo.

Minha conclusão é que a indústria está num estado melhor do que há alguns anos atrás. Tecnicamente estamos entrando em uma espécie de renascimento e isso promete render muito material para posts aqui. Em termos de gerencia de projetos e processos as pessoas estão finalmente se convencendo que tudo tem limite, até ineficiência.

Posted in .net, arquitetura, australia, bancos.de.dados, beyondjava, brasil, cbd, comunidade, domain.driven.design, domain.specific.languages, engenharia, foss, gerencia, guj, java, javascript, linux, lisp, livros, metodologias, microsoft, negocios, orientacao.a.objetos, php, plataformas, programacao.funcional, programando, rails, rest, ruby, sistemas.operacionais, soa, testes, thoughtworks, unix, você.pergunta, web, ws-*/soap | 9 Comments »

Mingle Day - Rio e São Paulo

Tuesday, June 23rd, 2009

Como este blog já anunciou este ano será cheio de eventos da ThoughtWorks no Brasil.

Uma coisa a se notar sobre a ThoughtWorks é que somos uma empresa de consultoria mas com uma divisão de produtos. Como a eventual vinda da ThoughtWorks para o Brasil significa a vinda das duas partes é bom que também apresentemos ao mercado brasileiro os softwares que produzimos.

O software mais popular da suite é o Mingle, um sistema de gerenciamento de projetos com muitas características interessantes. Ele foi construído baseado na experiência da empresa prestando consultoria, entende bem que cada processo é diferente e que modelos engessados não funcionam bem. Também possui uma interface rica que aliada com alguns recursos de hardware se torna uma ferramenta extremamente útil quando um Kanban eletrônico é necessário. Por fim é provavelmente o mais famoso caso de uso do JRuby on Rails -o Mingle usa componentes escritos em Java aliados aos recursos do Rails.

Se você quer conhecer mais sobre o produto tem duas oportunidades. Abaixo os convites.

Rio de Janeiro

Hi,

ThoughtWorks is sponsoring Agile Brazil 2009, the first major conference on Agile methodologies to be held in Rio de Janeiro, Brazil. In this extensive, one-day event, various practitioners and speakers will conduct sessions on a range of well-known Agile methodologies and practices such as Lean, Scrum, XP, User Stories, Continuous Integration, Release management and Test Driven Development.

Date and Venue:
June 27, 2009, 8:30am - 6:00pm.
Salao A (Padre Anchieta hall)
PUC-Rio, Gavea, Rio de Janeiro, Brazil.
Registration Information
Registration: R$ 200,00.
Register for Agile Brazil 2009

Mingle User Group Meeting in Rio de Janeiro

We have organized a free follow-on event for agile enthusiasts. We invite you to the Rio Mingle User Group (MUG) Meeting, an exclusive meet for Mingle users in Brazil, to discuss and share their experience with Mingle. Adam Monago, our product expert along with other Agile experts will take you through Mingle and its features and provide you tips and tricks on how to better use Mingle for project management and collaboration. After the talk you can interact with the attendees over food and drinks.

Date: 1- July-2009
Time: 17:30 - 19:00
Venue: PUC-Rio, Rua Marques de Sao Vicente 225 - Predio Padre Leonel Franca - 13 andar - Gavea, Rio de Janeiro, Brazil

To confirm your participation for the Mingle User Group, simply reply to this email: Studios-Brazil@thoughtworks.com?

Regards,
ThoughtWorks Studios
Studios-Brazil@thoughtworks.com

São Paulo

A Aspercom e a ThoughtWorks convidam você para o Encontro Agile / Mingle User Group Meeting. Este será um evento gratuito em São Paulo com mini-palestras, discussões e muito bate-papo.

Data: 30 de junho de 2009 às 19:00hs / Local: Av. Paulista

Facilitadores:
Paulo Caroli, Adam Monago (ThoughtWorks)
Rodrigo Yoshima, José Paulo Papo

Mingle User Group Meeting

O encontro do Mingle User Group (MUG) do Brasil é uma oportunidade para conhecer, discutir e compartilhar experiências com o Mingle. Adam Monago, um especialista no produto juntamente com outros Agilistas experientes, demonstrarão o Mingle provendo dicas e truques em como usar o produto para gerenciamento de projetos e colaboração.

Local, agenda, inscrições e outras informações acesse: http://blog.aspercom.com.br/2009/06/22/evento-agile-mingle/

Rodrigo Yoshima
ASPERCOM

Paulo Caroli
ThoughtWorks

Posted in beyondjava, brasil, comunidade, engenharia, eventos, gerencia, java, metodologias, negocios, palestras, plataformas, rails, rio, ruby, thoughtworks, web | No Comments »

Agile Brazil 2009

Sunday, May 24th, 2009

Caso você ainda não saiba a ThoughtWorks está patrocinando um evento em Junho, no Rio de Janeiro: Agile Brazil 2009.

Além de palestrantes locais o evento vai contar com três ThoughtWokers: Jason Yip, Paulo Caroli e Adam Monago. O Jason é um dos mestre jedis em lean software development que temos na TW. O Paulo é brasileiro e trabalha oficialmente na TW US mas está em uma temporada na Índia. O Adam é gerente de produtos do Mingle.

Eu tenho conversado bastante com o Jason para explicar mais sobre o cenário de desenvolvimento de software no Brasil -que é bem diferente de qualquer outro país que eu conheça. Conhecendo a peça eu tenho certeza que a palestra vai ser uma excelente oportunidade para quebrarmos alguns mitos sobre lean que estão sendo introduzidos na cultura brasileira -como os de que contar “bugs por linhas de código” é uma métrica razoável para justificar uma prática ou metodologia.

Uma coisa boa é que ele está muito entusiasmado em fazer visitas à empresas interessantes. Eu entrei em contato com alguns lugares que considero bons candidatos mas se você tem alguma história interessante para contar e gostaria de recebê-lo por um dia me mande um e-mail que eu coloco vocês em contato. Note que ele vai estar no Rio e que você precisaria de alguma espécie de intérprete Inglês-Português.

Infelizmente eu não vou poder ir ao Brasil neste início de ano já que estou começando um projeto complicado na próxima semana que deve durar até Julho. Existe uma grande possibilidade de ir no segundo semestre, vamos ver se ela se realiza.

Posted in brasil, comunidade, eventos, gerencia, metodologias, palestras, rio, thoughtworks | 2 Comments »

Gerencie como um pr0n star!

Friday, May 15th, 2009

Se você não entendeu a piada com o título clique aqui.

Então tivemos o Scrum Gathering Brazil esta semana. Infelizmente eu não estava por lá mas acompanhei bastante a movimentação via twitter e conversando com amigos nos instant messengers da vida. Agora estou lendo a cobertura dos blogs.

A que mais me chamou atenção –e eu já previa isso tendo conversado com o autor durante a evento- foi a do Rodrigo Yoshima. Entre diversos comentários sobre apresentações que deixaram pontos de interrogação e exclamação na cabeça do autor eu destaco:

Usando Scrum com o Visual Studio Team Systeam - Fabio Camara [...]
- Ele acha incrível como a Regra de Pareto se aplica a projetos de software: 20% dos desenvolvedores fazem 80% do trabalho.
- Ele se questiona se vale a pena o programador testar. Para ele, o programador só deve verificar e um testador, que é mais barato, testa efetivamente. Na mesma linha ele questiona TDD para projetos que ele denomina “time-driven”. Não achei referências para esse termo, mas ele classifica como os projetos onde tudo é para ontem. Nesses projetos não há tempo para pensar em testes unitários.
- A maior divergência porém, é o papel do ScrumMaster na visão do Fabio Camara. Para ele o ScrumMaster Monta o Plano, Distribui Atividades, Obtém Feedback e Refaz o Plano. Ele deixou claro na palestra que essa é a opinião dele. Quando questionei a respeito da auto-organização do Scrum ele disse que também não acredita na auto-organização.

E o grande sumario disso (desculpe o hotlink, Rodrigo!):

Este é o tipo de coisa sobre a qual eu falei aqui, aqui, aqui, aqui e, principalmente, aqui.

Quanto mais as metodologias ágeis ganham o mainstream mas nós vamos ver este tipo de coisa. O fato de que Scrum possui certificações e selinhos só piora tudo já que dá credibilidade imediata a uma informação errada no seu princípio básico.

Isso me lembrou alguns casos. Uma vez uma amiga foi para um cliente que havia implantado Scrum há pouco tempo. Todos fizeram o cursinho e tinham selinho de CSM. O diretor do programa tem o selinho melhor, CSP, e estava no caminho do seu CST, o selinho máximo.

Ela é uma analista de negócios e quando chegou foi levada imediatamente para uma sala com todos os stakeholders e desenvolvedores. Eles olharam seriamente para ela e disseram algo como:

- Precisamos muito da sua ajuda. Precisamos de aconselhamento em como deixar a informação visível. Agora com Scrum nós precisamos deixar claro o que está acontecendo aqui no desenvolvimento para todos.
- Uh. Ok, então acho que vocês podem começar me explicando o processo de negócios, acho que posso ficar algumas horas vendo como vocês trabalham e como o sistema é usado. Depois queria conversar um pouco com o time de desenvolvimento, podemos fazer uma mini-retrospectiva e uma futurospectiva para tentar entender porque a comunicação é um problema. A partir daí nós traçamos um plano, pode ser necessário conseguirmos coaches técnicos e, talvez, um gerente de projetos com experiência em métodos ágeis…
- Er… ahm. Ta. Mas… não era bem isso que estávamos pensando. Sabe, nós já fizemos tudo isso. Tivemos uma grande reunião, acertamos os fluxos de trabalho e tal.
- É? Mas… pelo que eu vi conversando com pessoas durante as últimas semanas vocês ainda têm problemas, os desenvolvedores estão reclamando de que tudo muda o tempo todo, o pessoal de negócios reclama que vocês estão quinze meses atrasados…
- Sim, sim, sabemos disso tudo. Mas nós sabemos que com o Scrum eventualmente essas coisas vão se resolver, não estamos preocupados. O que nós não conseguimos entender é como otimizar a radiação de informações utilizando kanbans distribuído pelo chão de fábrica.
- “Otimizar..kanban…” peraí, vocês querem que eu ajude você a decidir onde colocar seu story wall?
- É, acho que você pode colocar deste jeito…
- Você tem alguma idéia do quanto vocês estão pagando por hora pra eu estar aqui?!?

Eventualmente o cliente percebeu que onde posicionar o story wall era o menor dos seus problemas. Um dos principais problemas deles é que estavam fazendo exatamente o que o Fabio Câmara sugeriu: tinham um Scrum Master que criava, gerenciava e ajustava o plano. Os desenvolvedores estavam sempre atrasados porque eles nem sabiam qual era o plano, apenas sabiam das atividades. Discussão típica:

- Estamos atrasados!
- Você está atrasado, meu time está em dia.
- Como assim?
- Eu falei que precisava de dois dias para colocar o back-end em produção, bom estamos terminando agora, com o mínimo de atraso.
- Mas o front-end não está pronto, qual a diferença?
- Isso é com o time do Beltrano. Nós aqui estamos certos. Sprint goal atingido, vamos para o bar.

Ou, na “obtenção de feedback”:

- Ok, esta tarefa aqui está demorando muito então vamos acabar entregando aquela ali atrasada.
- Você está dizendo que o projeto vai atrasar?!
- Não, não. Você me entendeu mal. Meu time está OK, nós vamos entregar em dia, não se preocupa não.
[dois dias depois]
- E aí, tudo certo?
- Tudo.
- Aquela tarefa ali… está meio atrasada, não?
- Não, não. Veja bem, ela já vai estar pronta… já já.
[final do sprint]
- Então, como estamos?
- Bom. Aquela tarefa ali atrasou. Isso fez com que o Fulano ficasse preso ajudando o Beltrano e não fizesse o trabalho dele. Mas não tem tanto problema porque ele não ia conseguir fazer o trabalho dele mesmo já que esta tarefa depende da outra.
- Então… o que vocês estão entregando hoje?
- O Domain Model, todas as classes no lugar. Ta pronto. Só falta testar.

A solução neste caso específico teve que ser meio drástica. O que queríamos fazer era remover todos os Scrum Master e devolvê-los a sua posição original (geralmente gerente de projetos e desenvolvedores sênior) mas vimos que isso ia causar problemas políticos demais. A solução mais viável foi manter os Scrum Masters -pelo menos o título- e usarmos “Gerentes de Iteração”. Iteration Manager é o termo que usamos para um papel equivalente ao Scrum Master –gerente de projetos é outra coisa- e estes caras atuavam como lideres dos times e gerentes de iteração.

Os gerentes de projeto -ainda chamados Scrum Masters por razões históricas- tinham ainda o “plano”, algo em extremo alto nível que dizia que considerando a situação atual de escopo e velocidade a funcionalidade X vai ser entregue dia Y, a Z dia W e assim por diante. Arrastar barrinhas no Microsoft Project não mudava o plano, ele era apenas um retrato da situação real e para mudar a situação real você tem que resolver seus impedimentos. Sem truques.

Outro problema foi o tal do testes. Nós sabemos que desenvolvedores profissionais testam mas neste cliente eles compartilhavam da idéia do Fábio de que testar é coisa pra recurso barato. Resultado? Os recursos caros ficavam dias produzindo código caro que não funcionava. Apos um sprint inteiro de código caro produzido se tinha que reescrever boa parte. Como é aquela história de “o barato sai caro mesmo”?

Nada disso, qualidade é algo muito caro para ser produzido por “recursos baratos”. Como o Jason Yip diz: controle qualidade é responsabilidade do time todo -ele sugere o termo “Inspetor de Qualidade” para o que normalmente chamamos de QA- e para isso os desenvolvedores precisam entrar na dança.

Sendo extremamente sincero, eu não consigo entender como um desenvolvedor experiente assume que uma metodologia ágil consiga funcionar sem testes. Você não tem sequer uma especificação dizendo o que vai construir!

A única maneira que eu vejo disso meio que funcionar é se ao invés de uma metodologia ágil você utilizar apenas mini-waterfalls a cada sprint. Fica um tempo especificando o que vai ser feito, um tempo fazendo, um tempo testando. Enxágüe e repita. Mas isto não é uma metodologia ágil, o ciclo de feedback é muito longo!

E este foi só um dos múltiplos exemplos que tivemos nos últimos dois anos. É preciso ter cuidado, muito cuidado. Scrum vêm crescendo muito como hype e é um framework, cheio de lacunas por definição. Quando alguém com bastante bagagem vê as lacunas no Scrum ele logo assume que basta enfiar o que já se usa em desenvolvimento “tradicional” e acaba criando um híbrido de modelos quase sempre extremante ineficiente.

Scrum não diz como desenvolver software? Sem problemas, nós sabemos fazer isso: escreve uma especificação no wiki, codifica, testa. Scrum não diz como compartilhar conhecimento sobre o código? Sem problemas, nós sabemos como fazer isso: antes do código ser enviado para o SCM ele tem que ser aprovado por um membro mais sênior do time. Scrum não diz como integrar código? Sem problemas: cada um cria seu branch e nós integramos no final do Sprint.

É bom notar que mesmo com as lacunas citadas o framework tem princípios bem definidos. A opinião de que o Scrum Master é o dono do plano vai de encontro com o que o Scrum prega. Pode ser a opinião de alguém experiente, você pode achar que faz sentido… só não pode dizer que isso é Scrum.

E se você soma isso ao fato de que não é preciso muita coisa para ter um certificado em Scrum o problema toma proporções gigantescas. Scrum em si não diz que é errado, digamos, escrever um documento de caso de uso de vinte páginas para cada item de backlog. E se, ainda por cima, a pessoa que sugeriu isso ainda possui um selinho dizendo que ele sabe Scrum?

Se você não tem um time experiente em metodologias ágeis então comece seguindo todas as práticas de XP. Após ganhar experiência decida o que funciona e o que não funciona –mas teste todas antes, e por um tempo considerável.

Não comece apenas por Scrum. Como falei antes você vai encontrar muitos buracos e sempre a solução mais fácil vai ser fazer o que já se fazia antes.

Repetindo um tema freqüente neste blog: eu posso programar FORTRAN em qualquer linguagem. Eu posso gerenciar waterfall e/ou comando-e-controle em qualquer metodologia.

Posted in brasil, comunidade, eventos, gerencia, metodologias, palestras, perolas, testes | 14 Comments »

Não Vai Subir Ninguém!

Tuesday, December 9th, 2008

A coisa mais comum em uma empresa é a formação de uma “tropa de elite”, contendo os principais e provavelmente mais talentosos desenvolvedores. O raciocíno é simples. Empresas em geral são uma bagunça tecnicamente, anos e anos contratando desenvolvedores sem muito critério (e não investindo nos mesmos após contratação) fez com que sejam criados sistemas que não se falam, projetos que atrasam, duplicação de esforço além dos odiosos bugs em produção que te acordam na hora em que eu estou almoçando aqui em Oz.

E é claro que as consequências são desastrosas. Não houve uma só grande empresa onde (ou para quem) eu tenha trabalhado onde não existe a elite da tropa. São aqueles technical stakeholders pessoas para quem você bate continência e tem que agradar. São aquelas pessoas que não estão envolvidas com seu projeto mas ainda assim podem acabar com ele. São parte daquele grupinho que age como a polícia e defende a “moral e bons costumes”, matando a inovação no caminho. São aqueles que estampam seu projeto com o “selo de qualidade”, onde qualidade significa concordar com eles.

Lembranças dolorosas não faltam. Certa vez eu cheguei em um projeto muito perto da ida para o ar. A estrela dentre as funcionalidades era um sistema meio estranho que categorizava conteúdo, mas como eu era novo no time deixei para lá e fui resolver os bugs que impediam o release. Na véspera do release nós percebemos que o sistema “estranho” não aguentava nem um terço dos acessos que teríamos.

O líder de desenvolvimento daquele sistema foi extremamente contra qualquer mudança no mesmo. Ele havia sido desenvolvido de acordo com os critérios passados pelo grupo de arquitetura da empresa e o arquiteto havia solicitado uma solução genérica que pudesse ser reutilizada em todos os mais de 100 produtos da empresa.

Um requisito mais que válido. Reinventar aquilo cem vezes seria um desperdício sem tamanho. Mas o projeto deveria ser entregue em alguns meses e desenvolver aquela funcionalidade “pensando no bem da nação” o fez não só atrasar e custar noites em claro bem como resultou em um sistema que sequer atendia o projeto em questão, muito menos todos os outros 99 sistemas.

O problema é que o arquiteto não fazia parte daquela equipe e não entendia seus requisitos e características. Não estava presente no desenvolvimento, não escreveu uma linha de código, não tinha comprometimento com a entrega.

Não importa o quão bom o time seja, conhecimento técnico só tem valor dentro de um contexto e neste caso o contexto é um time ou um projeto. A falta de comprometimento e de “senso de time” faz com que a “tropa de elite” seja vista mais como uma dificuldade a passar do que algo que traz auxílio. Eu não tenho idéia de quanta vezes tive que adicionar e remover caixinhas em diagramas só para agradar alguém que senta em uma torre de marfim e desce apenas para chicotear os incautos.

E em médio prazo as coisas pioram. Um fato claro é que o grupo se fecha: ninguém dos reles desenvolvedores é bom o suficiente para subir para a elite. Os desenvolvedores com potencial acabam saindo da empresa porque são tão cortados pelo time de elite que desistem e vão tentar ser arquitetos em outro lugar. A falta de abertura, o medo que os desenvolvedores têm dos “caveiras” e a auto-confiança que o grupo desenvolve (afinal eles não têm que passar por avaliação técnica nenhuma, eles são a verdade!) faz com que opiniões se tornem leis.

Recentemente eu tive um caso engraçado. Estávamos introduzindo serviços REST em uma empresa e uma das barreiras era este tipo de time. Eles eram os melhores desenvolvedores da empresa, ditavam as leis e odiavam qualquer coisa que lembrasse processamento remoto. Meu então chefe, um excelente técnico mas com uma capacidade acima do normal de perder a cabeça, e eu marcamos uma reunião com este time para apresentar a idéia.

Durante a semana anterior eu fiquei polindo slides e buscando referências para responder qualquer dúvida técnica. No dia da reunião eu estava extremamente nervoso e após 15 minutos de atraso meu chefe saiu da sala para ver porque os arquitetos não haviam chegado ainda. Eu aproveitei os minutinhos para dar uma última revisão quando comecei a ouvir gritos do lado de fora. Ao sair dei de cara com meu chefe e o arquiteto sênior discutindo calorosamente a questão dos serviços.

O arquiteto master argumentava que eles já tentaram EJB e deu errado, já tentaram WS/SOAP e deu errado e que ninguém vai usar mais serviço nenhum. Isso não funciona nesta empresa, já vimos isso e ponto final. Vendo que aquilo não ia ajudar muito eu puxei meu chefe pelo braço e voltamos para o escritório.

Não havia como desistir da tecnologia nem do projeto, então marcamos uma segunda reunião. Desta vez eu mudei todos os slides e fiz questão de não convidar meu chefe. Eu removi todos os slides que falavam de REST e a palavra “serviço”, deixei apenas o HTTP. A reunião foi ótima, o sistema estava abençoado pelo arquiteto master e podíamos seguir em frente. Qual o valor que estas duas reuniões e duas semanas de trabalho trouxeram? Elas alimentaram o ego do arquiteto, ele realmente acreditou que nós mudamos a arquitetura para o agradar. Só isso.

Este tipo de barreira cria medo entre os desenvolvedores. Ainda que você tenha uma excelente idéia para aquele seu projeto vai ter que justificar para aquela pessoa que não quer nada além de arrumar algo que justiique seu cargo. A inovação morre em meio ao medo de propôr algo e ser rechaçado.

É impressionante como este padrão de organização departamental lembra a história da humanidade. Um grupo é oprimido por um governo corrupto e injusto. O grupo é exilado (i.e. pede demissão) une forças, volta e derruba o governo. No próximo passo o grupo forma seu próprio governo, corrupto e injusto como o anterior.

Mas o que fazer? Como falei no início, as empresas são uma zona! É comum que a cada 100, 200 desenvolvedores tenhamos meia dúzia que está acima da média. A solução me parece óbvia: não concentre, distribua.

Se você tem poucos bons desenvolvedores não faz o menor sentido agrupá-los, pelo contrário! Espalhe os desenvolvedores bons entre os times e certifique-se que eles possuem autoridade suficiente para mudar as coisas. Treine seus desenvolvedores como coaches e os faça ocupar o papel de líder técnico em projetos. Crie um programa de mentoria de desenvolvedores e faça com que seus jovens talentos tenham como referencial os melhores.

E como controlar este tipo de atividade por toda a empresa? Crie comunidades de prática. Ao invés de um “departamento” de arquitetura ou de “práticas de desenvolvimento” crie uma comunidade que abrange diversos departamentos e times. Em vê de investir um bolo de dinheiro em um grupo de pessoas invista um pouquinho em cada um dos seus times, deixe eles realizarem atividades para melhorar suas habilidade durante o expediente. Em vez de criar xerifes e a cultura do medo crie uma cultura de melhoria contínua, remova as maçãs podres da sua empresa e crie mecanismos para acompanhar o desenvolvimento de todos os membros do time.

Posted in arquitetura, gerencia, metodologias | 38 Comments »

Deixa Para os Analistas de Verdade…

Sunday, November 23rd, 2008

Eu irritei bastante gente da última vez que falei sobre analistas de sistemas. Até hoje, 10 meses depois, ainda tem gente que me manda e-mail malcriado.

Muitos destes comentários falavam que eu estou desmerecendo o valor da análise. Minha resposta é que pelo contrario, o que eu estou dizendo é que análise é tão importante que não dá para misturar as coisas:

É certo que muitos clientes precisam entender seus próprios negócios antes de criar um sistema mas isso não é papel de analista de sistemas, é papel de analista de negócios. Um analista deste tipo possui capacitação em campos bem diferentes, é completamente possível que um analista de negócios seja um desenvolvedor (vamos abolir o “analista de sistemas” a partir daqui) mas neste caso ele está assumindo duas especialidades. Um analista de negócios possui um perfil não-técnico e mais especializado em um mercado como bancos, marketing, telecomunicações e etc.

Como eu falo no post citado, o problema é que pensamos que análise faz parte da profissão de desenvolvedor ou que é sua evolução. Isto não é verdade, o trabalho de analista de negócios pode resultar em algo que nem é um programa de computador. Em um caso recente o cliente queria um novo website para “automatizar processo” mas após a análise verificou-se que o que ele precisava era simplesmente melhorar seu formulário -de papel.

Eu realmente não entendo como pessoas conseguem misturar Test-Driven Development, Domain-Driven Design, metodologias ágeis e técnicas de análise de negócios em workshops de um dia.

Estou tendo a felicidade de ver um processo de ponta a ponta na pratica neste instante, participando de uma Inception, uma fase bem curta onde tentamos entender o que estamos fazendo. O projeto em si não começou, estamos apenas estabelecendo uma visão e pensando sobre a viabilidade do sistema.

O processo, segundo a metodologia que desenvolvemos na ThoughtWorks, é composto por diferentes workshops com quase todos os envolvidos do lado do cliente.

A atual equipe é composta por:

Facilitador: Alguém que conduz as atividades e mantêm o time nos objetivos. Não possui uma habilidade específica alem de “facilitação de colaboração”. No meu projeto atual o papel é executado por uma analista de negócios mas eu já vi testadores, desenvolvedores e gerentes de projeto executando esta tarefa.
Stakeholders + Analistas de negócios: Funcionários do cliente de diversas áreas envolidas e os nossos analistas que trabalham com eles.
Líder Técnico: Um profissional técnico com senioridade suficiente para responder às dúvidas que surgirem.

Note que existe algo engraçado aí: parece um time ágil ao contrário. Ao invés de cliente presente nós temos o técnico presente. Eles realizam o trabalho de definir o que o sistema vai ser, eu só estou lá para dizer o que faz ou não sentido tecnicamente. Em um mundo ideal teríamos todo o time técnico presente (considerando que um time ágil não é nunca grande), mas como somos uma consultoria e cobramos por tempo o cliente quer, obviamente, minimizar custos em um projeto que ele ainda nem sabe se vai construir.

A Inception é muito curta. Ela precisa ser curta porque, já que não pretende entregar nada alem de uma visão geral do projeto, o desperdício precisa ser minimizado. As pessoas mais experientes dizem que nenhum projeto ágil pode ter mais de duas semanas de Inception.

As entregas são freqüentes, temos um showcase por semana (i.e. 2 no total) onde são apresentados aos stakeholders que não participam dos workshops (geralmente a alta gerencia) o que desenvolvemos naquele período: definições sobre o que o projeto é e o que ele não é. Como a maioria dos processos ágeis nós usamos ferramentas de baixa tecnologia como post-its e cartões, estes são fotografados e/ou convertidos em slides.

A entrega final depende do cliente. Em geral nós sempre temos uma lista com as histórias identificadas nestas duas semanas e suas estimativas de alto nível, formando um backlog inicial para o projeto começar. Também temos o que alguns poderiam chamar de project charter, mas ao invés de páginas e páginas de documentos temos um deck de slides com basicamente a consolidação dos dois showcases.

E qual o papel do tal analista de negócios nisso tudo? Eles trabalham junto com os stakeholders para gerar uma visão única do projeto (já que possivelmente cada stakeholder que uma coisa diferente) e transformar isso em algo que possa ser executado (histórias). No meio do caminho eles ajudam a eliminar desperdício, introduzir idéias novas, validar os pedidos, conferir viabilidade e tudo mais que não faz parte do papel de um desenvolvedor e sim de alguém que, de fato, entenda do negócio do cliente.

Desde quando trabalhávamos juntos que eu converso bastante com o Antônio Carlos sobre este tipo de coisa. No nosso ambiente nós tínhamos clientes que não sabiam o que queriam e desenvolvedores que não entendem do negócio. O resultado final era que nada que ia pro ar era exatamente o que o cliente queria, seja por falha de comunicação ou porque ele mudou de idéia e “esqueceu” de avisar aos desenvolvedores.

Note que o papel do analista de negócios não elimina a necessidade de termos um cliente presente. Não existe mapeamento de requisitos ou coisas do tipo, além de usar seu expertise naquele domínio em específico, o analista de negócios age como facilitador e não como ponte entre cliente e desenvolvedores. Ele também não é um tradutor, os termos de negocio e os processos devem ser entendidos por todos os envolvidos. Após a Inception o cliente não fica de fora do projeto, só voltando para colher os frutos. Ele faz parte da equipe o tempo todo, um analista de negócios, por melhor que seja, nunca substitui seu valor.

Esta fase do processo também responde a uma eterna discussão o fato de que XP (que é a metodologia-base usada na ThoughtWorks) não tem “foco em negócios”. Nem é para ter! XP ou qualquer metodologia ágil que se preze vai focar em pontos específicos. XP não atende a todo o ciclo de vida do projeto, ele faz parte do ciclo de vida. Quando a Inception acaba começa a Iteração 0 e daí o XP entra em ação.

Update: O Guardian, que passou pelo processo descrito aqui, tem um post bem legal sobre o assunto.

Posted in comunidade, gerencia, metodologias, negocios, thoughtworks | 8 Comments »

Fragmental