Skip to content

Rugby pedindo espaço

Para os que acompanham este humilde espaço virtual, queria deixar aqui um convite ou mesmo uma dica de um esporte que vem se destacando na mídia, ainda mais com a conquista do Brasil para sediar as Olimpíadas de 2016.

O Rugby para aqueles que tiram um tempo para conhecer, acaba conquistando suas atenções pela dinâmica do jogo e também por toda a mística existente dentro e fora do campo. Apesar de ser um esporte de alto contato, fora das quatro linhas ele tem como objetivo a integração de seus participantes, fomentando um espírito coletivo diferenciado dos esportes que estamos acostumados a acompanhar.

Atualmente estou participando de uma equipe gaúcha de Rugby: Novo Hamburgo Rugby Clube.

Para os interessados no assunto sugiro que acompanhem o blog do Terceiro Tempo disponível no portal ClicRBS. O espaço mantém atualizadas as notícias referentes ao esporte no estado.

Esse post é algo breve, mas espero estar divulgando ainda mais o esporte por aqui.

Posted in Geral.

By Lucashgt
04/02/2010

No comments

Gerando aplicação com VRaptor3 usando Maven

Algum tempo sem atualizar as coisas por aqui, resolvi tirar um tempo para me atualizar no framework que acompanho já faz algum tempo, VRAPTOR.

Ultimamente tenho utilizado o Maven para controlar as dependências de Jar’s das aplicações que trabalho, e tem me ajudado bastante. Então resolvi tirar um tempo para gerar um POM para o VRaptor, já que na estrutura original dele esse arquivo não o acompanha.

Utilizei o Eclipse com suporte ao Maven para gerar o projeto após ter gerado o POM do VRaptor.

Alguns passos para se ter sucesso na criação da estrutura:

1º – Faça o download do Vraptor e coloque o seu jar numa pasta qualquer.

2º – Instale o Maven ou utilize o recurso que está disponível em sua IDE.

3º – Execute o comando abaixo:

mvn install:install-file -DgroupId=br.com.caelum -DartifactId=vraptor -Dpackaging=jar -Dversion=3.0.0-SNAPSHOT -Dfile=LOCAL_ONDE_ESTA\vraptor3-3.0.0-SNAPSHOT.jar -DgeneratePom=true

4º – Edite o pom.xml do VRaptor que deve estar no repositório local [$USER_HOME\.m2\Repository\br\com\caelum\vraptor] com o seguinte conteúdo:



<?xml version="1.0" encoding="UTF-8"?>
<project 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd" 
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <modelVersion>4.0.0</modelVersion>
  <groupId>br.com.caelum</groupId>
  <artifactId>vraptor</artifactId>
  <version>3.0.0-SNAPSHOT</version>
  <description>POM was created from install:install-file</description>

  <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring</artifactId>
            <version>2.5.5</version>
        </dependency>

        <dependency>
            <groupId>com.thoughtworks.paranamer</groupId>
            <artifactId>paranamer</artifactId>
            <version>1.3</version>
        </dependency> 

        <dependency>
            <groupId>org.objenesis</groupId>
            <artifactId>objenesis</artifactId>
            <version>1.1</version>
        </dependency>

        <dependency>
            <groupId>com.google.code.google-collections</groupId>
            <artifactId>google-collect</artifactId>
            <version>snapshot-20080530</version>
        </dependency>

        <dependency>
            <groupId>org.aspectj</groupId>
            <artifactId>aspectjrt</artifactId>
            <version>1.6.0</version>
        </dependency>   
        
        <dependency>
            <groupId>cglib</groupId>
            <artifactId>cglib-nodep</artifactId>
            <version>2.2</version>
        </dependency>

        <dependency>
          <groupId>commons-fileupload</groupId>
          <artifactId>commons-fileupload</artifactId>
          <version>1.1</version>
          <exclusions>
                <exclusion>
                  <groupId>commons-io</groupId>
                  <artifactId>commons-io</artifactId>
                </exclusion>
          </exclusions>
        </dependency> 
        
        <dependency>
          <groupId>org.apache.commons</groupId>
          <artifactId>commons-io</artifactId>
          <version>1.3.2</version>
        </dependency>

        <dependency>
          <groupId>javassist</groupId>
          <artifactId>javassist</artifactId>
          <version>3.8.0.GA</version>
        </dependency>
        
        <dependency>
          <groupId>javax.servlet</groupId>
          <artifactId>jstl</artifactId>
          <version>1.1.2</version>
        </dependency> 

        <dependency>
          <groupId>log4j</groupId>
          <artifactId>log4j</artifactId>
          <version>1.2.12</version>
        </dependency>

        <dependency>
          <groupId>net.vidageek</groupId>
          <artifactId>mirror</artifactId>
          <version>1.5.1</version>
        </dependency>

        <dependency>
          <groupId>ognl</groupId>
          <artifactId>ognl</artifactId>
          <version>2.7.3</version>
          <exclusions>
                <exclusion>
                        <groupId>jboss</groupId>
                        <artifactId>javassist</artifactId>
                </exclusion>
          </exclusions>
        </dependency> 

        <dependency>
          <groupId>org.slf4j</groupId>
          <artifactId>slf4j-api</artifactId>
          <version>1.5.6</version>
        </dependency>
        
        <dependency>
          <groupId>org.slf4j</groupId>
          <artifactId>slf4j-log4j12</artifactId>
          <version>1.5.6</version>
        </dependency> 
        
  </dependencies> 

