HI,
Já tem um tempão que criei meu Twitter, mas como não queria escrever se eu tava sentado no vazo sanitário ou escobando os dentes, não tava postando nada nele.
Mas agora já sei o que escrever nele ( claro que cometo um certo pecado de falar da minha vida pessoal, hehehe ). Vou postar dicas sobre tecnologia, desenvolvimento, etc. Não será apenas um instrumento de apontar para artigos aqui do blog. Terá conteúdo próprio.
Espero vocês lá: http://twitter.com/dprogrammer
Tem um post sobre download de vídeo aulas e apostilas sobre C# e Visual Basic.Net.
Até Mais
segunda-feira, agosto 24, 2009
domingo, agosto 02, 2009
Apagando todos os contatos do windows mobile
HI,
Depois de alguns meses sem aparecer por aqui, sem responder aos comentários, resolvi aproveitar um novo começo de mês para voltar a atualizar esse blog e ao site de vídeos que tenho, que também foi abandonado.
Começo com uma chatice que tive ao acessar o MSN a partir do windows mobile 6, com o meu htc p4351. Quando fui realizar o login pela primeira vez apareceu uma tela de sim/não dizendo que todos o meus contatos do msn seriam incluídos nos contatos do wm. Tava precisando acessar o MSN naquele momento, então permiti.
Pensem na bagunça que ficou meus contatos. Mais de 180 contatos, hehehe. Resolvi então a excluir alguns contatos do ppc. Dois problemas: A tela de contatos do windows mobile não permite selecionar mais de um registro e o contato também será excluído do MSN, hehehe.
Resolvi excluir todos os contatos do ppc. Procurei a solução e encontrei uma maneira de fazer uma limpa geral nos contatos.
Solução: Start>Settings>Sim Manager>Menu>Delete Contacts.
Na busca em um forum encontrei a dica e usar outro programa para conversar com o MSN. Acabei instalando o Palringo. Tá perfeito agora. Ele conversa com outros serviços também.
Uma amigo passou pelo mesmo problema. Ele excluiu tudo e foi usar o msn de novo e os contatos sumiram do MSN. Ele disse que tem uma opção de recuperar os contatos no messenger.
Não testei a possibilidade de sincronizar os contatos com o outlook, excluir os contatos do MSN, deixando apenas os contatos do Telefone e mandando sincronizar de novo. Para ver se remove do ppc esses contatos que foram excluídos no pc.
Até Mais.
Depois de alguns meses sem aparecer por aqui, sem responder aos comentários, resolvi aproveitar um novo começo de mês para voltar a atualizar esse blog e ao site de vídeos que tenho, que também foi abandonado.
Começo com uma chatice que tive ao acessar o MSN a partir do windows mobile 6, com o meu htc p4351. Quando fui realizar o login pela primeira vez apareceu uma tela de sim/não dizendo que todos o meus contatos do msn seriam incluídos nos contatos do wm. Tava precisando acessar o MSN naquele momento, então permiti.
Pensem na bagunça que ficou meus contatos. Mais de 180 contatos, hehehe. Resolvi então a excluir alguns contatos do ppc. Dois problemas: A tela de contatos do windows mobile não permite selecionar mais de um registro e o contato também será excluído do MSN, hehehe.
Resolvi excluir todos os contatos do ppc. Procurei a solução e encontrei uma maneira de fazer uma limpa geral nos contatos.
Solução: Start>Settings>Sim Manager>Menu>Delete Contacts.
Na busca em um forum encontrei a dica e usar outro programa para conversar com o MSN. Acabei instalando o Palringo. Tá perfeito agora. Ele conversa com outros serviços também.
Uma amigo passou pelo mesmo problema. Ele excluiu tudo e foi usar o msn de novo e os contatos sumiram do MSN. Ele disse que tem uma opção de recuperar os contatos no messenger.
Não testei a possibilidade de sincronizar os contatos com o outlook, excluir os contatos do MSN, deixando apenas os contatos do Telefone e mandando sincronizar de novo. Para ver se remove do ppc esses contatos que foram excluídos no pc.
Até Mais.
sábado, março 21, 2009
Retornar a data do primeiro e do último dia da semana
HI,
Estou trabalhando em uma rotina para enviar a rota da semana para os vendedores. Minha idéia foi de enviar todos os registros da semana, e não apenas do dia atual até o último dia da semana.
Então como fazer para enviar os registros que estão entre Domingo e Sábado ?
Abrir o delphi e fiz um algotimo para pegar a data do primeiro dia (Domingo) da semana e do último (Sábado) dia.
Ficou assim:
procedure TForm1.BitBtn1Click(Sender: TObject);
Var DiaSemanaHoje : Byte;
begin
DiaSemanaHoje := DayOfWeek(Date());
Edit2.Text := DateToStr(Date() - (DiaSemanaHoje - 1));
Edit3.Text := DateToStr(Date() + (7 - DiaSemanaHoje));
end;
Preciso utiliza isso no Oracle. Então lá vou eu para a home page do banco de dados (utilizo o oracle express aqui no note).
Peguei o exemplo que se encontra aqui no blog para pegar o dia da semana e bolei essa Sql:
select SYSDATE AS HOJE,
SYSDATE - (to_char(SYSDATE, 'D') - 1) AS DOMINGO,
SYSDATE + (7 - to_char(SYSDATE, 'D')) AS SABADO
from dual
Pronto. Já posso trabalhar com essa lógica no Where.
Mas aí achei um jeito mais simples, hehehe.
Pegar pelo dia da semana no ano.
Então o Where vai ficar assim (Delphi):
Sql.Add('Where to_char(SYSDATE, ''WW'') = ' + IntToStr(WeekOfTheYear(Date)));
Espero que possa ajudar mais alguém com isso.
[editando]
Mostrei esse código a um amigo que é DBA e ele me mostrou outra maneira de pegar as datas do primeiro e último dia da semana utilizando a função do NEXT_DAY do Oracle.
select sysdate AS HOJE ,
TRUNC(next_day(sysdate,'MONDAY')-8) as DOMINGO,
TRUNC(next_day(sysdate,'SATURDAY')) as SABADO
from dual
Acabei utilizando essa lógina no meu Where. É que pegando a semana do Ano deu bug, hehehe. Não retornou a Segunda e a Terça.
Where TRUNC(Data) BetWeen TRUNC(next_day(sysdate,'MONDAY')-8) and TRUNC(next_day(sysdate,'SATURDAY'))
Esse TRUNC é para retornar a data sem a parte da hora.
[/editando]
Até +
Estou trabalhando em uma rotina para enviar a rota da semana para os vendedores. Minha idéia foi de enviar todos os registros da semana, e não apenas do dia atual até o último dia da semana.
Então como fazer para enviar os registros que estão entre Domingo e Sábado ?
Abrir o delphi e fiz um algotimo para pegar a data do primeiro dia (Domingo) da semana e do último (Sábado) dia.
Ficou assim:
procedure TForm1.BitBtn1Click(Sender: TObject);
Var DiaSemanaHoje : Byte;
begin
DiaSemanaHoje := DayOfWeek(Date());
Edit2.Text := DateToStr(Date() - (DiaSemanaHoje - 1));
Edit3.Text := DateToStr(Date() + (7 - DiaSemanaHoje));
end;
Preciso utiliza isso no Oracle. Então lá vou eu para a home page do banco de dados (utilizo o oracle express aqui no note).
Peguei o exemplo que se encontra aqui no blog para pegar o dia da semana e bolei essa Sql:
select SYSDATE AS HOJE,
SYSDATE - (to_char(SYSDATE, 'D') - 1) AS DOMINGO,
SYSDATE + (7 - to_char(SYSDATE, 'D')) AS SABADO
from dual
Pronto. Já posso trabalhar com essa lógica no Where.
Mas aí achei um jeito mais simples, hehehe.
Pegar pelo dia da semana no ano.
Então o Where vai ficar assim (Delphi):
Sql.Add('Where to_char(SYSDATE, ''WW'') = ' + IntToStr(WeekOfTheYear(Date)));
Espero que possa ajudar mais alguém com isso.
[editando]
Mostrei esse código a um amigo que é DBA e ele me mostrou outra maneira de pegar as datas do primeiro e último dia da semana utilizando a função do NEXT_DAY do Oracle.
select sysdate AS HOJE ,
TRUNC(next_day(sysdate,'MONDAY')-8) as DOMINGO,
TRUNC(next_day(sysdate,'SATURDAY')) as SABADO
from dual
Acabei utilizando essa lógina no meu Where. É que pegando a semana do Ano deu bug, hehehe. Não retornou a Segunda e a Terça.
Where TRUNC(Data) BetWeen TRUNC(next_day(sysdate,'MONDAY')-8) and TRUNC(next_day(sysdate,'SATURDAY'))
Esse TRUNC é para retornar a data sem a parte da hora.
[/editando]
Até +
segunda-feira, março 02, 2009
Formatação de Datas no Oracle
Dica para formatar uma data no Oracle.
AM - AM ou PM
CC - Século
D - Dia da semana (1-7)
DAY - Dia da semana ('SUNDAY')
DD - Dia do mês (1-31)
DDD - Dia do ano
DY - Dia da semana abreviado ('SUN')
FM - Tira os blanks ou Zeros da esquerda
HH - Hora do dia (0-12)
HH24 - Hora do dia (0-24)
MI - Minutos da Hora
MM - Mês com 2 dígitos
MON - Mês abreviado ('NOV')
MONTH - Mês por extenso ('NOVEMBER')
PM - AM ou PM
RR - Ano com 2 dígitos - especial
RRRR - Ano com 4 dígitos
SS - Segundos do minuto(0 - 59)
SSSSS- Segundos do dia
W - Semana do Mês
WW - Semana do Ano
YEAR - Ano por extenso
YY - Ano com 2 dígitos
YYYY - Ano com 4 dígitos
Achei essa dica quando precisei semana passada pegar o dia da semana, para determinar se era dia útil, sábado ou domingo.
Exemplo: select to_char(SYSDATE, 'D') from dual
Até Mais.
AM - AM ou PM
CC - Século
D - Dia da semana (1-7)
DAY - Dia da semana ('SUNDAY')
DD - Dia do mês (1-31)
DDD - Dia do ano
DY - Dia da semana abreviado ('SUN')
FM - Tira os blanks ou Zeros da esquerda
HH - Hora do dia (0-12)
HH24 - Hora do dia (0-24)
MI - Minutos da Hora
MM - Mês com 2 dígitos
MON - Mês abreviado ('NOV')
MONTH - Mês por extenso ('NOVEMBER')
PM - AM ou PM
RR - Ano com 2 dígitos - especial
RRRR - Ano com 4 dígitos
SS - Segundos do minuto(0 - 59)
SSSSS- Segundos do dia
W - Semana do Mês
WW - Semana do Ano
YEAR - Ano por extenso
YY - Ano com 2 dígitos
YYYY - Ano com 4 dígitos
Achei essa dica quando precisei semana passada pegar o dia da semana, para determinar se era dia útil, sábado ou domingo.
Exemplo: select to_char(SYSDATE, 'D') from dual
Até Mais.
sexta-feira, fevereiro 27, 2009
Delphi HTML Preview
HI,
Acabei de preparar um exemplo com uma rotina que achei para visualizar um código HTML no componente WebBrowser sem precisar criar um arquivo.
Antes quando precisa exibir algo em HTML no programa, eu criava um arquivo .html com o código e caregava no componente. Mas recentemente precisei exibir um código HTML armazenado no banco de dados. Poderia ter feito no esquema que já sabia, mas decidi fazer algo mais decente, hehehe. Pegar o código e carregar diretamente no componente TWebBrowser.
Download do exemplo AQUI.
Até Mais.
Acabei de preparar um exemplo com uma rotina que achei para visualizar um código HTML no componente WebBrowser sem precisar criar um arquivo.
Antes quando precisa exibir algo em HTML no programa, eu criava um arquivo .html com o código e caregava no componente. Mas recentemente precisei exibir um código HTML armazenado no banco de dados. Poderia ter feito no esquema que já sabia, mas decidi fazer algo mais decente, hehehe. Pegar o código e carregar diretamente no componente TWebBrowser.
Download do exemplo AQUI.
Até Mais.
O Desenvolvedor agora brinca no Google
HI,
Tem coisa melhor do que aprender com exemplos?
Ben Lisbakken, engenheiro do Google criou um serviço para facilitar a vida de quem deseja aprender a trabalhar com as APIs em JavaScript do Google. Ele chegou a conclusão de que os manuais não eram o suficiente para o aprendizado das APIs e criou esse serviço nos seus 20% de tempo que são dedicados aos projetos pessoais.
Acho que se eu dormir só umas quatro horas por dia, sobra um pouco de tempo para esses tais projetos pessoais. Geralmente trabalho das 07:30 às 00:00, hehehe. Acordo às 06:00.
Ontem andei brincando nesse PlayGround. São dezenas de exemplos agrupados pelos tipos de APIs. É possível editar o exemplo e visualizar todo o código.
Excelente iniciativa. Lembro que eu vivia no Help do Pascal olhando os exemplos. Aprendi muito. E eu nem entendia direito o que estava escrito. Estava em inglês, hehehe. Até brinco dizendo que primeiro entendia o exemplo para depois saber o que tava escrito, hehehe.
Fonte: Blog da Info
Até Mais.
Tem coisa melhor do que aprender com exemplos?
Ben Lisbakken, engenheiro do Google criou um serviço para facilitar a vida de quem deseja aprender a trabalhar com as APIs em JavaScript do Google. Ele chegou a conclusão de que os manuais não eram o suficiente para o aprendizado das APIs e criou esse serviço nos seus 20% de tempo que são dedicados aos projetos pessoais.
Acho que se eu dormir só umas quatro horas por dia, sobra um pouco de tempo para esses tais projetos pessoais. Geralmente trabalho das 07:30 às 00:00, hehehe. Acordo às 06:00.
Ontem andei brincando nesse PlayGround. São dezenas de exemplos agrupados pelos tipos de APIs. É possível editar o exemplo e visualizar todo o código.
Excelente iniciativa. Lembro que eu vivia no Help do Pascal olhando os exemplos. Aprendi muito. E eu nem entendia direito o que estava escrito. Estava em inglês, hehehe. Até brinco dizendo que primeiro entendia o exemplo para depois saber o que tava escrito, hehehe.
Fonte: Blog da Info
Até Mais.
Integrando seu site ao PagSeguro
quarta-feira, fevereiro 18, 2009
LG passa a usar o Windows Mobile
Por Daniel Serrano
A Microsoft está com motivos de sobra para comemorar. Esta semana a empresa anunciou que a LG um dos maiores fabricantes do mundo de celulares estará utilizando o seu sistema operacional Mobile (foto) em mais de 50 modelos, o que aumentará substancialmente o market share da MS em operacionais para dispositivos móveis.
A LG já havia utilizado o Windows Mobile anteriormente, mas apenas em um único modelo. A MS cujo sistema operacional Windows equipa mais de 90% de notebooks e PCs, ao redor do mundo, segundo dados da empresa, quer repetir a façanha nos dispositivos móveis.
Restante da notícia AQUI
http://planetech.uol.com.br/?p=4070
É bom saber disso. Um dos motivos de minha ausência aqui no blog é o fato deu está trabalhando no desenvolvimento de um sistema de vendas para Windows Mobile. A versão atual é em PalmOS e a Palm está nos abandonando. O novo SmartPhone, o palm Pré, com sistema operacional WebOS não executará os aplicativos antigos.
E ainda tem o fato da Microsoft ter anunciado a nova versão do Windows Mobile, versão 6.5. Significa que em breve teremos a 7.0. Acho que vem no mesmo tempo do Windows 7.
Até a Próxima.
A Microsoft está com motivos de sobra para comemorar. Esta semana a empresa anunciou que a LG um dos maiores fabricantes do mundo de celulares estará utilizando o seu sistema operacional Mobile (foto) em mais de 50 modelos, o que aumentará substancialmente o market share da MS em operacionais para dispositivos móveis.
A LG já havia utilizado o Windows Mobile anteriormente, mas apenas em um único modelo. A MS cujo sistema operacional Windows equipa mais de 90% de notebooks e PCs, ao redor do mundo, segundo dados da empresa, quer repetir a façanha nos dispositivos móveis.
Restante da notícia AQUI
http://planetech.uol.com.br/?p=4070
É bom saber disso. Um dos motivos de minha ausência aqui no blog é o fato deu está trabalhando no desenvolvimento de um sistema de vendas para Windows Mobile. A versão atual é em PalmOS e a Palm está nos abandonando. O novo SmartPhone, o palm Pré, com sistema operacional WebOS não executará os aplicativos antigos.
E ainda tem o fato da Microsoft ter anunciado a nova versão do Windows Mobile, versão 6.5. Significa que em breve teremos a 7.0. Acho que vem no mesmo tempo do Windows 7.
Até a Próxima.
segunda-feira, dezembro 22, 2008
Sete maneiras de melhorar o desenvolvimento de software
A receita para equilibrar agilidade e documentação e estabelecer um ciclo de entregas regulares existe. Leia a opinião de especialistas
Para se concretizarem, os projetos de software exigem investimentos, apoio, cuidados, trabalho árduo e dedicação. Uma boa prática de gerenciamento de entrega garante que, depois de criado, o software possa ser implementado com êxito, atendendo às necessidades da área que o solicitou e, ainda, de outras unidades que queiram utilizá-lo no futuro.
Na lista de clientes que confirmam essa premissa está uma grande empresa britânica de telecomunicações. A companhia decidiu mudar de fornecedor na hora de realizar uma reengenharia dos sistemas para gestão da área de billing (bilhetagem) e da emissão de contas. A companhia tinha de implementar as mudanças em três meses ou poderia perder centenas de milhões de libras, inclusive com queda no valor das ações. Outra questão era que, na época, os processos para desenvolvimento de software eram ruins e o gerenciamento de entrega extremamente problemático.
A empresa de telecomunicações chamou uma empresa especializada para ajudá-la a entregar o software no prazo e recuperar um processo falho de gerenciamento das mudanças. Com isso, em três meses, fez os lançamentos pendentes e conseguiu realizar a reformulação de dois aplicativos. Mais importante, estabeleceu um processo de gerenciamento de entregas simples e direto para assegurar que futuras liberações aconteçam no devido tempo e com a qualidade exigida.
A seguir, segue um detalhamento de todo o processo, inclusive, com os erros cometidos.
1. Entender o estado atual do gerenciamento de entregas.
Você não pode começar a consertar alguma coisa sem entender o que ela é e qual o problema. O primeiro passo para aprimorar o sistema de gerenciamento das entregas do nosso cliente foi criar um panorama detalhado do processos antigos. Para começar, a empresa realizou várias sessões explanatórias com pessoas-chave envolvidas no processo de software.
Nas reuniões, o fornecedor descobriu que o ponto de partida era muito ruim: ainda havia software a espera de liberação, depois de dois meses em que ele estava pronto.
Os ambientes de teste eram limitados, sem gerenciamento e, portanto, desatualizados e impossíveis de usar. Pior ainda, melhorar novos ambientes e renovar os existentes era um processo relativamente lento.
Em média, um teste manual de software demorava três meses. E boa parte deles acabava sendo abandonado, o que reduzia a qualidade das soluções entregues.
De um modo geral, o engajamento da equipe de desenvolvimento era muito baixo. Como os profissionais nunca tinham sido ajudados a fornecer software de boa qualidade, regularmente, estavam desestimulados.
2. Estabelecer um ciclo regular de liberações.
Quando obtivemos um panorama geral do estado atual do processo, começamos a definir um ciclo regular de liberações.
Se a equipe de engenharia é o coração do projeto, o ciclo de liberações é seu batimento cardíaco. Para determinar a freqüência de liberações para produção, foi preciso descobrir de quanto teste não funcional precisaríamos e quanto tempo demoraria. Este projeto exigiu teste de regressão, desempenho e integração.
Estabelecer um ciclo de liberações é vital porque:
• Cria uma oportunidade de discutir a fundo os testes não funcionais de que o software possa precisar.
• Anuncia um cronograma de entrega das porções da funcionalidade que as partes interessadas poderão obter. Se elas souberem que haverá liberação de funcionalidade regularmente, podem continuar concordando em relação ao resultado final esperado.
• Cria uma rotina que todas as equipes podem seguir (inclusive marketing e engenharia).
• Dá aos clientes a confiança de que podem pedir algo e receber o que pediram.
O ciclo de liberações tem de ser o mais exato possível, não um número inatingível que você inventou durante o almoço. Antes de anunciá-lo, teste-o. Não há nada pior para um processo de liberações já falho do que mais datas ilusórias!
Sugerimos um ciclo semanal. Este plano, porém, mostrou-se inviável, já que o ambiente de banco de dados do cliente não podia ser renovado com suficiente rapidez. Então tentamos ciclos quinzenais. Não houve objeção imediata dos participantes, mas as duas primeiras tentativas fracassaram! Tornou-se viável depois que superamos alguns gargalos do ambiente e automatizamos alguns testes.
Por fim, estabelecemos um ciclo em que, a cada duas semanas, o código da equipe de engenharia, pronto para produção, era encaminhado para teste no sistema. Quinze dias depois, liberamos este código para produção.
Lembre-se: seu ciclo de liberações não diz respeito a quando seu cliente quer a liberação, mas quando você pode realizá-la com o nível desejado de qualidade. Nossos clientes apoiaram nosso ciclo de liberações porque nós os chamamos para ajudar a determiná-lo. A opinião dos clientes é apenas um dos fatores levados em conta para estabelecer a regularidade das liberações.
3. Adotar processos leves. Testá-los no início e revisá-los regularmente.
Se existe um princípio norteador da engenharia (ou reengenharia) de um processo, este princípio é desenvolver um pouco, analisar os resultados e fazer um pouco mais. Repita esta abordagem cíclica até alcançar os resultados desejados.
Processos leves são aqueles que não exigem aprovações longas e burocráticas ou reuniões intermináveis para obter consenso. Normalmente, demandam apenas o nível mínimo aceitável de inputs e outputs. O que lhes falta em volume e burocracia é compensado com resposta a mudanças e adoção popular!
Subjacente a esta abordagem há o problema espinhoso da documentação. Você precisa registrar o que fez e como fez. Do contrário, o que vai revisar e como vai melhorar?
Não é o tipo de documentação volumosa que ameaça as florestas tropicais ou dá sono nos leitores. É a documentação que as pessoas (técnicas ou não) podem ler e seguir.
A equipe de engenharia escolheu uma ferramenta comercial para documentar seu trabalho colaborativo. Os engenheiros usaram o software para elaborar uma documentação mínima, porém eficaz, do que estavam concordando em criar em cada ciclo de trabalho. Registraram o que e como tinham criado e o que era necessário para que entrasse em funcionamento. Vimos o valor desta abordagem e a implementamos -- assim como a ferramenta – para o restante dos envolvidos no processo.
Inicialmente, sugerimos uma seqüência de tarefas para liberar o software que recebemos das equipes de engenharia, abrangendo o modo como recebemos a entrega por parte do sistema de gerenciamento de controle de origem, que nomes os pacotes teriam e como cada elemento (código executável, scripts de banco de dados etc.) funcionaria em quais plataformas. Depois fizemos um teste simulado utilizando código fictício para cada elemento. Testamos nossa seqüência documentando o que e como fizemos. Isso formou a base das instruções de instalação.
Em seguida, as pessoas que iriam implementar o release real fizeram outro teste simulado usando apenas a nossa documentação. Elas estenderam, corrigiram e aprimoraram nossas instruções. O processo se tornou mais abrangente e todos colaboraram com a documentação. O processo foi adotado de maneira mais ampla e com mais qualidade, já que todos ajudaram a defini-lo.
Revisamos o processo depois de cada liberação. Examinamos a documentação e identificamos mudanças feitas durante a liberação. A cada vez, verificamos como a documentação poderia ser aprimorada e incorporamos os aprimoramentos ao processo.
4. Estabelecer uma infra-estrutura de liberações no início.
A infra-estrutura de liberações é tudo aquilo que precisa existir para que o software seja implementado e as pessoas possam utilizá-lo. Seu compromisso com o cliente não é somente criar um software excelente, mas que ele esteja disponível para ser acessado e utilizado.
Para obter um bom processo de liberação, é crucial que você descubra o que precisa estar implantando para disponibilizar ao cliente antes da equipe de engenharia acabar de criar o software.
A infra-estrutura de liberações cobre hardware, storage, conexões de rede, banda larga, licenças de software, perfis dos usuários e permissões de acesso. Recursos humanos e habilidades também fazem parte da infra-estrutura de liberações. Se você precisa que um software especializado seja instalado e configurado, por exemplo, não é uma atitude inteligente excluir do seu plano de infra-estrutura a disponibilidade das habilidades envolvidas ou o custo de obtê-las.
Quando estiver em busca do hardware necessários ou das habilidades que faltam (por exemplo, para configurar redes seguras), é vital descobrir gargalos ocultos o mais cedo possível. Você precisa resolvê-los antes que eles atrasem a entrega do software.
Não é coisa simples. Nós nos esforçamos para implantar nossa infra-estrutura de liberações assim que iniciamos o projeto. Depois de seis semanas, ainda estávamos esperando memória e hard drives especiais para os servidores de teste!
5. Automatizar e padronizar o máximo possível.
A automação permite que você execute tarefas repetitivas sem comprometer recursos humanos valiosos. A padronização garante que inputs e outputs da automação sejam consistentes o tempo todo.
Antes do nosso envolvimento com o projeto, as equipes de engenharia produziam manualmente um pacote implementável. Não havia garantia de que um novo pacote seria igual ao anterior. Na realidade, nem havia garantia de que era o software que as equipes andavam desenvolvendo e se funcionaria! Muitas vezes, a equipe técnica levava dias para criar um pacote com os recursos que estavam sendo entregues em uma estrutura que pudesse ser implementada.
Formulamos imediatamente uma estrutura e critérios de aceitação para o pacote implementável que as equipes estavam nos entregando e as ajudamos a padronizar o empacotamento. Isso ativou a implementação de processos automatizados para criar o software nesta estrutura consistente para cada ponto da liberação.
De repente, o empacotamento do software para liberação deixou de ser um problema. Sua executabilidade estava garantida, já que tínhamos automatizado a verificação dos critérios de aceitação — por exemplo, testar o código antes da entrega e implementar o teste para assegurar que a implementação real poderia ser feita. Como resultado, conseguimos empacotar, versionar, testar e implementar código acabado com um único comando em pouquíssimo tempo.
Mas a automação não parou por aí. A cada ciclo de desenvolvimento, tínhamos que fazer ainda mais testes de regressão. Os testes de regressão existentes levavam três semanas para serem executados manualmente e, por isso, as liberações nunca eram bem testadas.
No nosso recém-criado ciclo de liberações, tínhamos que realizar testes de regressão, desempenho e integração em duas semanas para podermos colocar em produção. Podíamos superar a questão de ter diferentes tipos de teste utilizando ambientes separados para cada um. Mas como encaixar três meses de testes de regressão em um período de duas semanas?!
Iniciamos um exercício de priorização. O cliente identificou os testes de regressão mais prioritários, o mínimo que aceitaria como prova de que a antiga funcionalidade ainda executava. Depois partimos para automatizar este conjunto. Testes de aceitação subseqüentes também se tornaram automatizados, assegurando que poderíamos fazer testes de regressão em cada liberação em algumas horas em vez de dias.
6. Estabelecer expectativas positivas.
Se a liberação de software é importante para você, não faça segredo disso. Nossas equipes reforçaram o compromisso de liberar o software quando sabiam que era importante.
Endossamos esta importância ao estabelecer que o gerente de liberações designado presumiria que o software estaria pronto na data que as equipes concordaram que ele estaria pronto. Fizemos o gerente de programa (na realidade, nosso cliente) explicar para as equipes por que esta liberação era importante. (No fim das contas, o motivo era não perder muito dinheiro!)
Pedimos que o software fornecido pelas equipes de engenharia seguisse um padrão (versionado, testado, documentado e empacotado). Estabelecemos que solicitaríamos este empacotamento padrão para cada ciclo de liberação. Tivemos de explicar por que queríamos o software desta maneira (nosso processo automatizado se tornava mais fácil e consistente) e incorporamos o feedback da equipe ao processo.
Estabelecer expectativas positivas é uma ótima maneira de empoderar todos os envolvidos no processo. Não nos foi delegada nenhuma autoridade executiva e, portanto, não receávamos sansões ou demissões. Tínhamos o poder da expectativa positiva para fazer as pessoas aderirem e nos ajudarem a melhorar o processo de liberação. Elas tomaram decisões-chave (que nunca tinham se sentido capazes de tomar antes) porque "Mike e Tym precisam deste software na quinta-feira e nós dissemos que o entregaríamos”.
7. Investir em pessoas.
Não importa o quanto você gaste em hardware, software e processos imaginativos -- sem o comprometimento dos membros da equipe você não alcançará um sucesso sustentável na liberação do seu software.Talvez você nem mesmo tenha um software para liberar!
Provavelmente você pensou que falaríamos em arregimentar as pessoas certas e recompensá-las bem ou que discorreríamos sobre as ferramentas e qualificações necessárias para o trabalho. A verdade é que você sabe que precisa ter as pessoas certas nas equipes (a definição de "certas" varia de uma empresa para outra), você deve recompensá-las adequadamente pelo valor que agregam e, sim, você deve assegurar que elas tenham as ferramentas e qualificações necessárias.
Nossa pressuposição básica é de que as pessoas estão inerentemente interessadas em fazer um bom trabalho. Se você quiser que os membros das suas equipes se importem com seu produto e com a realização de um bom trabalho, antes você precisa demonstrar que se importa com o que é importante para elas. Desde o começo do projeto, criamos um ótimo relacionamento com todos os membros das equipes, baseado em compreensão e respeito mútuo. Demonstramos que éramos flexíveis em termos de desafios pessoais e fizemos o que estava ao nosso alcance para ajudar. Comprar almoço, pegar alguma coisa para beber, organizar treinamento, aconselhar, ouvir problemas, fazer o papel do advogado do diabo... fizemos o que era necessário para que cada indivíduo se sentisse valorizado e um elemento vital do processo.
No nosso primeiro contato com o projeto, detectamos um sentimento geral de apatia. Alguns funcionários fixos mais antigos estavam simplesmente à espera de um pacote de dispensa de pessoal; outros não eram chamados para nada porque nunca tinham feito nada certo. Nos dedicamos a criar um bom relacionamento e despertar um auto-julgamento positivo para que as pessoas voltassem a se importar em adicionar valor pessoal ao processo.
O gerenciamento de liberações é uma parte muito importante de qualquer projeto de software e, freqüentemente, não recebe a atenção que merece. Poderíamos compartilhar muitas outras dicas e observações excelentes sobre nossa experiência de fortalecer o processo de liberações desta empresa de telecomunicações de médio porte. Mas estas são as sete mais importantes para nós neste caso específico, embora suponhamos que sejam idéias muito boas para qualquer situação.
Um bom gerenciamento de liberações exige trabalho árduo, determinação e ótima comunicação. Mas o mais importante é a habilidade de revisar, aprender e adaptar melhorias.
Boa sorte!
Mike Sutton era um menino programador prodígio. Hoje, depois de 15 anos de atuação, deixou de ser tão menino mas é prodigioso em ajudar as equipes de programação a se tornarem fornecedoras de soluções vencedoras utilizando metodologias ágeis e abordagens pragmáticas como as descritas neste artigo. CEO da Wizewerx, é consultor de TI independente especializado em soluções de desenvolvimento Java high-end e coaching e mentoring para métodos ágeis e já trabalhou para empresas de primeira linha no Reino Unido e na Europa.
Tym Moore estava ocupado demais ajudando seus clientes e não conseguiu enviar a tempo sua biografia de autor.
Para se concretizarem, os projetos de software exigem investimentos, apoio, cuidados, trabalho árduo e dedicação. Uma boa prática de gerenciamento de entrega garante que, depois de criado, o software possa ser implementado com êxito, atendendo às necessidades da área que o solicitou e, ainda, de outras unidades que queiram utilizá-lo no futuro.
Na lista de clientes que confirmam essa premissa está uma grande empresa britânica de telecomunicações. A companhia decidiu mudar de fornecedor na hora de realizar uma reengenharia dos sistemas para gestão da área de billing (bilhetagem) e da emissão de contas. A companhia tinha de implementar as mudanças em três meses ou poderia perder centenas de milhões de libras, inclusive com queda no valor das ações. Outra questão era que, na época, os processos para desenvolvimento de software eram ruins e o gerenciamento de entrega extremamente problemático.
A empresa de telecomunicações chamou uma empresa especializada para ajudá-la a entregar o software no prazo e recuperar um processo falho de gerenciamento das mudanças. Com isso, em três meses, fez os lançamentos pendentes e conseguiu realizar a reformulação de dois aplicativos. Mais importante, estabeleceu um processo de gerenciamento de entregas simples e direto para assegurar que futuras liberações aconteçam no devido tempo e com a qualidade exigida.
A seguir, segue um detalhamento de todo o processo, inclusive, com os erros cometidos.
1. Entender o estado atual do gerenciamento de entregas.
Você não pode começar a consertar alguma coisa sem entender o que ela é e qual o problema. O primeiro passo para aprimorar o sistema de gerenciamento das entregas do nosso cliente foi criar um panorama detalhado do processos antigos. Para começar, a empresa realizou várias sessões explanatórias com pessoas-chave envolvidas no processo de software.
Nas reuniões, o fornecedor descobriu que o ponto de partida era muito ruim: ainda havia software a espera de liberação, depois de dois meses em que ele estava pronto.
Os ambientes de teste eram limitados, sem gerenciamento e, portanto, desatualizados e impossíveis de usar. Pior ainda, melhorar novos ambientes e renovar os existentes era um processo relativamente lento.
Em média, um teste manual de software demorava três meses. E boa parte deles acabava sendo abandonado, o que reduzia a qualidade das soluções entregues.
De um modo geral, o engajamento da equipe de desenvolvimento era muito baixo. Como os profissionais nunca tinham sido ajudados a fornecer software de boa qualidade, regularmente, estavam desestimulados.
2. Estabelecer um ciclo regular de liberações.
Quando obtivemos um panorama geral do estado atual do processo, começamos a definir um ciclo regular de liberações.
Se a equipe de engenharia é o coração do projeto, o ciclo de liberações é seu batimento cardíaco. Para determinar a freqüência de liberações para produção, foi preciso descobrir de quanto teste não funcional precisaríamos e quanto tempo demoraria. Este projeto exigiu teste de regressão, desempenho e integração.
Estabelecer um ciclo de liberações é vital porque:
• Cria uma oportunidade de discutir a fundo os testes não funcionais de que o software possa precisar.
• Anuncia um cronograma de entrega das porções da funcionalidade que as partes interessadas poderão obter. Se elas souberem que haverá liberação de funcionalidade regularmente, podem continuar concordando em relação ao resultado final esperado.
• Cria uma rotina que todas as equipes podem seguir (inclusive marketing e engenharia).
• Dá aos clientes a confiança de que podem pedir algo e receber o que pediram.
O ciclo de liberações tem de ser o mais exato possível, não um número inatingível que você inventou durante o almoço. Antes de anunciá-lo, teste-o. Não há nada pior para um processo de liberações já falho do que mais datas ilusórias!
Sugerimos um ciclo semanal. Este plano, porém, mostrou-se inviável, já que o ambiente de banco de dados do cliente não podia ser renovado com suficiente rapidez. Então tentamos ciclos quinzenais. Não houve objeção imediata dos participantes, mas as duas primeiras tentativas fracassaram! Tornou-se viável depois que superamos alguns gargalos do ambiente e automatizamos alguns testes.
Por fim, estabelecemos um ciclo em que, a cada duas semanas, o código da equipe de engenharia, pronto para produção, era encaminhado para teste no sistema. Quinze dias depois, liberamos este código para produção.
Lembre-se: seu ciclo de liberações não diz respeito a quando seu cliente quer a liberação, mas quando você pode realizá-la com o nível desejado de qualidade. Nossos clientes apoiaram nosso ciclo de liberações porque nós os chamamos para ajudar a determiná-lo. A opinião dos clientes é apenas um dos fatores levados em conta para estabelecer a regularidade das liberações.
3. Adotar processos leves. Testá-los no início e revisá-los regularmente.
Se existe um princípio norteador da engenharia (ou reengenharia) de um processo, este princípio é desenvolver um pouco, analisar os resultados e fazer um pouco mais. Repita esta abordagem cíclica até alcançar os resultados desejados.
Processos leves são aqueles que não exigem aprovações longas e burocráticas ou reuniões intermináveis para obter consenso. Normalmente, demandam apenas o nível mínimo aceitável de inputs e outputs. O que lhes falta em volume e burocracia é compensado com resposta a mudanças e adoção popular!
Subjacente a esta abordagem há o problema espinhoso da documentação. Você precisa registrar o que fez e como fez. Do contrário, o que vai revisar e como vai melhorar?
Não é o tipo de documentação volumosa que ameaça as florestas tropicais ou dá sono nos leitores. É a documentação que as pessoas (técnicas ou não) podem ler e seguir.
A equipe de engenharia escolheu uma ferramenta comercial para documentar seu trabalho colaborativo. Os engenheiros usaram o software para elaborar uma documentação mínima, porém eficaz, do que estavam concordando em criar em cada ciclo de trabalho. Registraram o que e como tinham criado e o que era necessário para que entrasse em funcionamento. Vimos o valor desta abordagem e a implementamos -- assim como a ferramenta – para o restante dos envolvidos no processo.
Inicialmente, sugerimos uma seqüência de tarefas para liberar o software que recebemos das equipes de engenharia, abrangendo o modo como recebemos a entrega por parte do sistema de gerenciamento de controle de origem, que nomes os pacotes teriam e como cada elemento (código executável, scripts de banco de dados etc.) funcionaria em quais plataformas. Depois fizemos um teste simulado utilizando código fictício para cada elemento. Testamos nossa seqüência documentando o que e como fizemos. Isso formou a base das instruções de instalação.
Em seguida, as pessoas que iriam implementar o release real fizeram outro teste simulado usando apenas a nossa documentação. Elas estenderam, corrigiram e aprimoraram nossas instruções. O processo se tornou mais abrangente e todos colaboraram com a documentação. O processo foi adotado de maneira mais ampla e com mais qualidade, já que todos ajudaram a defini-lo.
Revisamos o processo depois de cada liberação. Examinamos a documentação e identificamos mudanças feitas durante a liberação. A cada vez, verificamos como a documentação poderia ser aprimorada e incorporamos os aprimoramentos ao processo.
4. Estabelecer uma infra-estrutura de liberações no início.
A infra-estrutura de liberações é tudo aquilo que precisa existir para que o software seja implementado e as pessoas possam utilizá-lo. Seu compromisso com o cliente não é somente criar um software excelente, mas que ele esteja disponível para ser acessado e utilizado.
Para obter um bom processo de liberação, é crucial que você descubra o que precisa estar implantando para disponibilizar ao cliente antes da equipe de engenharia acabar de criar o software.
A infra-estrutura de liberações cobre hardware, storage, conexões de rede, banda larga, licenças de software, perfis dos usuários e permissões de acesso. Recursos humanos e habilidades também fazem parte da infra-estrutura de liberações. Se você precisa que um software especializado seja instalado e configurado, por exemplo, não é uma atitude inteligente excluir do seu plano de infra-estrutura a disponibilidade das habilidades envolvidas ou o custo de obtê-las.
Quando estiver em busca do hardware necessários ou das habilidades que faltam (por exemplo, para configurar redes seguras), é vital descobrir gargalos ocultos o mais cedo possível. Você precisa resolvê-los antes que eles atrasem a entrega do software.
Não é coisa simples. Nós nos esforçamos para implantar nossa infra-estrutura de liberações assim que iniciamos o projeto. Depois de seis semanas, ainda estávamos esperando memória e hard drives especiais para os servidores de teste!
5. Automatizar e padronizar o máximo possível.
A automação permite que você execute tarefas repetitivas sem comprometer recursos humanos valiosos. A padronização garante que inputs e outputs da automação sejam consistentes o tempo todo.
Antes do nosso envolvimento com o projeto, as equipes de engenharia produziam manualmente um pacote implementável. Não havia garantia de que um novo pacote seria igual ao anterior. Na realidade, nem havia garantia de que era o software que as equipes andavam desenvolvendo e se funcionaria! Muitas vezes, a equipe técnica levava dias para criar um pacote com os recursos que estavam sendo entregues em uma estrutura que pudesse ser implementada.
Formulamos imediatamente uma estrutura e critérios de aceitação para o pacote implementável que as equipes estavam nos entregando e as ajudamos a padronizar o empacotamento. Isso ativou a implementação de processos automatizados para criar o software nesta estrutura consistente para cada ponto da liberação.
De repente, o empacotamento do software para liberação deixou de ser um problema. Sua executabilidade estava garantida, já que tínhamos automatizado a verificação dos critérios de aceitação — por exemplo, testar o código antes da entrega e implementar o teste para assegurar que a implementação real poderia ser feita. Como resultado, conseguimos empacotar, versionar, testar e implementar código acabado com um único comando em pouquíssimo tempo.
Mas a automação não parou por aí. A cada ciclo de desenvolvimento, tínhamos que fazer ainda mais testes de regressão. Os testes de regressão existentes levavam três semanas para serem executados manualmente e, por isso, as liberações nunca eram bem testadas.
No nosso recém-criado ciclo de liberações, tínhamos que realizar testes de regressão, desempenho e integração em duas semanas para podermos colocar em produção. Podíamos superar a questão de ter diferentes tipos de teste utilizando ambientes separados para cada um. Mas como encaixar três meses de testes de regressão em um período de duas semanas?!
Iniciamos um exercício de priorização. O cliente identificou os testes de regressão mais prioritários, o mínimo que aceitaria como prova de que a antiga funcionalidade ainda executava. Depois partimos para automatizar este conjunto. Testes de aceitação subseqüentes também se tornaram automatizados, assegurando que poderíamos fazer testes de regressão em cada liberação em algumas horas em vez de dias.
6. Estabelecer expectativas positivas.
Se a liberação de software é importante para você, não faça segredo disso. Nossas equipes reforçaram o compromisso de liberar o software quando sabiam que era importante.
Endossamos esta importância ao estabelecer que o gerente de liberações designado presumiria que o software estaria pronto na data que as equipes concordaram que ele estaria pronto. Fizemos o gerente de programa (na realidade, nosso cliente) explicar para as equipes por que esta liberação era importante. (No fim das contas, o motivo era não perder muito dinheiro!)
Pedimos que o software fornecido pelas equipes de engenharia seguisse um padrão (versionado, testado, documentado e empacotado). Estabelecemos que solicitaríamos este empacotamento padrão para cada ciclo de liberação. Tivemos de explicar por que queríamos o software desta maneira (nosso processo automatizado se tornava mais fácil e consistente) e incorporamos o feedback da equipe ao processo.
Estabelecer expectativas positivas é uma ótima maneira de empoderar todos os envolvidos no processo. Não nos foi delegada nenhuma autoridade executiva e, portanto, não receávamos sansões ou demissões. Tínhamos o poder da expectativa positiva para fazer as pessoas aderirem e nos ajudarem a melhorar o processo de liberação. Elas tomaram decisões-chave (que nunca tinham se sentido capazes de tomar antes) porque "Mike e Tym precisam deste software na quinta-feira e nós dissemos que o entregaríamos”.
7. Investir em pessoas.
Não importa o quanto você gaste em hardware, software e processos imaginativos -- sem o comprometimento dos membros da equipe você não alcançará um sucesso sustentável na liberação do seu software.Talvez você nem mesmo tenha um software para liberar!
Provavelmente você pensou que falaríamos em arregimentar as pessoas certas e recompensá-las bem ou que discorreríamos sobre as ferramentas e qualificações necessárias para o trabalho. A verdade é que você sabe que precisa ter as pessoas certas nas equipes (a definição de "certas" varia de uma empresa para outra), você deve recompensá-las adequadamente pelo valor que agregam e, sim, você deve assegurar que elas tenham as ferramentas e qualificações necessárias.
Nossa pressuposição básica é de que as pessoas estão inerentemente interessadas em fazer um bom trabalho. Se você quiser que os membros das suas equipes se importem com seu produto e com a realização de um bom trabalho, antes você precisa demonstrar que se importa com o que é importante para elas. Desde o começo do projeto, criamos um ótimo relacionamento com todos os membros das equipes, baseado em compreensão e respeito mútuo. Demonstramos que éramos flexíveis em termos de desafios pessoais e fizemos o que estava ao nosso alcance para ajudar. Comprar almoço, pegar alguma coisa para beber, organizar treinamento, aconselhar, ouvir problemas, fazer o papel do advogado do diabo... fizemos o que era necessário para que cada indivíduo se sentisse valorizado e um elemento vital do processo.
No nosso primeiro contato com o projeto, detectamos um sentimento geral de apatia. Alguns funcionários fixos mais antigos estavam simplesmente à espera de um pacote de dispensa de pessoal; outros não eram chamados para nada porque nunca tinham feito nada certo. Nos dedicamos a criar um bom relacionamento e despertar um auto-julgamento positivo para que as pessoas voltassem a se importar em adicionar valor pessoal ao processo.
O gerenciamento de liberações é uma parte muito importante de qualquer projeto de software e, freqüentemente, não recebe a atenção que merece. Poderíamos compartilhar muitas outras dicas e observações excelentes sobre nossa experiência de fortalecer o processo de liberações desta empresa de telecomunicações de médio porte. Mas estas são as sete mais importantes para nós neste caso específico, embora suponhamos que sejam idéias muito boas para qualquer situação.
Um bom gerenciamento de liberações exige trabalho árduo, determinação e ótima comunicação. Mas o mais importante é a habilidade de revisar, aprender e adaptar melhorias.
Boa sorte!
Mike Sutton era um menino programador prodígio. Hoje, depois de 15 anos de atuação, deixou de ser tão menino mas é prodigioso em ajudar as equipes de programação a se tornarem fornecedoras de soluções vencedoras utilizando metodologias ágeis e abordagens pragmáticas como as descritas neste artigo. CEO da Wizewerx, é consultor de TI independente especializado em soluções de desenvolvimento Java high-end e coaching e mentoring para métodos ágeis e já trabalhou para empresas de primeira linha no Reino Unido e na Europa.
Tym Moore estava ocupado demais ajudando seus clientes e não conseguiu enviar a tempo sua biografia de autor.
copiado de
segunda-feira, dezembro 08, 2008
Inglês na Faixa
HI,
Um dia ainda aprendo inglês para poder assistir filmes sem legendas, hehehe. Última vez que tentei, faltou força de vontade. Comprei a coleção BBC English Plus que vinha na revista EPOCA. isso foi em 2006. Estudei uns 5 livros e depois parei.
Vou ver se converto os DVDs para avi e estudar no smartphone, hehehe. Um dia faço isso.
Mas antes de tentar concluir esse curso, vou estudar outros.
No momento estou baixando o Curso Completo em Áudio e Apostila - Inglês Profissional. São 650mb de conteúdo. Vai do básico ao nível profissional.
Antes eu tinha baixado o Curso Básico de Inglês. Aprenda Inglês em apenas 30 dias.
Para ajudar nessa tarefa, também é bom usar o serviço de gratis de alguns sites:
English Experts - guia para quem estuda inglês por contra própria usando a internt.
Tecla SAP - dicas de inglês.
Inglês Curso - curso grátis de inlgês
Audiobooks Gratuitos em Inglês - livros em audio.
BBC Learning English - estude inglês no site da BBC.
Se alguém tiver alguma dica ae, é só dizer que atualizo este post.
Um dia ainda aprendo inglês para poder assistir filmes sem legendas, hehehe. Última vez que tentei, faltou força de vontade. Comprei a coleção BBC English Plus que vinha na revista EPOCA. isso foi em 2006. Estudei uns 5 livros e depois parei.
Vou ver se converto os DVDs para avi e estudar no smartphone, hehehe. Um dia faço isso.
Mas antes de tentar concluir esse curso, vou estudar outros.
No momento estou baixando o Curso Completo em Áudio e Apostila - Inglês Profissional. São 650mb de conteúdo. Vai do básico ao nível profissional.
Antes eu tinha baixado o Curso Básico de Inglês. Aprenda Inglês em apenas 30 dias.
Para ajudar nessa tarefa, também é bom usar o serviço de gratis de alguns sites:
English Experts - guia para quem estuda inglês por contra própria usando a internt.
Tecla SAP - dicas de inglês.
Inglês Curso - curso grátis de inlgês
Audiobooks Gratuitos em Inglês - livros em audio.
BBC Learning English - estude inglês no site da BBC.
Se alguém tiver alguma dica ae, é só dizer que atualizo este post.
Assinar:
Postagens (Atom)