timeBox

Desde que vi esses comerciais…

….passei a viajar na idéia de que o espírito Apple de criar seus produtos estava de alguma forma ligado aos valores e princípios pregados pela agilidade.

Pra quem desenvolve software tradicionalmente a algum tempo, só o fato de tomar conhecimento sobre o que diz o manifesto ágil já é algo que desperta. Algo que traz uma vontade imediata de trabalhar daquele jeito.

Quando tomei conhecimento sobre a proposta de produtos e softwares que a Apple segue, senti a mesma coisa. Uma vontade imediata de passar a usar computadores daquela forma, com aquela simplicidade e elegância matadora.

Mas até ai tudo bem. O fato de imaginar coisas, ligações aparentemente inexistentes, conceitos loucos, não é novidade alguma pra mim. rsrsrsrs

Até que hoje, participando do Dev in Rio 2009, assisti duas palestras de pessoas que com toda certeza viajaram nessa mesma questão.
Primeiro veio o Akita com sua palestra sobre ruby on rails (que tem uma comunidade notoriamente interessada em seguir princípios ágeis). E como ele iniciou a palestra?
Com esse vídeo aqui…

Esse pessoal da 37 Signals é tão apaixonado pela plataforma Apple, que chegam a relacionar o sucesso dos seus produtos a inspiração adquirida ao se trabalhar com Macs.

Depois do Akita ainda teve a palestra do Jeff Patton, que relacionou técnicas ágeis com o sucesso na criação de produtos.

Jeff Patton, Dev In Rio 2009

Em determinado momento da palestra, quando ele falava sobre a quantidade, simplicidade e qualidade das features em um produto, o cara puxou um iPhone do bolso e mandou: “Aqui não tem tudo que poderia ter, como muitos reclamam, mas o que tem, é simplesmente magnífico.”

Agile é objetividade, simplicidade, satisfação por estar fazendo algo com prazer, feliz, sem burocracias idiotas, sem documentações em excesso, que só você vai ler enquanto produz, sem gerente-comando-controle, sem terno em pleno Rio de Janeiro, sem diplomas ou certificações pra inglês ver.

Hi, I’m a Mac, and you?

Você é chamado para fazer parte de um projeto que não vai necessariamente entregar um sistema classicão (do tipo com telinhas, usuários de carne e osso, etc). Sua função é criar uma interface java com um content management de mercado.

Ok.

Você então projeta sua solução com base em JUnit.
Testa a chamada a interface, verifica que está tudo ok e entrega o produto.
Pra não ficar só em código, você até documenta a interface gerada em uma espécie de contrato. Dizendo como ela deve ser chamada e o que se esperar dela e tal. Tudo bonitinho.

Ai alguém chega pra você e diz que sua entrega não está aderente a metodologia da casa.
Afinal, faltou criar o diagrama de caso de uso e seu respectivo documento word de descrição do mesmo.
Então você entrega o tal caso de uso e algumas semanas depois ele volta pra você num e-mail que diz: Seu caso de uso não está aderente as melhores práticas pregadas pela casa para o mesmo. O fluxo básico está usando de termos técnicos e não representa com clareza uma interação entre o ator e o sistema.

Agora me diga. Qual a utilidade de se fazer um caso de uso numa situação como essa? Onde seu trabalho se resume a produzir um serviço de comunicação com uma ferramenta, o qual será chamado por outros serviços?

Qual a utilidade de se engessar de tal forma a quantidade e qualidade da documentação que deve ser feita?

Não pegou a idéia ainda?
Imagine só. Alguém te convida pra ser padrinho de casamento. Um outro alguém te alerta que você deve ir de terno a um casamento. Gravata, sapato, tudo certinho.
Mas o casamento que te convidaram pra ser padrinho será na praia, ali na areia e tal. Sei lá, a noiva viu um assim numa revista e resolveu que o dela seria assim também!

E ai? Você vai aparecer por la de terno? Gravata no sol de meio dia? Sapato na areia?
Seu bom senso vai te dizer alguma coisa sobre isso, não?

Muita gente já tem batido nessa tecla aqui no Brasil em blogs e revistas. Lá fora então, a décadas que esse tipo de coisa é difundida e até tem tido uma evolução no nível de aceitação.
O RUP tem isso, o XP também, o SCRUM. O que não falta é metodologia e escritor famoso defendendo esse ponto de vista. Mas aqui no nosso mercado, infelizmente, ainda estamos engatinhando com tímidas iniciativas.

Eu estou falando de ESCOPO NEGOCIÁVEL + DESENVOLVIMENTO ITERATIVO.

Não é raro eu entrar nesse assunto com alguém e ouvir de volta: “ah…muito legal, mas no mundo real não é assim”, ou então, “você está sendo acadêmico demais”.

Eu? Acadêmico? hehe….Vamos pular essa parte e partir pra alguns dados reais de mercado.