</project>

5º – Crie um projeto Maven.

6º – Edite o pom.xml do mesmo com o seguinte conteúdo:



<project xmlns="http://maven.apache.org/POM/4.0.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>GERALMENTE_ESTRUTURA_DO_PACKAGE</groupId>
  <artifactId>ARTIFACT_ID_QUE_DESEJAR</artifactId>
  <packaging>war</packaging>
  <name>NOME_QUE_DESEJAR</name>
  <version>0.0.1-SNAPSHOT</version>
  
  <dependencies>
          <dependency>
                  <groupId>br.com.caelum</groupId>
                  <artifactId>vraptor</artifactId>
                  <version>3.0.0-SNAPSHOT</version>  
          </dependency>
  </dependencies> 
  
</project>

7º – Clique com botão direito, opção Maven, update dependecies

Pronto, libs adicionadas ao projeto, tudo organizado para iniciar as atividades.

Post simples e direto. Dúvidas que surgirem, por favor comentem.

Posted in Code, VRaptor.

By Lucashgt
16/10/2009

3 comments

Produto ou cliente?

O que é mais importante: Produto ou Cliente?

Talvez para uma grande parte das pessoas que atuam no desenvolvimento de software o mais importante possa ser o produto. Sua concepção, estrutura (arquitetura), design e tudo mais que esteja vinculado ao mesmo. Existe também aqueles que buscam no desenvolvimento do produto a satisfação pessoal, onde cada pattern aplicado lhe proporciona momentos de satisfação, orgulho. Por um lado isso é muito bom, pois a qualidade interna do produto tende a ser muito boa, porém, a peça fundamental na construção desse produto está fora do computador, sim acredite. O Cliente é o objetivo final, é ele quem tem que se satisfazer ao “botar o olho” no produto e ter a sensação de que suas necessidades foram atendidas.

Estamos num processo de transição na área de desenvolvimento de software, onde não basta mais ser um bom programador, ter sua visão apenas no código ou estrutura da aplicação. É essencial que nós profissionais da computação temos o dever de buscar entender melhor o contexto do cliente, saber se comunicar de forma clara e coesa. Para isso é necessário mergulhar no dia-a-dia do cliente (interno ou externo), buscar fazer uso da mesma linguagem utilizadas por eles, facilitando entendimento do domínio.

Ferramentas de testes e design de código hoje fazem uso desse pensamento. Um exemplo disso é o Concordion utilizado para desenvolvimento de testes de aceitação.

O objetivo desse post é apenas para propiciar um momento de reflexão, de nada adianta nos escondermos no desenvolvimento de código, temos que colocar a cara para fora e buscar uma melhor comunicação e entendimento da real necessidade do cliente, pois no final, é ele quem vai dizer se o produto está ok ou não.

Posted in Geral, Workplace.

By Lucashgt
05/09/2009

2 comments

Apresentação Lean e Kanban – FTEC Caxias do Sul

Estive ontem a noite em Caxias do Sul na Semana acadêmica da FTEC em conjunto com meu colega de trabalho Eduardo Bobsin, fazendo uma apresentação sobre Lean Sofware Development e Kanban.

