Movimento Ágil

Anulado Concurso Público da UESC

2010-08-25T12:48:00.000-03:00

"25/08/2010

A Universidade Estadual de Santa Cruz (UESC), tendo em vista as conclusões do Processo Administrativo constituído pela portaria nº 878, declara nulo o Concurso Público de provas e títulos para o provimento e formação de cargos de Técnico Universitário e de formação de cadastro de reserva para o cargo de Analista Universitário, objeto do Edital nº 055/2010.

Por considerar descumprido todo o objeto do Contrato nº 036/2010, firmado entre a UESC e a Empresa, foi aplicada multa de 10%, estipulada na cláusula onze do contrato, à Empresa Concepção Consultoria Técnica Especializada Ltda.

Os candidatos inscritos no Concurso Público poderão, querendo, solicitar cancelamento da inscrição e devolução da taxa, ou permanecer inscrito e aguardar a designação de nova data para realização das provas."

Mais detalhes sobre a decisão estão na Portaria Nº 1142.

Agora sim... vamos esperar uma nova data com uma nova empresa.

Tomara que não aconteça outra marmelada dessas... =]

Publicado Firefox 4 beta 1 - agora oficial, com mais divulgação

2010-07-07T13:24:00.001-03:00

A Mozilla publicou agora oficialmente o beta 1 do Firefox 4. Aquela versão divulgada recentemente, como anunciado, era um "preview do beta", um "candidate build". Esta nova versão é um pouco diferente do candidate (o instalador para Windows é um pouco maior e há algumas mudanças na interface, como o botão Feedback).

As grandes mudanças com relação ao conhecido Firefox 3.x são várias, na verdade houve uma boa reescrita do código do navegador para se adequar às novidades esperadas. A barra de endereço e a disposição das abas seguem o estilo do Google Chrome. Na verdade lembra ele, é diferente mas é inspirado nele, já que foi o Chrome que popularizou esse conceito de interface para os navegadores.

O Crash Protection, ou "proteção contra travamentos", é outra coisa interessante: ele isola alguns plugins em processos separados. Se algum deles travar ou parar de responder, o navegador todo não precisa ser encerrado, basta recarregar a aba do site em questão. Esse mesmo recurso apareceu no Firefox 3.6.4, onde funciona para plugins do Flash, QuickTime e Silverlight. No Chrome isso é feito desde o princípio, inclusive para as abas - e daqui para frente tende a ser adotado em outros browsers.

HTML 5 e CSS 3 estão tão comentados ultimamente que dispensam comentários, né? Além disso o Firefox 4 traz mais coisas, como WebSockets, Web Console e Indexed DB (este permite aos sites guardarem arquivos e configurações localmente).

Um novo sistema de plugins permitirá que as extensões sejam instaladas sem precisar reiniciar o navegador, o que era uma das maiores críticas ao Firefox para quem gosta de experimentar novas extensões.

O Firefox 4 ainda vem com um gerenciador de add-ons mais fácil de usar, suporte a WebM e vídeo HD, e mais recursos de privacidade. No hotsite de divulgação do beta há várias informações sobre as mudanças, além do link de download.

Resumindo tudo...

2010-06-11T21:10:00.000-03:00

Aí todo mundo lê um monte de coisa sobre metodologias ágeis e ninguém resumi nada. Mas será?

Bom, para vocês que querem resumir qual é a 'onda' dessas metodologias, segue abaixo um resuminho sobre elas.

Existem inúmeras metodologias de desenvolvimento de software rápido, cada uma destas exposta pela The Agile Alliance. A maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do software em curtos períodos, chamados de iteração, os quais gastam tipicamente menos de uma semana a até quatro. Cada iteração é como um projecto de software em miniatura de seu próprio, e inclui todas as tarefas necessárias para implantar o mini-incremento da nova funcionalidade: planejamento, análise de requisitos, projeto, codificação, teste e documentação. Enquanto em um processo convencional, cada iteração não está necessariamente focada em adicionar um novo conjunto significativo de funcionalidades, um projecto de software ágil busca a capacidade de implantar uma nova versão do software ao fim de cada iteração, etapa a qual a equipe responsável reavalia as prioridades do projecto.

Métodos ágeis enfatizam comunicações em tempo real, preferencialmente face a face, a documentos escritos. A maioria dos componentes de um grupo ágil devem estar agrupados em uma sala. Isto inclui todas as pessoas necessárias para terminar o software. No mínimo, isto inclui os programadores e seus clientes (clientes são as pessoas que definem o produto, eles podem ser os gerentes, analistas de negócio, ou realmente os clientes). Nesta sala devem também se encontrar os testadores, projectistas de iteração, redactores técnicos e gerentes.

Métodos ágeis também enfatizam trabalho no software como uma medida primária de progresso. Combinado com a comunicação face-a-face, métodos ágeis produzem pouca documentação em relação a outros métodos, sendo este um de seus pontos negativos.

É isso ai galera... resta agora pesquisar mais e aderir ao movimento!

Pra refletir...

2010-06-11T15:09:00.000-03:00

Acabei de ver isso em um livro. Creio que essa seja a melhor definição para o que são as metodologias ágeis. Vale a pena tentar aprender, incentivar e ingressar em seus projetos, seja eles os mais diversos

"Agilidade é a habilidade de criar e responder a mudanças com respeito ao resultado financeiro do projeto em um turbulento ambiente de negócios. Agilidade é a habilidade de balancear flexibilidade com estabilidade". (Highsmith, Jim. Agile Project Management, 2002)

O super FAIL do Google

2010-06-11T14:53:00.001-03:00

Milhões de internautas de todo o planeta mandaram um recado na quinta-feira (10) para o Google: “Não nos enfie nada goela abaixo.”

