Posts Tagged ‘Sprint Planning’

Yahoo! procura Ninjas

Thursday, January 14th, 2010

Estamos procurando Desenvolvedores e Scrum Masters Ninjas para integrarem nossa equipe no Yahoo!

Nosso time é o que chamamos de “Innovation Cell”, que é algo como uma incubadora de projetos, responsável por pesquisar e criar novos produtos. Atualmente nosso carro-chefe é o Yahoo! Meme, que foi inteiramente desenvolvido no Brasil no último ano e já está em vários outros países como Indonésia, Filipinas, México, Argentina e Taiwan.

Desenvolvedor Ninja

Os Desenvolvedores Ninja serão responsáveis pelo desenvolvimento e manutenção de aplicações web, em especial o Yahoo! Meme e outros aplicativos de integração com redes sociais. É imprescindível ser faixa preta em Python, PHP ou JavaScript e conhecer bem pelo menos uma segunda outra dessas três. Mesmo sendo essas as principais linguagens que usamos por aqui, precisamos de desenvolvedores multidisciplinares que saibam usar diferentes tipos de ferramentas – porque nunca sabemos quais produtos virão no futuro e que tipos de vantagens poderemos ter usando ferramentas diferentes.

Tão ou mais importante do que isso é ter ótimos conhecimentos sobre desenvolvimento ágil e ser capaz de trabalhar com TDD, entender sobre CI e a sua importância, automatização de rotinas/build/etc., melhores práticas de desenvolvimento de software, Orientação à Objetos, Domain-Driven Design e tudo mais que puder ser relevante para ajudar a construir software confiável e manutenível de forma rápida e com ritmo/qualidade sustentável. Experiência com automatização de testes com Selenium ou Webdriver também é essencial.

Como desenvolvemos produtos de escala mundial, é necessário ter experiência com aplicações de alta performance e disponibilidade, identificação e otimização de gargalos de performance, escalabilidade, caching e sharding. É importante também ter bons conhecimentos de pelo menos um tipo de Unix e seus derivados.

Conhecimentos de OpenSocial, desenvolvimento de mashups, arquitetura de serviços e experiência com uso e desenvolvimento de APIs (REST, YQL, etc.) são diferenciais.

Scrum Master Ninja

O Scrum Master Ninja deverá ajudar o time de desenvolvimento a produzir no máximo da sua capacidade. Sua missão será organizar e facilitar os Sprint Plannings e Reviews, bem como Retrospectivas e o que mais for necessário para suportar os times de desenvolvimento e produto. Ele deverá identificar e remover impedimentos, ajudar o time a manter o foco mas dando todo o espaço e autonomia que ele precisa para se auto-organizar e gerenciar. É necessário já ter tido alguma experiência anterior relevante nesta posição.

Como o Yahoo! é uma empresa que em sua maioria ainda trabalha com métodos tradicionais de desenvolvimento, esta pessoa também será responsável por fazer com que o time esteja dentro das normas da empresa, gerando relatórios para as células de gerenciamento de projetos e fazendo algum trabalho burocrático de registro e comunicação de métricas.

Queremos um Scrum Master influente, que seja capaz de entender questões técnicas mesmo que em alto nível, que seja apaixonado por procurar maneiras de melhorar o processo de desenvolvimento, construtivo na hora de resolver problemas e solucionar conflitos e com muita vontade de descobrir novas maneiras de trabalhar com métodos ágeis. O Yahoo! é uma empresa que ainda está engatinhando em métodos ágeis e por isso precisamos de alguém com muita disposição e vontade de mudar a empresa!

Por último, experiência com XP, Lean Software Development, Kanban e diversos métodos ágeis são diferenciais.

Continuando…

Para ambas as posições é necessário inglês avançado, o que quer dizer que você deve ser capaz de conversar e ler/escrever em inglês sem problemas (e eventualmente ser entrevistado em inglês caso necessário).

Estamos procurando por pessoas criativas, que gostem de inovação, de pesquisar e identificar novas tendências e de encarar desafios complexos com agilidade e velocidade. Nosso time é pequeno, jovem e nosso ambiente está em constante mudança e evolução. Queremos pessoas irreverentes, que gostem de desafios, com idéias novas e com vontade de criar produtos incríveis!

A empresa oferece contratação apenas por CLT e benefícios como plano de saúde e ticket refeição. Estamos localizados na Vila Olímpia em São Paulo. Vamos dar preferência para pessoas de São Paulo mas também vamos olhar com carinho currículos de pessoas de fora e daremos auxílio para mudança caso necessário.

Se você se encaixa em algum destes perfis, mande seu curriculo em inglês para mim (gc AT yahoo-inc.com) com uma lista dos últimos 3 livros técnicos que leu. Não esqueça de colocar links para o seu Twitter, LinkedIn, GitHub e o que mais você achar relevante e que pode nos ajudar a te conhecer melhor. :)

Houston, we have a problem!

Sunday, August 24th, 2008

Oi Guilherme, tudo bom?

Eu tenho uma curiosidade, como vcs aí da Globo fazem quando no Scrum um item que teve pontuação baixa na reunião de planning (algo como 3 ou 5) na realidade é um abacaxi de 40, 50?

De acordo com a mecânica do Scrum, no Sprint Planning o time e o P.O. definem juntos um objetivo para a próxima iteração, que é o Sprint Goal (um exemplo de goal seria “prover serviços para que um usuário possa despublicar seus vídeos do site”). Após a definição do Sprint Goal, é selecionada uma porção do Product Backlog para que esse objetivo seja atendido.

A partir daí você tem o Sprint Backlog, que é o conjunto de histórias que serão trabalhadas no próximo Sprint.

Se no meio de um Sprint você percebe que uma dessas histórias é um monstro 10 vezes maior do que parecia, você pode fazer uma das duas coisas:

1) Se essa história puder ser removida sem afetar o Sprint Goal, basta tirar a história do Sprint. É importante no entanto que se descubra as causas disso ter acontecido (pode ser na Sprint Retrospective) para que não aconteça novamente. As estimativas têm uma margem de erro implícita, mas quando alguma coisa multiplica tantas vezes assim de tamanho pode ser que o time não esteja conversando o suficiente sobre as funcionalidades antes de estimar. Muita gente fala inclusive que o principal produto de uma reunião de estimativas não são as estimativas em sí, mas o conhecimento que o time adquiriu discutindo sobre os problemas.

2) Se essa história for fundamental para atender ao Sprint Goal, o Sprint deve ser cancelado e um novo Sprint Planning deve ser feito. Se você não pode trabalhar na coisa que adiciona mais valor para o projeto, ou seja, uma história que atende diretamente ao goal definido junto com o P.O., é preciso fazer um novo planejamento para descobrir no que trabalhar. No Sprint planning pode-se decidir várias coisas, desde quebrar essa história em histórias menores até descobrir que dada a nova estimativa o custo-benefício da história não vale a pena e ela deve perder a prioridade no backlog.

Por isso é muito importante ter objetivos muito bem definidos. Um bom Sprint goal ajuda o time a se reorganizar em caso de problemas, além é claro de ajudar a focar no que é mais importante para o projeto no momento.

No mais, recomendo a leitura dos capítulos 3.5 e 3.6 do Agile Software Development with Scrum que falam sobre a definição do goal no Sprint Planning e a mecânica dos Sprints, incluindo uma parte sobre cancelamento de Sprints.