Tivemos um atraso em virtude do trânsito entre Porto Alegre até Caxias, mas no final foi tudo tranquilo.

Gostaria de deixar aqui o meu agradecimento para Profª Neiva Kuyven e o Profº Thiarlei Macedo, pela oportunidade de estarmos presentes no evento e quem sabe contribuindo um pouco mais no conhecimento das pessoas que estavam presentes.

Estou disponibilizando também a apresentação utilizada durante o evento.

Lean Kanban

Posted in Workplace.

By Lucashgt
16/06/2009

No comments

Crack nem pensar!!

Aproveitando o espaço, vou tomar parte na luta contra esse mal que assola várias pessoas.

Somos livres para viver, a morte é algo que nos persegue todos os dias, então, aproveite a vida e não acelere o próprio fim.

Posted in Geral, Pensamento.

By Lucashgt
05/06/2009

No comments

Começando com agile – organizando a equipe

Continuando o post anterior sobre “Começando com agile”…  Acredito que a principal barreira a ser vencida é a cultura predominante no ambiente em que está inserido. Realizar mudanças em ambientes que já possuem um tempo vida é algo extremamente complicado, para entender um pouco melhor sugiro a leitura do post do blog Java Anywhere, muito válida a contribuição deles com relação ao assunto.

Quando penso em equipe, vejo todos os envolvidos, desenvolvedores, cliente, analistas de negócios (caso existam), testadores. O ponto chave no meu ver está numa primeira conversa, onde se alinham os objetivos e tenta-se ao máximo passar a importância de cada um com relação a construção da solução.

Temos noção dos julgamentos que nos cercam, como por exemplo:

- “Quem desenvolve uma rotina, não pode testar a mesma”;

- “Pede para o estagiário testar”;

- “Cliente é muito chato e não sabe o que quer”;

- “Testador não sabe nada de programação, então eles ficam achando problema onde não têm. Por que raios ele está reclamando do label que está 1px fora do alinhamento”;

- “Analista é o cara que não tem noção de programação, por isso dos requisitos malucos que são passados para o desenvolvimento”;

Ou seja, os itens acima são exemplos que escuto e escutei durante esses 10 anos que atuo com desenvolvimento. São detalhes que perpetuam pelos anos, impedindo que as pessoas tenham uma visão menos preconceituosa e que tentem enxergar uma forma de tirar o melhor de cada um.

Corte o mal pela raiz – busque formas diferenciadas para mostrar o valor que cada um tem no projeto, realize de início workshops, pedindo para que cada um traga assuntos relacionados a sua atividade, permitindo dessa forma, que todos saibam o que cada um faz no todo.

Pair Programing – se possível tente verificar o nível técnico da equipe, assim fica mais fácil de organizar essa atividade. Tenho tido bons resultados, principalmente no que diz respeito a percepção da produtividade e melhoria de código. Se praticado em conjunto com TDD, o benefício é ainda maior, pois os testes desenvolvidos passam pelo crivo de duas pessoas. Também é interessante usar o seguinte par: Desenvolvedor e Testador, assim, ambos vão entendendo e possivelmente melhorando a atividade de um e do outro.

Ambiente – procure unir a equipe, proporcionando um espaço de fácil comunicação e acesso. O contato humano não pode ser substituído por messenger ou coisas do tipo, sendo que as pessoas estão uma do lado da outra. Incentive a troca de idéias, discussões, tenta quebrar o máximo possível da timidez dos envolvidos, a comunicação é vital para a execução do projeto e também das atividades. Um quadro sempre é bem vindo, além de exercitar a caligrafia, ajuda a esboçar as idéias e também as definições de forma claro e dinâmica.

Atitude – uma equipe joga junto, estrelismo, jogador herói ou todo poderoso Darth Vader (aquele cara que sabe pra caramba, mas só coopera com base na porrada na equipe) não tendem a ajudar muito. Use de relações, por exemplo: futebol é coletivo, escanteio é todo mundo na área (não levem ao pé da letra), basquete, é cooperação extrema, não há momento para indignação em meio ao jogo, todos sabem que não podem deixar o adversário chegar no garrafão, futebol americano é outro exemplo e poderiam ser usados muitos outros. Em suma, trabalhe o espírito de equipe, incentive a cooperação e compartilhamento de conhecimento para fortalecer ainda mais o todo.