A possibilidade de incluir um “papel de parede” personalizado no buscador foi lançada no mundo inteiro da pior maneira possível. Os usuários tiveram a página do Google alterada de um dia para o outro, sem nenhum aviso antecipado. Pior: não era possível voltar para o layout clássico e minimalista – só dava para trocar a imensa foto por outra. A ação desastrosa deveria durar 24 horas, mas a reação negativa foi tão grande que os termos “remove Google background” ficaram em quinto lugar nos Estados Unidos. Por volta das 11h30 da quinta-feira, os engenheiros reverteram a mudança.

Marissa Mayer, vice-presidente de Produtos de Busca e Experiência do Usuário, correu para dizer, no blog oficial do Google, que um bug havia impedido que aparecesse uma explicação sobre a mudança na página. Difícil de acreditar nisso, porque a alteração começou às 21 horas da quarta-feira (9). Ou seja, desde o início até o momento em que foi revertida, passaram-se 13 horas e 30 minutos. Na internet, isso é uma eternidade. Se realmente tivesse havido uma falha, um aviso teria sido dado muito tempo antes.

A própria Marissa, em seu Twitter, respondeu a um usuário que o único jeito de eliminar as imagens era escolher o plano de fundo branco, que estava entre as opções oferecidas: “It’s the opt out. Otherwise, we will be back to normal tomorrow.” A pressão das massas levou a uma mudança radical desse plano. A funcionalidade deixou o Google com a cara do Bing, o que só amplificou a repercussão negativa. Foi um FAIL completo.

Todo o episódio mostra como o pessoal do Google está perdendo o contato com a realidade. Os engenheiros preparam uma nova funcionalidade, acham que é “supercool” e jogam sobre as cabeças dos internautas. Talvez por estar na liderança por tanto tempo, o povo de Mountain View tenha se tornado arrogante – decisões são tomadas sem uma análise cuidadosa das consequências. Foi a mesma coisa que ocorreu no lançamento do Google Buzz e no caso da captura ilegal de dados de Wi-Fi pelo Street View. Isso é muito – mas muito – perigoso.

Texto retirado DAQUI.

Vamos ver o que a Google vai fazer com relação ao seu buscador e ao Orkut que está tendo um índice de rejeição grande perante a sua nova página de recados.

Google foi coerente ao proibir o Windows

2010-06-08T12:37:00.001-03:00

A notícia de que o Google restringiu o uso do Windows por seus funcionários deixou muita gente ficou revoltada. Foi, no entanto, uma decisão natural.

A medida faz todo sentido se for levada em conta a filosofia da companhia, que defende que os sistemas operacionais hoje se tornaram irrelevantes – o que manda, para esse pessoal, é a vida na nuvem. O Google Apps foi o primeiro fruto desse pensamento. A criação do Google Chrome foi o segundo. O próximo será o lançamento do sistema operacional Chrome OS, no fim do ano.

Seguindo esse ponto de vista, o Windows não precisa ser usado por boa parte dos cerca de 20 mil empregados do Google. Boa parte deles realmente não necessita de nenhum software que só rode no sistema operacional da Microsoft. Por que gastar milhões com licenças? Agora que o Chrome chegou à versão estável para Linux e Mac, apenas os desenvolvedores de produtos para o ambiente Windows têm justificativa para continuarem usando o sistema operacional de Bill Gates. Os outros podem se virar com o Google Docs e outros aplicativos web.

Há também, é claro, o problema da segurança. Combater vírus de computador é como acabar com a dengue. Todo mundo sabe como fazer, mas tem sempre algum infeliz que deixa um pneu acumulando água no quintal. Não existe sistema operacional mais atacado por crackers e criminosos virtuais do que o Windows. Por mais que alguém aconselhe e ensine, algum funcionário sempre vai fazer bobagem – mesmo em Mountain View e em suas sucursais (lembram da história do Google na China?). Então, melhor proibir de uma vez. Isso não garante 100% de segurança, mas aumenta absurdamente o nível de proteção.

Claro que o marketing é outro motivo por trás da decisão. Como o Google pretende confrontar a Microsoft com o Chrome OS em breve, seus funcionários devem ser os primeiros a “provar” que podem viver sem o Windows. Muita gente vai pensar: se eles conseguem, também consigo. Será? Saberemos no fim do ano.

Texto retirado DAQUI

Protesto! - Concurso mal formulado da UESC

2010-06-07T10:41:00.002-03:00

Bom dia pessoal...

Dormi bem essa noite e também ancioso para pegar o gabarito da prova do concurso que fiz ontem ( domingo 06/07/2010 ) na espectativa pois sei que fiz uma prova muito boa.

Para minha surpresa, fiquei revoltado só de começar a corrigir a primeira questão do bloco de português e a cada questão corrigida uma revolta a mais.

Passei para o bloco de Informática ( esse sim, tinha brocado na prova, certeza de que tinha gabaritado a prova ) para meu ódio aumentar, sou pego de surpresa na seguinte questão:

>>> Software é uma sequencia de instruções que são interpretadas e executadas pelo computador. Das opções a seguir, identifique o programa de planilha eletrônica.

Power Point
Excell
Outlook
Word
Internet Explorer

Bom, eu trabalho com isso diariamente, então conhecendo o pacote office da Microsoft eu marquei o número 2. Sendo que no gabarito está constando como resposta correta o número 3. LoL ¬¬" Não sabia que o Outlook ( gerenciador de emails da Microsoft ) também fazia planilhas eletrônicas.

Esse foi apenas um dos erros que aconteceram nessa prova tosca.

Abaixo segue um link de um blog de notícias aqui da região que tem o depoimento de um candidato nesso concurso e alguns relatos a mais de coisas "sobrenaturais" que aconteceram neste domingo de prova.

Pimenta na Muqueca: Chiadeira em concurso da UESC.

Isso é tudo

Revoltado =/

Incrementando assuntos no blog

2010-06-07T00:53:00.002-03:00

Pois é... acho que não precisa falar muita coisa com um títudo desses. Estarei nos próximos dias colocando novas assuntos relacionados a minha área de formação que não se restrinja a apenas metodologias ágeis. Este blog eu comecei para escrever pedaços da minha monografia, sei que não tem muita dimensão, mas vamos tentando.

