Formando equipes de alto desempenho, parte 1: Início e fases de evolução
Nesta primeira parte de uma série sobre equipes de alto desempenho e gerenciamento Agile, veja uma introdução geral e uma apresentação dos estágios de formação das equipes.
Notícias
O conteúdo foi adicionado aos favoritos!
Houve um erro ao adicionar aos favoritos! Por favor, tente novamente.
Venkat Subramaniam em Verdades e Mentiras do Desenvolvimento de Software Cotidiano
Postado por Srini Penchikala , traduzido por Flávia Castro de Oliveira em 03 Fev 2009
O desenvolvimento de software é desafiador e muito divertido, mas há diversos fatores que não deixam os times ter sucesso nos projetos de TI. Estes fatores não são normalmente as ferramentas ou as tecnologias mas são as pessoas que afetam o sucesso dos projetos de desenvolvimento de software. Venkat Subramaniam falou sobre as verdades e mentiras do desenvolvimento de software cotidiano. Ele fez uma apresentou um keynote na conferência CodeMash 2009 sobre o quais cuidados os desenvolvedores e gerentes de projeto devem tomar para assegurar o sucesso de seus projetos.
Aqui estão algumas das mentiras do desenvolvimento de software sobre as quais Venkat falou em seu keynote:
Mais tempo e dinheiro resolverão os nossos problemas:
Venkat disse que é importante ter claro os "objetivos de negócio" quando estiver trabalhando nos projetos. Ele mostrou estatísticas de que 64% das funcionalidades implementadas em um projeto são raramente ou nunca utilizadas e quanto maior for a duração de um projeto, menor a probabilidade de que o projeto seja bem sucedido. Os desenvolvedores de software precisam desenvolver o que ele chamou de "software capaz e relevante".
É deve ser bom porque é desta grande fornecedora de software:
Ele questionou se é realmente necessário usar EJB que (em alguns casos) torna o desenvolvimento complicado e pesado. Os desenvolvedores são em parte culpados por esta situação (usando o EJB para praticamente todos os casos). Uma das razões para a adoção do EJB foi que a competição (e não a necessidade) trilhou o caminho. A necessidade deve determinar a tecnologia, não a tecnologia determinar a necessidade e não é uma boa evolução quando a padronização ocorre antes da inovação. Frameworks como Rails e Spring nos mostraram que a inovação antes da padronização levam a frameworks úteis e relevantes impulsionados pela comunidade ao invés dos fornecedores.
Fazemos off-shoring porque poupará nosso dinheiro:
Venkat falou sobre o atual modelo off-shoring e se esse modelo está realmente funcionando ou não. Ele comparou o modelo quando as empresas fizeram tudo aqui nos EUA e nós mesmo assim não obtiveram sucesso. Então ele perguntou, por que você colocaria oceanos entre designers e programadores e esperaria resultados diferentes? O modelo Off-shoring tornou-se principalmente uma estratégia "Falhar-por-menos". Ele sugeriu que os gerentes de projetos contratem desenvolvedores inteligentes e experiêntes, que possam aprender rápido e em seguida lhes de ferramentas boas, ferramentas e práticas. Um pequeno time de desenvolvedores capazes é melhor que um time grande de desenvolvedores abaixo da média. Ele afirmou que off-shoring está aqui para ficar então devemos tirar vantagem do talento real a nível mundial.
Linguagens Dinâmicas não são seguras:
Ele falou sobre Java ser fortemente tipado e mesmo assim você ainda pode receber um ClassCastException se você não tiver cuidado quando codificar, o mesmo acontece nas linguagens Ruby e Groovy. Tipagem forte por si só não melhora o código. O Compilador é útil, mas é frequentemente superestimado porque nenhum compilador pode verificar de forma plena a intenção do programador. Ele também recomendou que os desenvolvedores tirem vantagem das novas linguagens dinâmicas.
Static typing é essencial para a clareza do código:
Venkat disse que com disciplina, os desenvolvedores podem escrever código legível, compreensível e de fácil manutenção em qualquer linguagem. Ele sugeriu as seguintes práticas para manter o código limpo e sustentável.
- Usar nomes descritivos para método/classes.
- Escrever classes curtas e métodos curtos.
- Deixar a equipe interagir e se comunicar.
- Escrever testes unitários automatizados. Os testes unitários tem redundância de expectativa. Ele obriga você a fazer um bom design.
Ele também discutiu a importância dos testes unitários no ciclo de vida do desenvolvimento de software. Testes unitários são o equivalente de software a exercícios, e mesmo sendo muito bom, a maioria dos programadores não fazem. Ele ajuda a melhorar a saúde do código e se o código é testável o design está bom. Venkat concluiu a apresentação destacando que isso é importante para expressar a "intenção" no software.
Nenhum comentário
Acompanhar Discussão Responder