Momento para lavar a roupa suja – sim, a cobrança tem que ser percebida por todos e realizada por todos, porém, no momento certo. Reuniões diárias, reuniões de finalização de etapas do projeto ou mesmo reuniões de última hora, todas servem para todos colocar a mão na consciência e pensar se a atitude perante a equipe está correta, se pode melhorar  ou se está péssima. Aqui fica um ponto para o pensamento individual, todos na vida somos cobrados e temos que a cada dia trabalhar esse ponto que é chato. Ninguém gosta de ser cobrado ou criticado, mas numa equipe a cobrança é com o ser profissional, as atitudes que possam vir a prejudicar o andamento da equipe é que são os pontos de cobrança e não o “eu” da pessoa, todos lutam por um mesmo objetivo, isso faz com que cada um repense a cada momento se o objetivo continua o mesmo ou se acabou tomando o caminho contrário. No blog Débito Técnico tem um post descrevendo sobre reunião diário e cobrança, muito bem escrito pelo Rodrigo.

Melhoria contínua – leia, pratique, compartilhe e veja o que pode ser melhorado.

Posted in Geral, Workplace.

By Lucashgt
22/05/2009

No comments

Começando com agile

Para aqueles que pretendem iniciar com Agile. Vou usar o termo Agile mesmo, pois não vou descrever algo que se defina como sendo um Scrum ou seja mesmo o XP, pretendo somente mostrar alguns passos que podem futuramente levar o interessado a aprofundar seus estudos e práticas para qualquer uma das definições existentes dentro das metodologias ágeis.

A tempo venho refletindo em como ajudar a iniciar o processo de adoção de práticas existentes dentro das metodologias ágeis, a fim de, usar como “referência” nas conversas com amigos, colegas e até mesmo, pessoas que estejam interessadas, porém, não sabem por onde começar.

O início – Por quê preciso disto?

Antes de qualquer atitude a ser tomada, se questione do por que da necessidade. Tente entender os reais motivos para adotar essas novas práticas no dia a dia. Para isso, sugiro que revise qual é o negócio da empresa, o que realmente é produzido pela mesma, qual seria o possível retorno desse investimento, quais os impactos que essa mudança pode causar, se está preparado para as consequências e principalmente, qual o fator motivador que será repassado para todos os envolvidos, pois a magia está totalmente ligada a eles.

Tenha uma coisa em mente, são os envolvidos que farão tudo dar certo, mas cabe a você motivá-los, mostrar o caminho das pedras e se possível, ajudar a remover muitas delas durante o percurso.

Outro ponto importante, todos estão aptos a inverter a pirâmide, servir ao invés de mandar/delegar/controlar? Todos tem noção da importância do envolvimento de cada um? Parece idiota, mas esse é o pensamento. Mandar é fácil, qualquer problema ocorrido tem em quem jogar suas desculpas, agora se empenhar junto com o colega é algo bem diferente, muitas vezes assumir que o conhecimento técnico não é seu forte pode te fazer menor, mas em um ambiente colaborativo, que luta por um mesmo objetivo, esse ponto é o de menor importância.

Tenho para mim que Agile está muito além de uma forma diferente de pensar/agir, traz para todos um sentido humano e o detalhe principal, que todos tem capacidade (com muito empenho) de produzir e crescer junto a equipe.

Leia, busque renovar o conhecimento, discuta, mude o ambiente para que todos possam participar expondo suas idéias, sem o sentimento de que serão coibidos, são estes os momentos de ganho dentro da equipe, por nada a retrospectiva é algo essencial dentro do Scrum, assim como as reuniões diárias. Acredito que isso já serva como um dos “por quê” do início.

A mudança é essencial e não pode ser deixada de lado.

A execução – Mas como? Será que dá?

Verificados os detalhes do início, tenta observar a rotina de trabalho da equipe. Se você está inserido nela, se retire por um momento (dias) e verifique como as coisas acontecem. Tente entender onde está o ponto chave do problema (se existir um, é claro). Geralmente quando estamos na “roda viva” é quase que impossível pensar de que forma mudar, porém, sabe-se que está tudo errado e que algo precisa ser feito. Frases do tipo: “bom, depois da correção X nós vamos parar para arrumar a casa!” ou “o dia de hoje foi uma correria, amanhã eu vou parar para ver o que podemos fazer!” o problema é que o amanhã nunca chega, pelo contrário, ele já passou faz tempo.

