Escolhas 2.0 13
<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>
A princípio, meu instinto sugeriu-me falar sobre o Manifesto
2.0
(texto,
slides,
vídeo),
no qual discuto
uma nova escola de pensamento da indústria de TI
mas,
refletindo sobre a missão principal das Empresas Juniores e
no
público presente, não julguei o tema
como o mais
adequado à situação. Haveria ali muita
gente de
outras áreas que pouco compreenderiam
situações
específicas do universo do desenvolvimento de software,
além de vários estudantes com ainda pouca estrada
para de fato se sensibilizarem com a necessidade de um mundo
2.0.
Pensei então naquela palestra sobre Empreendedorismo
2.0, que realizei no UniCEUB
há algumas semanas
atrás, mas também logo desanimei, por me tocar
que, para
aqueles que estão começando uma
carreira, empreendedorismo é algo ainda muito
distante
de seu
horizonte de visão. Seria primeiro necessário
discutir
com esses alunos o que lhes acontecerá ao longo da vida
profissional e os vários caminhos que o mercado lhes tem a
oferecer. E foi então que nasceu esta
apresentação, que chamei de Escolhas 2.0, pingada
de
clichês motivacionais, mas repleta do meu mais sincero
voto (e testemunho)
a todos os presentes.
Em síntese, minha mensagem foi a seguinte:
- Todos passamos por fases profissionais.
- Em todas as fases, teremos desafios.
- É importante compreendermos a lógica de cada fase para não nos afogarmos (e sermos vencidos) em seus desafios.
- A superação de desafios é, na verdade, a nossa busca por melhor qualidade de vida (sucesso, paz, estabilidade, equilíbrio).
- Temos que atingir esta qualidade de vida num contexto capitalista, que rege toda a lógica do mundo ocidental.
- Neste contexto, o empreendimento de idéias é o caminho mais viável para nossos objetivos finais.
- Ao empreender, empreenda conforme os princípios 2.0.
[]s
Maré de Agilidade com Açaí
<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>
Texto produzido pelo grupo Tá Safo!
Para quem ainda não sabe do que se trata, o Maré de
Agilidade é um
evento itinerante que viaja pelas cidades do Brasil, apresentado
assuntos como Extreme Programming (XP), Scrum, Domain Driven Design
(DDD), Model Driven Design
(MDD), Test-driven Development (TDD), Feature-driven Development (FDD),
Gerenciamento Ágil de Projetos (GAP), Lean, e tantos outros.
Esses assuntos começam a fazer parte do
vocabulário do desenvolvedor de software, no entanto muitas
vezes sem a devida capacitação para entendimento
e aplicação de tantos conceitos.
Como as ondas de uma maré, o evento já passou por
Brasília
(setembro/2008 − 1° edição); Salvador
(março/2009 − 2°
edição) e Fortaleza
(agosto/2009 − 3° edição).
Agora em sua 4°
edição
chegou a vez de Belém,
para falar das novas tendências em gerência de
projetos e técnicas de desenvolvimento de software que
constiuem atualmente o grande diferencial de empresas como Apple,
Google, Microsoft, Yahoo e Globo.com.
O evento está programado para os dias 26, 27 e 28 de Novembro de
2009,
sendo os 2 primeiros dias de mini-cursos, sessões de Dojo e
OpenSpace. O 3° dia reservado para palestras e
discussões.
Acesse o site do evento: www.maredeagilidade.com.br
O que é Pomodoro? 11
Pomodoro Technique é uma técnica de organização, concentração e produtividade pessoal que está dando o que falar ultimamente.
A prática chama atenção por sua simplicidade. A única coisa que ela demanda é um cronômetro regressivo desses que todo mundo traz no relógio de pulso, no celular, ou em cima da escrivaninha, tomando poeira. (Dá até raiva quando se começa a utilizar a prática e se percebe a quanto tempo essas coisas estiveram bem embaixo do nosso nariz.)
Na verdade, a prática exige algo mais que um simples relógio - claro. O principal talvez seja um pouco de disciplina - o que não é trivial, mas será indispensável em qualquer solucão que trabalhe com pessoas.
O nome da técnica faz referência àqueles timers de cozinha, usados pra avisar o tempo de cozimento das coisas.
Explicando brevemente, trata-se da técnica de usar o cronômetro regressivo para estabelecer um fluxo de trabalho dividido em ciclos de 30 minutos, sendo 25 min de concentracão total e 5 minutos de reflexão e descanso. A cada 4 ciclos, descansa-se por 15 minutos. Simples assim.
Os benefícios do tomate para a saúde
O primeiro benefício que a técnica Pomodoro traz é o de aumentar a produtividade pessoal. Diminuindo bruscamente a quantidade de interrupções e lapsos de concentracão que as pessoas têm durante suas atividades, o dia de trabalho real aproxima-se do dia ideal - comumente utilizado para estimar.
Os segundos e fracões de segundo que se perde a cada interrupcão, se somados ao longo de um dia, representam quantidade significativa de tempo jogado fora. Especialmente se levarmos em consideracão que dez segundos gastos atendendo uma ligacão, por exemplo, na verdade consomem bem mais que 10 segundos de trabalho. Até que a pessoa se lembre do que estava fazendo, retome a concentracão e volte ao ritmo anterior, lá se vão pelo menos mais 10 segundos.
Embora a técnica aparentemente reserve muito tempo ao descanso - afinal, em um dia de 8 horas, reserva-se quase 2 horas para os breaks - o que se percebe rapidamente ao se utilizar a técnica, é que o tempo "improdutivo" na verdade diminui - e muito. Diminui e, por incrível que pareça, torna-se mais eficiente. Quando não se mistura o tempo de trabalho com o tempo de descanso, ambos se tornam mais efetivos.
Porque o tomate funciona?
Parece contraditório, mas o pomodoro melhora o fluxo de concentracão por meio de interrupcões - o alarme do cronômetro.
O primeiro motivo pelo qual as interrupcões ajudam a manter a concentracão trata-se de uma questão óbvia: descanso. Todos sabem o quanto atividades intelectuais complexas cansam. E sendo as atividades complexas e cansativas, é natural que exijam mais motivacão e disposicão física e mental. As paradas obrigatórias de 5 minutos a cada meia hora, e de quinze minutos a cada duas horas são o tempo ideal para manter a energia necessária pra fazer as coisas bem feitas.
O ponto está no fato de as interrupcões serem previsíveis, permitindo que a gente se prepare pra elas. Enquanto o relógio está andando, à sua vista, você se despreocupa com os próximos compromissos que tem. Não precisa ficar de olho no relógio, por que o alarme vai te avisar no tempo previsto.
Durante um tomate, não preocupa também a dúvida sobre se está se perdendo tempo demais na tarefa atual. Não enquanto se está realizando a tarefa. Isso porque a escolha das tarefas foi feita nos 5 minutos de intervalo agora a pouco e será reavaliada ao final de mais alguns minutos. Quando se sabe que a questão será analisada logo mais, não há motivo pra ficar preocupado enquanto se está concentrado em "fazer".
Ao se estipular explicitamente um tempo de descanso, autorizado e oficial, onde a pessoa poderá dar uma olhada no email, contar uma piada ou comentar sobre o jogo de futebol, o que acontece é que se diminui a ansiedade em fazê-lo. Dá vontade de olhar o email, você olha na barra de tarefas e vê que seu tomate acaba em 7 minutos, e desiste imediatamente da ideia, pois sabe que já já terá direito a um tempinho pra isso.
O Pomodoro possui uma estrutura análoga à dos processo de planejamento de Scrum/XP, baseados no ciclo PDCA. Ao se delinear com precisão os momentos de parada para reflexão, separa-se muito bem a atividade de "decidir o que fazer" da de "fazer" efetivamente - um dos princípios fundamentais dessas técnicas. Com isso, os planos ao longo do dia se adaptam melhor aos imprevistos, e o progresso que faz durante a execucão é sensivelmente maior.
Por fim, ao estabelecer de forma clara e justa o tempo em que se deve trabalhar e o tempo em que se pode descansar, fortalecem-se os laços de confiança nas relacões de trabalho, o que permite aumentar a autonomia das pessoas, que ficam satisfeitas e - também por isso - trabalham melhor.
[update: 17:30]
Estime em tomates!
Outro aspecto muito interessante sobre a técnica Pomodoro é sua relacão com as metodologias ágeis e a forma como auxiliam o processo de planejamento e estimativas. Eu expliquei como usamos tomates para estimar nesse artigo publicado na InfoQ . Não deixe de dar uma olhada!
Mini-curso online de Liferay 9
<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>
O conteúdo em si não foi muito profundo mas, de
tão positivo que foi o feedback da turma, acabei resolvendo
gastar um pouco mais de esforço para deixá-lo
para prosperidade. O resultado foi uma sequência de slidecasts
que hoje começo a disponibilizar.
Nesta primeira leva, teremos 2 apresentações.
Ambas são bem introdutórias, mas essenciais para
tratar com quem nunca ouviu falar no assunto. Nos próximos
episódios, falarei um pouco mais de desenvolvimento de
portlets, não apenas em Java, como também em
outras tecnologias, como Ruby e PHP.
Foi minha primeira experiência na
gravação de *casts. O resultado não
ficou 100%, mas já
quebra o galho. O importante é a melhoria
contínua.
Feedbacks, como sempre, são mais que bem-vindos.
[]s
Agilidade & Licitações 14
Estamos numa espécie de cruzada na resolução deste problema, tão maior que a gente, que é o de se trabalhar utilizando metodologias ágeis no governo. As dificuldades são enormes, e ainda não há solução satisfatória, mas em que ponto estamos no momento?
No Ágiles 2009, fizemos uma apresentação sobre este tema (abaixo).
Seguida pela entrevista do Alê pelo Luiz, da Bluesoft:
Entrevista com Alexandre Gomes da SEA Tecnologia no Ágiles 2009 from Bluesoft on Vimeo.
Resumindo a conversa, devido a uma combinação de várias Leis e acórdãos do TCU, o Governo passou a considerar desenvolvimento de software como sendo um serviço comum, sendo obrigado a ser adquirido via pregão. E a unidade de software licitada é normalmente baseada numa métrica, a maioria Pontos por Função.
Uma das conseqüências do uso de pregões para aquisição de software tem sido a diminuição da necessidade de comprovações técnicas, que ocorriam nas licitações do tipo técnica e preço. Por exemplo, onde antes se pedia MPS.BR nível A, hoje aceita-se qualquer certificação MPS.BR. O mesmo vale para o CMMI. E também já faz algum tempo que certificações de profissionais não são mais pedidas como critérios de pontuação técnica, visto que a empresa não precisa ter o profissional contratado antes do início do projeto. As comprovações técnicas dos profissionais são pedidas no momento do contrato, já definido o ganhador do pregão.
Um dos objetivos dos órgãos públicos estarem diminuindo esses critérios para participação é permitir a concorrência entre mais empresas e diminuir o preço do serviço, visto que este é considerado serviço comum. Isso tende a diminuir a força e a fatia de mercado de médias e grandes empresas dentro das áreas de Tecnologia da Informação do governo (será que estavam satisfeitos com elas?). Mas vamos analisar a questão de serviço comum por um instante.
A Lei nº 10.520/02, define que bens e serviços comuns são aqueles cujos padrões de desempenho e qualidade possam ser objetivamente descritos no edital, por meio de especificações usuais no mercado. Mas observem nos slides os “objetivos” padrões de desempenho e qualidade que caracterizam software como serviço comum (e tirem suas próprias conclusões).
Acreditamos que ainda existem algumas fragilidades nessas definições para podermos considerar desenvolvimento de software como serviço comum. Por exemplo: concordamos que haver mecanismos de gestão do projeto favorece que os projetos estejam mais sob controle e que documentação aumente as chances do sistema ser melhor manutenível, mas e se forem mal planejados? Quais são os critérios de qualidade de um plano? Ou de um documento de visão? Ou de um documento de arquitetura? Quando existem, são caracterizados pela presença de tópicos (ex: documento de visão ter definição do problema, necessidades, características e definição dos usuários) e validação de um profissional. Mas isso não seria ainda muito subjetivo? Você pode definir mal o problema, as necessidades e mesmo assim esses tópicos constarem no documento. E a documentação também pode ficar obsoleta. O profissional vai usar quais critérios objetivos para validar a documentação? O mesmo vale para os questionários e aceites normalmente utilizados.
Reiterando: consideramos todos esses mecanismos válidos para aumentar as chances da qualidade do resultado, mas ainda não podem ser considerados como definitivos para tal finalidade. Por isso proporemos novos critérios, baseados em métricas de qualidade como cobertura de testes e taxa de duplicidade do código que, assim como os atuais, também favorecerão a qualidade do software entregue, bem como manutenibilidade e documentação do código.
É claro que pode-se ter um software 100% coberto por testes e ainda assim estes testes serem ruins. Nenhuma métrica totalmente objetiva jamais será perfeita. O fato é que haver testes automatizados no software aumenta as chances de ele ter qualidade, ser melhor documentado e mais manutenível ao longo do tempo.
Observe que estes critérios não resolveriam o problema da qualidade no momento da contratação, pois as métricas só seriam aferidas nas entregas. Mas, ao longo do tempo, descartando-se as empresas que não entregam software com qualidade (por exemplo, numa eventual fase de homologação), haveria uma adaptação dos produtos e do mercado para uma realidade melhor.
Por que o interesse nesses novos critérios? Porque apesar das boas intenções, as conseqüências desse formato de contratação não têm sido boas. Os preços de fato caíram muito, mas muitas empresas não estão conseguindo entregar os sistemas. E muitas delas entregam sistemas de qualidade muito ruim, o que em muitos casos deverá resultar em nova contratação para o mesmo projeto (Isso já foi noticiado na imprensa.). Ou seja, não está havendo economia de fato. Acreditamos que esse modelo tende a colapsar. Ainda há necessidade de adaptação a esse novo formato, e acreditamos que estas métricas de qualidade de código contribuem para isso.
Outra razão (mais particular), é que nós trabalhamos com testes automatizados, sabemos que isso favorece a qualidade dos sistemas e sabemos o quanto isso melhoraria os sistemas que têm sido desenvolvidos para a população. Só que até então, não observamos nenhum retorno desse diferencial. O desenvolvimento está nivelado por baixo. Então a idéia é tangibilizar essa qualidade para que seja valorizada e requerida em editais, para que todos que trabalham como trabalhamos e agregam o valor que agregamos no código possam se beneficiar disso.
Portanto, nossa próxima batalha é essa: tangibilizar a qualidade que dizemos agregar, de forma a contribuir para aumentar a qualidade do serviço de desenvolvimento de software prestado ao Estado. Depois, tentar sensibilizar o governo em quanto a isso, para que possa melhorar seus editais de contratação (quiçá, Acórdãos e Leis!). Quem tá junto nessa?
Já existe um grupo discutindo isso. Se tiver interesse em participar, mande um e-mail para renato ponto willi arromba seatecnologia ponto com ponto br.
[]s
Willi