Papel DEV

O Time de Desenvolvimento (DEV)

De acordo com o Guia Scrum, o time de desenvolvimento consiste de profissionais que fazem o trabalho de entregar um incremento de “Done”, potencialmente entregável de um produto/projeto ao final de cada Sprint. Somente membros do time de desenvolvimento podem criar o incremento. Times de desenvolvimento são estruturados e recebem poder pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante otimiza a eficiência e eficácia geral do time de desenvolvimento.

Responsabilidades do Time de Desenvolvimento:

• Auto organizados: Eles decidem como transformar itens do Product Backlog em soluções funcionais.
• Multifuncionais: Como um todo eles têm todos as habilidades necessárias para criar o incremento de produto.
• Sem títulos: Todo mundo é desenvolvedor, não tem um título especial.
• Não há sub-times em um time de desenvolvimento.
• Comprometidos em atingir o objetivo da Sprint e entregar um incremento de alta qualidade.

Um grande time de desenvolvimento...

• Persegue a excelência técnica: Grandes times DEV usam Extreme Programming (XP) como fonte de inspiração. XP providencia práticas e regras que giram em torno de planejar, desenhar, codificar e testar. Exemplos são refactors, programação em pares, integração contínua, testes unitários e testes de aceitação.
• Aplicam o conceito de “team swarming” (enxame de desenvolvimento): Grandes times DEV dominam o conceito de “team swarming”. Este é um método de trabalho onde o time todo ataca poucos itens de uma vez, preferencialmente um por vez. Cada item é finalizado tão rápido quanto possível por ter muitas pessoas atuando nele em conjunto, ao invés de ter uma série de itens em paralelo. Referência: http://www.infoq.com/news/2013/02/swarming-agile-teams-deliver
• Usam soluções “spike”: Uma solução “spike” é uma atividade concisa e de tempo pré-determinado usado para descobrir o trabalho necessário para cumprir uma grande tarefa ambígua. Grandes times DEV usam “spike” para resolver desafios técnicos ou de arquitetura ou problemas de design.
• Refina o product backlog como um time: Grandes times DEV consideram o refinamento de backlog uma atividade do time. Eles entendem que a qualidade do Product Backlog é a fundação para um ritmo de desenvolvimento sustentável e de construção de grandes produtos. Apesar do Product Owner ser o responsável pelo Product Backlog, este depende de todo o time ajudar no refinamento.
• Respeita a regra do “bom escoteiro”: Grandes times DEV usam a regra do “bom escoteiro”: sempre deixe o acampamento mais limpo do que encontrou. Traduzindo para o contexto do desenvolvimento de software, sempre deixe o código em estado melhor do que você encontrou. Se você encontrar um código bagunçado, limpe-o, independentemente de quem fez a bagunça.
• Critique ideias, não pessoas: Grandes times DEV criticam ideias, não pessoas. Ponto final.
• Compartilha experiências: Grandes times DEV compartilham experiências com seus pares. Isso pode ser feito dentro e fora da organização: seminários e conferências são uma grande forma de compartilhar experiências e absorver conhecimento. Além disso, escrever suas lições aprendidas podem ser valiosos para outros times.
• Entendem a importância de ter uma folga: Grandes times DEV tem uma folga programada dentro da Sprint. Seres humanos não podem ser produtivos o dia todo. Eles precisam de um tempo para descansar, ter uma conversa e relaxar. Eles precisam de uma folga para serem inovadores e criativos. Eles precisam de tempo para ter alguma diversão. Assim, eles garantem alta motivação e produtividade máxima. Mas a folga é também necessário para lidar com emergências que podem aparecer. Você não quer sua Sprint inteira em problemas quando você precisa criar um hotfix. Portanto: planejem uma folga. E quando a Sprint não tiver emergências, ótimo! Isso dá ao time a oportunidade de algum refactor ou redesign emergencial. É uma relação ganha-ganha.
• Divertem-se uns com os outros: Grandes times DEV garantem que uma dose saudável de diversão estará presente durante o dia. Adotar essa prática cria uma atmosfera de interação e colaboração, além de deixar o dia mais leve.
• Não tem qualquer “reunião” de Scrum: Grandes times de DEV consideram os eventos SCRUM como oportunidades para conversação. Scrum é centrado em pessoas, e pessoas conversam. Há conversas para planejar, alinhar e refletir. Essas conversas devem ocorrer em tempo e duração apropriadas para informar o andamento do trabalho. Se não há essas conversas, nós se saberá o que está sendo feito, para onde o time está caminhando e estarão repetindo os mesmos erros.
• Conhecem seu cliente: Grandes times DEV conhecem seu cliente. Eles estão em contato direto com ele. Eles entendem verdadeiramente o que eles desejam e portanto são aptos a tomar as decisões técnicas corretas.
• Podem explicar o valor de negócio de requisitos não funcionais: Grandes times DEV entendem a importância de requisitos não funcionais, por exemplo, performance, segurança e escalabilidade. Eles podem explicar o valor de negócio para seu PO e cliente e assim garantir que isso é parte do Product Backlog.
• Confiam uns nos outros: Grandes times DEV confiam uns nos outros. Sim, isso é obvio. Mas sem confiança, é impossível para um time atingir um estado de excelência.
• Garantam a retrospectiva divertida: Grandes times DEV pensam eles mesmos em formatos de retrospectiva. Eles apoiam o SM com formatos criativos, divertidos e úteis e oferecem a possibilidade de gerenciar a reunião eles mesmos.
• Entregam funcionalidades durante a Sprint: Grandes times DEV entregam funcionalidades continuamente. Basicamente, em determinado nível de maturidade, eles não precisam mais de sprints. O feedback é coletado e processado sempre que um item é passado para “done”. Isso cria um fluxo de entrega contínua.
• Não precisam de uma Sprint 0: Grandes times DEV não precisam de uma Sprint 0 antes da Sprint “real” começar. Eles estão aptos a entregar requisitos com valor de negócio logo na primeira Sprint.
• Atua de forma verdadeiramente multifuncional: Grandes times DEV não somente tem uma composição multifuncional mas são verdadeiramente multifuncional. Eles não falam sobre diferentes papéis dentro do time mas são focados em entregar um produto a cada Sprint como um time. Todos fazem o necessário para atingir o objetivo da Sprint.
• Atualiza o kanbam sozinhos: Grandes times DEV garantem que o Kanbam esteja sempre atualizado. Ele deve ser um reflexo preciso da realidade. Eles não precisam de um SM para encorajá-los; ao invés disso, eles colaboram com o SM para atualizar o kanbam.
• Investe tempo em inovação: Grandes times DEV entendem a importância de inovação técnica e de arquitetura. Eles sabem que é necessário manter-se atualizados com a rápida mudança no cenário da tecnologia. Eles garantem que terão tempo para inovação durante as horas regulares de trabalho.
• Não precisam da definição de “Done”: Céluas iniciantes precisam ter uma definição do que será considerado como “Done” para o PO. Grandes times DEV entendem profundamente o que “Done” significa para eles. Para os membros deste time, escrever a definição de “Done” não é mais necessário. Eles sabem. O único motivo para escrever é deixar claro aos stakeholders a definição de “Done”.
• Sabe como dar feedback: Grandes times DEV aprendem como dar feedback um ao outro de maneira respeitosa. Eles compreendem o conceito da ferramenta de feedback “Situação – Comportamento – Impacto” e, por isso, provê feedback claro e concreto. Eles dão feedback sempre que necessário e não postergam o feedback até a retrospectiva. Referência: https://www.mindtools.com/blog/corporate/wp-content/uploads/sites/2/2014/05/SBI-Feedback-Tool.pdf
• Gerencia a composição do time: Grandes times DEV gerencia sua própria composição do time. Sempre que habilidades específicas são necessárias, eles colaboram com outros times para discutir as oportunidades de “contratar” essas habilidades específicas.
• Praticam a propriedade coletiva: Grandes times DEV entendem a importância da propriedade coletiva. Portanto, eles rotacionam desenvolvedores através dos diferentes módulos das aplicações e sistemas, para replicar o conhecimento entre todos.
• Arrumar dependências com outros times: Grandes times DEV estão atentos às possíveis dependências com outros times e se auto gerenciam. Assim, garantem um ritmo de desenvolvimento sustentável para o produto.
• Não precisam de pontos nos itens: Grandes times DEV não focam mais nos pontos. Eles refinam o product backlog tanto que o tamanho dos itens de maior prioridade não varia muito. Eles sabem quantos itens eles podem fazer a cada Sprint. Apenas informar o número de itens/histórias de usuários é o suficiente para eles.