negocios « Fragmental

Archive for the ‘negocios’ Category

Inovação: Construa e Eles Virão

Tuesday, June 1st, 2010

Inovar é preciso, e você sabe disto. Todos aqueles livros sobre a Cabeça do Pai Rico que Mexeu no Queijo do Segredo da Arte da Guerra foram bem claros: inove ou morra.

Mas como se faz isso em um ambiente corporativo? Sinceramente, não é muito difícil. A coisa mais importante é ter as pessoas ideais. Existem pessoas que trabalham de nove às cinco, e não existe problema nenhum em fazê-lo. Eu, entretanto, prefiro trabalhar com gente apaixonada pelo que faz. Gente apaixonada têm o privilégio de ter como hobby sua própria profissão. Dado este tipo de gente, basta você criar a oportunidade.

A minha experiência neste tipo de cenário começou com o que aprendi com o Antônio Carlos Silveira, que é meu grande mentor em anti-corporativismo. Quando trabalhávamos na Globo.com, a vida era uma eterna disputa entre dançar a dança tentando não cair no corporativismo das requisições de mudança, Jiras e PMAs. Das lições mais importantes que aprendi com o Toninho, uma das que mais ficou pode ser resumida em: você pode ter vestir uniforme de marinheiro mas ainda é um pirata.

E nós tentamos várias coisas, e falhamos miseravelmente em quase todas. Como exemplo, nosso time iniciou um projeto piloto para copiar os (míticos) 20% livre do Google. Sexta-feira a tarde os desenvolvedores eram livres para fazer o que quiser, seus projetos pessoais. Essa foi uma iniciativa capitaneada pelo Danilo Bardusco que, antes de ser promovido à gerente do lojinha fazia parte da finada equipe de Webmedia da Globo.com, certamente o melhor time com que já trabalhei na vida e cuja maioria dos membros são grandes amigos até hoje.

Todas as idéias que surgiram nestes projetos falharam de uma maneira ou de outra. A maioria não foi para frente por motivos técnicos/motivacionais (i.e. fogo-de-palha) e alguns chegaram a ter implementações completas mas não foram pro ar porque o pessoal de negócios não achou a idéia atraente.

Fracasso? Perda de tempo? Muito pelo contrario. O clima na equipe mudou de uma maneira tão brusca que parecia outra empresa. Quando entrei na Globo.com, em 2006, a Webmedia era, basicamente um departamento de uma grande empresa. Entravam requisitos e saia código. Após esta e muitas outras iniciativas como a adoção oficial de métodos ágeis –é bom notar que nós, na Webmedia, nunca fizemos Scrum de fato. E eu me orgulho muito disso.— o clima mudou completamente. A equipe passou a ter um clima muito diferente, bem mais próxima de uma startup do que de uma empresa de três letras. A coisa foi tão bem sucedida que o que você vê de Globo.com é uma tentativa de espalhar esta cultura.

Nos últimos dias eu tenho experimentado uma proposta parecida. Aqui na ThoughtWorks nós temos o eterno problema de tentar conciliar crescimento com qualidade e inovação. Como fazer para estimular pessoas que já trabalham em projetos para clientes para que não percam a motivação?

Algumas mentes tiveram uma ótima idéia: um concurso. Todos os ThoughtWorkers da Austrália são convidados a formar grupos e desenvolver uma aplicação para o iPad. O grupo vencedor leva dois iPads.

Parece algo bobo, mas será? Um iPad em Sydney custa por volta de AUD$1.000.00. Com descontos corporativos e uma série de benefícios fiscais que o governo fornece você consegue comprar o modelo mais caro por uns AUD$700.00. A maioria dos meus colegas ou já comprou um iPad ou está esperando a segunda geração, ninguém está contando com o prêmio em si. Por que as pessoas entrariam na competição?

Porque é divertido. Lembra de como eu falei que as pessoas que eu gosto de trabalhar misturam trabalho e diversão? Pois é. A foto abaixo mostra o Fábio Lessa e o Ben Barnard num domingo em pleno escritório:

O que é necessário para que este tipo de comportamento aconteça? Do mais importante nós já falamos: pessoas interessadas. A segunda coisa é suporte material. No caso do Fábio e do Ben, a empresa oferece algumas coisas que motivam alguém a ir para o escritório no Domingo aprender uma nova tecnologia:

