Transcrições
1. Formando a introdução da equipe Agile: Oi, eu sou Teresa Bennett, e esta é a segunda parte da série de treinamento Agile para analistas de negócios. E esta parte da série, vamos analisar a formação da equipe Agile. Há quatro tópicos que abordaremos neste treinamento. A primeira são as unidades da equipe. Vamos falar sobre a unidade de negócios e a unidade de desenvolvimento, e quais áreas da organização se encaixam em cada uma dessas unidades. Quando estamos falando sobre nossa equipe e colocando as pessoas juntas que vão fazer parte dessa equipe Agile. Então vamos olhar para os papéis dos membros da equipe e ver quais papéis são desempenhados pelas pessoas nessas duas unidades. Em seguida, passaremos para as melhores práticas para a equipe. O que é que precisamos fazer de forma consistente para garantir que nossa equipe seja bem-sucedida? Para cada sprint e cada projeto que completamos. Em seguida, falaremos sobre sua equipe, sua função em sua equipe Agile e quais mudanças de mentalidade você pode precisar para fazer um pedido para ser bem-sucedido em uma equipe Agile. E o que a flexibilidade significa para você quando você está trabalhando em um ambiente ágil. Junte-se a mim no próximo vídeo e vamos começar.
2. Unidades da equipe ágil: Duas unidades formam a equipe Agile. Primeiro, temos a unidade voltada para o cliente, que você também pode pensar como a unidade de negócios. As pessoas que formam essa equipe são, primeiro lugar, o cliente, que é o patrocinador do projeto. Você também tem a equipe de marketing, que é a equipe de marketing da sua empresa ou a empresa para a qual o produto é. Se a sua empresa é uma empresa de consultoria e foi trazido para ajudar em um projeto em outra organização do que seria a equipe de marketing dessa organização. O gerente de produto é a pessoa que gerencia as operações do produto. E eles também fazem parte da unidade voltada para o cliente. E então, é claro, temos os executivos que eu consideraria
ser qualquer um a nível de diretor ou superior. Temos também o CMMI, que são especialistas no assunto. Essas são as pessoas que trabalham com AND OR suportam o produto. Então eles são os únicos que realmente estão trabalhando com ele dia após dia e realmente sabem todas as porcas e parafusos do produto. Então eles são capazes de responder suas perguntas sobre como você faz isso? O que acontece se um cliente pedir? Como você passa por esse processo? Eles devem ser capazes de responder a esse tipo de perguntas. Também temos partes interessadas como parte da unidade voltada para o cliente. São pessoas ou grupos que têm algo a ganhar ou perder com o resultado do seu projeto. A razão pela qual eu estou mencionando algo a perder aqui é pensar sobre isso em termos de quando você está fazendo uma atualização para um processo, há algumas vezes coisas que são
removidas do processo enquanto estamos tornando as coisas mais eficientes. E isso pode tomar medidas que um determinado grupo de pessoas estava fazendo ou tirar um processo completamente que o grupo estava fazendo. Assim, um detentor de estaca que está perdendo algo poderia ser um grupo que não vai mais ter executar uma função porque as mudanças que estão sendo feitas estão tornando as coisas mais eficientes e essa função não é mais necessária. E então, é claro, pode haver outras pessoas envolvidas dependendo do que é o projeto. Então você pode precisar considerar representantes de atendimento ao cliente, equipe
de vendas, talvez recepcionistas. Se, por exemplo, o software é talvez um sistema de reserva de hotel. Então você teria funcionários da recepção, qualquer um desses tipos de pessoas que você pode ter que pensar sobre isso poderia ser incluído ou suave ou outro grupo de pessoas que pode precisar estar envolvido
no projeto e então outros gerentes de produtos e partes interessadas. Então, quem mais poderia estar envolvido além das partes interessadas que você já pensou? Existem outras pessoas que podem ser afetadas? Agora vamos dar uma olhada em quem está incluído na unidade de desenvolvimento. Temos, é claro, os desenvolvedores, certo? Essas são as pessoas que estão codificando. Eles estão desenvolvendo o aplicativo. Eles estão fazendo mudanças no software real, o analista de negócios. Então esta é a pessoa detalhando as histórias durante as sessões de preparação com a unidade de negócios. Então, se você é o analista de negócios, então. É aqui que a maior parte do seu trabalho vai ser feito na equipe Agile. A Qa também está envolvida na unidade de desenvolvimento. Então, a equipe de QA são as pessoas que estão fazendo testes de software, testes de
procedimento, testes de fluxo de processo, qualquer coisa que não seja o teste de unidade, que é normalmente feito pelos desenvolvedores porque eles estão testando seus próprios código antes que eles estão virando. Portanto, o teste de unidade não está incluído no QA, que é parte da função de desenvolvedor. Mas qualquer outro teste que está acontecendo é tipicamente incluído no queixo de alimentos de QA e, em seguida, o gerente de projeto. O gerente de projeto pode ser separado do Scrum Master. Ou o gerente de projeto também pode ser discriminante. Ou eu vi isso de ambos os lados em diferentes organizações em que trabalhei. Portanto, depende apenas de como sua organização está configurada e como eles estão definindo funções e responsabilidades dentro de sua organização. Assim, você pode ter uma função combinada onde o gerente de projeto e o mestre scrum ou a mesma pessoa, ou onde eles são papéis separados realizados por dois indivíduos diferentes. Em seguida, temos os escritores técnicos e/ou escritores manuais de treinamento. Eles são responsáveis pela criação de documentação técnica e documentação de treinamento. A documentação de treinamento pode ser feita pela unidade cliente. Então alguém da unidade de negócios pode ser designado para escrever o manual de treinamento. Novamente, isso depende apenas de como a organização é configurada na empresa em que você está trabalhando. Então eu tenho trabalhado em organizações onde eles não
tiveram um escritor manual de treinamento dedicado. Assim, a equipe técnica que fez a escrita técnica também cria os materiais de treinamento. E eu também trabalhei em organizações onde a unidade de negócios, certo, a unidade de atendimento ao cliente tinha uma equipe de treinamento e é alguém para escrever os materiais de treinamento. Então só depende de como eles estão configurados. Se eles têm uma pessoa para criar os materiais de treinamento como parte da unidade voltada para o cliente, então eles seriam incluídos nessa área e não na unidade de desenvolvimento. Então temos nossa UX e pessoas criativas de design. Então eles são as pessoas que estão definindo a aparência do aplicativo e a experiência do usuário. Então temos as pessoas de arquitetura que também estão incluídas na unidade de desenvolvimento porque estamos falando de arquitetura de sistema, arquitetura de banco de dados. É mais da arquitetura técnica em
vez de qualquer coisa que esteja relacionada aos negócios. E então temos outro tipo de outra categoria, certo? Assim, qualquer outra equipe de TI ou I S que é necessário para o sucesso do projeto. E, novamente, isso depende de como sua organização é configurada e para
que esse projeto específico serve quanto ao que outras unidades podem estar envolvidas nesse projeto específico.
3. Papéis de equipe: Em seguida, vamos dar uma olhada nas funções da equipe. Então vamos falar sobre quem é responsável pelo quê em ambas as unidades que acabamos de falar, a unidade voltada para o cliente e a unidade de desenvolvimento. Cada uma dessas pessoas tem certas responsabilidades dentro da equipe. Portanto, para a unidade voltada para o cliente, eles são responsáveis pela visão e roteiro do produto. Eles também são responsáveis por gerenciar o Product Backlog, que é o escopo, mas pense nele como o escopo do projeto. O que estamos fazendo para este projeto? Espera-se que eles sejam preparados com detalhes no momento apropriado. Assim, em qualquer ponto que a equipe do projeto precisa de detalhes específicos relacionados a qualquer coisa para as funções de negócios do projeto. Eles precisam estar preparados para poder responder a essas perguntas. Eles precisam estabelecer expectativas claras de aceitação, significa que eles precisam ter certeza de que toda a equipe entende qual
é a sua expectativa para quando eles vão dizer que o que foi desenvolvido e construído atende às suas expectativas. Portanto, eles precisam nos dizer antecipadamente quais
são essas expectativas para que estejamos construindo para atender a essas expectativas. Que a esperança é quando chegarmos ao ponto em que estamos rebaixando um produto para eles. Eles estão dizendo que sim, é assim que eu esperava que fosse. E eles estão, naturalmente, muito envolvidos na comunicação em toda a equipe não apenas definindo e ajudando a equipe a entender o que é que eles querem, mas também na comunicação de quaisquer mudanças e seus comentários ao que está sendo criado e construído para eles. A unidade de desenvolvimento é responsável por estimar, que
significa que eles precisam ter um bom controle em estimar o tempo
que vai levar para completar tudo o que está dentro do escopo do projeto. Eles são responsáveis por planejar e se comprometer com a iteração. Assim, uma iteração também é conhecida como um sprint no mundo Agile. E um Sprints são tipicamente duas semanas, talvez três semanas. Vi algumas organizações fazerem sprints de quatro semanas. No entanto, eu adverto contra eles porque você começa a se mover para
uma mentalidade mais cachoeira quando você
entra em um sprint que é de quatro semanas de duração ou mesmo mais longo do que isso. Então o melhor prazo para um sprint é de duas semanas ou três semanas, cara. E durante esse sprint, ou o que poderia ser conhecido como uma iteração, a expectativa é que a unidade de desenvolvimento é capaz de planejar o que eles vão fazer durante essa iteração e se comprometer com isso, e então sair do outra extremidade com essas coisas concluídas. Obviamente, eles vão precisar executar a iteração, certo? Então, depois que eles planejaram e se comprometeram com o que vão fazer, então eles precisam ser capazes de executar isso e completar as tarefas que precisam ser feitas. E depois disso, é aí
que entra a demo que eu mencionei antes quando eu estava falando sobre a unidade de negócios. Então, a equipe de desenvolvimento vai fazer uma demonstração no final que para sprint para mostrar o que foi concluído durante esse período de tempo. E se a comunicação aconteceu bem, e todos tiveram a mesma compreensão que o que eles estão vendo na demonstração deve ser o que eles esperavam ver. E, portanto, eles devem dizer, sim, eu aceito isso porque foi construído da maneira que esperávamos que fosse. E, claro, eles são esperados para fornecer comunicação
clara durante cada um dos sprints através da conclusão do projeto.
4. Melhores práticas e sua equipe: Agora vamos falar sobre as melhores práticas da equipe. Queremos começar como uma equipe e terminar como uma equipe. O que queremos dizer com isso é quando você começa em um projeto para todos estão muito animados com ele. Pólvora como sim, nós vamos fazer essa coisa onde a bordo com isso, nós não queremos entrar em um ciclo onde nós estamos empolgados com as coisas. E então entramos em uma iteração e começamos a trabalhar através dela e surgem problemas. E no momento em que terminamos essa iteração naquele período de duas semanas ou três semanas. Chegamos ao fim, todos apontam os dedos e dizem, bem, não fizemos isso porque isso não estava claro. E não fizemos isso porque essa pessoa não fez isso. Queremos começar como uma equipe e terminar como uma equipe. E o que isso significa é que durante todo esse período de duas a três semanas, estamos trabalhando juntos, colaborando juntos. Estamos trazendo problemas que surgem e resolvê-los juntos para que completemos esse sprint. Sempre juntos como uma equipe e não estamos nos fragmentando. E ter essas coisas acontecem que podem quebrar isso e causar a má vontade durante uma equipe. Assim, a comunicação é fundamental lá durante todo
o processo para que a equipe permaneça coesa e trabalhe em conjunto. E parte disso é o número dois, que é uma comunicação aberta e honesta. Se você está perdendo algo, se você está tendo um bloqueio que está impedindo você de fazer algo. Temos que ser capazes de falar sobre essas coisas e encontrar soluções para essas coisas. O número três é inspecionar e adaptar. Então, o que essa prática recomendada significa é que estamos sempre olhando para o que estamos fazendo, pensando em como podemos fazê-lo melhor, e depois adaptando e fazendo essas mudanças avançando. O que nos leva ao número quatro, que é melhoria incremental no produto e no processo. Para que possamos melhorar o produto, ou
seja, o que estamos entregando, temos sempre que melhorar nossos processos também. Portanto, durante essa comunicação aberta e honesta e a inspeção e adaptação, queremos melhorar nossos processos para melhorar o produto que estamos entregando à sua equipe. Então vamos falar sobre suas expectativas. Que expectativas você tem quando está trabalhando em uma equipe Agile? Quais mudanças e mentalidade precisam ser feitas quando você está passando da cachoeira para uma abordagem ágil. Uma das coisas para mim, provavelmente a maior coisa para mim foi entender e estar bem com o fato de que eu não vou saber tudo ao mesmo tempo. Então, quando você está trabalhando com, em um ambiente de cascata, você está preenchendo todos os requisitos. Então você pode estar trabalhando na fase de análise de um projeto. Quatro. Certamente por semanas de cada vez, às vezes meses de cada vez, dependendo do tamanho do projeto. E quando você chegar ao final da fase de análise, você conhece o produto dentro agora. Você tem trabalhado nisso por tanto tempo que agora você se tornou um CMMI para o produto. E com o Agile, você não vai estar lá no final de uma iteração, no final de um sprint, certo? Tudo o que você vai realmente se sentir confortável e saber sobre os requisitos, ou
seja, as histórias que foram concluídas e trabalhadas durante esse sprint. Então você está construindo seu conhecimento ao mesmo tempo, a equipe de desenvolvimento está construindo seu conhecimento. E essa foi provavelmente a maior mudança que eu tive que fazer na minha mentalidade era estar bem com o fato de que eu não iria saber tudo o que eu iria aprender ao longo do caminho, junto com todos os outros. A outra coisa com a qual você tem que se sentir confortável é a flexibilidade. Então, pulando onde você é necessário. Uma das coisas que realmente funciona bem em um ambiente ágil que não temos muitas
oportunidades de fazer em um ambiente de cachoeira é entrar e ajudar em outras áreas. Porque em um ambiente de cachoeira você está tão
focado em fazer tudo em um conjunto de tempo. terminando todos os requisitos, você está fazendo, toda a sua documentação. Então você está tendo todas as suas sessões de requisitos. Você está criando todos os seus requisitos. Você está criando todos os seus fluxos de processo. Você está criando todos os seus diagramas de fluxo de dados, qualquer tipo de documentação que você tem que fazer casos de uso, o que quer que seja, você está fazendo a coisa toda. Então você está muito focado em tudo isso. O que tem que ser feito nesse mundo. E você tem blinders ligados porque você tem que, a fim de passar por tudo isso. No entanto, em um mundo ágil, você tem um pouco mais de flexibilidade porque você está focado apenas em um determinado pedaço de trabalho de cada vez. E isso deixa você com a habilidade de abrir os olhos e ser capaz de ver o que está acontecendo ao seu redor e no que o resto da equipe está focado e ouvir quais desafios estão tendo e talvez entender como se estivessem a ter um bloqueio de estrada ou um desafio com esta coisa. Mesmo que isso não faça parte das minhas tarefas do dia-a-dia, eu sei como ajudar com isso. Posso ajudá-los a superar esse bloqueio. E você pode falar mais alto e
dizer, quer saber, eu posso ajudá-lo com isso. Portanto, ser flexível e levar isso em consideração e tomar esses passos para ajudar
seus companheiros de equipe é outra coisa que você está aprendendo a fazer e se sentir confortável em um mundo ágil. Seu projeto para esta classe é documentar quais expectativas você tem para trabalhar em um projeto Agile e quais mudanças e mentalidade você acha que você pessoalmente precisaria fazer se você estivesse mudando de um ambiente de cachoeira para um ou se você é novo no Agile e não trabalhou em Cachoeira anteriormente. Então você não tem necessariamente uma mudança a fazer. Em seguida, liste três coisas que você acha que são necessárias para uma mentalidade bem-sucedida, para um ambiente de trabalho Agile.
Teresa Bennett, Business Analysis Expert
