Olá Habr! Meu nome é Zhenya. Sou analista de sistemas na NORBIT e iniciante no Scrum-master. Há muito tempo que olho o Scrum para estudar, tentar e avaliar suas capacidades em nossa equipe de analistas. E agora, após um
leve chute de uma conversa inspiradora com a RP, percebi: pare de pensar, é hora de fazê-lo.
Neste artigo, falarei sobre nossa experiência em preparar o uso do Scrum limitado em nome do Scrum master: o que fizemos para começar. No momento da redação deste artigo, o 15º sprint está concluído. O vôo é normal!
Eu sempre ouvi falar sobre o uso da estrutura Scrum em equipes cujos membros não são desenvolvedores. Equipes com vários conhecimentos estão se juntando ativamente ao Agile. Eu pensei que o Scrum foi criado originalmente para equipes de desenvolvimento de ciclo completo e, portanto, há várias dificuldades ou pontos interessantes nos quais você deve prestar atenção se a equipe diferir da referência que os criadores pensaram. Distingo as equipes na direção da experiência e do grau de participação no ciclo de desenvolvimento do produto. A direção da experiência, na minha opinião, não limita o uso do Scrum. Mas o grau de participação no desenvolvimento de produtos pode limitar. Alguns deles podem executar o ciclo completo de trabalho no produto, sendo responsáveis pelo resultado final disponível para o cliente - e na minha opinião, nessas equipes, você pode usar um Scrum completo. E outros fazem apenas parte do ciclo completo, fazendo parte da cadeia de trabalho. Nesse caso, pode haver perguntas e dificuldades com um Scrum completo. Essa situação de design pode exigir um compromisso.
Este artigo focará na equipe responsável por parte do ciclo de desenvolvimento do produto e na preparação para o lançamento do ScrumBut.
Nosso plano de ação para o lançamento foi o seguinte:
- estudar e avaliar a situação atual e os objetivos desejados
- construir um como é e ser modelo na terminologia ScrumBut,
- apresentar e inspirar a equipe
Como eu aprendi o que é ScrumBut
Primeiro, pesquisei no Google e obtive:
Um ScrumBut possui uma sintaxe específica: (ScrumBut) (Razão) (Solução alternativa). Exemplos do ScrumMas: "(Usamos Scrum, mas) (ter um Scrum diário todos os dias é muito caro) (portanto, temos apenas um por semana.)" "(Usamos Scrum, mas) (Retrospectivas são uma perda de tempo ,) (para que não os façamos.) "
I.e. ScrumMas é um Scrum limitado. Essa variação da estrutura permite que você pegue tudo o que precisa do Scrum e não pegue o que, em nossa opinião, não é necessário. Claro, esse é um caminho escorregadio, porque Para entender o que é necessário e o que não é necessário, era importante ter uma idéia do clássico Scrum, era importante para mim perceber por que isso está incluído na versão completa.
Úteis para mim no material foram:
- estudo de literatura: Manifesto ágil de desenvolvimento de software , “Método revolucionário de gerenciamento de projetos SCRUM” (Joseph Sutherland), “Treinamento em equipe ágil” (Lissa Adkins);
- uma série de consultas longas e interessantes com um scrum master certificado ativo praticando os clássicos.
Como avaliei a situação atual
Para começar, aproveitei minha visão e propus vários pontos para avaliação pelos gerentes.
Reuniu as opiniões dos membros da equipe e as registrou.
Temos duas listas: o que temos na entrada e o que queremos obter.
Aqui farei listas consolidadas e generalizadas.
O que eles tinham na entrada
- Um grande projeto para o desenvolvimento de um sistema de interpretação.
- Equipes separadas de desenvolvedores, suporte e analistas.
- Uma equipe legal de analistas (cerca de 14 pessoas).
- A capacidade de agir apenas dentro da estrutura de uma equipe de analistas.
- Liberar versão das versões do sistema.
- Modelo de gerenciamento do ciclo de vida do software Waterfall.
- A impossibilidade de um planejamento rígido, já que as tarefas do cliente ocorrem a qualquer momento.
- Carga de trabalho desigual de analistas.
- Distribuição funcional das zonas de exame dos analistas.
O que queremos obter
- Ser capaz de responder rapidamente às mudanças nos negócios.
- Leve em conta e priorize tarefas no trabalho
- Tenha previsões viáveis de crescimento de produtos.
- Sprints curtos podem permitir que você rastreie, grave e conclua tarefas e preveja com mais precisão quando as tarefas serão liberadas.
- Crie uma lista de pendências de tarefas para analistas.
- A qualquer momento, o analista sabe o que fazer.
- Trocar experiência na solução de problemas complexos.
- Estabelecer o trabalho em equipe de forma a compartilhar conhecimento foi agradável, confortável e mutuamente benéfico.
- Organize seu Scrum com Black Jack, etc. :)
- Tente coisas novas, melhore o espírito de equipe. Caras legais. Porque não
Modelagem
Na fase de modelagem, alocamos as funções da equipe: identificamos os proprietários do produto, os membros da equipe e eu como um scrum master, a duração do sprint, o processo de preenchimento e priorização do backlog.
Foram determinados atributos de tarefa obrigatórios, fluxo de trabalho para rastreamento, ferramenta de rastreamento, atribuição de uma estimativa em horas humanas para cada tipo de tarefa e o número total de horas por semana para cada analista, levando em consideração o cumprimento do plano da equipe de sprint, tempo e regularidade de comícios e retrospectivas diárias.
O proprietário do produto e a pessoa que define o backlog é o chefe de um grupo de analistas. Decidiu-se formar equipes de 2 a 7 pessoas, atendendo ao requisito de 7 ± 2. Eram duas equipes, divididas condicionalmente de acordo com o atributo funcional das tarefas que estavam sendo resolvidas, mais próximas do modelo original, mas mais distantes do objetivo pretendido - a funcionalidade cruzada.
Para o rastreamento, decidimos usar o TFS existente, no qual é conveniente colocar tarefas nos status “Novo”, “No Trabalho”, “Concluído” no quadro e é possível coletar pequenas estatísticas sobre os resultados para discussão em uma reunião retrospectiva no final do sprint. A placa do TFS imita uma placa física do Scrum, mas também tínhamos uma placa física.
Apresentação
A etapa de planejamento terminou com uma demonstração para a equipe da apresentação sobre os resultados da modelagem, discussão e correção do “Getting Started Together Together”, o que não encontrou resposta dos rapazes.
Scrum e ScrumMas, em particular, são trabalho em equipe, coerência, transparência e aceitação geral. Foi um momento importante a partir do qual começamos com inspiração.
FonteConclusões dos preparativos para o lançamento
Quando você trabalha em um projeto grande, não há como entrar na piscina com a cabeça; portanto, você não pode fazer isso sem planejar. É importante entender como será e quais resultados trará, mas atendemos à necessidade de estarmos preparados para o fato de que o plano, em alguns aspectos, continuará sendo o plano. No planejamento, pintamos com pinceladas grandes e, já na fase de implementação, pudemos adicionar os detalhes que a equipe e a situação do design trouxeram.
Nossa equipe é responsável apenas por parte do ciclo de desenvolvimento de software; portanto, houve dificuldades com o que chamar de produto e o que receber como aumento. Sabíamos que deveria ser holístico e completo. Concordamos que, por parte da equipe de analistas, estamos preparando vários tipos de documentos para interação com o cliente e criando tarefas para os desenvolvedores fazerem o backlog deles. Assim, as tarefas caem nos sprints para os desenvolvedores. Na minha opinião, esse caminho de compromisso pode ser adequado tanto para projetos em que equipes individuais de analistas, desenvolvedores, testadores, suporte quanto para projetos em que o número de pessoas exija separação em várias equipes. Há também um sinal negativo nesta decisão - nossos membros da equipe não podem afetar o tempo da disponibilidade da funcionalidade do produto, apenas podemos afetar o desempenho de sua parte do trabalho. Há vantagens - a continuidade das tarefas dos analistas para desenvolvedores. Essa decisão nos permitiu evitar tentativas de se tornar uma equipe multifuncional (analistas = desenvolvedores = testadores etc.), o que, no nosso caso, neste estágio seria impossível, mantendo o ciclo de desenvolvimento do produto com uma refração de comprometimento na junção da interação da equipe.
Na fase de apresentação, nosso pessoal da
NORBIT reagiu com muito
entusiasmo e interesse. Mas suponho que a resposta emocional positiva da equipe seja o mérito de elaborar os objetivos e sua conexão com problemas urgentes e óbvios.
Os passos descritos acima (estudo teórico, modelagem e apresentação) deram o resultado: começamos com sucesso.
Mas iniciar é apenas o primeiro passo. Vou falar sobre o que aconteceu após o lançamento e quais resultados foram alcançados no meu próximo artigo.