Um computador decente para cada empregado, neste caso um MacBook Pro trocado há cada dois anos
Chave do escritório para todos os consultores, com acesso ilimitado e sem que seja feitas perguntas sobre “o que diabos você estava fazendo aqui?”
Geladeira cheia de guloseimas, refrigerante, suco, cerveja e demais coisas que fazem mal
Uso de cartão corporativo para pagar coisas como contas no Github, livros e downloads de screencasts
Acesso corporativo às ferramentas necessárias (neste caso uma conta corporativa no iPhone Developer Program)

Mas por que a empresa oferece isso? Porque é boazinha e quer que todo mundo seja feliz? Não exatamente. A ThoughtWorks é uma consultoria, nós fazemos questão de nos diferenciarmos de outras empresas do ramo pela nossa qualidade. O concurso do qual estou falando vai ser decidido por uma banca de juízes. Nesta banca estão as pessoas de vendas da empresa.

A idéia não é apenas que um bando de desenvolvedores se junte e gaste alguns domingos bebendo cerveja de graça e esmurrando o teclado; a idéia é que criemos algo útil. Os times são estimulados a tentar focar em um dos nossos atuais clientes, pensar em um produto que possa ser interessante para os problemas que estes possuem.

A realidade Australiana é, certamente, bem diferente da Brasileira mas isso não quer dizer que algo do tipo não seja viável. Substitua iPads por HTML5 e você tem um programa muito parecido e com custo bem baixo, por exemplo.

E, como no caso da Globo.com, ainda que nada saia destes projetinhos seu papel já foi cumprido. Nós queremos que nossos consultores se interessem cada vez mais por tecnologia. Nós queremos que nossos clientes entendam que somos especialistas em tecnologia.

Nós queremos inovar. Sempre.

Posted in australia, beyondjava, brasil, comunidade, gadgets, gerencia, mac, metodologias, negocios, plataformas, programando, thoughtworks | 11 Comments »

Fazer e Falar

Saturday, May 15th, 2010

Eu sou terrivelmente tímido. Você pode não acreditar dada a facilidade em que eu me meto em pagação de mico, mas esta é a verdade. Eu simplesmente morro de medo de começar uma conversa com uma pessoa que não conheço; o único motivo de fazê-lo com certa naturalidade hoje em dia é porque, apos tantos anos, eu descobri que ou me forço a falar com pessoas ou minha vida não vai para a frente.

A timidez me trouxe muitas coisas ruins mas também moldou meu comportamento de algumas formas que considero benéficas. Uma das conseqüências da timidez é que eu sou bem ruim em convencer os outros de alguma coisa. Isso é horrível em diversos cenários, mas uma coisa boa é que eu aprendi que antes de tentar convencer alguém é melhor ter meus argumentos, provas e protótipos prontos.

E, felizmente, durante a minha vida eu encontrei muitas pessoas com um comportamento parecido –ainda que, na maioria das vezes, não gerado por timidez mas sim por algum outro motivo. Especialmente, eu vi diversas vezes e espero continuar vendo o impacto que um time de “fazedores” tem em uma organização.

O cenário é sempre igual. Determinado lugar, seja um dos meus clientes atuais ou alguma das empresas para quem já trabalhei, possui um grupo de pessoas de alto prestígio dentro de casa. Infelizmente estas pessoas não entregam nada há anos, eles apenas vivem de política. Por algum motivo é formado um time com pessoas que se preocupam mais com fazer do que falar. Este time acaba entregando em uma cadência bem superior do que o melhor dos times antigos. A empresa fica feliz, os gestores resolvem espalhar a “cultura do fazer” (que sempre toma um nome mais buzzwordy como “agile”, “lean”, “times auto-geridos”, “gestão 2.0” ou coisa que o valha).

O problema é que a cultura do fazer não escala muito bem. As pessoas que preferem fazer à falar são chamadas pela diretoria e se pede a eles que ajudem a espalhar a boa nova para toda a organização. Neste ponto, em minha experiência, o time original se divide em dois.