Colocarei assuntos diversos nas áreas que estou estudando atualmente. Lembrando que todos os projetos serão feitos usando essas metodologias pois foi com elas que melhor me adaptei e aconselho quem queira começar a usá-las.

Isso é tudo...

Até breve com novos assuntos.

Boa noite =]

Evolução de um projeto utilizando metodologias ágeis

2010-06-06T23:05:00.001-03:00

e esse ciclo continua a depender do tempo que levará o projeto.

Um cardápio de metodologias ágeis

2010-06-06T22:46:00.007-03:00

Boa noite...

Este documento não foi de minha autoria, e sim achei em um blog na rede quando andei pesquisando sobre algumas metodologias recentemente para poder estudar e conhecer um pouco mais além de Scrum e XP.

Segue pra vcs agora o texto criado por Fábio Camara em "Um cardápio de metodologias ágeis".

-------------------------------------

Um projeto de software está com sérios problemas e quando acordei percebi que não era um pesadelo. Peguei um livro e li: O mau gerenciamento pode incrementar os custos de um projeto de software mais rapidamente que qualquer outro fator, escreveu Barry Boehm em 1981. Temi pelo meu emprego e pensei: antes de desistir vou contratar muitos desenvolvedores. Peguei outro livro e li: Adicionar pessoas faz um atrasado projeto atrasar ainda mais, escreveu Frederick Brooks em 1995.

Neste cenário assustador questionei-me: o que vou fazer diferente se preciso de resultados diferentes? Como compreender os verdadeiros obstáculos do gerenciamento de um projeto de software?

Procurei por muitos caminhos mas a resposta que mais gostei me foi ensinada pelos métodos ágeis. Entre muitos aprendizados que tive, li que o pensamento ágil reconhece 5 obstáculos no gerenciamento de projetos de software. São eles: pessoas, tempo, funcionalidades, orçamento e recursos (excluindo pessoas). Com isto em mente, coloquei em prática um pouco de 4 propostas ágeis que estudei.

Vamos conhecer um pouco destas propostas ágeis. São elas XP, MSF, SCRUM e FDD.

eXtreme Programming

Métodos ágeis são propostas incomuns de técnicas para projetos de software. XP, como o nome sugere, é algo um pouco mais radical. Propostas estranhas de técnicas esquisitas fazem os gerentes de projetos temerem utilizá-las em grandes projetos. Para atrapalhar ainda mais as poucas iniciativas de se quebrar paradigmas, o radicalismo de alguns pensadores de XP afastam a compreensão sobre as reais vantagens e os benefícios para o negócio que podemos alcançar com estes métodos.

A programação em pares, um dos mais diferentes e originais métodos do XP, traz para o gerente do projeto a necessidade de uma posição sem hipocrisia. Ou você ama, ou você odeia. Até hoje não encontrei um gestor "em cima do muro" sobre esta técnica.

Como exemplo, vamos citar Karl Wiegers, famoso autor de livros técnicos, que afirma em seus ensinamentos que a programação em pares como forma de inspecionar código não é efetiva na redução dos defeitos. Segundo o mesmo, entre 25 % e 35 % é o ganho atingido no aspecto "defect reduction". Esta afirmativa é questionada por David Anderson, outro grandioso autor, que defende um número percentual em torno de 50%.

Já em minha própria vivência, as reuniões em pé (stand-up meeting) são fabulosas em quase todos os aspectos. Particularmente acredito no pensamento de Jonh Kennedy, ex-presidente dos EUA, que dizia: quando se quer não fazer nada fingindo que está trabalhando, entre em uma reunião.

Listamos a seguir os principais métodos polêmicos do XP.

Pair Programming;
Continuous Integration;
Stand-Up Meeting;
Collective Ownership (código fonte coletivo);
Refactoring;
On-Site Customer;
Generalists.

Na minha leitura, o XP é uma proposta muito completa de ciclo de vida de desenvolvimento de software, agradando ou não um gestor de projetos. Um dos principais fundadores do XP chama-se Kent Beck.

FDD - Feature Driven Development

Criado entre 1997 e 1999 em Cingapura por um time liderado pelo Jeff De Luca, é uma simples compilação de práticas estabelecidas nos últimos 30 anos. Um de seus maiores desenvolvedores, Peter Coad, definiu a idéia de Feature Definition e Feature List. Diversos renomados autores participaram da concepção das idéias do FDD. Dentre estes destacamos: Tom De Marco, Tim Lister, Jerry Weinberg e Frederic Brooks.

Em sua essência, FDD é mais um método de gerenciamento de software do que um ciclo de vida de desenvolvimento de software.

Resumidamente, FDD é dividido em 5 fases que explicam sua função. São elas:

Shape Modeling - é uma forma de questionar se todos compreendem o que é para fazer, analisar requisitos não-funcionais e modelo de arquitetura;
Feature List - É a representação do escopo listando a compreensão do que é para ser feito e os requerimentos a serem desenvolvidos;
Plan by subject area - É a modularização da lista em conjuntos de funcionalidades relacionadas, permitindo o desenvolvimento de parte do sistema autonomamente;
Design by feature set - É uma orientação que determina o desenvolvimento com base no domínio do problema. Sugere-se nesta fase uma modelagem profunda e detalhada em UML;
Build by Chief Programmer Work Package - É o empacotamento de pequenas funcionalidades, uma redução evolutiva que nasce na fase 2 até a fase 4. Prioriza-se este pacote, codificando sua funcionalidades e criando unit tests.

FDD define também 4 camadas de arquitetura de software:

UI - User Interface;
PD - Problem Domain (lógica do negócio);
DM - Data Management;
SI - Systems Interfaces.

Notamos que o "core" de todas as fases e das camadas de arquitetura é a funcionalidade (feature). Cada funcionalidade é definida com uma fórmula simples, que permite ser repetível e confiável. A fórmula da funcionalidade tem a seguinte estrutura:

