[MÚSICA] Olá! Bem-vindo ao curso Princípios de Desenvolvimento Ágil de Software. Eu sou Clovis Fernandes e na aula de hoje iremos apresentar o Time de Desenvolvimento, ou seja, ao final dessa aula, você terá aprendido quais são as principais características que compõem o papel do time de desenvolvimento no nosso contexto do time scrum, o scrum com XP. Qual que é esse time de desenvolvimento? Vamos lembrar que nós temos o time scrum. O time scrum é composto do product owner, do time de desenvolvimento propriamente dito, e do scrum master. Hoje iremos falar sobre o time de desenvolvimento. Uma das coisas importantes que nós temos que ver sobre o time de desenvolvimento é o tamanho do time. Existe número, que a gente chama de número mágico de Miller, que é o sete mais ou menos dois, que tem a ver com as coisas que nós, no nosso cérebro, somos capazes de guardar simultaneamente. É sete mais ou menos dois, atualmente é três grupos de três mas o sete mais ou menos dois também funciona. E o que isso tem a ver com o grupo? Veja o exemplo. Esse grupo tem seis pessoas, então ele é o sete menos seis pessoas. Então eu posso ter de cinco a nove pessoas. O que isso tem a ver com a complexidade do cérebro? Porque cada pessoa vai estar interagindo com as outras pessoas, e isso significa complexidade nessa interação que a pessoa vai ter com as outras. Quanto mais gente, maior a interação, mais complicado fica no cérebro da pessoa. Então as equipes scrum, elas são sempre pequenas. Pode-se desrespeitar pouco o número na parte de baixo, cinco, que é o mínimo que a gente está colocando, pode ser até três, depois eu vou explicar pouquinho melhor. No topo eu já trabalhei com grupos que tinham sete, doze pessoas. Mas aí já começa a depender o grupo, das personalidades das pessoas, da formação de cada uma também, que vai ajudar ou não. Outra coisa importante sobre o time é que, normalmente, nós vamos colocar o time numa sala, todo mundo trabalhando junto, cara a cara, discutindo e podendo trocar ideias uns com os outros a cada momento. Isso é essencial. Lógico que nós podemos ter grupos distribuidos, mas precisa-se tomar mais cuidado, ter outras considerações para tratar esses grupos distribuidos. O ideal é todos numa sala só. E normalmente o product owner, o PO, ele fica numa sala do lado, exatamente do lado da sala do time de desenvolvimente que ele trabalha junto, no time scrum que ele trabalha. Outra coisa que é muito importante é que o time é multifuncional. O que significa ser time multifuncional? O que a gente já até falou quando estava falando do time scrum. É o fato de eu ter pessoas com várias competências. Pessoas que saibam trabalhar no front-end, na interface, projeto de interface, pessoas que saibam trabalhar com desenvolvimento Java. E pessoas que sabem trabalhar com banco de dados também, com redes, com computação nas nuvens. Com várias tecnologias que envolvam web. O ideal aqui é você ter pessoas com aquela característica que a gente chama de full stack web development, ou full stack developer, que são pessoas que conhecem praticamente tudo, mas, não tendo isso, junta-se essas pessoas com essa diversidade de conhecimento. Uma característica que, isso pode afetar o número menor de pessoas no grupo, por exemplo, se você tiver três pessoas só você vai exigir pessoas de mais competência, no geral, aqueles que a gente chama de full stack developer. Já quando se tem muitas pessoas, você pode ter os nichos sujeito ao que a gente vai descrever daqui a pouco. A questão do ser auto-organizado, auto-gerenciado, é que o grupo é que decide muitas das coisas, por exemplo, ele vai decidir que compromissos ele vai assumir pra desenvolver, por exemplo. Mas também tem num outro nível, ele pode, por exemplo de existir assim, olha, nós vamos trabalhar num scrum mas não num scrum com framework padrão, nós vamos pôr alguma mudança. Você quer que a gente trabalha com scrum e XP, tá bom, vamos trabalhar, mas só que nós não vamos trabalhar programação pares. Ou seja, eles é que decidem. O PO não manda neles. O scrum master não manda neles. Eles é que decidem, eles que se auto-gerenciam. Isso você vai conseguir na equipe ao longo do tempo, não é de repente que se consegue fazer. Normalmente o time negocia os compromissos junto com o PO. Que compromissos são esses? São os compromissos de desenvolvimento. Então na hora de escolher que user stories vão ser feitas, vão ser escolhidas aquelas que estão no topo do backlog. Mas eu vou pegar uma user story, duas user stories, três user stories, quantas eu vou pegar? O time de desenvolvimento é que decide. Nesse exemplo, o sprint de duas semanas, por exemplo, o time está escolhendo que vai fazer as três user stories primeiras. Vocês vejam que eu estou acrescentando, além do business value, o size. O que é o size? É o número de story points que você fez já o planejamento, o planning poker, e definiu qual é o esforço de duração, qual é o tamanho de desenvolver, qual é a dificuldade que eu tenho de desenvolver aquela user story. Então a primeira é quatro, a segunda é dois pontos de story e o time se comprometeu a desenvolver esses três. Dá total de oito pontos de estória. Ele poderia duas semanas fazer dez pontos de estória, por exemplo. Ele está fazendo oito nesse primeiro. Por que? É o primeiro sprint, normalmente ele vai ter que trabalhar com uma arquitetura básica no sistema, talvez esteja trabalhando com banco de dados que não conheça, então ele vai perder mais tempo pra desenvolver a parte de banco de dados, e assim por diante. Já no segundo sprint, por exemplo, ele pode assumir as duas user stories que vão dar, cada uma tem cinco pontos de estória, vai dar total de dez pontos de estória, ou seja, é esforço maior do que o sprint inicial. Mas por que eu posso fazer isso agora? Porque algumas características de arquitetura, de banco de dados, de rede, de computação nas nuvens, já foram decididas no primeiro sprint. Então eu posso assumir agora user stories com maior trabalho. Outra coisa, ninguém de fora do time de desenvolvimento diz como que ele deve desenvolver. Se vai desenvolver a parte do banco de dados antes, a interface, não, o time tem autonomia pra fazer, desde que ele assumiu o compromisso que vai fazer aquilo duas semanas, por exemplo, se o sprint é de duas semanas, ele que decide como ele quer fazer. Ele tem autonomia. Que técnica ele vai usar. Desde que no final a user story esteja completada e passe pelo teste de aceitação. Então, autonomia total. Ninguém tem influência sobre o time de desenvolvimento quando ele está num sprint. Outra coisa, nós temos aquele critério da multifuncionalidade, a equipe tem multifuncionalidade, mas a responsabilidade é de todos. Não é porque o cara que estava trabalhando com o banco de dados ficou doente que a equipe vai parar. Não, alguém vai assumir e fazer aquela parte do banco de dados. Saiu o cara, trocou de emprego o cara que trabalhava e fazia conexão com as nuvens. Não importa. A responsabilidade é do time. Alguém vai ter que assumir. A responsabilidade é de todos. Por isso, inclusive, a gente promove a programação pares pra que todo mundo participe de cada coisa. Todos tem grau de conhecimento de como está sendo desenvolvido a interface com o usuário, o banco de dados, e o desenvolvimento Java como todo. Com isso você aprendeu nessa aula as principais características que envolvem time de desenvolvimento nesse contexto do time scrum, dentro do scrum e XP. Obrigado. [MÚSICA] [MÚSICA]