O primeiro grupo é formado por pessoas que vêem na oportunidade um reconhecimento de que, finalmente, atingiram o nível de “ninja” –ou qualquer outro nome saído de algum desenho animado que os desenvolvedores superstar resolvam usar—e sua missão agora é virar alguma espécie de evangelista. Estas pessoas, então, passam a maior parte do seu tempo falando, e quando fazem alguma coisa estão ou trabalhando em algum projeto para reinventar a roda ou atrapalhando a vida de alguém com alguma de suas idéias brilhantes.

O outro grupo até tenta entrar na roda. Eles vão às primeiras reuniões, aos coding dojos e aos outros eventos. Eventualmente eles percebem no que estão entrando. Eles percebem que, se ficarem ali, sua vida mudará. Eles entendem que seu novo cargo não é nem um pouco diferente daquelas antigas “pessoas de alto prestígio dentro da empresa”. Possivelmente eles descobrem que tais pessoas foram, um dia, fazedores. Que estas pessoas foram convertidos de fazedores para peso-morto em um processo parecido com o que se está iniciando.

E então ocorre algum cisma. O primeiro grupo, dos desenvolvedores hax0r-evangelista-superstar-ninja-estrelinha-blogueiro-palestrante-modelo-atriz-manequim fazem da torre de marfim sua nova casa. Os desenvolvedores do segundo grupo voltam para sua caverna e tentam continuar trabalhando em paz.

Eventualmente o grupo dos ninjas começa a contratar pessoas com uma opinião parecida com a sua própria. Em pouco tempo a empresa está tomada por um estilo que um amigo costuma chamar de “awesome, dude!” (em uma voz de americano que acabou de fumar alguma coisa estranha).

Existem alguns benefícios, claro. Os problemas históricos da empresa são, geralmente, trabalhados. O problema é que ao invés de resolver o problema o time awesome está mais interessado em usar as novas ferramentas ninja. Se a ferramenta ninja não possui o necessário para resolver o problema é melhor ainda, eles podem usar suas maravilhosas habilidades awesome para desenvolver o necessário –ainda que isso signifique fazer a organização pagar um custo absurdo para desenvolver infra-estrutura em casa quando existem centenas de alternativas consolidadas e amplamente disponíveis, ainda que não sejam ninja.

Apos algum tempo as coisas começam a ficar engraçadas. O clã dos ninjas perde prazo atrás de prazo, entregando novas rodas ao invés de valor de negócio. Quando a coisa começa a apertar, o clã lança uma bomba de fumaça e some na escuridão; sua fama no meio awesome-ninja-modelo-atriz-manequim já o garantiu um outro emprego de evangelista ou coisa parecida em outro lugar. Todos os filhotes de ninja ficam perdidos. Lideranças alternativas aparecem e guerras internas sobre o que, afinal, significa ser awesome destroem a produtividade. Plataformas são reescritas a cada quinze dias.

De repente, alguém repara que o único time que anda entregando algo é o time daquele povo que fazia parte do grupo de fazedores original mas recusou-se a converter em ninja awesome. Alguém resolve visitar a caverna destas pessoas e descobre o que restou deles lá dentro, no escuro, isolado das ondas de hype. Usando ferramentas e técnicas que fora banida pelos ninjas há muito.

Infelizmente nem todos estão ali, alguns já desistiram e foram para outras organizações. E, nestas organizações, eles vão eventualmente encontrar outro grupo de fazedores. E vão entregar software de qualidade e no prazo. E vão ser chamados pela gerencia para espalhar a boa nova pela empresa. E o ciclo se repete.

Posted in artigos, brasil, comunidade, gerencia, metodologias, negocios | 39 Comments »

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 »

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 »

ThoughtWorks Brasil – Perguntas Frequentes

Monday, June 8th, 2009

O Martin foi o primeiro a falar abertamente sobre o assunto. Desde a mensagem dele eu recebi quase duas dezenas de e-mails com dúvidas e ao invés de responder um a um com o mesmo conteúdo resolvi colocar aqui.

Note que este blog não representa em hipótese alguma a ThoughtWorks, estou apenas compartilhando informação que já é publicável mas talvez nunca tenha sido disponibilizada, ao menos em Português.

Cuma?

A ThoughtWorks é uma empresa global com escritórios em diversos continentes. É uma das pioneiras em metodologias ágeis e berço de diversas técnicas e tecnologias que você certamente já ouviu falar.

