estratégias para times de drupal
contratação
- Encontrando Profissionais
- Avaliando Profissionais
encontrando profissionais
- Canais
- https://groups.google.com/forum/#!forum/drupal-br
- http://drupal-br.org/
- Empresas
- Desenvolvimento
- Taller
- Chuva
- Itelios
- MMDA
- CI&T
- Treinamento
- Taller
- Fisqua
avaliando profissionais
O profile do desenvolvedor no drupal.org é um ótimo recurso para se avaliar.
Você pode ver o código, acompanhar as discussões, e analisar módulos contribuídos pelo desenvolvedor.
papéis de um time de drupal
- Temos duas noções de equipe
-
Do projeto
- Incluí pessoas técnicas e não técnicas
- Gerente de Projeto
- Gerente de Produto
- StakeHolders
- Dev team
- Arquiteto
- Tester
- Front-end (Themer)
- Dev (Backend developer)
- Devops
processo
release planning
- Primeira rodada de análise de requísitos
- Focando no macro
- Cubra o escopo inteiro
- Produção do backlog
- Datas Chaves
- Entregas, time to markets, deadlines, egos, etc
- Priorização do Backlog
- Estimativa Inicial
- Plano de Projeto
o backlog
- Composto de User Stories - um modelo de especificação que visa expressar o uso do software da perspectiva do usuário:
- Como um <usuário>, gostaria de <seu desejo>, para/porque <suas razões, seus propósitos>
user story
- Resumo: Pequena descrição seguindo o modelo canonico
- Como um <usuário>, gostaria de <seu desejo>, para/porque <suas razões, seus propósitos>
- Critérios de Aceitação: aquilo que deve ser satisfeito pela implementação para que a story seja considerada pronta
- Usuário somente é logado quando os credenciais corretos são dados, incluindo username, cep, e password
- Uma opção de "Lembrar de mim" está disponível.
user story
- Descrição: Qualquer informação útil do contexto da funcionalidade. Pode incluir documentação e referencias.
- Especificação da Solução: Informação inserida po arquitetos e desenvolvedores seniors brevement explicando a solução e pontos sobre implementação.
sprint planning
- Como o Release, só que entrando em detalhes
- Grandes Stories, o que são considerados "Epics", devem ser quebradas em Stories
- Time quebra Stories em Tasks, "To Do's"
- Re-estimativa
- Comprometimento
daily scrum
- O time de desenvolvimento se reune diáriamente com o Scrum master, e cada comunica
- O que fez dês do último daily
- Os problemas e/ou impedimentos que encontraram
- O que farão até o próximo daily
sprint review
- Entrega daquilo que foi comprometido no Sprint
- Somente entrega-se o que está totalmente pronto
- Os devs apresentam
- Primeiro o que está sendo entregue
- Depois o que faltou e o status
sprint retrospective
Momento em que times ágeis focam em identificar problemas com o processo e melhorias, e denominam estratégias para mudar.
arquitetura de soluções
Arquitetura de soluções Drupal feita em dois passos, o primeiro após o Release Planning e o segundo à cada Sprint Planning.
pós Release Planning
Depois do Release Planning é hora de escolher a distribuição
- Avaliar vantagens e disvantagens, critérios
- O que vem pronto
- Filosofia de implementação
- Modificabilidade
- Estabilidade
- Afinidade dos devs
- Atividade de Manutenção
durante Sprint Planning
Hóra de pensar em componentes e entidades do Drupal. e avaliar os módulos que oferecem soluções.
- Componentes
- Content Types CSV
- Entity Fields CSV - Information about entities, bundles, and fields
- Nodequeues CSV
- Image styles CSV
- Menus CSV
- Vocabularies CSV
- Views CSV
- User Roles CSV
durante sprint planning
- Avaliar integração com Distro base
- Sistemas chaves
- Context
- Layouts
- Access
- Sómente distrinchar aquilo que entra neste sprint e um pouco do próximo
estratégias para times de drupal
By Vinicius Freitas