action result object

Exemplo:

action O valor total de vendas

result Faturamento bruto mensal

object Produtos vendidos no período

MSF - Microsoft Solutions Framework

Disseram-me que MSF só funciona em projetos com tecnologias da Microsoft. É impressionante a associação restritiva que naturalmente os desinformados impõem as coisas. Também já ouvi que metodologias ágeis só são recomendadas para projetos pequenos. Pior que isso! Ouvi de uma diretora de TI de um banco: _ Hoje nós somos ágeis (referindo-se a ausência de gestão e de análise de requisitos de seu departamento), queremos ser mais organizados.

Estudando o assunto há 9 anos, eu sempre considerei o MSF uma proposta equilibrada, aonde seus 2 modelos e suas 3 disciplinas nunca se apresentaram como uma espécie de bíblia sagrada, determinística ao sucesso ou fracasso de seu projeto. Inclusive na versão 3.1 do MSF, antes da formalização das propostas ágeis no ano de 2001, tinha como conceito chave: _ Stay agile, expect changes.

O MSF 4.2, possui duas novas instâncias: MSF for Agile Software Development e MSF for CMMI Process Improvement. Podemos afirmar que o MSF Agile é um mix de posições equilibradas, pois defende um SDLC (Software Development Life Cycle) mais curto com iterações de no máximo 4 semanas, contudo preserva a importância dos papéis definidos previamente e abomina a linha "todo mundo pode fazer tudo no projeto". Outro quesito de destaque nesta fusão são os testes unitários e a preocupação com a cobertura de 100% do código fonte.

Um tema muito forte dentro do MSF Agile é integração. Metodologias ágeis nescessitam que os "stakeholders" estejam presentes o tempo todo durante o projeto. Para isso são constituídos cenários de tarefas de trabalho que englobam atividades planejadas para um desenvolvedor. Estes cenários fazem parte de uma determinada iteração do plano de iterações. Esta iteração agrupa os cenários de desenvolvedores e os cenários de testes (que são efetuados em seguida ao desenvolvimento). Desta forma controla-se a integração de um time com papéis diversos dentro do projeto (usuário, desenvolvedor e analista de testes).

Para o MSF, um projeto precisa dos seguintes pápeis (entende-se papéis como responsabilidades que devem ser assumidas por algum membro da equipe):
Program Manager
Product Manager
User Experience
Tester
Developer
Architect
Release Manager

É árduo afirmar que foi o fundamentador do MSF, porém o grande patrocinador sempre foi a própria Microsoft. Para não ficar em branco com nomes, Michael Cusomano, Steve McConnell destacam-se entre muitos outros como personagens da história do MSF.

SCRUM

SCRUM é um método de gerenciamento de software que pode ser usado com XP ou MSF. É baseado na teoria do controle empírico de processos e seus fundamentos são originados na indústria de manufatura japonesa.

Ciclo de vida empírico é um ciclo baseado na observação dos fatos. Muitos gerentes de projetos não gostam do método reativo sugerido pelo SCRUM e preferem trabalhar com um planejamento que na minha leitura é um trabalho especulativo, pois tenta prever uma seqüência de atividades lineares. Por mais que o cronograma tenha um valor que é o planejamento prévio, ou seja, pensar antes de sair fazendo, perde muito em tentar prever atividades distantes cheias de dependências predecessoras e não facilita o controle das mudanças de requisitos.

Segundo o SCRUM, o desenvolvimento deve ser trabalhado em 3 níveis: Sprint, Release e Product.

O ponto central é que os requisitos são convertidos em uma lista que contém valores do cliente chamada Product Backlog. Um sub-conjunto desta lista é criado e chamado de Release Backlog. Este sub-conjunto é particionado mais uma vez transformando-se em Sprint, uma espécie de acordo de desenvolvimento de funcionalidades que após aceito pela equipe não deve ser mais alterado.

Praticando SCRUM, o que mais chama a atenção é a simplicidade. Controlar projetos desta forma é participar de um jogo competitivo e saudável em que todos se auto-avaliam todos os dias (daily stand-up meeting) tornando possível resultados e técnicas de melhoria contínua.

O gerente de projetos como conhecemos hoje, na proposta SCRUM, é chamado de SCRUM Master. Suas principais responsabilidades resumem-se em duas: Proporcionar a passagem técnica e retirar todos os impedimentos. A equipe do projeto é dividida em apenas 3 pápeis: o SCRUM Master (coach), o Product Owner e a equipe.

Em diversos aspectos, as técnicas do SCRUM diferenciam-se das propostas convencionais. Destaque para:

Product Backlog;
The 30-Day Sprint;
The SCRUM Meeting;
Team Size;
The Sprint Review.

Para saber mais sobre SCRUM, é imprescindível ler algum dos títulos lançados por Ken Schwaber.

O que experimentar

Independente de sua curiosidade para novos sabores, os métodos ágeis são uma honesta resposta a pergunta: o que vou fazer diferente se preciso de resultados diferentes?

Baseados em processos iterativos incrementais e empíricos, os métodos ágeis são indiscutivelmente diferentes das propostas tradicionais que são fundamentadas em processos cascata. Esta diferença pode ser a resposta a sua dúvida também.

Meus resultados mudaram significativamente quando entendi a diferença essencial da proposta ágil em comparação ao modelo que eu havia aprendido nos ensinamentos do PMI - Project Management Institute.

A orientação PMI é:

A orientação ágil é:

Considere na imagem que a seta vermelha é uma constante, a seta verde é mais ou menos variável e a seta lilás é a mais variável.

Compreendendo a diferença entre as duas e alinhando com as características das expectativas de seus "stakeholders", você conseguirá alcançar resultados diferentes.

Experimente!

-------------------------------------

É isso ai pessoal.

Philco PHN 10103 - Parte 4 (o Final)

2010-05-19T09:47:00.003-03:00