Há muito tempo se cogita abrir um escritório no Brasil. O Roy já esteve no país e todas as vezes que o encontrei ele fala sobre o assunto. Nos últimos meses vêm ficando óbvia a necessidade de abrir um escritório na America do Sul, tanto para suprir a demanda de off-shore quanto para explorar o mercado local, e o Brasil é o favorito para sediar este escritório.

Neste momento estamos estudando a possibilidade como um todo. Nos próximos meses diversos ThoughtWorkers, entre brasileiros e gringos, estarão no país para trocar idéias com pessoas do mercado local e conhecer as possibilidades.

Então você vai voltar para o Brasil?

Não está nos meus planos uma volta definitiva mas eu estou ajudando a iniciativa. Como falei antes aqui, este mês eu não pude ir mas estou ajudando aos que vão à marcar conversas com empresas e pessoas interessantes.

Até Agosto eu acho muito difícil conseguir deixar a Austrália devido ao meu projeto atual.

Você foi para a ThoughtWorks com este objetivo?

Não. Como falei acima eu sabia do interesse mas nem fui contratado com esta finalidade nem tinha isto como objetivo próprio.

Como vai ser o escritório local?

Não sabemos ainda, vai depender de nossos estudos de viabilidade.

Como eu me candidato?

No mesmo lugar de sempre. O Brasil não vai estar listado ainda mas o endereço é um só.

Posted in australia, brasil, comunidade, negocios, pessoal, thoughtworks | 2 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 | 10 Comments »

Festa Retardatária

Wednesday, September 24th, 2008

Em 2003 eu liguei para o escritório da ImproveIT e falei com o Vinicius Telles. Ele certamente não se lembra disso. Perguntei sobre os cursos da empresa em XP, datas e preços. O que o Vinicius me falou na ocasião foi que não havia muita demanda para este tipo de curso e que por isso eles eram oferecidos muito esporadicamente ou apenas para empresas em turmas fechadas. Como eu falei que possuía um pequeno time e um orçamento de tamanho semelhante ele sugeriu que eu comprasse alguns livros e usasse listas de discussão.

Se eu precisasse de algo semelhante no Brasil hoje, não teria este problema. Não este, ao menos. O meu maior problema seria encontrar, no meio do mar de ofertas, quem contratar.

Apesar de estar relativamente afastado da comunidade brasileira –o que pode ser percebido pela falta de atualizações freqüentes aqui- eu acompanho listas e fóruns e pude ver como as coisas mudaram nos últimos meses. Listas de discussão sobre métodos ágeis foram invadidas por ofertas de treinamentos, cursos, coaching e mentoring. Algumas listas que eram bem interessantes viraram apenas um veículo para a divulgação de serviços.

E como aferir as credenciais dos prestadores de serviço? Boa pergunta. Algumas desta pessoas, segundo meu histórico do Gmail, estavam oferecendo cursos de levantamento de requisitos no melhor estilo waterfall há alguns meses. Outros possuem treinamentos cujo programa é apenas uma xerox do Certified Scrum Máster –se o treinamento de SCM original já possui valor real muito baixo imagina quando o mesmo conteúdo é ministrado por alguém que não possui a experiÊncia habitual dos CST.

Outros dizem que já trabalharam para 50,60…100 empresas com metodologias ágeis. Estes são meus favoritos. Supondo que o sujeito tenho começado a trabalhar com metodologias ágeis em 2001 -quando o Agile Manifesto foi assinado- e já passou em 50 empresas, ele teria passado apenas um mês em cada empresa, na média. Além do fato de que eu duvido que estes pratiquem técnicas ágeis desde 2001, em minha vida eu vi poucos projetos de apenas um mês que tenham sido relevância para o currículo de alguém. Como previsto, os agilistas retardatários estão em todo lugar, cuidado.

Existe um trecho do Phillip Krutchen no seu livro de RUP que eu acho que se aplica com perfeição para algumas coisas que eu tenho visto por aí:

A Major Misconception

Although the four phases of a RUP project (Inception, Elaboration, Construction, and Transition) are run sequentially, remember at all times that the RUP lifecycle is fundamentally iterative and risk-driven. There is a big misconception that we would like to push aside very early in our discussion: The various phases are not simply a renaming (to sound fancy or different) of the classical phases of a waterfall process. From practitioners making their first acquaintance with the RUP, we have frequently heard, “Oh, I get it! In Inception you do all the requirements, in Elaboration you do the high-level design, in Construction you write the code, and you finish the testing in Transition.”

