O Artigo fala um pouco sobre erros comuns de times ágeis. Isso inclui não somente o time, mas P.Os, Scrum Masters e todos os demais envolvidos. Vale a pena conferir.
Os demais artigos também são de excelente qualidade e a leitura dos mesmos é extremamente recomendada.
Quem não se lembra do comercial da Oi sobre bloqueio de celulares que fez bastante barulho?
O bloqueio as vezes faz parte da vida do Desenvolvedor de Software. Em muitas empresas que trabalhei, tive que conviver com alguns. Foram eles:
Bloqueio da Internet (Parece mentira, mas trabalhei num lugar onde somente algumas equipes tinham acesso a internet)
Bloqueio de Instant Message
Bloqueio de email (Não dava pra acessar o Gmail)
Bloqueio do Internet Banking
Bloqueio de alguns sites (Eu não conseguia acessar alguns blogs importantes)
Bloqueio do Telefone (Não dava nem pra ligar pra casa e em algumas empresas nem telefone na mesa tinha)
Bloqueio da estação de trabalho (Como que um desenvolvedor que não pode instalar nada no seu computador consegue trabalhar?)
Bloqueio da Impressora (Tinha senha especial pra imprimir)
Depois de sofrer bastante com esses bloqueios eu me interessei em saber o motivo que leva muitas empresas a trabalhar dessa forma. Apesar do argumento deles ser furado, vou listar o que eu ouvi de diversas pessoas:
Perda de produtividade (segundo eles, as pessoas perdem muito tempo com coisas inúteis na internet e telefone)
Falta de foco dos funcionários (Pessoas se desconcentravam facilmente com o IM e outros)
Desperdício de recursos da empresa. (Gente imprimindo e usando o telefone demasiadamente)
Depois disso, passei a observar o comportamento das pessoas pra ver como cada um se resolvia com essa série de bloqueios. Eis o que percebi:
A ausência da Internet gerava falta de produtividade, pois os desenvolvedores não conseguiam pesquisar algumas coisas, não tinham forum de discussão e não se mantinham atualizados lendo alguns blogs de tecnologia
A ausência do Instant Message impedia que um desenvolvedor pedisse ajuda a algum colega que já tenha trabalhado com ele para solucionar um determinado problema.
A falta do email fazia com que houvessem notebooks com internet móvel espalhados pela empresa para que o pessoal conseguisse ler seus emails.
A impossibilidade de instalação de softwares na máquina do desenvolvedor fazia com que o mesmo perdesse mais tempo que o necessário para resolver determinados problemas.
Muitos criaram seu prórpio jeito de burlar isso tudo (Proxys anônimos, senha de admin das máquinas escondido, mais tempo de almoço pra telefonar e imprimir em lan-houses)
E o pior: Essas empresas PERDERAM ÓTIMOS PROFISSIONAIS.
Atualmente eu trabalho numa empresa onde não tem dessas coisas. Aqui nossa internet é totalmente liberada, podemos usar o telefone sem problemas, enviar email a vontade, pagar nossas contas e até mesmo usar o Instant Message (MSN, Yahoo, ICQ, Gtalk), que é considerado por muitos um absurdo.
A conclusão que eu cheguei foi que não importa o que a empresa faça, se o desenvolvedor não quiser trabalhar, ele vai dar um jeito de faze-lo, mesmo que seja burlando as coisas ou simplesmente levando um livrinho e passando o dia lendo na sua mesa.
O que a sua empresa precisa é contratarprofissionais de verdade e não pessoas que simplesmente querem um emprego, pois quem quer realmente trabalhar, usa esses recursos a favor da empresa e não contra.
Faz alguns meses que os gujeirosRodrigo Yoshima e Carlos Villela blogaram sobre o uso errado da tecnologia numa fábrica de pastas de dentes. Para resolver o problema de caixas vazias que passavam desapercebidas numa linha de produção, a empresa comprou uma ultra-mega-power solução que ainda acabou atrapalhando os trabalhadores da fábrica. Mas os próprios trabalhadores se encarregaram de comprar um ventiladorzinho de 20 dólares e dispensar o mega equipamento.
Quem é Brasileiro e principalmente presenciou as corridas de nossos grandes pilotos de Fórmula 1, provavelmente ainda acompanha a categoria, mesmo que exporadicamente. Eu, criado em uma família muito ligada a esportes, com forte inclinação para F1(por que será que meu nome é Emerson? Alguém consegue advinhar? rs), continuo acompanhando os campeonatos, na esperança de que um brasileiro novamente seja campeão mundial.
Eis que no primeiro GP noturno da história da F1 a Ferrari atrapalhou Felipe Massa durante o seu pit-stop com um equipamento ultra moderno que foi desenvolvido para substituir o tradicional pirulito, durante os pit-stops. Esse pirulito foi utilizado por mais de 20 anos e que sempre se mostrou adequado. O novo equipamento fica posicionado em uma altura acima da cabeça do piloto, o que dificulta a visualização em caso de uma nova instrução para parar. O piloto brasileiro perdeu uns 30 segundos pois a mangueira de combustível rompeu-se e sua corrida foi comprometida, inclusive comprometendo a possibilidade de conquiista do campeonato. No pit-stop seguinte, na mesma corrida, a Ferrari voltou a usar o pirulito e no GP seguinte, aposentou de vez a sua engenhoca.
Uma das filosofias que mais gosto para Desenvolvimento de Software nos tempos atuais é KISS. Eu até hoje não sei o motivo de querermos fazer as coisas de forma complicada ao invés de simplificar (eu mesmo já errei muito nisso). Note que simples não significa sem qualidade, mas fazer o suficiente que possa atender a necessidade. As metodologias ágeis da moda como SCRUM / XP falam muito sobre isso. A prática de TDD também tem esse foco, quando prega que devemos fazer o código mais simples possível que atenda a necessidade em questão. E não poderia me esquecer do tão importante princípio de Baby Steps, utilizado em tudo isso que mencionei anteriormente.
Eu sinceramente acho que esse problema é inerente do ser humano e nós é que devemos nos doutrinar pra não cair nessa besteira.
Nesses últimos 2 dias, estive presentei no Rails Summit Latin américa. A organização do evento está de parabéns, principalmente o Fabio Akita, que conseguiu trazer pessoas chave da comunidade Rails mundial. As únicas coisas que senti falta foi uma camiseta do evento e a tradicional livraria, essa última eu tolerei pois ganhei um livro na palestra do Danilo Sato
O Evento promete ser bem legal, principalmente por ser o primeiro evento de Rails desse porte a ser realizado aqui no Brasil (se não me engano, rs).
Espero que esse evento ajude a alavancar ainda mais o desenvolvimento Ruby/Rails aqui no Brasil e que em breve esse mercado esteja tão aquecido quanto o mercado de Java.
Nas empresas que trabalhei até hoje durante a minha carreira, a maioria delas tinha uma coisa em comum: o funcionário tinha que trabalhar para agradar seu chefe, ao invés de trabalhar em favor da empresa.
Nesse momento, surge uma nova definição de processo de desenvolvimento: BDD - Boss Driven Development (Desenvolvimento voltado para o chefe). Basicamente funciona da seguinte maneira:
Se seu chefe chega cedo, trate de chegar cedo, pois se ele chegar antes de você, é muito ruim e provavelmente você terá problemas com ele
Se der a hora de você ir embora e por algum motivo ele ainda estiver na empresa, permaneça até ele sair, pois ele pode precisar de você para alguma coisa. Quem sabe pegar um café pra ele?
Por mais que você saiba que precisa melhorar alguma coisa que não está muito legal no projeto, cuidado ao falar com ele, pois ele pode achar isso uma ofensa, ou até mesmo dizer que a culda disso é sua.
Se ele pedir pra você ficar fazendo tarefas que nada tem a ver com a sua profissão/aptidão/vocação, não questione, afinal de contas, o segredo para crescer em uma empresa é fazer tudo que o chefe manda e ficar bem caladinho.
Por mais incrível que possa parecer, ainda existem muitas empresas que trabalham dessa forma. Especialmente as famosas consultorias [A-Za-z]{3}.
O BDD relacionado a testes de software é bem mais interessante, não é mesmo?
O mais engraçado disso tudo é que tem algumas pessoas que por mais que você mostre reultados, elas insistem que isso é uma modinha e que daqui a pouco passa.
Quando entrei aqui na Globo.com não achei que ia postar alguma coisa tão rápido. Mas acontece que ontém colocarmos nos ar o site de inscrições para o BBB9. Como todo projeto na vida, esse teve seus desafios, afinal de contas, colocar o site de inscrições para o BBB9 em 1 semana apenas, só mesmo com metodologias ágeis.
Aproveitando esse post, vou falar um pouco do novo time e do novo ambiente de trabalho.
Bem, basicamente trabalhamos praticamente todos juntos no nosso “mesão”.
Como podem ver, o “mesão” é bem compacto, mas ao mesmo tempo cada um tem um espaço razoável pra não ficar apertado. Existem apenas 2 membros do time que ainda não migraram pra cá, mas o farão em breve.
Como estarmos todos bem perto um do outro, a comunicação foi (é) bem intensa, fazendo que o ruido na seja praticamente nulo. O compromentimento do time também foi algo bem interessante. O pessoal que por alguns momentos havia terminado suas tarefas, se prontificava a ajudar os demais membros do time para garantir a nossa entrega, afinal de contas, BBB é algo que tem data fixa pra entrar.
O melhor de tudo foi receber um email do Product Owner hoje pela manhã agradecendo e elogiando todo o time.
Os anuncios na TV estão bombando, e pra quem gosta de BBB o site de inscrições é: http://bbb.globo.com/
Na última sexta-feira, deixei a Bradesco Seguros, empresa onde trabalhava pela DTS Consulting para encarar novos desafios.
Gostaria de agradecer aos amigos que me apoiaram bastante e aos meus antigos chefes na Bradesco Seguros, e também da DTS Consulting, que deixaram as portas abertas para um possível retorno futuro.
Há mais ou menos 1 mês atrás, o Bruno Pereira me chamou para uma vaga na Concrete Solutions. Ele me deu ótimas referências da empresa e resolvi aceitar o convite. Após todos os acertos, estou trabalhando alocado aqui na Globo.com, desde o início desta semana.
É um novo desafio na minha carreira, pois terei a oportunidade de trabalhar com SCRUM, o qual fiz um curso em março passado na TeamWare, e num ambiente realmente ágil, que começou com uma iniciativa do Phillip Calçado no ano passado.
Já comecei em um Sprint/Iteração e a coisa está realmente quente. Na semana que vem vou postar sobre o assunto e começarei a postar algumas coisas interessantes sobre Agile/SCRUM, baseado na minha vivência aqui.
O Workshop foi bem interessante, abordando temas atuais e de extrema importância no conhecimento do Desenvolvedor de Software.
No primeiro dia, o foco foi bastante em FDD, M3 e Agile Draw. Foi bem legal esse primeiro dia, pois eu experimentei algumas técnicas que nunca havia tentado. Confesso que não simpatizei muito com a modelagem com as figurinhas, nem muito com a FBS, mas eu vou pensar mais sobre o assunto e tentar me aprofundar um pouco pra tirar melhores conclusões.
Da esquerda pra direita: Colega de verde(rs), Gustavo, Eu, Colega de Branco(rs)
No segundo dia, o foco foi todo vontado para Domain Driven Design e UML em Cores. Foi bem interessante, pois o assunto tem um hype nos dias de hoje e é um assunto bastante motivador também.
A técnica de UML em Cores me ajudou um pouco a identificar algumas coisas em Model Driven Design, mas ainda assim, preciso testar mais pra definir se usarei essa técnica.
No mais gostaria de dar os parabéns ao Felipe Rodrigues e o Manoel Pimentel pelo evento que foi muito legal e tenho certeza que surgirão outros.
Da esquerda pra direita: Adndré, Eu, Felipe, Gustavo e Manoel
O unico problema é ter que se despencar do Rio de Janeiro toda vez, pois aqui estamos meio carentes de coisas do tipo, exceto pelo fato que as ultimas reuniões do RioJUG foram excelentes.
A Revista Visão Ágil, que sempre apresenta artigos muito interesantes, publicou este mês de outubro a edição número 5 com um artigo meu sobre Os 7 Pecados Capitais de Um time Ágil. O editorial está de parabéns pelo trabalho que fizeram. Realmente a revista ficou ótima.
Recent Comments