Bom dia...
Terminando a história com a Philco...
Meu netbook chegou; em perfeito estado, dentro da caixa do jeito que eu tinha mandado, não retiraram os plásticos protetores e o mais importante... o teclado veio funcionando perfeitamente.

Mas não pensem que tudo são flores... depois de tanta insistencia para saber o progresso do concerto do aparelho, eu consegui informações importantes.
Infelizmente nem todos trabalhando de bom grado nos empregos que tem. Ou acordaram mau humorados com a desculpa de que "a noite não foi boa", ou então são um monte de ¨%$¨$##¨%$*@ sem noção que só querem saber de estregar a vida dos outros.

Enfim, a culpa de toda a enrolação foi da assistência técnica de Salvador que não passava as informações relevantes para a garantia da Philco em SP.

Pelo menos ele chegou inteiro e funcionando.

Lição: Fique sempre no pé da assistência e da garantia, ligue todo dia se for preciso, uma hora vc consegue as informações.

Bom...
É isso ai...

Philco PHN 10103 - Parte 3

2010-04-14T10:12:00.002-03:00

Bom,

Quarta-feira, dia de ligar para a assistência para ver o que foi feito no aparelho. Detalhe, se vcs têem um aparelho desses e um dia precisam mandar para a autorizada estando ele na garantia, liguem bastante para la, fiquem no pé, pq so assim eles trabalhando e te dão a informação necessária e todo o procedimento.

Liguei hj para a Philco e toda vez que eu ligo, alguém me dá uma informação totalmente diferente da anterior... hj inventaram de falar que meu netbook só foi chegar na assistência na segunda-feira, sendo que já está completando uma semana que ele chegou para ser aberto. Me falaram para ligar mais tarde pq só assim poderiam me passar uma informação de todo o procedimento.
Desliguei o telefone e liguei direto para a autoriazada em Salvador-Ba e la sim, tive informações positivas e concretas.

A sorte deles é que ainda estão dentro do prazo que foi me passado para conserto.

O aparelho está pronto, só aguardando a autorização dos CORREIOS para emitir a nota de postagem de volta para Itabuna-Ba.
Problema: Um simples mal contato no teclado provocou tudo isso!

Agora, mais tranquilo, espero a volta do aparelho!
Sinto que isso pode demorar ainda, pq os CORREIOS de Itabuna não trabalham direito!!! =[

Até

Philco PHN 10103 - Parte 2

2010-04-12T09:55:00.003-03:00

Bom Dia...

Passado o final de semana, lá vamos nós ligar para a assistência da Philco atrás de informações sobre o aparelho.
Resultado, depois de esperar um pouco mais na linha para ser atendido e ouvir a musiquinha deles umas 4 vezes, meu netbook já está em bancada sendo analisado.
Segundo a atendente, devo retornar na quarta-feira para assim tem um posicionamento do que aconteceu e se vai ser resolvido ou se virá um aparelho novo (ohhh ilusão). Só sei que até agora eles estão no prazo estipulado de 15 dias entre o envio/conserto/devolução.

Esperar agora até quarta.

Fui...

Philco PHN 10103 - Parte 1

2010-04-09T10:27:00.004-03:00

Bom pessoal, sei que esse não é intuito do blog e como ele tava parado devido a vários fatores (tempo, preguiça e etc) resolvi postar isso porque na net não encontrei nada sobre o problema apresentado por esse aparelho.

Tudo começou a 3 meses atrás quando em uma mega promoção em um supermercado de Itabuna - BA conseguí comprar o netbook que queria, saindo de um preço altíssimo (R$ 1750,00) para um muito, mais muitooooo baixo (R$ 998,00).
Ele veio com S.O. Linux Mandriva 2009.1, já tinha usado outros linux's por ai, e cá pra nós, não tenho do que reclamar desse, lógico que preferia o Ubuntu, mas esse veio tão "redondinho" que não precisava fazer mais nada.

No final de semana da páscoa, estava usando ele numa boa, digitando um relatório referente ao trabalho quando de repente um aviso de bateria fraca. Peguei o carregador, pluguei e esperei carregar. Quando a bateria estava cheia, apertei qualquer tecla para sair do modo de espera e ir para o verificador de senha do usuário. Para a minha surpresa, os "*" que indicam que a senha tava sendo escrita não estavam aparecendo e por isso não conseguia logar no meu usuário.
Reiniciei a máquina e em seguida apertei a tecla "DEL" para acessar as configurações da BIOS e o netbook simplesmente desligou do nada. Esperei carregar todo o sistema e em seguida fui testar o teclado, outra surpresa, toda tecla que apertava ia até a tela de desligar o sistema mostrada abaixo.

Pensei que era coisa do sistema, mas decidi pegar um teclado USB e colocar pra ver se funcionava. Ohhhhhhhh funcionou de boa, todas as funções e etc. Como isso era no final de semana, esperei até segunda para ligar pro SAC da Philco e ver qual era o procedimento já que o aparelho estava na garantia.

Me surpreendi bastante com o atendimento da Philco, não tenho o que reclamar. Não fiquei no telefone ouvindo musiquinha esperando atendimento, a moça foi super educada e providenciou logo logo uma solução para o meu caso.
Como a assistência técnica mais próxima de mim é em Salvador - BA, a Philco emitiu uma autorização de transporte para meu aparelho que graças a Deus já está em Salvador.

Estou esperando ver o que vai acontecer, liguei para a Philco hoje pela manhã e eles avisaram que o produto chegou na assistência ontem a tarde e que ela só poderia me dar uma resposta na segunda, que liguasse pela manhã que ela passaria todas as informações necessárias.

O mais curioso é que eu não imaginei que um produto com 3 meses de uso, sem ter tomado pancadas, que ainda tem o plástico de proteção da tela e da WebCam iria dar um problema no TECLADO.

LoL

É esperar agora...

Assim que pintar alguma notícia eu volto a escrever. Vamos ver se a Philco até lá mantem o padrão de qualidade que eu estou achando que eles teem. =]