In trying to match the RUP to their current practice, they completely miss the point of iterative development. Yes, in the early weeks or months of a project the emphasis is very likely to be more on requirements and during the final weeks or months to be more on testing and polishing. This change in focus across the lifecycle is precisely what is hinted at by the “humps” on the lifecycle iteration graph (see Figure 1.3); the height of the humps varies across the cycle. But inside each phase, you plan iterations (see how in Chapter 12), and each of these iterations includes many of the software development activities to produce tested code as an internal—and later external—release.

Muitas das pessoas que hoje oferecem serviços em métodos ágeis foram exatamente as mesmas pessoas que criaram toda a confusão sobre fases no RUP. Substituindo iterative por agile (que egloba desenvolvimento iterativo) em “In trying to match the RUP to their current practice, they completely miss the point of iterative development” vai ter exatamente o cenário atual.

Um exemplo disto é a forma como alumas pessoas tentam transformar XP em algo mítico e irreal. Em discussões recentes eu vi gente taxando o XP como inferior à coisas como Scrum porque ele “visão de negócios” ou “focada em engenharia”. Mas heim?

A parte da “engenharia” é engraçada. XP é uma metodologia para desenvolvimento de software e como de se esperar ela possui praticas que estão ligadas com… er… desenvolvimento de software!

E a paixão pelo Scrum é algo fantástico. Uma busca por “Scrum framework” no meu Gmail traz milhares de emails de listas de discussão. As pessoas adoram Scrum porque é um “framework para processo”. Muito flexível, muito pratico e te deixa adotar suas praticas de engenharia favoritas. O Scrum pode ser extremamente formal ou informal.

Uhm… onde é que eu vi isso antes?

The RUP is also a process product that provides you with a customizable process framework for software engineering. You can configure the RUP product to support small or large teams and disciplined or less-formal approaches to development. It also allows you to add your own best practices and to share experiences and artifacts with peers and experts.

O que talvez muita gente não perceba é que há sempre um jogo de compensação em metodologias ágeis. Os valores definidos no Manifesto Ágil não são facilmente atingíveis e as praticas do XP são uma forma (não necessariamente melhor ou pior) de atingi-los. Obviamente você consegue atingir os valores através de praticas diferentes mas o que eu vejo é a maioria das pessoas usando as mesmas praticas que já usavam antes, talvez com cartões ao invés de documentos Word, e esperando que seja diferente do passado.

Misturar praticas é algo sadio quando feito por alguém que entende como estas se relacionam, mas a maioria das pessoas apenas está jogando as que não entendem ou são difíceis de vender. Eu já estive em diversas empresas brasileiras onde “ágil” significava colocar cartões na parede e ficar em pé meia hora todo dia de manhã.

Mas o que eu quero dizer, que você não deve contratar pessoas para ajudar sua empresa a adotar método ágeis? De jeito nenhum. Apesar de não prestar serviços no mercado brasileiro meu trabalho consiste exatamente nisso, seria bem estranho eu advogar contra. Este texto é apenas um desabafo e um alerta.

Um alerta porque através de amigos e colegas eu já estou vendo muitas empresas jogando dinheiro fora com treinamento, consultoria e mentoring sendo prestados por pessoas que possuem pouca ou nenhuma experiência a mais que os próprios alunos.

Desabafo porque acho que finalmente entendi porque a ImproveIT saiu do mercado de consultoria e coaching.

Posted in brasil, comunidade, gerencia, metodologias, negocios | 13 Comments »

A Completa Irrelevância do Certified Scrum Master

Tuesday, May 27th, 2008

Semana passada o Richard Durnall me chamou para assistir a uma aula que ele deu na University of Melbourne. O Rich é o guru local de Lean e é uma figura.

A aula foi interessante. O curso é o mestrado em alguma das 343.435 ramificações de Tecnologia da Informação, basicamente uma escolinha para CIO-wannabe. Para se ter uma idéia todas as perguntas da sessão foram sobre implantação de ERPs, você via claramente que nenhum dos estudantes tinha a mínima vivencia na indústria e acreditavam piamente nas suas Info Corporate da vida.