Dica, se o ambiente possui várias entradas para as demandas (telefone, e-mail, conversa com o “pensante” do produto, bug tracking, wiki), solucione logo adotando uma forma central de recebimento das mesmas. Dessa forma se conseguirá dar uma classificação para cada uma, caminhos podem ser definidos mais facilmente e de forma coesa. Se todos atendem a tudo, tente ao menos verificar uma forma organizada de atendimento/execução.

Para isso, aplicações como Redmine, Jira, Trac podem auxiliar muito bem. Se possível, defina um workflow para os tipos de chamados que serão atendidos, assim, fica mais fácil de definir as etapas pelo qual o atendimento irá passar até a sua finalização. (Veja, já podes começar a entender aqui um pouco de Product Backlog, kanban)

Para os envolvidos com a programação, os tempos mudaram, as linguagens evoluíram, assim como os ambientes de desenvolvimento também evoluíram, proporcionando o uso de práticas até então não utilizadas (me desculpem aqueles que discordam) como o desenvolvimento orientado a testes ou mesmo o desenvolvimento de testes unitários, programação em par para dar ritmo a equipe e também para compartilhar conhecimento, sessões técnicas para diminuir o débito técnico e também encorajar todos a falar e trocar idéias sobre o assunto.

Os resultados são bons, se o coach (mentor, motivador) estiver junto fazendo seu papel e a equipe estiver comprometida com a causa os resultados tendem a melhorar a cada dia. A disciplina no uso da aplicação ou execução da tarefa de organização das atividades deve ser seguida, ela será o radiador do andamento da equipe, é a partir desse ponto que as melhorias com relação a execução serão realizadas a cada dia também.

Ou seja, existe uma forma, essa foi a que participei e hoje já estou em um ambiente diferente, melhorado e buscando aperfeiçoar cada vez mais.

Saiba envolver a todos, mostre o valor que cada um tem perante a todos e principalmente, o objetivo final é o produto com qualidade, ambiente tranquilo e crescimento pessoal (de cada um).

A melhoria – E agora, para onde vou?

Deixe passar um bom tempo, analise diariamente o ambiente, faça uso das retrospectivas para identificar os pontos fortes e fracos da equipe (se inclua nela, você não é diferente deles). Verifique melhorias e tente ajudar a executá-las.

Quando estiver seguro ou sentir que é possível adotar um Scrum, mãos a obra. Como dito no início, deixe todos os envolvidos a par do que está acontecendo e para onde estão indo, trabalhando de forma transparente é mais fácil obter o comprometimento de todos.

Aprofunde os estudos na prática que irá adotar, busque na internet ou qualquer outro meio informações a respeito, tente encontrar cases, ou pessoas tente conhecer pessoas que fizeram uso, para ter uma visão de como as coisas aconteceram nesses outros ambientes.

Mantenha os pés no chão, não invente e faça de maneira simples. Acredito que essas dicas possam servir para um bom início na adoção de Agile.

Posted in Geral, Pensamento, Workplace.

By Lucashgt
20/05/2009

No comments

Metodologia Ágil no ensino superior – Reflexão no Agile Weekend 2009

Bom pessoal, estive nos dias 25/04 e 26/04 no Agile Weekend. O evento foi o maior sucesso, vários cases, palestras a respeito de adoção de metodologias ágeis no mais diversos ambientes e também relatos do pessoal que estavam presentes na platéia, dinâmicas bem elaboradas e muita informação.

Todas as palestras foram interessantes, inclusive serão disponibilizadas no site do evento e também do grupo de usuários as apresentações assim como os videos, porém, queria dedicar esse post a um assunto um tanto quanto interessante que ocorreu no evento: Metodologias Ágeis no ensino superior.

Discutimos um bom tempo sobre o assunto, a quantidade de pessoas presentes na sessão aberta coordenada pelo Daniel Wildt não foi tão expressiva, pois no mesmo tempo estavam ocorrendo duas outras interessantes palestras, mas o que interessa é que há o interesse por parte das pessoas envolvidas com métodos ágeis para que o assunto tome forma também dentro das universidades.

Durante a conversa se pode levantar vários pontos, desde uma avaliação da grade curricular até a formação de grupos de estudos. Este último acredito ser de aplicabilidade imediata, pois todos sabemos do interesse da academia em grupos de estudos dentro da instituição.

