Tag: Desenvolvimento de Software
Por Samba Tech em Samba Insight em julho.9.2009
Uma constante nas empresas que trabalham com TI é a complexidade dos projetos de desenvolvimento de software, não importa se a empresa é pequena, média ou grande. Não é raro encontrarmos empresas fazendo grandes investimentos na tentativa de reluzi-la, porém tais investimentos não trazem o retorno esperado. A razão disso é que a área de TI vive da complexidade e por esta razão extingui-la vai contra seu próprio instinto de sobrevivência.
Espectro da Complexidade no Processo de Desenvolvimento de Software
Projetos simples em TI são aqueles em que os requisitos são totalmente conhecidos e as tecnologias utilizadas estão 100% dominadas, porém estes projetos não geram retorno financeiro uma vez que podem ser considerados “commodities”. Por outro lado, projetos onde os requisitos são totalmente desconhecidos e que precisam ser desenvolvidos utilizando-se de ferramentas “experimentais”, por melhor que seja o retorno financeiro, não são executáveis.
Assim sendo, ao contrário do que muitos acreditam, as empresas de TI não querem tornar as coisas simples. Na verdade elas querem estar à beira do caos (ponto ótimo da curva do ROI). Esta é uma das principais razões para as inúmeras tentativas em busca de um Shangri-la de simplicidade fracassar.
Em resumo, empresas de TI não podem trabalhar com projetos simples. Ao contrário, elas precisam encontrar formas para trabalhar à beira do caos, mas isto já é assunto para o próximo post.
Referência:
KEN SCHWABER, Agile Project Management With Scrum: Microsoft Press, 2004
Por Samba Tech em Samba Insight em julho.2.2009
Estouro no orçamento, atrasos e comprometimento do conteúdo são os principais problemas enfrentados em projetos de software.
Avaliando que em projetos baseados no modelo PMI, a fase de planejamento corresponde em média a 30% do cronograma total, verifica-se o verdadeiro caos que é trabalhar com estimativas de projetos de software. Para quebrar esse paradigma o físico israelense. Dr. Eliyahu M. Goldratt apresentou ao mundo a Corrente Crítica.
A Corrente Crítica é considerada um dos maiores avanços na área de gerenciamento de projetos dos últimos 30 anos e tem sua origem na Teoria das Restrições.
Assim como em uma corrente, a empresa é tão forte quanto o seu elo mais fraco. Logo, se quisermos melhorar o desempenho do sistema, precisamos conhecer sua principal restrição e atuar nela, de forma a promover um processo de melhoria contínua. (A Meta, Eliyahu Goldratt)
Conforme Goldratt explica no livro “Corrente Crítica” as previsões de estimativas são fornecidas sempre por pessoas distintas, que têm somente acesso às etapas dos projetos nas quais estão diretamente envolvidas. Há uma tendência natural, impulsionada pela incerteza característica da atividade, de se pôr o máximo de segurança nos tempos de processo.
Diferentemente dos atrasos de uma atividade, que são passados para outras atividades por completo, comprometendo todo o cronograma do projeto, os avanços feitos em uma atividade são geralmente desperdiçados. Estes mecanismos de “segurança” que são embutidos e prejudicam as estimativas são o que o autor caracteriza como:
• Síndrome do estudante: é esperar que uma atividade se torne realmente urgente para realizá-la.
• Lei de Parkinson: é fazer com que o trabalho se expanda para preencher todo o tempo disponível, mesmo que a atividade possa ser concluída antes do tempo, o recurso gastará todo o tempo estimado.
A Corrente Crítica sugere que se planeje as atividades estimando suas durações de forma agressiva, reduzindo o tempo, mas de forma que seja possível a realização, para cada atividade do cronograma.
Os tempos estimados que representam essa “margem de segurança”serão colocados ao final do cronograma, que geralmente é uma estimativa baseada na média da duração das tarefas. Assim consegue-se uma redução em torno de 50% da estimativa original do cronograma. Esta margem de segurança é chamada de “pulmão”.
Exemplo:
Podemos perceber que trabalhar com corrente crítica em projetos é uma mudança de paradigma necessária e fundamental para que os projetos de software possam ter respaldo e confiança dos clientes, eliminando todos os desperdícios que são embutidos nas atividades estimadas.
As metodologias ágeis também trabalham de forma a reduzir as “margens de seguranças” existentes em cronograma de projetos. Uma agregação de valor para os projetos de software poderia ser o uso de uma metodologia ágil com os conceitos de Corrente Crítica. Vale à pena pensar no assunto!
REFERÊNCIAS:
GOLDRATT, ELIYAHU. The Goal. Great Barrington: North River Press, 1992.
GOLDRATT, ELIYAHU. Critical Chain. Great Barrington: North River Press, 1997.
Por Samba Tech em Samba Insight em junho.29.2009
Se você conversar com seus amigos, seja na empresa, faculdade, internet ou até mesmo em uma festa, tem sempre alguém falando em “projeto”, palavra que começou a fazer parte com mais frequência em nosso cotidiano. Para tudo de novo que se pretende fazer, é dado o nome de projeto, seja para construir uma casa, fazer uma viagem, criar uma lei, ou até mesmo o seu projeto de vida. Mas afinal, o que é um projeto?
Segundo o PMBOK, “projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo”. É importante ressaltar que possui um objetivo específico e único. Normalmente possui recursos finitos (pessoas, investimentos, equipamentos, etc).
Um projeto é temporário por ter seu começo e fim definidos e conhecidos. Se não tem fim, é um produto, um processo ou uma operação. Tem um objetivo específico porque deve estar claro qual a meta do projeto, ou seja, o resultado esperado. E é único pois não se repete, por mais que você irá fazer a mesma coisa, como por exemplo, construir uma nova casa com o mesmo projeto (planta), essa será única pois algumas características serão alteradas (tempo, imprevistos, variações ambientais, material, equipe, etc).
Quando falamos de projeto, temos basicamente cinco fases: iniciação, planejamento, execução, controle e finalização. Dessas fases, a fase de planejamento é considera muito importante pois determinará o curso de todo o projeto (início, meio e fim), logo deverá ser bem feita.
Mas afinal, é mais importante planejar ou executar? Será que devemos investir a maior parte do tempo do projeto em planejamento ou começar a executar e com o tempo realizar as adequações? Essa é a grande dúvida quando falamos em criar um produto ou serviço onde envolve desenvolvimento de software.
Nos próximos posts irei falar sobre projetos de desenvolvimento de software, metodologias ágeis e compartilhar experiências (boas e ruins).
Por Samba Tech em Samba Insight em junho.23.2009
Muito se tem falado sobre Cloud Computing, mas esse é um conceito que há muito tempo já é utilizado. Um exemplo claro disso são os serviços de webmail terceirizados oferecidos para empresas, onde se paga pela quantidade de armazenamento utilizado. Entretanto, o termo se popularizou com a disponibilização simplificada de recursos computacionais (processamento e memória) sobre demanda (pague o que utilizar) para pequenas e médias empresas. Isso possibilitou que essas empresas, normalmente sem muito dinheiro em caixa, não precisassem pagar por máquinas caras à espera de uma possível grande carga em seus sistemas. Agora é possível pagar por poucos recursos computacionais em momentos de pouca utilização e por mais recursos quando o tráfego aumenta. Isso tráz um grande ganho e melhores resultados a essas empresas.
A popularização desses mecanismos, representado principalmente pelo Amazon Elastic Compute Cloud (Amazon EC2, http://aws.amazon.com/ec2/), cria a cada dia novas oportunidades para pequenos sistemas competirem com grandes e ricos sites. Porém, tráz também grandes desafios para os arquitetos de software. Com a facilidade de adicionar novas máquinas à estrutura que suporta a sua aplicação, como projetar um sistema que pode ter partes sendo migradas para outras máquinas em busca de mais recursos? Como gerenciar, de forma segura e eficiente, os dados que terão que trafegar entre essas novas máquinas? Quando é realmente necessário mais recursos? Como otimizá-los para não pagar pelo que não é necessário?
Tentarei discutir mais sobre esses desafios em meus próximos posts…
