There are a sort of way to develop a computational system. Each one of then will let to a different place and it depends on the type of management are bean used. I'm particularly involved in some projects with a variety of development/management style.
There are a lot of companies doing outsourcing, this is good, it let you focus on your business and run a lot of things concurrently, but a project isn't just a delivery it's a live organism and you can't foreseen all you need in. It's very common to the outsider see the things in other ways, and you need to light all the way thought, but wen you find the good one, that who see as you see, you need to keep then.
Doing everything internally has it good and bad sides too, as outsourcing. The are the other things you must think, the system that is currently running, the bugs, the server crash, etc, but you can take advaced of the business knowledge you alread have.
To choose what way to go is sometimes difficult, you need to balance a lot of things to take that decision but a mix of the two is something very useful.
sábado, 25 de setembro de 2010
sexta-feira, 10 de setembro de 2010
Metodologias ágeis
Estou a algum tempo coordemando alguns projetos e uma das minhas metas é executar um piloto de metodologias ágeis, alguns Sprints depois já conseguimos ver o horizonte.
Uma ponto muito importante na implantação de uma nova metodologia, principalmente a ágil, é preciso ter em mente que é um processo iterativo/evolutivo. Demora um pouco até entrar na rotina mas uma vez que entra é fácil se acostumar com a flexibilidade, agilidade e visibilidade na evolução do projeto.
Outra coisa ótima é o acompanhamento com os pontos das estórias e o gráfico de Burndown. Você consegue acompanhar dia a dia como está a sua previsão de entrega em relação ao que foi previsto, alem de criar um histórico de velocidade da equipe em relação ao tipo de projeto, plataforma, linguagem, etc, o que é um ótimo combustível para planejamentos de novos projetos. A pouco passamos por uma "estimativa" que utilizamos os dados históricos para prever o tempo de desenvolvimento.
Outra coisa que percebi, na prática, é que a équipe é um diferencial. Se você tiver a equipe engajada, o projeto chega lá. É preciso deixar claro os objetivos que se deseja alcançar na entrega e ter o cliente acessível para uma dúvida ou outra.
Uma ponto muito importante na implantação de uma nova metodologia, principalmente a ágil, é preciso ter em mente que é um processo iterativo/evolutivo. Demora um pouco até entrar na rotina mas uma vez que entra é fácil se acostumar com a flexibilidade, agilidade e visibilidade na evolução do projeto.
Outra coisa ótima é o acompanhamento com os pontos das estórias e o gráfico de Burndown. Você consegue acompanhar dia a dia como está a sua previsão de entrega em relação ao que foi previsto, alem de criar um histórico de velocidade da equipe em relação ao tipo de projeto, plataforma, linguagem, etc, o que é um ótimo combustível para planejamentos de novos projetos. A pouco passamos por uma "estimativa" que utilizamos os dados históricos para prever o tempo de desenvolvimento.
Outra coisa que percebi, na prática, é que a équipe é um diferencial. Se você tiver a equipe engajada, o projeto chega lá. É preciso deixar claro os objetivos que se deseja alcançar na entrega e ter o cliente acessível para uma dúvida ou outra.
sexta-feira, 26 de fevereiro de 2010
Entropia de software
Esbarrei no termo esses dias lendo sobre "What Is Time? One Physicist Hunts for the Ultimate Theory", e achei muito interessante a definição. Nunca havia parado para realmente entender o termo, mas é incrível como está conectado sobre várias áreas do cotidiano, inclusive no trabalho de Analista de Sistemas.
Por definição entropia é uma função de não conservação de estado. Ou seja, pouca entropia define que o estado da coisa está pouco alterado, muida entropia define que o estado está bem alterado em relação ao estado inicial. Existe um ponto máximo de entropia, podemos defini-la como "pior que está não fica". Ou seja as coisas tendem para o caos e a desordem automaticamente, aumentam a entropia.
Um exemplo simples é quando deixamos um maço de folhas empilhados sobre a mesa e depois saimos, depois de uma semana, quando voltarmos, muito provavelmente o maço estará desorganizado.
Relacionando com desenvolvimento de softwares, quando começamos um projeto sabemos onde está tudo, o softwaer funciona e a coisa está organizada, dai então entra outro programador, outra equipe, os prazos apertam, etc, e a coisa começa a ficar um pouco mais confusa. Nesse momento estamos aumentando a entropia, as coisas começam a ficar mais desorganizadas ou não documentadas. Com a evolução do software e manutenções corretivas se atinge um estado de entropia máxima, e o sistema não suporta mais "novas funcionalidades" e sequer correções pequenas se tornam uma tortura. Esse é o ponto de reescrever o software ou o módulo.
sexta-feira, 5 de fevereiro de 2010
Seu grande inimigo
Li a frase "(...) and competing with no one but himself,(...) any issue that must be handled was solved first and foremost in a dialogue between him and himself(...)" e não consegui parar de pensar nela.
Parece uma coisas simples, mas perceber que você só tem um único inimigo e que esse inimigo é você mesmo lhe da um novo entendimento das coisas. Se lembra daquela promoção que não te deram mas a deram ao João, ou aquele carro que queria comprar mas acabou optando por um mais barato, ou aquele curso que queria fazer mas não tinha tempo. Quem lhe atrapalhou foi você mesmo, porque não se esforçou mais, porque não juntou dinheiro mais uns messes e porque não reservou um tempo.
Essa filisofia também é nova pra mim, estou aprendendo a encara-la.
sexta-feira, 29 de janeiro de 2010
Copy and Past Hell
Vamos começar assim, estabelecendo uma regra:
- se um programador efetuar mais que 5 copy and past por dia seus dedos mindinho e indicador serão cortados, dificultando muito faze-lo.
Copy and past é uma coisa do dia a dia, mas no desenvolvimento de sotware acaba gerando um antipattern chamado "Big ball of mud". Dificulta a manutenção do código e pode espalhar bugs.
Recentemente esse tipo de problema tem ficado bem evidente. Estou utilizando o Hudson como ambiente de integração continua e o plugin Violations em conjunto com o Simian(bem, não é mavem, o que posso fazer) para analisar trechos de código iguais no código. Como só implementamos essa ferramenta a pouco tempo e o software já tem um tempo na estrada, não é de se esperar que haja alguns problemas desse tipo. A figura 1 mostra o que estou falando, enquanto a figura 2 mostra porque estou escrevendo(é mole).
Figura 1) Bem, não está tão mal.
Figura 2) 1800? Tá de brincadeira.
Vamos torcer para a coisa melhorar.
terça-feira, 19 de janeiro de 2010
Google-fu
Achei o termo muito interessante e não podia deixar passar em branco a oportunidade de cometa-lo.
"Google-fu é a arte de responder qualquer pergunta feita utilizando recursos de internet, como ferramentas de busca". Já há algumas entradas em dicionários urbanos e na wikipedia para o termo.
A internet é uma verdadeira base de dados viva, que a cada minuto ganha milhares de novas entradas, em qualquer área, saber minera-la pode ser um diferencial.
Ser especialista nessa técnica não está atrelado apenas a informática. A pouco tempo presenciei uma quase "formação em medicina" (rsrs) baseado apenas em google e publicações de medicina com base na internet (sério).
Para a área de informática essa técnica é ainda mais importante, acho que vou preparar um curso sobre isso. Hoje existem vária tecnologias eminentes e o mundo se reinventa a cada seis messes. Mais importante que um certificação é a capacidade de adaptação rápida a novas tendencias, a absorção de nova tecnologia e modelos deve ser rápida senão as chances de sucesso ficam comprometidas.
Assinar:
Postagens (Atom)