O ReToRnO!!!

2009-06-10T14:55:00.002-03:00

Bom pessoal,

Depois de muito tempo sem postar nada aqui, só terminando os projetos da faculdade, incluindo a minha monografia, chegou a hora de retomar as atividades aqui no blog.

Como todos sabem, aqui falamos aspectos relacionados com as Metodologias de Desenvolvimento Ágil, que por sinal é usada na minha monografia. Então aguardem novos posts por ai.

Abraço

Protesto!!!

2009-04-22T20:01:00.003-03:00

Pessoal, infelizmente essas coisas acontecem. Venho aqui deixar o meu protesto pela falta de compromisso da Universidade com o curso de Comunicação Social da instituição.

Click na imagem para ser direcionado ao blog do movimento e entendam o porque!

"Getting Real"

2009-04-20T18:01:00.002-03:00

Ai pessoal, pra quem quer começar a abrir a mente para as metodologias ágeis, recomendo a leitura do livro Getting Real da 37signals, já tem a versão traduzida para o português. =]

Segue o link pra vocês: Getting Real

Boa leitura. xD

Termos do Scrum - Artifacts

2009-04-20T17:03:00.008-03:00

Terminando esse assunto abordando os "Termos do Scrum", falaremos agora sobre os Artefatos utilizados nesse método de desenvolvimento.

• Product Backlog

É uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.

Durante o Sprint Planning Meeting, o Product Owner prioriza os itens do Product Backlog e os descreve para a equipe. A equipe então determina que itens será capaz de completar durante a Sprint que está por começar. Tais itens são, então, transferidos do Product Backlog para o Sprint Backlog. Ao fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais tarefas do Sprint Backlog. Isso ajuda a dividir o trabalho entre os membros da equipe. Podem fazer parte do Product Backlog tarefas técnicas ou atividades diretamente relacionadas às funcionalidades solicitadas.

• Sprint Backlog

O Sprint Backlog é uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades.

Cabe a equipe determinar a quantidade de itens do Product Backlog que serão trazidos para o Sprint Backlog, já que é ela quem irá se comprometer a implementá-los.

Durante um Sprint, o Scrum Master mantém o Sprint Backlog atualizando-o para refletir que tarefas são completadas e quanto tempo a equipe acredita que será necessário para completar aquelas que ainda não estão prontas. A estimativa do trabalho que ainda resta a ser feito no Sprint é calculada diariamente e colocada em um gráfico, resultando em um Sprint Burndown Chart.

Bom,

Acho que sobre Scrum é isso. =]

Fonte: Product Backlog e Sprint Backlog

xD

2009-04-18T19:51:00.002-03:00

Como funciona o Scrum:
O Scrum Master é um facilitador para Scrum Team quando este encontra impedimentos no decorrer de uma Sprint.

Termos do Scrum - Meetings (parte 2)

2009-04-18T19:23:00.003-03:00

Continuando ...

• Sprint Review Meeting

"Ao final de cada Sprint é feito um Sprint Review Meeting. Durante esta reunião, o Scrum Team mostra o que foi alcançado durante o Sprint. Tipicamente, isso tem o formato de um demo das novas funcionalidades.

Os participantes do Sprint Review tipicamente incluem o Product Owner, o Scrum Team, o Scrum Master, gerência, clientes e engenheiros de outros projetos.

Durante o Sprint Review, o projeto é avaliado em relação aos objetivos do Sprint, determinados durante o Sprint Planning Meeting. Idealmente, a equipe completou cada um dos itens do Product Backlog trazidos para fazer parte do Sprint, mas o importante mesmo é que a equipe atinja o objetivo geral do Sprint".

• Sprint Retrospective

"O Sprint Retrospective ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar".

Na foto, ta o Sprint Retrospective depois da nossa primeira sprint. Fizemos numa folha A4 e escrevemos (cada membro do Scrum Team) as coisas boas e ruins ocasionadas no decorrer do desenvolvimento dessa primeira sprint.

P.S. >>> Qualidade da foto horrível. xD

Fonte: Sprint Review Meeting e Sprint Retrospective

CPU 2009 - VII Edição

2009-04-18T18:32:00.002-03:00

O Campeonato de Programação Universitário – CPU é um campeonato realizado pela Empresa Júnior de Computação da UESC – TecnoJr, destinado aos alunos do curso de graduação na área de Computação e afins (Ciência da Computação, Engenharia de Computação, Sistemas de Informação, Matemática, etc.) com o objetivo de:

Estimular o interesse pela programação de computadores.
Aumentar a integração aluno‐empresa.
Proporcionar a prática nas disciplinas de programação.
Proporcionar desafios aos estudantes das Faculdades ou Universidades da região.
Estimular o trabalho em equipe.

Esse ano o CPU ocorrerá no dia 04 de maio na Universidade Estadualde Santa Cruz (UESC), em paralelo com a ERBASE que ocorrerá entre os dias 4 e 8 de maio.

Mais informações no site do evento.

O Scrum Master

2009-04-18T15:15:00.001-03:00

Termos do Scrum - Meetings (parte 1)

2009-04-18T13:28:00.005-03:00

Continuando com os termos utilizados no Scrum, hoje falaremos sobre as Reuniões (Meetings) que as equipes que utilizam essa metodologia participa.
Vamos lá:

• Daily Scrum

"A cada dia do Sprint a equipe faz uma reunião diária (Daily Scrum). Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia".

De uma forma "ideal", essas reuniões deve ser feitas logo pela manhã, seguindo o mesmo horário sempre. Isso é feito pra que se possa estabelecer as atividades do novo dia de trabalho. No nosso caso (eu, Pablo e o nosso orientador Carlão), fazemos nossas reuniões em dias alternados na semana sempre no horário da noite, isso porque você deve adaptar a sua equipe de desenvolvimento ao melhor horário cabível aos membros.

