25
0
Tenho acompanhado muitas discussões sobre processo/metodologia/framework de desenvolvimento de software e realmente é incrível a capacidade de reciclar idéias e colocar conceitos antigos em uma nova embalagem para "vender" mais do mesmo... não estou atacando o "movimento ágil" que surgiu no início desta década, mas os novos "xiitas" que teimam em colocar de um lado os "agilistas" e do outro "os trouxas" (como são chamadas as pessoas normais na saga do bruxinho de óculos).
Eu não tenho tanto tempo assim no mercado de TI, mas pude viver algumas ondas (ou modismos):
Enfim... isso tudo em menos de 20 anos. A cada onda, uma nova corrida era desencadeada, parecendo que tudo o que tinha sido feito até então estava errado e agora seria tudo lindo e maravilhoso. Onda após onda... mas nos últimos 10-15 anos, tivemos uma inovação tecnológica que mudou tudo: a internet. A internet permitiu que criassemos uma base de conhecimento gigantesca e incremental. Os grupos de discussão, blogs e wikis permitem que criemos uma base de conhecimento sobre o que realmente funciona e o que não funciona (ou funciona menos) nos projetos de desenvolvimento de software (ou em projetos com determinadas características).
O RUP, por exemplo, processo que conheço com bastante profundidade (vivido na prática), nasceu numa era pré-internet. Numa época em que o único meio de transmissão de conhecimento em massa que tinhamos eram os livros: as pessoas compravam os livros e "aplicavam" o processo. Depois, quando o RUP passou a ser encontrado "gratuiítamente" em CD, as pessoas passaram a utilizar os templates de documentos que vinham com o RUP e se diziam "aderentes" ao RUP. Não havia uma maneira rápida e direta de buscarem ajuda sobre como adotar, ou termo que prefiro, praticar o processo. Existiam os livros e os templates. Ninguém para dizer se estava certo ou errado.
Hoje isto mudou e temos dezenas de grupos e listas de discussão em português onde todos podemos buscar dicas e trocar informações sobre como melhorar a nossa eficiência no desenvolvimento de software. E assim como no futebol, onde temos 190 milhões de técnicos, agora temos milhares de gurus e metodologistas.
Uma das grandes falácias que vejo é sobre o uso da palavra "empírico": o processo de desenvolvimento de software deve ser empírico. Na maioria dos casos, ouço isso de pessoas que na verdade querem dizer: o processo de desenvolvimento de software deve ser o jeito que eu faço. Ora! O RUP, por exemplo, é um processo empírico: ele foi criado com base na observação prática do que funciona e que aumenta as chances de sucesso no desenvolvimento de software. Não é simplesmente porque ele descreve uma maneira de trabalho que deixa de ser empírico.
Da wikipédia: "empírico é um tipo de conhecimento "enciclopédico" fundamentado noutros, consagradamente notáveis"
Em vez disso, prefiro dizer que o processo deve ser adaptável e contínuamente aprimorado. E esse é o primeiro princípio do RUP.
Outro argumento comum que ouço é que "os times deve ser auto gerenciáveis". Normalmente o que as pessoas querem dizer com isto é: nos deixe trababalhar em paz. Ora! Eu sou um dos maiores defensores da filisofia aplicada pelo fundador da 3M que diz "contrate bons funcionários e deixe-os em paz". Mas isso não significa que não devam seguir determinados rituais adotados e padronizados pela empresa.
Outra frase feita: "a documentação deve ser a necessária". Como assim? As empresas são as donas dos softwares desenvolvidos: é um capital intelectual pelo qual a empresa pagou para que os funcionários desenvolvessem. Não é uma obra de arte que os desenvolvedores criaram simplesmente para satisfazer uma necessidade de negócio pontual. É obrigação deles fazer com que essa propriedade intelectual possa ser re-utilizada e proporcione o maior retorno sobre investimento possível. E isso deve acontecer depois que o desenvolvedor que criou aquela peça de software tenha passado desta para uma melhor (oportunidade de carreira, claro!).
Não estou dizendo aqui que a documentação deva ser um documento (na minha opinião a pior forma de documentação possível) ou um modelo UML produzido por engenharia reversa, perfeitamente sincronizado com o código e super detalhado. O software deve ser muito bem documentado, na melhor forma de documentação possível. Isso a equipe (ou uma equipe da empresa) é que deve decidir qual é a melhor forma de documentar o software. Isso me leva a mais repetida (e mal utilizada) verdade que tenho notícia:
Pessoas e interações mais que processos ou ferramentas. Antes que o senho leitor "agilista" pare de ler e comente este post, peço pela sua paciência e leia até o final. Eu concordo totalmente com essa frase e nós, da IBM Rational, sempre repetimos isto para todos os nossos clientes: ferramentas só irão acelerar o trabalho. Se as pessoas não estiverem trabalhando de modo que cheguem no lugar certo, as ferramentas só irão leva-las mais rapidamente ao lugar errado. Primeiro vamos trabalhar as pessoas, depois falaremos sobre ferramentas. Acontece que o que mais vejo por aí, são empresas buscando a tal "agilidade" que passam a fazer reuniões em pé e controlar as pendências usando um quadro branco e PostIts (ferramentas ainda que simples) e que continuam a praticar o mesmo PROCESSO de antes da introdução das mudanças. Ora! SCRUM e outros processos modernos (como o RUP) impõem um regime de ciclos de desenvolvimento curtos com revisões constantes e correções de rumo rápidas. Como o time espera atender às necessidades de conformidade (auditoria é algo cada vez mais comum em empresas de médio porte) e documentação (a "da boa" como disse lá em cima, não documentos) e ainda assim continuarem a ser "ágeis" sem ferramentas que tirem esses (só para citar alguns) entraves do meio do caminho?
Quero deixar claro que concordo com todos os pontos mencionados no Manifesto Ágil e que sou um agilista desde sempre. Mas vejo muita gente (muita mesmo!) deturpando os valores pregados pelo manifesto pensando somente em si (ou no projeto em si) e não no bem/ativo sendo desenvolvido para a empresa (falam até mesmo no "fim do agile").
Acredito que o time de desenvolvimento deva, acima de tudo, ter em mente que o software sendo desenvolvido é um bem da empresa e que deve atender a uma necessidade imediata e estar pronto para acomodar necessidades futuras. O objetivo aqui é um só: garantir agilidade para o NEGÓCIO da empresa.
Por hora é isto!
Eu não tenho tanto tempo assim no mercado de TI, mas pude viver algumas ondas (ou modismos):
- Análise Estruturada (ainda guardo meu livro do Chris Gane), Análise Essencial com abordagem Top-Down, Bottom Up e espiral, Modelo Iterativo..
- Arquiteturas Cliente-Servidor, 2-Tier, N-Tier, centradas em banco de dados, em objetos, em componentes, em serviços...
Enfim... isso tudo em menos de 20 anos. A cada onda, uma nova corrida era desencadeada, parecendo que tudo o que tinha sido feito até então estava errado e agora seria tudo lindo e maravilhoso. Onda após onda... mas nos últimos 10-15 anos, tivemos uma inovação tecnológica que mudou tudo: a internet. A internet permitiu que criassemos uma base de conhecimento gigantesca e incremental. Os grupos de discussão, blogs e wikis permitem que criemos uma base de conhecimento sobre o que realmente funciona e o que não funciona (ou funciona menos) nos projetos de desenvolvimento de software (ou em projetos com determinadas características).
O RUP, por exemplo, processo que conheço com bastante profundidade (vivido na prática), nasceu numa era pré-internet. Numa época em que o único meio de transmissão de conhecimento em massa que tinhamos eram os livros: as pessoas compravam os livros e "aplicavam" o processo. Depois, quando o RUP passou a ser encontrado "gratuiítamente" em CD, as pessoas passaram a utilizar os templates de documentos que vinham com o RUP e se diziam "aderentes" ao RUP. Não havia uma maneira rápida e direta de buscarem ajuda sobre como adotar, ou termo que prefiro, praticar o processo. Existiam os livros e os templates. Ninguém para dizer se estava certo ou errado.
Hoje isto mudou e temos dezenas de grupos e listas de discussão em português onde todos podemos buscar dicas e trocar informações sobre como melhorar a nossa eficiência no desenvolvimento de software. E assim como no futebol, onde temos 190 milhões de técnicos, agora temos milhares de gurus e metodologistas.
Uma das grandes falácias que vejo é sobre o uso da palavra "empírico": o processo de desenvolvimento de software deve ser empírico. Na maioria dos casos, ouço isso de pessoas que na verdade querem dizer: o processo de desenvolvimento de software deve ser o jeito que eu faço. Ora! O RUP, por exemplo, é um processo empírico: ele foi criado com base na observação prática do que funciona e que aumenta as chances de sucesso no desenvolvimento de software. Não é simplesmente porque ele descreve uma maneira de trabalho que deixa de ser empírico.
Da wikipédia: "empírico é um tipo de conhecimento "enciclopédico" fundamentado noutros, consagradamente notáveis"
Em vez disso, prefiro dizer que o processo deve ser adaptável e contínuamente aprimorado. E esse é o primeiro princípio do RUP.
Outro argumento comum que ouço é que "os times deve ser auto gerenciáveis". Normalmente o que as pessoas querem dizer com isto é: nos deixe trababalhar em paz. Ora! Eu sou um dos maiores defensores da filisofia aplicada pelo fundador da 3M que diz "contrate bons funcionários e deixe-os em paz". Mas isso não significa que não devam seguir determinados rituais adotados e padronizados pela empresa.
Outra frase feita: "a documentação deve ser a necessária". Como assim? As empresas são as donas dos softwares desenvolvidos: é um capital intelectual pelo qual a empresa pagou para que os funcionários desenvolvessem. Não é uma obra de arte que os desenvolvedores criaram simplesmente para satisfazer uma necessidade de negócio pontual. É obrigação deles fazer com que essa propriedade intelectual possa ser re-utilizada e proporcione o maior retorno sobre investimento possível. E isso deve acontecer depois que o desenvolvedor que criou aquela peça de software tenha passado desta para uma melhor (oportunidade de carreira, claro!).
Não estou dizendo aqui que a documentação deva ser um documento (na minha opinião a pior forma de documentação possível) ou um modelo UML produzido por engenharia reversa, perfeitamente sincronizado com o código e super detalhado. O software deve ser muito bem documentado, na melhor forma de documentação possível. Isso a equipe (ou uma equipe da empresa) é que deve decidir qual é a melhor forma de documentar o software. Isso me leva a mais repetida (e mal utilizada) verdade que tenho notícia:
Pessoas e interações mais que processos ou ferramentas. Antes que o senho leitor "agilista" pare de ler e comente este post, peço pela sua paciência e leia até o final. Eu concordo totalmente com essa frase e nós, da IBM Rational, sempre repetimos isto para todos os nossos clientes: ferramentas só irão acelerar o trabalho. Se as pessoas não estiverem trabalhando de modo que cheguem no lugar certo, as ferramentas só irão leva-las mais rapidamente ao lugar errado. Primeiro vamos trabalhar as pessoas, depois falaremos sobre ferramentas. Acontece que o que mais vejo por aí, são empresas buscando a tal "agilidade" que passam a fazer reuniões em pé e controlar as pendências usando um quadro branco e PostIts (ferramentas ainda que simples) e que continuam a praticar o mesmo PROCESSO de antes da introdução das mudanças. Ora! SCRUM e outros processos modernos (como o RUP) impõem um regime de ciclos de desenvolvimento curtos com revisões constantes e correções de rumo rápidas. Como o time espera atender às necessidades de conformidade (auditoria é algo cada vez mais comum em empresas de médio porte) e documentação (a "da boa" como disse lá em cima, não documentos) e ainda assim continuarem a ser "ágeis" sem ferramentas que tirem esses (só para citar alguns) entraves do meio do caminho?
Quero deixar claro que concordo com todos os pontos mencionados no Manifesto Ágil e que sou um agilista desde sempre. Mas vejo muita gente (muita mesmo!) deturpando os valores pregados pelo manifesto pensando somente em si (ou no projeto em si) e não no bem/ativo sendo desenvolvido para a empresa (falam até mesmo no "fim do agile").
Acredito que o time de desenvolvimento deva, acima de tudo, ter em mente que o software sendo desenvolvido é um bem da empresa e que deve atender a uma necessidade imediata e estar pronto para acomodar necessidades futuras. O objetivo aqui é um só: garantir agilidade para o NEGÓCIO da empresa.
Por hora é isto!
