Saudações pessoal! Algumas informações do mundo do VXTra.org. ======================================================================= 1. Artigo fresquinho Quero largar meu emprego! Será que consigo? Resumo: Vou aqui fazer um exercício, no qual vou me imaginar trabalhando em uma empresa e completamente insatisfeito com o meu trabalho atual. Pode ser que eu goste da empresa, tenha uma remuneração adequada, tenha boa [...]
BDD está ficando mais conhecido ultimamente e muitas pessoas estão adotando a prática no dia a dia de desenvolvimento. Mesmo assim BDD é tão antigo quanto o próprio TDD (Test Driven Development).
BDD nada mais é do que trazer ao código, e principalmente ao código que testa os casos de uso da aplicação, um pouco mais da lógica de negócio e do problema que está sendo resolvido no nível do usuário.
Quando escrevemos algum teste unitário, normalmente damos um nome ao teste para que possamos entender os resultados quando gerarmos um relatório após a execução dos mesmos. Também damos nomes que façam sentido, para facilitar a comunicação da equipe de desenvolvimento, pois se outra pessoa da equipe precisar dar manutenção no teste, torna mais fácil a compreensão do que o teste está encarregado de testar sem que seja necessário ler muitas linhas de código.
Nos tempos atuais falamos bastante de aumentar a integração da equipe com o cliente ou a área que entende do negócio da aplicação. Também falamos em uma maior colaboração de ambas as partes no desenvolvimento de software. Para quebrar essa barreira que existe entre desenvolvimento e análise, algumas equipes empregam uma programação mais voltada a resolver os casos de uso propostos, ao invés de resolver problemas de baixo nível e compor uma aplicação final.
BDD prega que o problema que será resolvido deve estar bem claro para a parte quem entende do negócio (chamarei de cliente, mesmo que algumas vezes não seja necessariamente um cliente), e quem desenvolve a aplicação em si. Para isso são escritos casos de testes baseados nos casos de uso do sistema, e tais casos de teste usam uma linguagem comum para ambas as partes.
Como normalmente o cliente não é técnico, fica muito difícil se comunicar com ele via testes unitários em código, e fica mais difícil ainda que o cliente colabore com a melhoria e a escrita de tais testes. Porém, os testes unitários e automatizados são a melhor ferramenta do desenvolvedor para testar a aplicação e garantir que a equipe mantenha o código funcionando.
Para suportar ambas as necessidades, e implantar o BDD de fato, uma das soluções é associar o problema de cada caso de uso, a um teste unitário que irá se certificar que aquele caso de uso está sendo corretamente executado.
Por exemplo, em java podemos dar nomes a nossas classes de teste de acordo com o caso de uso que aquele teste se refere. E podemos também nomear os métodos como a execução específica daquele caso de uso:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 |
public class TesteDeCadastroDeUsuario {
? ? ? ? @Test ? ? public void testeDeCadastrarNovoUsuario() { ? ? ? ? ? ? // … cadastra o usuário ? ? ? ? ? ? Assert.assertTrue(“Usuário novo não foi cadastrado corretamente, “ ? ? ? ? ? ? ? ? ? ? ? ? + “pois o nome está inválido.”, ? ? ? ? ? ? ? ? ? ? ? ? nomeUsuarioValido()); ? ? ? ? } ? ? } |
Dessa forma quando o cliente ver o resultado dos testes e perceber que este teste falhou, ao invés de ler algo como “O serviço de usuário voltou null.”, ele conseguirá ler “No teste de cadastro de usuário, ao testar que um usuário novo está sendo cadastrado, o teste falhou pois o usuário não possui um nome válido, logo não foi cadastrado.”
Parece pouca coisa, mas para o cliente é um informação muito importante nas discussões sobre prioridade de correção de bugs e melhorias do sistema. Isso porque fica claro para o cliente quando o desenvolvedor descreve o teste exato que falhou e o cliente sabe exatamente a qual caso de teste se refere e qual o problema que está sendo resolvido. Não é informação pertinente ao cliente como que tecnicamente se corrige o problema e como que o sistema está implementado para que o erro ocorre-se, esse é o papel do desenvolvedor.
Existem muitos frameworks para facilitar a empregação do BDD. Vimos aqui que mais do que um framework, BDD é uma cultura e pode ser empregado sem o uso de qualquer ferramenta, pois o importante é manter a comunicação entre os níveis técnicos diferente na mesma equipe.
Muitos correm atrás da implantação do BDD nos projetos com a esperança de que os problemas na resolução de bugs e na comunicação da equipe serão resolvidos. Isso não é verdade e seu projeto irá dar tão certo quanto ele daria antes da adoção de BDD. BDD é um mudança de comportamento na equipe onde todos devem estar empenhados na causa de melhorar a comunicação, e tentar entender os problemas de verdade que o sistema se propõe a resolver.
A mudança de comportamento tem que partir do lado do cliente também, pois é necessário a compreensão de que os erros que estão claros para ele agora, não surgiram do nada. Na verdade eles sempre estiveram presentes no sistema, só que protegidos pela barreira que impedia a comunicação entre de desenvolvimento e análise.
Espero ter sido claro, qualquer opinião sobre o assunto será bem vinda.
Por @Gust4v0_H4xx0r
…Houve um tempo em que eu achava que métodos ágeis eram um excelente álibi para programador preguiçoso. E, ainda hoje, as vezes fico pensando sobre o significado do nome “ÁGIL”. Será que esse nome contempla, de fato o seu propósito, ou é um nome meramente “marketeiro”? Veja só: No dicionário, o significado de “ágil” é ser rápido e flexível, por sua vez, no dicionário, o antônimo de ágil é lento e vagaroso. Ora, ninguém quer ser taxado como lento e vagaroso! Sendo assim, se eu não quero ser taxado de lento e vagaroso, então por eliminação eu sou ágil.
Esse clichê formado sobre a palavra ÁGIL distorceu um pouco as coisas. Muitas empresas e desenvolvedores que não conseguiam implantar processos de desenvolvimentos de software maduros, e que por muitas vezes cairam no mito da Fantástica Fábrica de Software, começaram a se intitular como ágil. Nesse contexto continuo achando que métodos ágeis são um excelente álibi para programador preguiçoso.
A questão é que desenvolver software é uma tarefa que dependente de tecnologia, processos, e, sobretudo, do conhecimento das pessoas. Como já diria Fred Brooks em seu famoso artigo No Silver Bullet, não existe bala de prata, não existe ferramenta, metodologia ou qualquer outra mágica que resolva milagrosamente todos os problemas.
Segundo [Filho, 2008]: “em uma organização imatura os mesmos problemas se repetem de projeto em projeto, o trabalho é excessivo e estressante e frequentemente há a necessidade de corridas desesperadas contra os prazos, a qualidade de vida no trabalho é ruim, o ambiente é desgastante e os profissionais são desmotivados. Os erros relativos ao processos de desenvolvimento de software são comuns em organizações que utilizam processos imaturos, ocorrendo também naquelas que possuem processos rígidos, complexos e burocráticos e naquelas em que os processos apesar de existirem são seguidos parcialmente, ou em última instância, não são seguidos.”
Não obstante, o mercado tem exigido produtos de software ainda mais sofisticados e em prazos de desenvolvimento mais curtos. A referida exigência, tem instigado a pesquisa na área engenharia de software, objetivando encontrar meios para garantir que o software seja produzido atendendo às expectativas do cliente e aos atributos de qualidade definidos pela organização fornecedora de software e esperados pelo mercado.
Antes de enfatizar a importância da agilidade do processo, é preciso entender o que ela realmente significa. Em suma, é a capacidade que uma organização possui para responder rapidamente às forças , fraquezas, oportunidades e ameaças do mercado. Há inúmeras situações práticas, onde agilidade do processo é altamente desejado, incluindo: apresentando um novo produto, entrar em um novo mercado, responder à entrada de concorrentes, responder a alterações de requisitos em produtos em construção, etc.
Outro aspecto, é que o processo de desenvolvimento de software é complexo e precisa favorecer a criatividade e a inovação, e ter um nível adequado de flexibilidade para beneficiar a engenharia de processos na melhoria contínua. O grande desafio na proposta de um processo é conseguir um conjunto de regras que guiem o desenvolvimento sem comprometer a criatividade e a motivação dos desenvolvedores e sem travar a organização para a constante evolução da tecnologia e as adequações necessárias.
Uma abordagem adotada para romper a barreira da imaturidade é a definição de um processo de desenvolvimento de software padrão. O referido processo descreve as atividades que devem ser realizadas no desenvolvimento de software em todos os projetos da organização. A idéia é que isso favoreça que a organização atinja a conformidade com os padrões de qualidade esperados. Na literatura existem várias definições para processos de desenvolvimento de software:
De forma bem resumida, o processo de desenvolvimento de software formal descreve por meio da sua documentação: o que é feito , quando é feito, por quem é feito, como é feito, além dos insumos que usa e os produtos de saída. Em outras palavras, o processo enfatiza a padronização para possuir um parâmetro de medida e de controle e para poder circunscrever o erro em busca de qualidade. Contudo, embora seja necessário definir um processo de desenvolvimento de software, só isso não é suficiente para a construção satisfatória de um software. Existem vários fatores envolvidos que influenciam diretamente a construção do software, por exemplo: a capacitação das pessoas envolvidas, as tecnologias e ferramentas utilizadas, a cultura organizacional, entre outros.
Um processo de desenvolvimento de software não é definido do zero. Na literatura existem vários modelos que descrevem orientações para a definição e implantação de processos, dentre eles a ISO 12207/15504, CMMI e MPS-BR. Nesta linha, o processo de desenvolvimento de software deve estabelecer :
Em busca de eliminar a imaturidade, as organizações investem em definir e implantar um processo baseando-se em modelos de maturidade como CMMI e MPS-BR. Entretanto, esses modelos são densos, repletos de subprocessos que devem ser implementados em cada área de processo de cada nível de maturidade (no caso de CMMI) .
Um nível de maturidade é um patamar evolutivo bem definido que que “determina” a capacidade que uma organização possui em desenvolvimento de software. Cada nível visa alcançar um processo de desenvolvimento de software cada vez mais maduro. Os níveis são uma forma de priorizar as ações de melhoria, de tal forma que se aumente a maturidade do processo de forma continua. Assim, os níveis de maturidade são cumulativos, ou seja, um nível de maturidade mais alto inclui os atributos dos níveis mais baixos. Uma vez que os modelos são projetados para descrever níveis discretos de melhoria de processo, níveis de capacidade provêem uma ordem recomendada para abordar a melhoria de processo dentro de cada área de processo.
É esperado que a cada nível alcançado pela organização, mais madura ela se torna em desenvolvimento de software. Um bom processo não garante que os produtos produzidos são de boa qualidade, mas é um indicativo de que a organização é capaz de produzir bons produtos. Para que isso seja alcançado, um bom processo de desenvolvimento de software baseado em modelos de maturidade como CMMI e MPS-BR só podem ser considerados maduros se houver uma equipe de Quality Assurance atuante, autônoma e não condicionada. Essa equipe trabalha constantemente na garantia e no controle de qualidade do processo e do produto, respectivamente.
Quando uma organização atinge o nível 5 no CMMI ou A do MPS-BR, ela entra em um espiral de melhoria continua. A equipe de projeto e a equipe de qualidade reportam para a equipe de definição de processo gargalos e deficiências do processo atual, e complementam com sugestões para melhoria de processo. A equipe de definição de processo por sua vez avalia todas as sugestão, e, se pertinentes, implantam a melhoria no processo. Isso se torna um ciclo de inspeção e adaptação do processo. Quanto mais madura a equipe, menos atividades de inspeção técnica e verificação são necessárias para garantir a conformidade com o processo e mais esforços podem ser realocado para garantir a conformidade do produto. Veja o post sobre Conformidade com o Produto vs. Conformidade com o Processo.
No gráfico acima tentei ilustrar o que percebo sobre a agilidade de processos. Quando se fala em agilidade em processo, já estamos condicionados a pensar em métodos ágeis de desenvolvimento de software como Scrum, eXtreme Programming , princípios Lean etc. No entanto, agilidade, na essência, se aplica em um ambiente de desenvolvimento formal também. No início, quando a organização não possui nenhum processo definido o ambiente não é estável, e, frequentemente, ela depende da competência e heroísmo das pessoas para atingir seus objetivos. Neste ambiente, a rigidez de processo é baixa, informal e caótico, mas apesar disso as organizações muitas vezes produzem produtos e serviços que funcionam. Entretanto, elas freqüentemente estão expostas a vários problemas de projeto como: exceder o orçamento e o cronograma planejado, baixa qualidade, não cumprir compromissos, abandonar processos em momentos de crises e não ser capazes de repetir sucessos do passado.
Para não ficar tão expostas aos problemas de projeto citados, as organizações partem para implantação de processos, e, a medida que esses processos são implantados e os níveis de maturidade de processo são obtidos, mais “rígido”, mais “burocrático” o processo se torna. No entanto, entendo que a tão criticada rigidez e burocracia de processos formais é uma fase transitória, de aprendizado, de padronização e, sobretudo de amadurecimento. Nos níveis mais altos de maturidade o objetivo é a simplificação, a “des-burocratização” de processo. Lendo isto alguém poderia estar perguntando: “Ora! Então porque a organização não vai direto para esse estado?” Bom, imagino que isso se torna necessário na caminhada da Imaturidade à Agilidade.
Chaus Report 2009 – Standish Group
Pesquisas como as realizadas pelo Standish Group apresentadas no Chaus Report 2009 demonstram que grande parte dos projetos de software falham ou são desafiados, seja porque não cumprem o orçamento, ou não cumprem o cronograma, ou as funcionalidades não atendem às necessidades dos usuários ou porque todos estes fatores estão presentes em conjunto. Para o Standish Group um projeto de software é considerado um Sucesso quando todas a funcionalidades do escopo inicial são entregues no orçamento e cronograma planejado. O projeto é Desafiado quando ele sofre com atrasos, não cumpre o orçamento inicial e/ou é entregue com menos recursos e funções do que o definido no escopo inicial. E finalmente, o projeto é considerado Falho quando ele é cancelado antes da conclusão ou o produto da sua entrega nunca é utilizado.
Há algumas décadas a indústria de software vem buscando técnicas de desenvolvimento que possam reduzir os riscos dos projetos de software e tornar essa atividade mais produtiva. A referida constatação não é recente. Já em em 1968 houve um evento denominado conferência de NATO, que, entre outras coisas, tentou entender e discutir o porquê que a maioria dos projetos de software falham ou são desafiados. De lá para cá, a indústria de software vem evoluindo e a partir dos anos 90 surgiram várias propostas como o desenvolvimento de processos formais como RUP, pautados sobre modelos de maturidade como CMMI e a evolução de autores consagrados como Coad & Yourdon, Pressman, Sommerville, Rumbaugh, Booch, Jacobson, etc.
Quando o assunto é desenvolvimento de software, existem basicamente duas grandes “escolas”: a tradicional e a ágil. Cada uma delas enxerga e trata o processo de desenvolvimento de software de maneiras bem peculiares, apesar dos objetivos finais serem os mesmos. Na escola tradicional o conceito de processo de desenvolvimento de software se assemelha ao usado em processos de produção industrial: um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e transformações usadas para atingir uma meta, centrado em documentação e controle operacional. Já os adeptos das metodologias ágeis não estão presos a processos rígidos; o que interessa é aquilo que de fato agrega valor ao usuário, não que a escola tradicional não pense assim, como entregas rápidas ou como já diria um dos princípios ágeis: “Nossa maior prioridade é satisfazer o cliente através da entrega rápida e contínua de software de valor.”
Não obstante, a indústria de software é bastante dinâmica, novas idéias, tendências e tecnologias surgem a todo instante e em todas as partes do mundo. Acompanhar essa dinâmica é fator crítico de sucesso para profissionais e empresas que pretendem adquirir um diferencial no mercado. Um ponto fundamental para acompanhar o dinamismo do mercado está na habilidade de lidar de forma mais eficiente com as mudanças de requisitos, aumentar a motivação da equipe e melhorar comunicação com o cliente do projeto, e, para isso, será necessário estar pronto para introduzir uma nova cultura de liderança que irá alterar os papeis e trará uma nova forma de trabalhar transferindo parte da responsabilidade do gerente do projeto para a equipe.
A adaptação às mudanças decorrentes de fatores externos são uns dos conceitos centrais dos métodos ágeis. Onde os métodos mais formalizados e centrados em planejamento e documentação são preditivos na tentativa de prever as necessidades futuras, em contrapartida, os métodos ágeis são adaptativos e rapidamente se adaptam às novas exigências, aderindo ao lema “abrace as mudanças!”. A única medida de sucesso é a de produto funcionando.
Outro princípio importante é a simplicidade e pensamento enxuto. De acordo com o conceito de pensamento ágil, projetos de grande escala, por exemplo, não são desejáveis. Pelo contrário, é preferível minimizar a quantidade de trabalho daquilo que não precisa ser feito. Isto inclui, por exemplo, não gastar tempo escrevendo documentação desnecessária.
Cada vez mais a abordagem ágil de desenvolvimento de software vem se popularizando entre grandes empresas de sucesso como: google, yahoo, amazom.com, globo.com entre outras. No entanto, nem sempre as empresas que tentam adotar a filosofia ágil têm obtido o mesmo sucesso. Várias discussões tem se formado para entender o motivo do referido insucesso, e as conclusões estão convergindo para fatores como: falta de treinamento dos colaboradores; equipes hierarquizadas, e, sobretudo, resistência de mudança cultural.
Desenvolver software é uma tarefa que exige técnicas de engenharia e arte. Se uma empresa ou profissional não absorver a filosofia ágil dificilmente se manterá competitiva no cenário atual do mercado de software por mais que se implemente uma metodologia.
Nesse sentido, cabe a nós profissionais críticos, formadores de opinião, termos a a clara consciência de adotar processos tradicionais ou processo ágeis, ou no melhor dos casos, como integrar os dois para tirar o maior proveito.
Chegou aquela altura do ano em que do lado do WordPress.org se começam a dar os retoques finais na próxima versão do WordPress (a 3.1, neste caso). Os utilizadores do WordPress.com são automaticamente incluídos na versão beta, dando-lhe todo o acesso a novas funcionalidades, um mês antes de estas serem lançadas oficialmente. Isto é bom, não só porque lhe dá um acesso antecipado ao que aí vem, mas como também a sua opinião nos ajuda a melhorar ainda mais. Estou muito animada, tanto pelos os novos recursos que acabámos de implementar, como por serem adições que já desejava há muito tempo. Aqui estão as novas funcionalidades que já pode ver no seu painel:
Fi.nal.mente. 
Está a escrever um post (ou uma página) no WordPress. Menciona algo que tenha escrito antes, e pensa: “Já sei, vou criar uma ligação para esse post!” O que é que fazia? Pode ser que abrisse um novo separador ou janela e que procurasse no seu conteúdo na sua lista de posts, ou ainda que visitasse o seu blog e procurasse esse post. Seja como for, teria que encontrar esse conteúdo, obter a respectiva URL, de modo a ao clicar no botão de link no editor de posts, poderia colá-la. Certo? Isso são o quê? Entre 5 a 8 passos, dependendo de como o fazia? Não mais!
Posts e páginas existentes podem ser encontrados e ligados com uma pesquisa dinâmica.
Com a nova funcionalidade de links internos, pode agora indicar qualquer URL para criar um link, como costumava fazer, ou então procurar nos seus posts e páginas existentes logo ali, na janela de inserção de links. Uma combinação de pré-carregamento, preenchimento previsivo e alguma magia Ajax tornam o uso da ferramenta de criação de links numa alegria (e confira quão mais rápida está a janela!). Esperamos que isto o incite a fazer mais conexões entre o conteúdo do seu site, o que tornará mais fácil para os seus visitantes encontrar mais conteúdo relacionado. Agora todos juntos: Viva! (Certo?)
Quando visita a página de Posts (ou de Páginas, ou de Media ou de qualquer outra informação em lista), alguma vez desejou poder clicar no nome da coluna para alterar a visualização, ordenando por exemplo a informação por data, por ordem alfabética, por autor ou por outro critério? Eu sei que eu quis, desde sempre. Já temos! Este recurso é o resultado de um bem-sucedido projecto de um aluno do Google Summer of Code, demonstrando ainda que o programa é uma ótima maneira de se envolver com o desenvolvimento do WordPress. A pequena seta ao lado do título da coluna (na minha imagem de exemplo, a coluna Data) mostra a coluna pela qual a informação está ordenada, e se a ordenação é ascendente ou descendente. Basta clicar no cabeçalho de qualquer coluna para ordenar por essa coluna ou para inverter a ordem.
Se tem muito conteúdo, pode ser que tenha tido uma experiência levemente irritante ao navegar as páginas posts, media ou outros. Clicar para a frente e para trás é fácil, tal como saltar para a primeira ou última página, mas então e o meio? Imaginemos que tem 23 páginas de posts; está na página 6 e, com base nas datas, acha que o que está à procura deve estar por volta da página 15. Teria que clicar várias vezes para avançar algumas páginas, até chegar à página desejada. Não mais! Com o novo estilo de paginação, os botões para a frente/fim e para trás/início continuam lá, mas agora pode ir directamente para qualquer página, alterando apenas o número editável mostrado na área de paginação (e carregar em Enter).
Os resultados de pesquisas são agora mais rápidos e não requerem actualizações do painel no seu browser graças à adição de Ajax. Rápido!
Nas opções do seu perfil, tem uma escolha de esquemas de cores do painel, cinza ou azul (o padrão é cinza). Actualizamos o esquema de cores cinza há algum tempo, mas não actualizamos o azul. (Lembra-se quando mudamos do cabeçalho do escuro para o mais claro? Bons velhos tempos.) O novo esquema de cores azul é mais leve, mais limpo e com base nos mesmos tons que o esquema de cor cinza, mas com uma tonalidade azul, para que o foco possa permanecer firmemente na criação de conteúdo, sem distrações. Se você nunca experimentou o esquema de cor azul, agora seria um óptimo para experimentar e ver se gosta! Existem outras cores que gostaria de ter como opções? Diga-nos nos comentários!
Para aqueles que têm tido problemas em usar arrastar e largar no painel ou ainda algum problema com o editor visual na criação de posts, com o Internet Explorer 9, foram feitas melhorias para funcionem agora sem problemas no mais recente browser da Microsoft.
A ter em conta: estas funcionalidades são novas e embora tenhamos trabalhado nelas durante bastante tempo, poderá encontrar um erro que nos tenha escapado. Se alguma delas lhe estiver a causar problemas, pode deixar um comentário neste post durante as próximas duas semanas, falar sobre isso nos fóruns, ou contactar o suporte através dos canais habituais.
Espero que apreciem estas notícias, tanto quanto nós gostamos de as desenvolver. Bom blogging!
Actualização
Graças aos vossos comentários, conseguimos já detectar e corrigir alguns erros que escaparam nos nossos testes.
Se mesmo assim continuar com problemas com as novas funcionalidades, quando deixar um comentário ou contactar o suporte, por favor indique o sistema operativo e browser que está a usar, para nos ajudar a resolver o problema mais depressa. Exemplos: “Estou a usar Firefox 3.9 com Mac OSX 10.5.” ”Estou a usar Google Chrome em Windows 7.”
Obrigado!
Começou um certo barulho na comunidade de desenvolvedores brasileiro em volta do plano de certificação Pomodoro. Isso não é novidade mas só agora crio um certo barulho.
Já há a bastante tempo venho usando a metodologia e em todos os casos que uso por completo o benefício é gigante.
O benefício real do pomodoro não está na idéia ridícula de ter um timer de 25 minutos. O intervalo na verdade pode ser qualquer tempo, contando que você consiga passar esse tempo todo sem distração.
A grande vantagem está no planejamento e revisão dos seus resultados. A medida que vai trabalhando com Pomodoro, começa a conhecer com mais precisão quantos pontos consegue fazer por semana. Outra vantagem é poder analisar seus resultados e ver porque na semana X você foi mais lento que na semana Y.
Estas análises tem me ajudado a perceber que trabalho melhor sem música, na parte da manhã e com skype/ichat fechados. Também passei a abrir o email apenas 3 vezes ao dia com base no que aprendi com os meus Pomodoros.
Na prática, eu não vejo diferença nenhuma de Pomodoro e métodos ágeis. Ou seja, releases menores, feedback, review, foco e etc. No meu ponto de vista as únicas diferenças são que o Pomodoro é aplicável em qualquer coisa, é individual e mais antigos que Agile.
De fato coisa é bem mais complicada que um timer bobo. Se você trabalha em um escritório com 10 pessoas, como deve proceder para a metodologia continuar tendo benefícios? Como você evita distrações em escritórios? Se você não usou um dia será quer perdeu suas métricas da semana toda? E se um cliente te liga para explicar uma funcionalidade, isso quebra o Pomodoro?
Essas perguntas só tem boas respostas quando respondidas por quem já usa há bastante tempo. Razão pela qual sempre achei interessante os cursos e material sobre Pomodoro do Francesco Cirillo.
Na prática eu vejo a aplicação do Pomodoro algo tão discutível como emprego de métodos como Scrum e principalmente Kanban. A diferença é que o foco é no indivíduo.
Também é importante lembrar que não adianta nenhum método ágil se o membro da equipe, sozinho, não for ágil o bastante para administrar o seu dia e cumprir suas tarefas.
Quanto a cerfiticação, é claro que sou contra. Mas sou contra por motivos diferentes do que as pessoas tem falado.
Percebi pessoas dizendo que isso é ridiculo mas no sentido da técnica ser simples de mais para caber algo como uma certificação. Se o raciocínio é este então eu descordo completamente e acho que faltou bastante pesquisa antes de formar uma opinião qualquer.
A razão pela qual sou contra a certificação é a mesma que me faz ser contra certificações Scrum, Ruby ou quem sabe, um dia, Kanban. Pelo simples motivo de não garantir nada e de que para ser produtivo uma pessoa pode usar vários métodos, Pomodoro é um deles.
.
Essa notícia é bem interessante, e no sentido real da palavra, de que nos interessa e muito, o Rafael Martinelli trouxe diretamente da MAX essa informação. Fiquei bastante impressionado com o MoleHill, motivo que me fez escrever esse post dando uma introdução sobre o assunto.
Estarei acompanhando com muito interesse o que estiver acontecendo nesse segmento e sempre que possível vou procurar trazer novidades sobre essa engine.
Mas afinal, o que é MoleHill?
“Molehill” é o nome de código para um novo conjunto de baixo nível, com APIs de aceleração GPU 3D que permitirá avançadas experiências em 3D nas telas através do Adobe ® Flash ® Platform runtimes.
Existem diversas comunidades, frameworks para desenvolvedores poderem ampliar seus horizontes na criação de aplicações 3D, como Alternativa3D, Away3D, Flare3D, Sophie3D ou Yogurt3D.
Durante a AdobeMAX um vídeo muito interessante foi apresentado para os participantes, ele mostra um jogo em 3D com gráficos mais apurados, algo que não deixa nada a desejar a consoles físicos para games, e que, talvez não fosse nada fantástico o vídeo abaixo se o game não estivesse rodando em um FlashPlayer.
Impressionante ver o que a Adobe fez, e contrariando muitos que dizem que o flashplayer requer processamento da máquina, a Adobe fez um game com uma estrutura potente e que requer ZERO, isso mesmo, ZERO de processamento da CPU, utilizando somente a placa aceleradora.
Confira o vídeo antes de continuar o artigo.
.
De acordo com o anúncio feito pela Adobe, no primeiro semestre de 2011, (quando em versão pública beta) a versão do Flash Player irá suportar essas novas APIs, bem como também acontecerá uma atualização do Adobe Flex SDK. Para obter mais informações leia atentamente o Molehill faq:
http://labs.adobe.com/technologies/flash/molehill/#faq
Para a maior parte das suas dúvidas você com certeza encontrará as respostas aí nesse link, portanto vou me fixar a falar das possibilidades de algo assim.
Não será novidade pensar que milhares de desenvolvedores começarão a criar seus games, mas não é só de game que vive o homem, apesar de ser muito bom é claro. Essa engine nos dará possibilidades de experimentar de fato uma nova era da web em 3D. Lembramos que o shockwave não deu certo, não emplacou, mas pelo visto a Adobe aprendeu com o erro e fez uma engine de qualidade, a cada dia mais e mais computadores saem de fábrica com placa aceleradora 3D, ao ponto que isso está se tornando comum, se essa engine é a primeira fase, podemos esperar muito pelo que esta por vir.
Pense nas aplicações 3Ds que poderão ser desenvolvidas, pensem em um showroom virtual, hotsites etc, tudo aquilo que era feito antigamente com as piores gambiarras possíveis, hoje poderá ser realizado com qualidade.
Sou suspeito para tecer elogios a Adobe visto que sou um entusiasta, fiz minha carreira em cima de todos os seus sofwares, e claro, da Macromedia, que hoje é Adobe… portanto fico feliz em saber que ela nunca abandonou o Flash, e mais que isso, se empenhou em criar inclusive um conversor de SWF para HTML5, fazendo com que os desenvolvedores Flash (vulgo flasheiros) não percam seu mercado, afinal, se Flash fará HTML5, certo é dizer que HTML5 nunca fará um SWF e nem chegará perto da qualidade, visto que essa tecnologia com todo respeito ainda está engatinhando.
Mas o assunto é MoleHill, vamos continuar falando de quem vai se dar bem nessa história toda na minha opinião.
.
.
Evidente, ela já se deu bem, e depois e todo o alvoroço e discussão sobre o Flash rodar ou não no Iphone fica aí um susto que a Adobe está dando a Apple, ou não, pois talvez a mesma já previa tal situação e portanto procurou evitar os games em Flash para poder alavancar a AppStore, sem entrar muito no tema, nem são os games 3Ds os mais vendidos na mesma (portanto nem sei porque da preocupação do Steve, talvez parcerias , enfim) mas… certamente essa é uma tecnologia fantástica que faz a Adobe novamente ficar a frente dos demais, como sempre esteve. Afinal, uma plataforma para desenvolvimento de games mais sérios, com suporte a joysticks, volantes etc, (nada pronunciado a respeito mas isso vemos nos vídeos, o volante do XBox sendo utilizado), combinado com um Flash Media Server, um ambiente de multiusuário, online, pode ser realmente devastador (no bom sentido) para o mercado como um todo.
Então não poderíamos deixar de falar quem é que mais ganha com isso.
.
.
O Android tem sido um parceiro do Flash simplesmente porque a Apple não quis ser no seu iOS, e a Adobe já se pronunciou a respeito dizendo que haverá acesso as APis 3D também para as plataformas móveis… fantástico, não só para games, mas como falei, para outros recursos de aplicativos.
A web sempre procurou introduzir o 3D, é uma tendência natural, também sou suspeito para falar do assunto pois sempre apostei no 3D e sou um 3Ddesigner também e obviamente amo o assunto e sempre acreditei que a experiência 3D é muito poderosa, pois ela trata quase todas as sensações visuais que o cérebro pode comportar, dando é claro maior realismo ainda que não haja muitos detalhes gráficos.
Posso dizer que consigo passar horas desenvolvendo algo em 3D sem me cansar, pois me sinto imerso no ambiente, mas não é a mesma coisa para desenvolver algo em 2D.
Enfim, o Android de fato vai se dar bem nessa história, vai abocanhar todo um mercado de 3D para mobile, com milhares de desenvolvedores famintos para migrar diversas aplicações e games prontos para essa engine, para rodar em Flash.
.
Os diversos frameworks que já citei.
.
Dentre eles eu aposto mais no AlternativaPlatform, me pareceu mais robusto, mais acabado inclusive, a maioria dos vídeos que trago aqui são desse framework, no mais, outras como Frare3D e Away3D também me parecem boas, mas como ainda não botei a mão em nenhuma delas fica suspeito comentar, em um futuro próximo farei alguns testes (como designer) e darei a minha visão. Mesmo assim, tanto designer como desenvolvedor terá uma gama de possibilidades bastando ver as suas necessidades, e ter várias opções nesse caso é muito bom.
Vou dar um foco maior a AlternativaPlatform, portanto veja o anúncio feito no blog da própria empresa sobre a Adobe Max.
http://blog.alternativaplatform.com/en/2010/10/16/alternativa-3d-is-free-see-you-at-adobe-max
Confira a qualidade do site:
http://alternativaplatform.com/en/
Uma breve introdução visual:
.
Confira outro vídeo, agora de uma visão externa mostrando o “jogador” do MaxRacer :
.
.
Outro vídeo da Alternativa3D:
.
.
Agora da Frima Studio (http://www.frimastudio.com/), que utilizou a engine usada para PSP do jogo Zombie Tycoon (http://www.zombietycoon.com/EN/index.htm) migrando para Molehill (sim fantático, não o jogo mas a possibilidade) :
.
.
Away3D :
.
.
O primeiro é a sessão de Sebastian (engenheiro-chefe na Molehill):
.
.
O segundo vídeo é da equipe Flare3D, apresentando o Molehill e suas vantagens:
.
.
Away3D e Alternativa3D teams (equipes), ainda sobre seus respectivos frameworks e vantagens:
.
.
E então a Pixel Bender 3D:
.
.
Bom galera, espero que esse post tenha sido uma boa introdução para conhecer o assunto, fiz uma pesquisa vasta para trazer as melhores informações sobre o tema e espero que tenham gostado.
Assim que tiver novas informações interessantes estarei postando, até lá se você também tiver algo a acrescentar não deixe de comentar aqui nesse post.
E que venha o mundo 3D na web.
_________________________________________
Eduardo Horvath é UX Specialist e Designer na DClick.
Formado pela Faculdade Impacta de Tecnologia no curso Design de Mídia Digital ele atua na área de Design a mais de 15 anos.
@eduardohorvath
Olá pessoal
Faz um bom tempo que não escrevo e isso porque eu tenho trabalhado bastante graças a DEUS.
Hoje vou falar sobre um assunto que pode ajudar quem tem Motorola Milestone, vou ensinar como habilitar a conexão 3G da OI, apanhei um pouco mais acabei conseguindo achar um conteúdo legal na net para fazer isso, então vamos ao trabalho.
Com seu Milestone em mãos, vá em Menu>Configurações>Redes Sem fio e Outras>Redes Móveis>Pontos de Acesso>Menu>Novo APN e coloque a configuração abaixo
| Oi | |
| Nome = Oi Dados APN = gprs.oi.com.br Proxy = Não definido Porta = Não definido Usuário = oi Senha = oi Servidor = Não definido MMSC = Não definido Proxy de MMS = Não definido Porta MMS = Não definido MCC = 724 MNC = 31 Tipo autenticação = Não definido Tipo APN = default |
Nome = Oi MMS APN = mmsgprs.oi.com.br Proxy = Não definido Porta = Não definido Usuário = oimms Senha = oimms Servidor = Não definido MMSC = http://200.222.42.204:8002 Proxy de MMS = 192.168.10.50 Porta MMS = 3128 MCC = 724 MNC = 31 Tipo autenticação = Não definido Tipo APN = mms |
Pronto, agora é só brincar com seu Milestone que na minha opinião é um dos melhores Smartfones do mundo.
Nesse primeiro screencast vamos falar sobre um programa para a construção de wireframes bem interessante, o Balsamiq.
Uma das principais características dele é a construção de interfaces com elementos que simulam o desenho feito a mão.
Essa característica, na minha opinião, é muito boa porque tira da mente do cliente / usuário que não teve contato anterior com documentações de wireframe a idéia que o produto apresentado é o visual (layout) da aplicação. Ou seja, o foco da discussão é direcionado exclusivamente para as questões de prioridade de informação, elementos de conteúdo e navegabilidade.
Confira abaixo o screencast e veja as possibilidades:
A correria está grande aqui em LA. Acabamos de chegar no hotel depois de ver a apresentação do Sneak Peaks e da festa de confraternização. Ontem ocorreu o mesmo, saímos para jantar e acabamos chegando tarde e cansados e não conseguimos colocar nenhum conteúdo.
Para resolver o problema e, na minha opinião, da melhor maneira possível, começamos a gravar hoje alguns podcasts. São conversar bem descontraídas sobre o que estamos vendo aqui na MAX. Nesta primeira parte participaram Diego Volpe e Rodrigo Botelho da Pearson Brasil(antigo COC), Henrique Marino e eu da DClick. Tivemos que parar esta primeira parte no meio, pois começamos uma conversa com um pessoal da Universal Mind e logo após isso os Sneak Peaks estavam começando. Mesmo assim, o Diego nos fala do que viu no Preconference Lab que ele fez.
Vejam que essa primeira parte está quebrada em duas, pois estávamos gravando e tivemos alguns problemas “técnicos”.
Amanhã postamos mais.
Abraço.
Clique aqui para fazer download P01E01
Clique aqui para fazer download P01E02
