jump to navigation

Dicas / Truques #3 para criação de cronograma de desenvolvimento de software (tradução) 13/06/2012

Posted by Zaratin in Desenvolvimento, Projetos.
Tags: , ,
add a comment

O Jean-Baptiste Queru soltou a terceira dica dele, segue a tradução.

Link para o original:

https://plus.google.com/112218872649456413744/posts/9oYqAoSRaR4

Com um pouco de cuidado é possível criar cronogramas razoavelmente precisos para desenvolvimento de softwar. No entando, desenvolvimento não é a única parte/tarefa de
engenharia de software. Debugging (me recuso a traduzir) é um aspecto que toma um tempo significante. Por conta disso, Debugging não pode ser ignorado no cronograma.

O problema é que o tempo de debugging não pode previsto: Se fosse possível saber quais bugs seriam feitos durante o desenvolvimento, esses bugs não seriam feitos.

A única maneira de prever é fazer estimativas brutas, que podem ser lapidadas por uma equipe. Como uma regra, quando estiver planejando o tempo utilizado, o ponto de
inicial é assumir que o tempo de debugging será o mesmo de desenvolvimento. Essa não é uma regra, e a realidade irá variar de acordo com a equipe e produto/projeto,
mas é melhor do que nada.

Quando todo o desenvolvimento for finalizado e o único trabalho restante for o debugging, é possível olhar com mais precisão. Nesse ponto, minha regra de ouro para
ponto de partida é que cada bug leva cerca de meio dia ser resolvido. É importante lembrar do primeiro artigo da série onde analistas não tem 100% do tempo deles
disponível, então não é provável um analista resolver 10 bug em uma semana, e a realidade será próxima de 5 bugs corrigidos por semana.

Para finalizar, bugs são imprevisíveis e diferentes. Se analistas tendem a corrigir os bugs fáceis primeiro, os únicos bugs que irá restar são os difíceis. Para evitar situações onde os bugs mais críticos e sem previsão são deixados por último, é importante fazer a correção de forma balanceada. Hoje, minha tática preferida é gerar um hash com o número do bug e priorizar a ordem ordenando as hashkeys.

Não importa o método, planejar qualquer faze de debugging é imprevisível e imprecisa. A única maneira de melhorar nesse ponto é coletar informação dos ciclos de desenvolvimento anteriores e aplicar nos ciclos futuros com o mesmo time e/ou produto.

Posts futuros nessa série irão falar sobre alocações incertas em grandes equipes e estouros de cronograma.

Copyright 2012 Jean-Baptiste Queru / CC:BY 3.0

Veja também a parte #1 da série sobre quanto tempo de um analista pode realmente ser considerado no cronograma
https://rzaratin.wordpress.com/2012/05/31/dicas-truques-1-para-criacao-de-cronograma-de-desenvolvimento-de-software-traducao/

Veja também a parte #2 da série sobre construição de cronogramas quebrando as tarefas em tarefas menores
https://rzaratin.wordpress.com/2012/06/01/dicas-truques-2-para-criacao-de-cronograma-de-desenvolvimento-de-software-traducao/

Qual a diferença entre SaaS e SOA? 12/06/2012

Posted by Zaratin in Desenvolvimento, Projetos.
Tags:
2 comments

Ultimamente tenho visto muita gente falando sobre SaaS e SOA, mas será que as pessoas que estão usando esses termos tem alguma ideia do que eles são e qual o uso deles? Pelo que andei lendo e conversando com algumas pessoas, muita gente nem sabe o significado real das palavras, apenas joga a sopa de letrinhas. Se você quer trabalhar com TI, mesmo sendo RH ou Vendas, acho essencial para um bom profissional conhecer bem os termos da área.

Em resumo SOA é uma arquitetura de desenvolvimento e deploy que pode ser utilizada no desenvolvimento de softwares. Em geral esses softwares são para uso interno nas empresas e desenvolvidos sob-medida.

SaaS é um modelo de negócio para produtos vendidos sob demanda. Ou seja, em geral são produtos feitos para serem usados na web e sem customização para determinada demanda.

Para quem quiser ler mais à respeito, alguns links

http://pt.wikipedia.org/wiki/Service-oriented_architecture

http://pt.wikipedia.org/wiki/Software_como_servi%C3%A7o

http://software.intel.com/en-us/blogs/2008/08/18/soa-and-saas-whats-the-difference//

http://blogs.msdn.com/b/hanuk/archive/2007/04/08/saas-and-soa.aspx

Fecho o texto pedindo para ninguém confundir SaaS com SAS http://pt.wikipedia.org/wiki/Serial_Attached_SCSI

Dicas / Truques #2 para criação de cronograma de desenvolvimento de software (tradução) 01/06/2012

Posted by Zaratin in Projetos.
Tags: , , , ,
add a comment

O Jean-Baptiste Queru soltou a segunda dica dele, segue a tradução.

Link para o original: https://plus.google.com/u/0/112218872649456413744/posts/hGfwXrURjZD

Em desenvolvimento de software, os detalhes são os grandes vilões. Tarefas que parecem simples em alto nível, geralmente revelam complexidades inesperadas quando investigados os detalhes.

Esse é o motivo de ser impossível estimar o tempo de uma tarefa olhando apenas no alto nível. A única maneira de estimar o tempo é quebrar as tarefas, pequenas o suficiente para serem colocadas na cabeça de uma pessoa.

Além disso, como todo analista é diferente, cada tarefa deve ser estimada pelo analista que irá efetivamente fazer o trabalho. Estimar o tempo de cada tarefa individualmente é parte do design do projeto. *