A décadas que o Standish Group vem divulgando o CHAOS Report, um conjunto de estatísticas sobre os resultados obtidos em milhares de projetos ao redor do mundo.
Só pra exemplificar, os dados de 2003 revelam que 34% dos 13.522 projetos pesquisados atingiram o sucesso, ou seja, foram entregues dentro do prazo, custo e ESCOPO FECHADO previsto inicialmente. Do restante, 15% foram cancelados e 51% tiveram prazo e/ou custo aumentados consideravelmente.

Com base nas funcionalidades que foram entregues nos projetos ditos de sucesso, foi perguntado aos clientes dessas funcionalidades, qual o grau de uso que eles estavam tendo sobre elas. A média das respostas foi a seguinte:
7% sempre são utilizadas, 13% frequentemente, 16% as vezes, 19% raramente e pasmem….45% nunca são utilizadas!

É isso aí, a maior parte estourou prazo/custo ou foi cancelada e dos que tiveram sucesso, quase a metade das funcionalidades não serve pra nada NO MUNDO REAL. Legal né???

Imagino que depois de ler isso em 2004, quem passou o ano anterior perdendo contratos ou gastando uma nota com hora extra, deva ter olhado com outros olhos essa questão de escopo negociável + desenvolvimento iterativo.

O problema de negócio que queremos resolver via software é que deve ter o escopo fechado.
As fronteiras que a solução sistémica não deverá ultrapassar é que devem ser delimitadas.

Agora, qual a real complexidade ou até mesmo necessidade dos X possíveis casos de uso, histórias, ou seja lá o que for, inicialmente imaginados pra resolver os problemas (de negócio) contidos no escopo (de negócio) de um projeto?
Não tem como responder isso com precisão ! Nem com ponto de função nem com qualquer outro ponto que seja.

Bem vindo(a) ao mundo real

- Documentos por favor.
- Sim senhor.
- É…você tem uma irregularidade aqui.
- É mesmo é?
- É mesmo! Não vai poder seguir em frente não.

Não, eu não estou fugindo do tema desse blog e relatando um desfecho comum para os engarrafamentos de 1 hora no aterro do flamengo ( o tempo normal pra atravessa-lo é de 5 min).

Quando se desenvolve software para uma grande corporação, não é raro se deparar com essa situação ai do diálogo. No papel do policial normalmente está algum membro da EIB (Equipe de Infra-estrutura Básica) e na pele do motorista está algum desenvolvedor com a inevitável missão de submeter um sistema (ou pedaço de um) à aprovação da EIB.

Uma EIB normalmente é composta por um conjunto de pessoas, onde cada uma tem uma aptidão específica, como administração de banco de dados, ou arquitetura SOA por exemplo. Muitas vezes uma EIB é até composta por um conjunto de equipes menores, cada qual com sua especialidade. Mas enfim, a função dessa galera de infra é dar apoio as equipes de desenvolvimento de software, criando diretrizes e convenções corporativas, as quais devem ser seguidas pelas equipes de desenvolvimento.

Existem duas formas de se trabalhar essa questão “EIB vs equipes de desenvolvimento”:

1 – Colocando uma contra a outra nessa estratégia de BLITZ CORPORATIVA, onde o pessoal de EIB apenas gera um mar de documentos-diretrizes, envia esse “manual de trânsito” para as equipes de desenvolvimento e marca uma data (normalmente ao final de alguma entrega importante) para revistar (ops!) digo….analisar, o trabalho da galera de desenvolvimento.

2 – Promovendo a comunicação e a humildade (valores da modelagem ágil) entre ambas as partes. Isso se faz inserindo as pessoas de EIB em determinados projetos de desenvolvimento por algum período de tempo, fazendo com que elas compartilhem sua maturidade profissional nas áreas em que se especializaram. Assim, as diretrizes corporativas passam a ser amadurecidas, repassadas e colocadas em prática em um cenário real. De quebra, ainda se cria um ambiente amigável e colaborativo entre as partes. Isso funciona! Dia desses estava conversando sobre isso com o Gustavo Serafim e ele diz estar tendo bons resultados com essa abordagem.

Ah! não posso deixar de dizer isso. Um grande risco de insucesso que se corre usando essa segunda abordagem, é colocando pessoas com pouca ou nenhuma habilidade de comunicação na EIB. Para isso funcionar é preciso ter profissionais bons tecnicamente mas que sejam sociáveis também. Já imaginou a pessoa ser apresentada como nova especialista XPTO pra apoiar o projeto durante algumas semanas, daí após essas semanas sem falar um “ah” ela manda um “manual de trânsito” por e-mail e some?

Leio blogs a muito tempo, mas blogar mesmo é algo que comecei a bem pouco tempo. E como todo iniciante, cometi algumas falhas, como por exemplo: não escolher muito bem a ferramenta que iria usar pra manter o blog. Não que o iWeb, programa que usei pra blogar até então, seja ruim. Ele apenas não é tão completo como o WordPress, com o qual estarei postando daqui pra frente. Aliás, todos os posts escritos no antigo endereço foram copiados pra ca.

Aos que comentaram meus posts por lá, peço desculpas. Pois perdi seus comentários quando tentei fazer com o iWeb coisas que ele não se propõe a fazer.

Sejam bem vindos