|
28 de setembro de 2010, por Denis Ferrari em Gerais
Não somos capazes de prever o futuro, mas analisando os erros cometidos no passado, podemos determinar os efeitos colaterais que uma decisão tomada no início de um projeto terá no longo prazo. Quando iniciamos um projeto de software, vários aspectos precisam ser resolvidos: As tecnologias envolvidas, o processo que será utilizado, como o projeto será organizado, etc. Uma decisão errada em qualquer um desses aspectos pode causar danos irreversíveis no projeto e reduzir sua vida útil consideravelmente. Muitas vezes, decisões “simples” de design/arquitetura voltam para nos assombrar quando o sistema precisa ser adaptado para uma nova situação que não havia sido pensada originalmente (Já viram essa história?).
11 de março de 2010, por Denis Ferrari em Podcasts
Há algum tempo houve uma discussão no Grupo .Net Architects sobre a definição de qualidade de software e quais são as formas de alcançá-la. A discussão foi muito produtiva e apresentou idéias e conceitos que todo profissional de desenvolvimento deveria conhecer, veja a discussão completa aqui. Algum tempo depois surgiu a idéia de gravar um podcast sobre o tema onde tivemos a oportunidade de participar juntamente com Alexandre Valente e Giovanni Bassi, o resultado final agradou muito:
11 de fevereiro de 2010, por Denis Ferrari em Gerais
Muitos profissionais da nossa área têm dificuldades em definir qualidade de software devido à quantidade de aspectos que precisam ser considerados para avaliar se um software possui ou não qualidade. Apesar do processo de avaliação da qualidade ser amplo e complexo, a definição de qualidade de software é simples de ser compreendida. Para avaliar a qualidade de um computador, avaliamos separadamente a qualidade de seus componentes, como vídeo, som, capacidade de processamento e quantidade de memória. A qualidade do computador pode ser considerada uma média das avaliações individuais de seus componentes. No software, a mesma idéia pode ser aplicada, porém, ao invés de olharmos para os componentes que o formam devemos olhar para como ele atende aos seus stakeholders: o cliente que paga pelo software, o usuário que trabalha diretamente com o software no seu dia-a-dia e o fornecedor que constrói ou mantém o software.
05 de fevereiro de 2010, por Denis Ferrari em Gerais
Nossa área de desenvolvimento de software é muito nova, e como consequência disso, ainda estamos aprendendo quais são as técnicas que funcionam e quais só atrapalham o dia-a-dia dos nossos projetos. É dever de todo profissional da área buscar meios para melhorar o nosso objetivo principal: Construir softwares que atendam aos clientes, aos usuários e às equipes de desenvolvimento. Práticas ágeis são um meio e não um fim, não deve-se utilizar as técnias se não é evidente quais problemas elas tentam resolver, usar por usar não melhora em nada o resultado final do seu projeto. Você só deve usar essas práticas se realmente entender porquê elas são necessárias, e não porquê estão na moda. |
|
