A Fundação Bradesco através do portal Escola Virtual oferece cursos online sobre Lógica Orientada a Objetos, C++, HTML, Java Script, Redes, entre outros.
Os cursos são gratuitos e o aluno em direito a um certificado de conclusão.
Além disso a fundação também oferece um curso semipresencial em parceria com a Cisco para certificação CCNA e CCNP , uma ótima oportunidade de se especializar em roteamento e gerenciamento de redes de grande porte ;)
Lista dos cursos oferecidos Cursos
http://www.escolavirtual.org.br/
Dica de certificação.
Se você está para perder o seu voucher porque ele vai expirar leia esta dica.
Digamos que seu voucher irá expirar em 29/02/2008 e hoje é 27/02/2008, digamos também que além de você não ter se preparado para a prova, você está impossibilitado de se deslocar até o centro autorizado mais próximo para realizar sua prova.
Um simples e breve pensamento deve tomar conta se seu sub-conciênte: " FUDEU! "
Calma, calma. Não criemos cânico.
Recentemente descobri que você tem até o dia 29/02/2008 para agendar o seu teste, esta data não é a data máxima para realização da prova.
Novamente seu sub-conciênte toma conta e um pensamento toma conta do seu eu: " COMO NÃO, TODO MUNDO FALA QUE É ASSIM, PORRA! TA LOCO?" .
Calma, calma. Não criemos cânico, eu explico.
Como havia dito, você tem até o dia 29/02/2008 para agendar o seu teste, e para não perde-lo siga os seguinte passos:
- Vá ao site da Prometric e agende o seu teste para a data mais longe possível, normalmente dois meses para frente.
Desta forma você tem dois meses para se preparar e realizar seu teste. Neste ponto você já ganhou dois meses de tempo, ou seja, totalizando quatorze meses ná prática e não os doze de costume.
Se em dois meses você ainda não conseguiu se organizar e fazer seu teste, siga o próximo passo.
- Vá novamente ao site da Prometric e reagende o seu teste para data mais longe possível. Novamente, dois meses para frente.
Desta forma você tem novamente mais dois meses para realizar o seu teste, ou seja você ganhou, na prática, dezesseis meses para fazer seu teste.
Não consegui verificar se existe limite para o reagendamento, então se neste tempo você ainda não conseguiu se organizar e se preparar para o teste repita o reagendamento :D
É CLARO QUE A MELHOR DICA AQUI É NÃO DEIXAR CHEGAR E ESSE PONTO :D
Digamos que seu voucher irá expirar em 29/02/2008 e hoje é 27/02/2008, digamos também que além de você não ter se preparado para a prova, você está impossibilitado de se deslocar até o centro autorizado mais próximo para realizar sua prova.
Um simples e breve pensamento deve tomar conta se seu sub-conciênte: " FUDEU! "
Calma, calma. Não criemos cânico.
Recentemente descobri que você tem até o dia 29/02/2008 para agendar o seu teste, esta data não é a data máxima para realização da prova.
Novamente seu sub-conciênte toma conta e um pensamento toma conta do seu eu: " COMO NÃO, TODO MUNDO FALA QUE É ASSIM, PORRA! TA LOCO?" .
Calma, calma. Não criemos cânico, eu explico.
Como havia dito, você tem até o dia 29/02/2008 para agendar o seu teste, e para não perde-lo siga os seguinte passos:
- Vá ao site da Prometric e agende o seu teste para a data mais longe possível, normalmente dois meses para frente.
Desta forma você tem dois meses para se preparar e realizar seu teste. Neste ponto você já ganhou dois meses de tempo, ou seja, totalizando quatorze meses ná prática e não os doze de costume.
Se em dois meses você ainda não conseguiu se organizar e fazer seu teste, siga o próximo passo.
- Vá novamente ao site da Prometric e reagende o seu teste para data mais longe possível. Novamente, dois meses para frente.
Desta forma você tem novamente mais dois meses para realizar o seu teste, ou seja você ganhou, na prática, dezesseis meses para fazer seu teste.
Não consegui verificar se existe limite para o reagendamento, então se neste tempo você ainda não conseguiu se organizar e se preparar para o teste repita o reagendamento :D
É CLARO QUE A MELHOR DICA AQUI É NÃO DEIXAR CHEGAR E ESSE PONTO :D
Management of Project
Sempre falo de algumas experiências que tive como gerente de projeto eu não adotei uma filosofia única de desenvolvimento, sempre achei que ficar preso em um processo específico é ruim ao projeto e por isso sempre preferi analisar o projeto como um todo e pegar partes dos processos que mais se adequavam ao problema.
Recentemente descobri que Ivar Jacobson (um dos pais da UML e do RUP) evangeliza que o importante não é o processo em si e sim as praticas, outra coisa que descobri é que o cara está cansado de processos. O que Ivar propõe é o foco no uso de práticas que fazem sentido.
Bom... acredito que no final eu não estou tão errado em defender esta forma de trabalhar afinal, o gande Ivan Jacobson com suas décadas de experiência na área pensa como eu.
Recentemente descobri que Ivar Jacobson (um dos pais da UML e do RUP) evangeliza que o importante não é o processo em si e sim as praticas, outra coisa que descobri é que o cara está cansado de processos. O que Ivar propõe é o foco no uso de práticas que fazem sentido.
Bom... acredito que no final eu não estou tão errado em defender esta forma de trabalhar afinal, o gande Ivan Jacobson com suas décadas de experiência na área pensa como eu.
Não deixe para depois - tech debt
Nos projetos de software sempre há algum nível de tech debt. Sempre a mesma história: não temos tempo para isso agora, na próxima oportunidade corrigimos.
O problema é que em muitos casos o acúmulo de coisas que deixamos pelo meio do caminho é prejudicial à saúde do projeto. Mais que preciosismo de nerds e perfeccionistas, tech debt pode –e geralmente vai- atrasar o andamento do time.
É bom alocar um orçamento para resolver estes problemas. Durante o planning game é importante deixar claro que precisamos resolver problemas enquanto estamos implementando funcionalidades e geralmente alocar alguns pontos na iteração para eles, normalmente algo perto de 20% do trabalho. Normalmente é aceitavel que estas histórias técnicas tenham prioridade baixa e no geral tudo ocorre bem.
No caso de uma emergência então costuma-se não ser muito flexível em relação à solução do problema. As histórias técnicas neste caso ganham prioridade máxima dentro da iteração.
Como geralmente o cliente está satisfeito com a velocidade da equipe num processo ágil (se não está há outro problema) quando sobra –e quase sempre sobra- tempo extra numa iteração geralmente eu preenche-se com tech debt, e em especial deixa-se os desenvolvedores priorizarem o que querem fazer. Muitas vezes não dá tempo para fazer homologação destas mudanças durante a iteração vigente e elas acabam indo para produção apenas na iteração posterior, mas é uma boa estratégia.
O que importa é não deixar o tech debt acumular. Se há duvidas dos problemas que o acúmulo de histórias técnicas causam basta lembrar a última vez que você entrou em um projeto para dar manutenção em um sistema pré-existente. Eu nunca vi um caso onde o sistema antigo não tenha toneladas de problemas causados por “deixar para depois” mudanças que não eram urgentes mas foram crescendo em urgência com o tempo.
Copiei e mudei algumas palavras para passar a mensagem que que gostaria de passar a todos vocês.
tech debts
O problema é que em muitos casos o acúmulo de coisas que deixamos pelo meio do caminho é prejudicial à saúde do projeto. Mais que preciosismo de nerds e perfeccionistas, tech debt pode –e geralmente vai- atrasar o andamento do time.
É bom alocar um orçamento para resolver estes problemas. Durante o planning game é importante deixar claro que precisamos resolver problemas enquanto estamos implementando funcionalidades e geralmente alocar alguns pontos na iteração para eles, normalmente algo perto de 20% do trabalho. Normalmente é aceitavel que estas histórias técnicas tenham prioridade baixa e no geral tudo ocorre bem.
No caso de uma emergência então costuma-se não ser muito flexível em relação à solução do problema. As histórias técnicas neste caso ganham prioridade máxima dentro da iteração.
Como geralmente o cliente está satisfeito com a velocidade da equipe num processo ágil (se não está há outro problema) quando sobra –e quase sempre sobra- tempo extra numa iteração geralmente eu preenche-se com tech debt, e em especial deixa-se os desenvolvedores priorizarem o que querem fazer. Muitas vezes não dá tempo para fazer homologação destas mudanças durante a iteração vigente e elas acabam indo para produção apenas na iteração posterior, mas é uma boa estratégia.
O que importa é não deixar o tech debt acumular. Se há duvidas dos problemas que o acúmulo de histórias técnicas causam basta lembrar a última vez que você entrou em um projeto para dar manutenção em um sistema pré-existente. Eu nunca vi um caso onde o sistema antigo não tenha toneladas de problemas causados por “deixar para depois” mudanças que não eram urgentes mas foram crescendo em urgência com o tempo.
Copiei e mudei algumas palavras para passar a mensagem que que gostaria de passar a todos vocês.
tech debts
Por que devo contratar você?
a jornalista Mary Pratt, da edição norte-americana do COMPUTERWORLD, entrevistou alguns executivos de TI sobre suas perguntas favoritas durante uma entrevista de emprego. Saiba o que eles responderam.
Boa leitura
Boa leitura
Assinar:
Postagens (Atom)