Outra dica importante é que estimativa de tempo não pode ser feita por apenas uma pessoa, é sempre melhor feita em dupla. Por ter que explicar a tarefa para outra pessoa, o analista que está estimando o tempo diminui a velocidade da tarefa o suficiente para permitir que possa ver detalhes relevantes.

Minha regra de outro é que tarefas precisam ser quebradas até prazos que demorem entre meio dia e dois dias, com granularidade de meio dia. Tarefas com mais de dois dias são complexas demais para serem estimadas. Tarefas também não podem durar menos de meio dia, por conta do tempo que será necessário para compilar o código, instalar, executar os testes e fazer uma revisão do código.

Copyright 2012 Jean-Baptiste Queru / CC:BY 3.0

* Aqui coloco um comentário meu, muitos analistas tem o costume de estimar para baixo o tempo de conclusão de uma tarefa, achando que assim irão agradar o gerente, o problema é que isso pode gerar diversos problemas como não entrega da tarefa no prazo estimado, o que pode comprometer todo o cronograma do projeto e o trabalho de outros analistas. Nesse caso acho que é interessante sempre ter um analista sênior acompanhando os mais novos.

Veja também a parte #1 da série sobre quanto tempo de um analista pode realmente ser considerado no cronograma
https://rzaratin.wordpress.com/2012/05/31/dicas-truques-1-para-criacao-de-cronograma-de-desenvolvimento-de-software-traducao/

Dicas / Truques #1 para criação de cronograma de desenvolvimento de software (tradução) 31/05/2012

Posted by Zaratin in Projetos.
Tags: , , , ,
add a comment

Semana passada recebi um link de um artigo do Jean-Baptiste Queru (Software Engineer do Google) com dicas sobre estimativa de tempo de tarefas, ele fez algo focado em desenvolvimento de software, mas eu acredito que possa ser utilizado para diversos outros fins. Vou deixar aqui uma tradução do artigo.

Parte #1

Quem quiser ler o orginal, segue o link https://plus.google.com/u/0/112218872649456413744/posts/YZZrAbJeqdb

Criar cronogramas para desenvolvimento de software é difícil. Alguns consideram uma arte obscura. Aprendi alguns truques quem tornam o processo um pouco mais preciso. Aqui vai o primeiro truque.

Analistas vão para reuniões. Eles lidam com papelada. Eles fazem entrevistas. Eles treinam novos analistas. Eles preparam apresentaçãoes e demos. Eles participam de apresentação e demos. Eles vão à conferências. Eles apresentam palestras. Eles lidam com fornecedores. Eles lidam com clientes. Eles lidam com usuários. Eles tiram folgas. Eles perdem tempo com builds quebrados. Eles contribuem com alterações de código. Eles configuram suas estações de trabalho e outras ferramentas. Eles fazem manutenção de código de outras versões/tarefas.

Todas essas tarefas são comuns à Analistas . E elas precisam ser levadas em consideração quando o cronograma está sendo preparado. No entendo, elas não devem ser parte da estimativa de nenhum projeto.

Minha dica para criação de cronogramas é considerar que analistas tem cerca de 50% do tempo deles disponvíel para a tarefa que foi programada. A outra metade vai para as tarefas indiretas mencionadas acima. Se uma tarefa para uma pessoas está estimada em 20 man-days, existe uma boa chance dessa tarefa levar cerca de 2 meses para ser finalizada em condições normais de trabalho.

O valor 50% é apenas uma estimativa. Esse valor fica provavelmente entre 40% e 60% na maioria dos casos. Em casos extremos esse valor pode ser acima ou abaixo. No entando, não existe a menor chance de um analista conseguir produzir 1 man-day por dia de trabalho sem que sejam feitas significantes e insustentáveis horas extras.

Copyright 2012 Jean-Baptiste Queru / CC:BY 3.0

Mover arquivos usando VB.net em um FTP 30/05/2012

Posted by Zaratin in Desenvolvimento.
Tags: , ,
add a comment

Retomando o blog com um artigo bem técnico, esses dias estava dando manutenção em um aplicativo em VB .Net e uma das tarefas era mover arquivos de um diretório para outro, usando apenas o que estivesse disponível no framework 2.0 do .Net.

A resposta / solução para esse problema é relativamente simples, não existe um comando para mover arquivos de um diretório para outro, nesse caso, basta renomear o arquivo com o novo caminho. Abaixo alguns exemplos de código.

Exemplo de código para criar diretórios:

Dim ftpReq As FtpWebRequest
Dim ftpRes As FtpWebResponse
ftpReq = FtpWebRequest.Create("ftp://ftp.meusite.com/novapasta/")
ftpReq.Method = WebRequestMethods.Ftp.MakeDirectory
ftpReq.Credentials = New NetworkCredential("usuario","senha")
ftpRes = DirectCast(ftpReq.GetResponse(), System.Net.FtpWebResponse)
ftpRes.Close()

Exemplo de código para “mover” arquivos:

Dim ftpReq As FtpWebRequest
Dim ftpRes As FtpWebResponse
ftpReq = FtpWebRequest.Create("ftp://ftp.meusite.com/arquivo.txt")
ftpReq.Method = WebRequestMethods.Ftp.Rename
ftpReq.Credentials = New NetworkCredential("usuario","senha")
ftpReq.UseBinary = True
ftpReq.RenameTo = "/novapasta/arquivo.txt"
ftpRes = DirectCast(ftpReq.GetResponse(), System.Net.FtpWebResponse)