Eu particularmente citei a importância da iniciativa por parte dos professores em abordar os assuntos relacionados ao agile, porém, também foi citada a iniciativa por parte dos alunos. Então, a partir dessa colocação refleti a respeito e vejo que esse pode ser um caminho efetivo para transformar esse anseio em realidade, buscar junto a universidade um espaço para práticas e estudos dos assuntos envolvidos com Agile.

Vale salientar que não se deve deixar de aprender o conhecimento transmitido ainda hoje, é a base para que possamos fundamentar nossas idéias e também conhecimento, nos permitindo refletir sobre tudo que surge no mercado no decorrer do tempo de forma crítica para daqui a pouco validar a usabilidade do mesmo ou não (lembre-se opinião pode variar de pessoa para pessoa).

Não vejo Agile como modismo e também como a bala de prata, mas os resultados apresentados pelas empresas durante o evento e outros relatos que tenho acompanhado me fazem estudar e aplicar ainda mais o mesmo. Atualmente estou em uma empresa que adotou as metodologias ágeis e também, os resultados estão sendo bastante satisfatórios.

Em conversas durante o coffee brake relatei que o incentivo sobre o assunto tinha que se acentuar mais nas regiões distantes das metrópoles, onde se concentra a maior parte dos eventos. Com base nisso, acredito que a iniciativa por wokshops e eventos podem surgir mais facilmente caso as universidade possuam ao menos um grupo de estudo envolvido com o assunto, apenas uma idéia clara que tenho até o momento.

Fica aqui então a sugestão para aqueles que tem abertura dentro das universidades ou até mesmo alunos que passam por aqui para dar uma olhada o incentivo a todos para formação de grupos de estudos.

Posted in Code, Geral, Workplace.

By Lucashgt
27/04/2009

2 comments

Dica de leitura

Para aqueles que por aqui passam, fica aí uma dica de leitura.

Posted in Code, Geral.

By Lucashgt
24/04/2009

No comments

Motivação

Já faz algum tempo que venho dedicando minhas leituras e meus anseios para as Metodologias Ágeis. Atualmente estou trabalhando em uma empresa que vem se dedicando a adoção dessas Metodologias, e sinceramente, estou muito empolgado.

Não pretendo descrever algo técnico de momento, mas sim, abordar um tema que tenho percebido ser de fundamental importância, não somente para as Metodologias Ágeis darem certo, mas qualquer coisa que se faça junto a equipe ou empresa, MOTIVAÇÃO!

Quem já não passou por uma equipe desmotivada, ou pior, não se sentiu motivado dentro de uma equipe ou empresa. Atuo fazem 9 anos com TI, já tive meus momentos de alegria, empolgação, desânimo, descrença, entre outros (sejam bons sentimentos ou não)… Mas o principal, passado um tempo, pude perceber que nossa vida não se limita a um teclado e monitor, pelo contrário, se deres uma olhada para o lado, vais ver que tem um colega, que pode te ajudar a melhorar ainda mais, ou mesmo, que esteja precisando de um pouco mais de conhecimento.

É justamente nessa hora, com essa pequena percepção que os melhores aprendizados virão, não é a toa que o XP incentiva a pogramação em pares, que o Scrum nos coloca em meio a retrospectivas, reuniões diárias. SIM, precisamos nos comunicar, saber se expressar, fazermos uso das nossas mãos para gesticular e não apenas teclar… Benefícios que podemos ter? Vários!!! Passamos a nos conhecer como pessoas, sabermos que uma crítica (construtiva) do código desenvolvido para o produto (não para mim ou para quem fez) pode melhorar a imagem de todos, que um conhecimento compartilhado pode evitar brigas diversas (principalmente a de Ego)…

E o mais interessante, agora sim com relação direta as Metodologias Ágeis, foram alguns “Senhores” que nos mostraram isso, e continuam a nos incentivar a cada dia que passa.

Talvez o impedimento disso ainda seja aquela sequela de 1º e 2º , onde ter dúvida ou tentar compartilhar conhecimento era motivo de risadas e pegação de pé, mas tranquilo, ainda bem que temos a oportunidade de crescer e aprender.

Então, tu te achas motivado? Ou melhor, o que te motivas a acordar cedo e ficar fora de casa pelo menos 8 horas por dia?

Posted in Pensamento, Workplace.

By Lucashgt
30/03/2009

No comments