Essa reunião serve para deixar todos os membros da equipe ligados no que está acontecendo no projeto e não para resoluções de problemas. "Durante o Daily Scrum, cada membro da equipe provê respostas para cada uma destas três perguntas":

O que você fez ontem?
O que você fará hoje?
Há algum impedimento no seu caminho?

No nosso caso as perguntas são:

O que você fez?
O que você fará até a próxima reunião?
Quais os impedimentos?

Perceba que as perguntas seguem o mesmo padrão, a diferença que existe é porque nossas reuniões não são "diárias".

Assim "a equipe ganha uma excelente compreensão sobre que trabalho foi feito e que trabalho ainda precisa ser feito. O Daily Scrum não é uma reunião de status report na qual um chefe fica coletando informações sobre quem está atrasado. Ao invés disso, é uma reunião na qual membros da equipe assumem compromissos perante os demais.

Os impedimentos identificados no Daily Scrum devem ser tratados pelo Scrum Master o mais rapidamente possível".

• Sprint Planning Meeting

"O Sprint Planning Meeting é uma reunião na qual estão presentes o Product Owner (Sr. Manoel da padaria), o Scrum Master (Pablo) e todo o Scrum Team (eu, Pablo e Carlão), bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente.

Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem ao Sprint Backlog.

O Product Owner não precisa descrever todos os itens que estão no Product Backlog. Dependendo do tamanho do Product Backlog e da velocidade da equipe, pode ser suficiente descrever apenas os itens de maior prioridade, deixando a discussão dos itens de menor prioridade para o próximo Sprint Planning Meeting.

Coletivamente, o Scrum Team e o Product Owner definem um objetivo para o Sprint, que é uma breve descrição daquilo que se tentará alcançar no Sprint. O sucesso do Sprint será avaliado mais adiante no Sprint Review Meeting (falaremos mais tarde) em relação ao objetivo traçado para o Sprint.

Depois do Sprint Planning Meeting, a equipe Scrum se encontra separadamente para conversar sobre o que eles escutaram e decidir quanto eles podem se comprometer a fazer no Sprint que será iniciado. Em alguns casos, haverá negociação com o Product Owner, mas será sempre responsabilidade da equipe determinar o quanto ela será capaz de se comprometer a fazer".

Fonte: Daily Scrum e Sprint Planning Meeting

ERBASE 2009

2009-04-17T23:53:00.003-03:00

9ª Escola Regional de Computação Bahia-Alagoas-Sergipe

Data: de 04 a 08 de maio de 2009
Local: Universidade Estadual de Santa Cruz - UESC - Ilhéus, BA

Maiores informações podem ser encontradas no site oficial.

Termos do Scrum - Roles

2009-04-17T17:11:00.004-03:00

Várias funções são definidas no Scrum. Essas funções podem ser relacionadas com os Roles (Papéis), Meeting (Reuniões) e Artifacts (Artefatos).

Hoje falaremos sobre os Roles:

• Product Owner

"O Product Owner é a pessoa que define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings.

O Scrum Team olha para o Product Backlog priorizado, seleciona os itens mais prioritários e se compromete a entregá-los ao final de um Sprint (iteração). Estes itens transformam-se no Sprint Backlog.

A equipe se compromete a executar um conjunto de atividades no Sprint e o Product Owner se compromete a não trazer novos requisitos para a equipe durante o Sprint. Requisitos podem mudar (e mudanças são encorajadas), mas apenas fora do Sprint. Uma vez que a equipe comece a trabalhar em um Sprint, ela permanece concentrada no objetivo traçado para o Sprint e novos requisitos não são aceitos."

• Scrum Master

"O Scrum Master procura assegurar que a equipe respeite e siga os valores e as práticas do Srum. Ele também protege a equipe assegurando que ela não se comprometa excessivamente com relação àquilo que é capaz de realizar durante um Sprint.

O Scrum Master atua como facilitador do Daily Scrum e torna-se responsável por remover quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões.

O papel de Scrum Master é tipicamente exercido por um gerente de projeto ou um líder técnico, mas em princípio pode ser qualquer pessoa da equipe."

• Scrum Team

"O Scrum Team é a equipe de desenvolvimento. Nela, não existe necessariamente uma divisão funcional através de papéis tradicionais, tais como programador, designer, analista de testes ou arquiteto. Todos no projeto trabalham juntos para completar o conjunto de trabalho com o qual se comprometeram conjuntamente para um Sprint.

Um Scrum Team típico tem de 6 a 10 pessoas, embora haja relatos de projetos Scrum com equipes maiores. A principal abordagem para trabalhar com equipes grandes no Scrum é usando o conceito de "Scrum of Scrums". Cada Scrum Team trabalha normalmente, mas cada equipe também contribui com uma pessoa que deverá freqüentar o Scrum of Scrums Meeting para coordenar o trabalho de múltiplas equipes Scrum. Esses encontros são análogos aos Daily Scrums, mas não acontecem necessariamente todos os dias. Fazer essa reunião duas ou três vezes por semana tende a ser suficiente na maioria das organizações."

Fonte: Product Owner, Scrum Master e Scrum Team

Scrum Process

2009-04-17T16:34:00.005-03:00

Como falamos, o "Srum é uma metodologia ágil para gestão e planejamento de projetos de software. No Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado.

As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog.

A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.

Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo. Veja a ilustração abaixo":

Fonte: Improvit

Scrum

2009-04-17T11:19:00.002-03:00

Scrum é um método ágil para Gerenciamento de Projetos.

Inicialmente, ele foi criado para gerenciamento de projetos em empresas de automóveis e bens de consumo. Foi concebido por Takeuchi e Nonaka no artigo "The New New Product Development Game".
A base desse método, é que a utilização de equipes pequenas e multidiciplinadas, produziam melhores resultados do que vinha acontecendo comumente.

"A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como eXtreme Programming (XP) e outras metodologias de desenvolvimento. Porém, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o planejamento de um casamento".