A matéria era sobre comparação de metodologias e o Rich não foi o único. Antes dele apresentou um senhor, que é professor da instituição e arquiteto do maior banco da Austrália, onde inclusive tenho conta (brr…). A palestra do senhor arquiteto foi sobre como ele participou da salvação de um projeto de data mining usando o bom e velho waterfall. O único ponto diferente de uma lição clássica sobre como não fazer software foi sobre o uso de técnicas de Six Sigma para avaliação e priorização dos requisitos.

Quando chegou a vez do Rich apresentar Agile/Lean foi um contraste enorme. Na sessão de perguntas:

- Você falou sobre estes métodos ágeis e sobre como eles…er.. não ligam para requisitos. O [cara defendendo waterfall] apresentou um caso real de um grande banco. Você realmente acha que as técnicas de algo como agile podem competir com Six Sigma? [nota: uh?]
- Então, na minha apresentação eu fui bem ralo e essa é uma palestra introdutória, então foi bom você perguntar isso. Eu trabalhei na [top 5 montadora de automóveis], na [maior empresa aérea do mundo] e em alguns bancos. Nas duas primeiras empresas eu fiz parte da implantação de Six Sigma, inclusive eu sou Black Belt. O que eu vi deste processo foi [...] e por isso que agile/lean é uma boa escolha.

Agora pense que em vez de “Six Sigma Black Belt” ele tivesse dito algo como “inclusive eu sou Agile Software Specialist e os problemas de Six Sigma são [...]“. Teria o mesmo efeito?

Outro caso recente e interessante foi no Australian Architecture Fórum em Sydney. O Halvard estava apresentando uma palestra extremamente interessante sobre governança de projetos SOA onde a única ferramenta é um wiki. Em algum momento alguém levanta:

- Ok, ok, isso aí é muito Web 2.0, muito legal mas não é aplicável no meu cenário.
- E qual seu cenário?
- Eu trabalho em um banco, faço parte do grupo de controle de serviços de segurança. Isso de REST, wiki é muito legal mas vocês não entrariam num banco de modo algum!
- Uhm.. interessante você falar disso porque segurança em serviços é uma das minhas áreas de estudo… eu concluí meu Ph. D. em SOA na Universidade de Sydney e meu foco é exatamente segurança. Na verdade, na ThoughtWorks a maioria dos clientes são bancos e, inclusive, tivemos hoje de manhã o arquiteto principal do banco [top 5 banco australiano] falando exatamente sobre como usaram este tipo de técnica para governança num projeto que participei.

Imagine que ele tivesse falado “Eu sou um Wiki Certified Contributor e um RESTafarian Official Gold Partner”. Teria o mesmo efeito?

Por que das historinhas? Para argumentar numa discussão que eu tive com o grande Juan Bernabó sobre a total e completa ausência d sentido em algo como Certified Scrum Master. O Juan argumentou que certificações são valorizadas -e requeridas- pelas empresas. Meus pontos são:

Eu não conheço nenhuma pessoa que acredite que um curso de dois dias, sem sequer uma avaliação final –pagou, passou na pratica- deva ser valorizada. Se nós sabemos que a certificação não tem valor por que a venderíamos de outra forma? Agile não é sobre trazer valor e melhorar praticas?
O mercado também quer porque quer e acha que precisa de cronogramas detalhados, requisitos esmiuçados e projetos que terminam em uma grande fase de testes. Nós sabemos que isso não traz valor não fazemos apologia a este tipo de coisa, por que com certificação seria diferente? Por que ao invés de combater a ineficiência e a busca por respostas fáceis nós criamos e glorificamos nossos próprios selos?
Uma certificação emitida por si mesmo não vale nada. A menos que alguém já acredite que Scrum traz algum valor essa certificação é como acreditar que o Inri Cristo é Jesus porque ele afirma o ser.

Em resumo, eu acho o curso que é dado com o CSM ótimo. Ele abre mentes e é uma fantástica introdução. E só. O certificado emitido por este curso não tem qualquer valor real e propagandear o contrario, ajudando empresas a continuar glorificando certificações sem sentido, vai contra a primeira linha do Manifesto Ágil:

We are uncovering better ways of developing
software by doing it and helping others do it.

O debate completo está aqui.

Posted in australia, comunidade, eventos, gerencia, metodologias, negocios, thoughtworks | 20 Comments »

Fragmental