Fonte: Wikipédia

eXtreme Programming: Visão Geral (parte3)

2009-04-16T18:19:00.002-03:00

Bom pessoal,
Seguindo o que temos falado sobre o XP, além dos valores citados no post abaixo, temos também algumas práticas:

• Cliente Presente
• Jogo do Planejamento
• Stand Up Meeting
• Programação em Par
• Desenvolvimento Guiado por Testes
• Reafactoring
• Código Coletivo
• Código Padronizado
• Design Simples
• Metáforas
• Ritmo Sustentável
• Integração Contínua
• Releases Curtos

Vale ressaltar que essas práticas são as ideiais para esse tipo de metodologia de desenvolvimento de softwares, mas se por acaso a programação em par por exemplo não funcionar com sua equipe, aborte essa prática e posteriormente, tente aplica-la no conjuto das práticas que você já usa. Não force sua equipe a trabalhar com algo que não surte efeito, lembre-se: a "satisfação dos membros da sua equipe, vale mais do que ferramentas ou métodos utilizados".

Ahhh, falaremos mais sobre essas práticas em outros posts. =]

eXtreme Programming: Visão Geral (parte2)

2009-04-15T22:30:00.002-03:00

Continuando com a visão geral sobre o XP, veremos agora que ele baseia-se em 4 valores fundamentais:

• FeedBack
• Comunicação
• Simplicidade
• Coragem

Falamos no post anterior que o cliente aprende com a suas necessidades a partir do momento que ele passa a manipular o sistema sendo desenvolvido. Com isso, ele gera o nosso primeiro valor (FeedBack).
O FeedBack é o mecanismo fundamental, onde o cliente conduz o desenvolvimento do sistema de forma que a equipe direcione as suas atenções e ações para aquilo que o cliente acha que tem mais valor.
Assim, para que o cliente possa compartilhar do seu aprendizado no decorrer do desenvolvimento com a equipe, é necessario que haja um canal de comunicação entre eles. Essa comunicação "permite que todos os detalhes possam ser tratados com a atenção e agilidade que merecem". Portanto, a comunicação deve ser da forma mais direta e eficaz, buscando aproximar os indivíduos envolvidos no processo.
O outro ponto de valor crucial para que tudo possa ocorrer bem com o desenvolvimento, é a simplicidade. Com ela nós podemos garantir que o cliente possa aprender durante o projeto gerando assim um feedback rápido. É necessário aprender que o valor da simplicidade nos ensina que devemos implementar apenas aquilo que é suficiente para atender a necessidade do cliente. Traduzindo de um outro modo, devemos implementar somente aquilo que resolve o problema de hoje, problemas futuros devem ser resolvidos no futuro.
Por último, nossa "equipe precisa ser corajosa e acreditar que. utilizando as praticas e os valores do XP, será capaz de fazer o software evoluir com segurança e agilidade". Isso porque o sistema é feito de forma incremental, a equipe diverssas vezes irá realizar manutenção do software criando outras funcionalidades. Assim, pode ocorrer de alterar algo que já vinha funcionando com precisão, o que leva a riscos e falhas.

eXtreme Programming: Visão Geral (parte1)

2009-04-15T19:20:00.002-03:00

Extreme Programming, mais conhecido como XP, é um processo de desenvolvimento de software que tem como meta a criação de softwares de alta qualidade, econômica, de uma forma ágil e flexível.
Ele concentra esforços da equipe para o desenvolvimento de atividades que geram resultados rapidamente na forma de um software que foi criado e testado segundo as necessidades impostas pelos usuários. Este modelo de desenvolvimento, elimina atividades redundantes reduzindo assim os riscos de atraso e estouro de orçamentos, priorizando a interação com o cliente de forma a estabelecer uma relação de confiança.

Este processo de desenvolvimento é voltado para softwares que:

• seus requisitos são vagos e mudam com frequência.
• desenvolvimento orientado a objetos.
• equipes pequenas, no máximo até 12 membros.
• desenvolvimento incremental, onde o sistema começa a ser implementado logo no início do projeto, ganhando novas funções no decorrer do tempo.

A premissa na qual o XP segue é que o "cliente aprende sobre as suas necessidades, na medida que é capaz de manipular o sistema que está sendo produzido". Assim o cliente a cada dia que passa, re-avalia o sistema seguindo a suas necessidades e orienta os desenvolvedores (feedback) segundo as mudanças necessárias que devem ser incorporadas no software.
"O XP busca assegurar que o cliente receba o máximo de valor a cada dia que passa."

Manifesto Ágil - O começo de tudo

2009-04-15T17:53:00.005-03:00

O manifesto ágil foi assinado em 2001 pelos principais profissionais veteranos na área de desenvolvimento de softwares. Eles se uniram para discutirem uma nova forma para melhorar a velocidade no desenvolvimento de seus sistemas tendo como base as suas experiências de anos programando.

Dentre os envolvidos nesse manifesto, encontra-se:
• Kent Benck - Criador do eXtreme Programming*
• Ken Schwaber - Criador do Scrum*

Embora muitos desenvolvedores sejam contra esta metodologia, pois pode causar confusão dependendo do tamanho da aplicação, muito já são adeptos dos 4 principais conceitos do desenvolvimento ágil.

• Indivíduos e interação entre eles mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Mais informações sobre esse movimento, você pode encontrar no site oficial do manifesto.

* Falaremos mais tarde sobre eles

Início

2009-04-15T12:20:00.002-03:00

Bom pessoal,

Meu nome é Hebert e sou graduando em Ciências da Computação.
Comecei agora a ter contato com metodologias ágeis e por isso resolvi criar esse blog para que assim possa consolidar conhecimentos sobre este movimento que vem crescendo muito.

Claro que aqui não será nada de profissional, teremos assuntos voltados para essa área assim como comentários relacionados com a experiência que estou tendo adotando essa metodologia no meu projeto de conclusão de curso.

É isso ai...

Att