Pré Game: Cascata, agilidade ou apenas opção para o mundo real?

Oi pessoal.

Este post tem que ter uma menção honrosa ao Eduardo D’avo, que me pediu pra pensar num método sobre Pré Game.

Vou contextualiza-los:

Trabalho numa grande (e muito legal e feliz) consultoria. Nós atuamos em muitos projetos e nem sempre nossos clientes conhecem Agile. Ou mesmo os que conhecem optam, por vezes, em não trabalhar desta forma e esse é o mundo real. Como todos aqui somos profissionais, e provavelmente não compramos as casas na praia que queremos ou viajamos pra todos lugares que desejamos, nós não negamos fogo a projetos “não ágeis”.

Sem duvida, não deixamos de explicar os benefícios do filosofia Agile (junte Lean aqui, ok) e de trabalhar com essa mentalidade, mas muitas vezes o cliente não abre mão da aceitação formal de fases, mantém o conhecimento em silos, deseja estimativa para saber prazo e custo e as outras maravilhas que todos conhecem. Então, nós aqui na Empresa fazemos um Pré Game.

O Pré Game consiste, no nosso caso, num curto espaço de tempo antes do início do desenvolvimento em si (das iterações) aonde averiguamos o contexto do Negócio (Projeto ou Produto) especulamos sobre seus objetivos, sua forma de gerar Valor e a quem ele gera valor. Também fazemos uma análise sobre as principais necessidades dos clientes e começamos a especular sobre as principais funcionalidades. Quando o caso é projeto, muitas vezes o Cliente já tem uma documentação preparada e tem seus Domain Experts.

Neste caso, literalmente sugamos o conhecimento junto ao Domain Expert, criamos conexões com os usuários e fazemos um reconhecimento da documentação existente. A questão é, Por que fazemos isso a invés de começar logo a desenvolver?

A resposta: Estamos no mundo Real!

Se pegarmos a documentação já existente, toma-la como correta e definitiva e começarmos a desenvolver, alguém aqui arrisca o resultado? Sim, o resultado será MERDA. Não por falta de qualidade ou incompetência. Sabemos o resultado de conhecimento de negócio colocado em papel, como forma de comunicação. Dá merda.

Outro ponto também: muitas vezes o cliente documenta o DESEJO e não o REQUISITO. E o pior: REQUISITO sem conhecimento do domínio do NEGÓCIO é como sexo sem órgão genital. O Pré Game, no nosso caso, serve também para criar a ponte entre o Cliente e o Time, fazer a contextualização sobre o Domínio do Negócio, unir as pessoas e criar o elo indivisível entre aqueles que querem entregar valor.

No nosso Pré Game, começamos a entender o que é desejo, o que é requisito e junto do Cliente buscamos o MPV (minimo produto viável) e criar o Plano de Release. É normal o cliente pedir tudo sem saber do valor sobre o que ele está pedindo. E ele acha que tem que pedir tudo pois provavelmente já teve experiências tristes e frustadas em outras consultorias, aonde coisas de valor pra ele, quando ele não especificou logo no começo do projeto e foi pedir depois, foi tratada como “change request” e foi um transtorno pra ser feito.

O nosso Pré Game serve como meta-game para educar o cliente, sem ele pedir está educação. E sem duvida nosso Pré Game também serve para outra coisa, que gera polêmica: ESTIMATIVAS. No nosso Pré Game, muitas vezes listamos as principais funcionalidades, as entendemos e estudamos sua complexidade técnica e em muitos casos, fazemos POCs.

E geramos uma potencial estimativa para ser feito o MVP. Ao longo do nosso processo de Pré Game, o cliente vai sentido que ele não precisa conhecer ou dominar todo o escopo. Explicamos o que realmente é uma estimativa e como vamos trata-la ao longo do projeto. Porém, por mais bonito que seja o discurso Ágil, e muitos sabem o quanto eu advoco por ele, muitas vezes os clientes não querem isso. Eles querem estimativa e prazo. Nossa artimanha para tentar ir quebrando esse medo e necessidade deles é o Pré Game.

Lá se vão 1 ano e 2 meses que estou aqui. Lá se vão 5 projetos que atuei diretamente e outros N > 10 e < 20 Pré Games feitos em propostas que não vingaram ou estão para vingar e o resultado tem sido muito bom. 2 casos recentes foram muito interessantes:

1 – Um cliente começou um projeto conosco mas por questões políticas internas deles, foram obrigados a parar.

Eles não poderiam fazer o projeto conosco por questões de contrato com outros parceiros e tal. Mas assim que isso se resolveu, eles nos escolheram não só pra terminar o projeto quanto começar um outro grande projeto.

O diferencial: O mote como fizemos o Pré Game e a concepção do MPV deles.

2 – Outro cliente que teve no seu Pré Game grandes descobertas de valor, graças a estudo de mercado e falseamento de hipóteses.

Ao fim do Pré Game, toda uma cadeia de valor foi estudada, grandes e inovadoras funcionalidades foram testadas em POC e hoje o produto ta no ar já dando o ROI esperado. E vem mais Releases dele…

Seria muito fácil para nós, negarmos fazer um projeto por sentir que o cliente não “deseja” Agile. Porém seria, IMHO, muito infantil da atitude de um profissional. Nosso Pré Game é um Meta Game de ensino de Agile. Sim, nós fornecemos estimativas e prazos, mas damos a estes o valor que eles merecem. Nada mais do que chutes ao vento cujo toda iteração iremos avaliar.

O ouro do nosso Pré Game é: O aprendizado junto ao cliente sobre o negócio e seu valor, gerando a integração entre stakeholders e Time, ao mesmo tempo que fornecemos o aprendizado em Agile, criando um elo de confiança.

No nosso Pré Game, sempre buscamos integrar o máximo possível de membros do Time junto aos stakeholders. Abaixo, seguem imagens do método de nosso Pré Game, de um material que gerei graças ao pedido do Edu.

Eu soltei ele pra Comunidade pois quero coletar feedback:

Pré Game

stakeholders

roi

fronteira

macrovisaofuncionalprovaconceito

meta

Anúncios

FDD, User Stories e Boards na Engenharia de Requisitos

Olá caros, tudo bom?

Hoje vou falar sobre junções de técnicas de diferentes métodos que auxiliam na Engenharia de Requisitos. Venho usando essa junção há algum tempo e obtendo bons resultados.

Vamos começar por FDD.

Feature Driven Development é uma metodologia ágil criada por Peter Coad e Jeff de Luca em 1997, utilizada em um projeto de um grande banco em Singapura.

O FDD oferece uma estrutura interessante:

  • DMA (Desenvolver um Modelo Abrangente): Análise Orientada por Objetos
  • CLF (Construir a Lista de Funcionalidades): Decomposição Funcional
  • PPF (Planejar por Funcionalidade): Planejamento Incremental
  • DPF (Detalhar por Funcionalidade): Desenho (Projeto) Orientado por Objetos
  • CPF (Construir por Funcionalidade): Programação e Teste Orientados por Objetos

No passo CLF, eu uso a estratégia criada do modelo ARO para escrever nos Products Backlogs. Vamos conhecer mais sobre o modelo:

<ação> <resultado> <objeto>

Exemplos:

  • <calcular> o <total> de uma <venda>
  • <calcular> a <quantidade total vendida por um varejista> para uma <descrição de produto>.

As funcionalidades são granulares, de acordo com a regra de que uma funcionalidade não levará mais do que duas semanas para ser completada, mas não tão granulares ao nível de “getters” e “setters” (os métodos de acesso aos atributos de uma classe). Duas semanas são um limite superior; a maioria das funcionalidades levam muito menos tempo do que isso. Quando um passo de uma atividade de negócio parece maior do que duas semanas, o passo é quebrado em passos menores, que então tornam-se funcionalidades. by Heptagon

Nos últimos projetos que atuei, construi meu Product Backlog, escrevendo as funcionalidades seguindo a descrição ARO. Interessante informar que, descrevendo deste modo, a percepção inicial sobre a funcionalidade é mais fácil de ser “sacada” pelo Time e também mais fácil de ser descrita pelo P.O (ou o Time do P.O).

Tendo como base que o Product Backlog é uma lista de desejos, acho interessante escrever o desejo no modelo ARO. Quando faço entrevistas com os clientes e usuários, vejo que eles tem uma visão interessante do objetivo que desejam alcançar. O que faço é quebrar estes objetivos em ações menores, e vai ficando fácil enquadar isto numa descrição no modelo ARO.

Em projetos que necessitam de um Pré Planning/Pré Game, popular o Product Backlog desta maneira é interessante pois facilita na explicação para o Time e ajuda-os a estimar. Pensando em Agile, não devemos nos alongar em coisas que não serão feitas agora (foco no ROI). Usando o modelo ARO para compor a lista inicial do Product Backlog ajuda, pois não necessita da mesma profundidade de análise e tempo que uma User Story.

O modelo ARO se mostra indiferente ao tamanho. Você pode usa-lo para descrever Funcionalidades menores (inferiores a duas semanas) ou Épicos. Os exemplos abaixo ilustram isso:

  • calcular o total de uma venda
  • calcular a quantidade total vendida por um varejista para uma descrição de produto.

O primeiro exemplo cai bem num Épico, pois é mais vago, está mais aberto para discussão e entendimento. O segundo exemplo cai bem para uma funcionalidade que está em vias de entrar em uma Sprint, pois já define um papel interessado, um cálculo definido e um objeto mais conciso.

Do FDD, eu também gosto de usar a Feature Breakdown Structure. A FBS é um modelo de estruturação de funcionalidades, igual a WBS.

A FBS é uma forma visual e interessante de modelar suas funcionalidades de acordo com a Modelagem de Negócios do Produto/Empresa.

A utilização dos conceitos de Funcionalidade do FDD e a FBS são de grande ajuda para fases iniciais do Projeto e para auxiliar em estimativas.

Para saber mais, dou a dica de dois posts: Um da VersionOne explicando mais sobre a FBS e estimativas e outro da Flylib explicando mais sobre uma fase de Pré Game, utilizando FBS e Funcionalidades.

Para o topo do Backlog, eu geralmente quebro as Funcionalidades, usando o modelo de User Stories:

As a [type of user]

I want to [perform some task]

so that I can [reach some goal]

Isso me facilita muito evoluir no entendimento da funcionalidade, reconhecer os reais usuários, as necessidades e o valor de negócio de uma User Story. Mantendo o padrão Agile, geralmente eu crio as User Stories apenas quando necessário. Em alguns projetos isto quis dizer:

  • No decorrer da Sprint
  • Uma Sprint de antecedência
  • Duas Sprints de antecedência

E vou atualizando minha FBS:

Pra quem utiliza Story Mapping, a FBS é uma mão na massa. Você pode montar suas Releases, Sprints, pinçar as funcionalidades e User Stories necessárias para atingir os objetivos e exibi-las no Map:

by Agile Product Design 

Pra quem usa Boards (ou mesmo o Método Kanban), pinçar as Funcionalidades e/ou as User Stories fica bem interessante, exibindo a decomposição, o avanço do entendimento e a evolução do desenvolvimento.

Eu submeti uma proposta de palestra sobre este tema para o Agile Brazil, vou torcer para entrar.

E você, o que acha desta miscelânia?

Scrum Master, tão simples quanto possível

Olá pessoal. No post de hoje vou falar um pouco do papel do Scrum Master, e vou usar como pano de fundo, o caminho que trilhei.

O Post também vem para cumprir uma Meta, e desde já agradeço ao Mestre Manoel Pimentel.

Hoje é muito debatido qual o verdadeiro papel do Scrum Master, se é necessário, se é desnecessário, se ajuda a promover a auto-organização…

Bem, como sempre, vamos por parte.

Scrum Master é um facilitador que remove impedimentos do Time, e que isso não necessariamente quer dizer que ele seja o único a fazer isto. Eu como Scrum Master sempre busquei auxiliar ao Time como descobrir seus reais problemas, e como combate-los como Time.

Em alguns impedimentos, minha atuação direta como Scrum Master ajudava, pois não precisaria dispender alguém do Time, logo não atrapalha o pessoal. Contudo, toda atuação minha para tirar impedimentos era clara. Eu fazia questão de informar ao Time o que eu fiz, como fiz, com o intuito de transmitir conhecimento.

Porém, alguns impedimentos realmente tinham que ser tirados pelo time. Geralmente conhecimentos técnicos, necessidades de infra que exigiam o conhecimento apurado de alguém para explicar. Nestes casos, eu atuava realmente como facilitador, buscando ajudar ao máximo.

Um Scrum Master tem uma meta básica que é zelar pelos Valores do Scrum, logo os Valores do Manifesto Ágil. Isto é realmente muito difícil e requer experiência.

Quando me foi sugerido ser Scrum Master, que no caso fui indicado pelo pessoal do Time, eu já tinha um bom conhecimento de Métodos Ágeis, porém, não poupei esforços para conhecer mais.

E qual foi a primeira coisa que fiz? Não. Não foi buscar a certificação.

Foi buscar um arsenal de Literatura e Mentoring. Na época a empresa era assistida por um Mentoring, o Felipe Rodrigues. Dezenas de livros amontoaram minha mesa e meu computador, dentre eles:

  • Agile Software Development with Scrum – Ken Schwaber
  • Agile Restrospecitves – Diana Larsen
  • Agile Estimating and Planing – Mike Cohn

Porém, fui mais além disto e quis conhecer as raízes então fui ler:

  • Scrum Papers – Jeff Sutherland
  • The New New Product. Development Game – Hirotaka Takeuchi and Ikujiro Nonaka

Me inundei numa leitura de Posts, tanto dos Gurus externos quanto internos e deixo aqui dois grandes posts do Fabio Akita:

http://akitaonrails.com/2009/12/10/off-topic-voce-nao-entende-nada-de-scrum

http://akitaonrails.com/2010/01/30/off-topic-lendo-os-principios-ageis

Sem falar nos Mentorings e troca de experiência com vários grandes profissionais da nossa área. Mergulhei mais ainda também em participação em eventos, reuniões, grupos de usuários e etc.

Em seguida veio a certificação CSM com o grande Alexande Magno. O processo certificatório pode ser falho, mas a oportunidade de troca de experiência com o Magno foi sensacional.

A atuação de um Scrum Master, zelando pelos Valores do Scrum é simples ou complicado mediante a sua verdade. Não se cria um sentimento de união, um senso de comprometimento e auto gerenciamento num Time de uma hora pra outra.

Cada Time tem sua dinâmica, e isto deve ser somado a realidade de cada Empresa. Como Scrum Master aprendi que melhorias no Time são ótimas mas podem não gerar bons frutos se forem feitas isoladas. Melhorias que buscam impulsionar os Valores Ágeis devem ser feitas em escala Empresarial. Eu tive muita dificuldade nesta parte.

O que acontece com algumas pessoas que atuam como Scrum Master, é que elas passam a achar que estão sempre certas e são Juízes, julgadores do bem e do mal. Eu sempre mantive claro para mim, que eu não era assim. Que como todo profissional eu estava passível de erros e acertos. Logo, eu aprendi com meus próprios erros vendo que quando estava pensando em lutar pelos Valores Ágeis, na verdade eu estava criando um cabo de guerra.

Se todo Scrum Master deve prezar pelos Valores Ágeis então ele deve ser o primeiro a realmente se fazer deles. Eu fazia retrospectivas e buscava melhorias. Quando percebi que minha atuação criava cabo guerra, sentei com todos os envolvidos e busquei dissolver isto.

Hoje, percebo que a atuação de um Scrum Master é tão simples quanto possível, utilizando como sua principal arma o Bom Senso.

Porém, o bom senso é algo relativo e deve levar em conta vários aspectos. Neste ponto, uma literatura me auxiliou muito:

Buscando melhorias, não podia me contentar com melhorias locais e passei a buscar melhorias sistêmicas. Minhas Retrospectivas tomaram outro caminho, onde junto do Time, analisavamos nossos problemas, o que os causavam, os pontos de alavancagem para as melhorias e o que isto impactaria a estrutura como um todo.

Mais uma vez, isto foi algo que eu errei e aprendi como Scrum Master. A grande dica que eu dou a quem exerce este papel é:

Jamais se ache MASTER

A simplicidade me guiou nesta caminhada. Como todo desenvolvedor que busca aprender, como todo analista que deseja conhecimento, eu também como Scrum Master segui o caminho de buscar aprendizado, de fazer, de errar, de aprender.

Eu causei muita polêmica como Scrum Master, gerei muitos embates e hoje vejo que não foi um dos melhores caminho que segui. Porém também vejo o quão o pessoal dos Times que atuei se desenvolveram, o quanto eles entregaram, o quanto estavam felizes. Tudo como um processo simples e natural da vida.

Ser Scum Master é tão simples quanto qualquer outro papel. Você deve buscar sempre conhecer tudo que é tido como fundamental e bom para exercer seu papel, você deve atuar, errar e aprender.

Grandes questões como “Scrum Master pode ajudar na auto gestão”, a respostas não está no papel do Scrum Master, e sim na pessoa que atua nele.

Ter Empatia por todos os envolvidos na dinâmica de desenvolvimento da Empresa, buscar melhorias consistentes e sustentáveis, ser verdadeiro, ter conhecimento podem fazer com que boas coisas aconteçam, independente do papel que a pessoa exerça.

Hoje, posso dizer que por espaços de tempo, eu vi times realmentes auto gerenciados, pude ver Retrospectivas com toda a Estrutura da Empresa envolvida no Produto, pude ver o crescimento de várias pessoas.

Não posso jamais dizer que eu criei Times Auto Gerenciaveis, que tinham total noção do ROI e blá blá blá. Mas posso dizer com certeza que por bons momentos, pude ver coisas feitas da forma certa. Pude ver P.Os discutindo com o Time o real alor das coisas, pude ver Times conseguirem atingir Metas incríveis, pude ver produtos Entregues, pude ver elogios da Gerencia e outras coisas boas.

Para mim, as coisas hoje são tão simples quanto possível. Eu vejo desejos de várias partes, vejo necessidades e oportunidades e busco fazer parte de toda esta dinâmica.

Ambientes que buscam melhorias e se valem dos Valores Ágeis, proporcionam a um Scrum Master ou um Agile Coach auxiliar o pessoal a chegar a grandes feitos. É isso que faço hoje.

Já conheci Scrum Masters que colocavam o nome do papel na assinatura de e-mail, já conheci outros que estimavam pelo Time, conheci outros que não sabiam o que era uma Iteração e outros ainda que não sabiam quem era Ken Schwaber. Por isso que digo que o X da questão não está no papel, está na pessoa.

E você caro amigo, como foram suas experiências como Scrum Master? Ou como o Scrum Master com que você atua é?

[]s.

Analista de Negócios, Analista de Requisitos, Analista de Processos. Preciso ir a uma Analista

Olá caros amigos, tudo certo?

Você vai ter uma overdose da palavra “Análise”, mas siga firme que terá êxito em ler o Post.

Como prometido há algum tempo, hoje vou falar sobre esta miscelânia de papéis que existem na TI referente a Análise.

Esta variedade de papéis costuma fundir a cabeça das recrutadoras do RH nas empresas, costuma causar crise de identidade nos profissionais e mais ainda, costuma causar problemas no projeto se o profissional não souber corretamente qual é o seu papel e o que se espera dele.

Mas afinal, será que Analista de Negócios, Analista de Processos e Analista de Requisitos não é tudo a mesma coisa?

A resposta: Não. Não é tudo a mesma coisa não.

Apesar de ser muito comum o desentendimento sobre cada papel e alguém acabar fazendo os três papéis (ou fazer apenas um e achar que está fazendo todos) no dia-a-dia, cada tipo de análise é sim uma coisa diferente.

Como gosto de fazer, vamos por parte e destrinchar cada um destes papéis:

Primeiro, vamos saber o que é um Analista:

a.na.lis.ta1 adj m+f (gr analystés) Que analisa. s m+f 1 Pessoa que analisa ou é versada em análises. 2 Pessoa cujo ofício é fazer análises das propriedades químicas, físicas ou de outra espécie de uma substância ou produto.

a.na.lis.ta2 adj m+f (lat annale+ista) Relativo ou pertencente a anais ou a quem os escreve. s m+f Pessoa que escreve anais.

O Analista é uma pessoa que tem por carateristícas, a vontade de observar, compreender e descrever a dinâmica de algum produto, processo ou modo de execução. É fundamental para quem exerce este papel ter uma dicção para poder se comunicar de forma clara, ter domínio da escrita, sendo simples na sua forma de descrever porém coeso e acertivo. Um Analista também deve ter em si uma curiosidade natural para sempre procurar saber mais sobre as coisas, como elas se iniciam, como se processam e como passam a diante.

Vamor ver o que é “Negócios”:

By Wikipedia:

Em apertada síntese, podemos dizer que, entende-se por negócio toda e qualquer atividade econômica com o objetivo de gerar lucro.

Etimologicamente, e num sentido mais lato, a palavra negócio deriva do latim, e quer dizer a negação do ócio. Negócio não trata apenas de negócio financeiro ou comercial, mas sim toda a atividade humana que tem efeitos jurídicos

Processos:

By Wikipedia:

Processo deriva do latim procedere, verbo que indica a ação de avançar, ir para frente (pro+cedere)) e é um conjunto sequencial e particular de ações com objetivo comum. Pode ter os mais variados propósitos: criar, inventar, projetar, transformar, produzir, controlar, manter e usar produtos ou sistemas.

Em gerenciamento de processos (também apelidado BPM), o processo de negócio é uma sequência de tarefas (ou atividades) que ao serem executadas transformam insumos em um resultado com valor agregado.

Requisitos:

By Wikipedia:

No âmbito da engenharia, um Requisito consiste da definição documentada de uma propriedade ou comportamento que um produto ou serviço particular deve atender.

O duro trabalho do Analista

Em outras palavras, o Negócio é algo “maior”. Está diretamente ligado as maneiras que a Empresa irá operar para conseguir gerar Lucro.

O Negócio alinha-se com a estratégia da Empresa e leva em consideração objetivos a serem alcançados e os meios que devem ser satisfetios para serem atingidos. A análise do Negócio percorre toda a estrutura da Empresa.

Esta análise é a que vejo menos ser feita nos Projetos de Software. Geralmente o que acontece, é que alguém realiza análise de Processo, ou seja, realiza análise de Gatilhos e Estados iniciais de uma área ou interação de uma área, análise suas ações e suas execuções e por fim análisa as saídas que esta área oferece para suas interações.

Este é o papel do Analista de Processo: analisar os processos que as áreas das Empresas realizam e geram para atingir uma Meta de Negócio.

Basicamente, todo processo tem um Gatilho ou um Estado Inicial. O processo tem sua execução e gera insumos que podem ser gatilhos para outros processos ou estados finais com respostas.

Entenda que o papel do Analista de Processo não é menor do que o Papel do Analista de Negócio, eles apenas estão em esferas diferentes.

Geralmente, uma Empresa já tem suas Metas definidas e buscam através de Projetos ou Produtos conseguir atingi-las. Poucas Empresas eu realmente vi estarem abertas para Análise de seu Negócio para aferir o que realmente um Projeto ou Produto pode fazer por ela.

Isto toma tempo, pode revelar algumas coisas interessantes e até indesejadas, dada a burocrácia e hierarquias da Empresas atuais. Mas posso dizer que o resultado de uma Análise de Negócio é algo realmente muito interessante e bom.

Analisar o Negócio está diretamente ligado em entender todo o ambiente aonde a Empresa se posiciona: O seu Mercado de atuação, sua posição neste mercado, seu histórico, seus concorrentes e etc..

Uma vez tendo a diretriz de negócio madura, pode-se iniciar a análise dos Processos que a Empresa realiza para atingir seus objetivos.

Não quero fazer alusão a Waterfall e mostrar uma sequência obrigatória, mas realmente fica mais fácil analisar o processo tendo uma diretriz de negócio definida, talvez estas duas análises não possam correr em paralelo.

Analisar o Processo requer uma imersão e um acompanhamento próximo no dia-a-dia da Empresa. Não que a Análise de Negócio não requira isto, mas a Análise de Processo se diferencia pelo grau de imersão e proximidade junto as áreas da Empresa, o dia-a-dia mesmo.

Analisar o Processo vai de encontro a entender os “mini objetivos” que as áreas da Empresa tem, analisar a interação entre elas e ver o quão isto se alinha ao objetivo da Empresa.

Os processos buscam satisfazer alguns requisitos e eles mesmo são compostos de algumas regras. Aqui entra o chapéu do Analista de Requisitos.

A Análise de Negócio gera Requisitos de Negócios a serem satisfeitos. A Análise de Requisitos trabalha diretamente para entende-los e ver suas partes na execuções dos processos. Compreender aonde cada requisito é requerido, processado e satisfeito.

Está no trabalho do Analista de Requisitos ser capaz de descrever e validar os requisitos da solução que foram iniciados na Análise do Negócio.

Não quero aqui gerar links profundos entre uma Engenharia de Requisitos, falar em tipos de documentos, técnicas, linguagens de modelagem com o conceito geral da Análise de Requisitos. Que seja livre de quem estiver exercendo este papel escolher as melhores ferramentas para atingir seus objetivos segundo sua realidade.

Mas, basicamente, temos uma “Cebola” com três camadas que demonstram a atuação de cada papel:

A Cebola da Análise

Dentro de um Processo Ágil, estas fase podem (e devem??) ser sobrepostas, o que faz com que a pessoa que irá realizar este trabalho assuma os chapéus de cada Analista em diferentes momentos ao longo do Projeto.

Este dinamismo da troca do chapéu ajuda a causar o desentendimento de cada papel em específico.

Segundo o IIBA, todo este processo de análise pode estar contido no papel do Analista de Negócios. Eu particularmente discordo um pouco, por achar que quem é capaz de fazer isso ou é o Super Homem ou é Louco e também por ver objetivos e características mais específicos para cada perfil de Analista.

Conheço grandes Analista de Requisitos que não têm muito o perfil de estar com uma Junta Diretora de uma Empresa e ser capaz de abstrair os obejtivos de Negócio e ser capaz de compreender a complexidade do Mercado, porém é extremamente habilidoso no mapeamento, modelagem e descrição dos requisitos.

Talvez seja uma questão de experiência, talvez seja uma questão de aprendizado, mas acho que cada Analista tem sim seu perfil mais adequado.

E você, discorda? Concorda? Acredita que todos estes papéis são sim uma coisa única em tempos diferentes? Ou que esses papéis são realmente diferentes mas possíveis de ser feito por uma única pessoa?

Expresse sua opinião.

[]s.

Práticas Lúdicas. O que são e como podem lhe ajudar

Olá caros amigos.

Hoje vamos falar sobre Práticas Lúdicas e seguindo a linha de sempre, vamos comer o boi a bife.

Lúdico:

adj. Relativo a jogo, a brinquedo; que apenas diverte ou distrai: atividade lúdica.

Ludico é uma forma de desenvolvimento da criatividade, conhecimentos e raciocínio através de jogos, atividades artísticas e etc. O intuito é ensinar, através da diversão e buscando a interagração entre as pessoas.

Prática/Atividade Lúdica:

Atividade lúdica é todo e qualquer movimento que tem como objetivo produzir prazer quando de sua execução, ou seja, divertir o praticante.

Sumariamente teríamos as seguintes características sobre elas:

  • são brinquedos ou brincadeiras menos consistentes e mais livres de regras ou normas;
  • são atividades que não visam a competição como objetivo principal, e mas a realização de uma tarefa de forma prazerosa;
  • existe sempre a presença de motivação para atingir os objetivos.

By Wikipedia

Como visto, práticas lúdicas são formas bem interessantes de aprendizado. E o que é realizar um projeto ou produto senão uma razão de um aprendizado sobre algum tema, num espaço de tempo.

Veja que, as práticas lúdicas tem um aporte de diversão, brincadeiras e busca inspirar, motivar e ajudar a atingir metas. Percebe o quanto uma Prática Lúdica está alinhado com o Core do Ágil?

Dito isto, como será que as Práticas Lúdicas podem lhe ajudar?

Bem, como disso no parágrafo anterior, a prática lúdica tem por o objetivo o ensinamento de modo divertido. Em projeto o Time aprende o negócio/domínio sobre um tema, e eles traduzem isto em um produto.

Este aprendizado pode ser feito de forma lúdica no período do desenvolvimento do produto. Metódos ágeis (alguns deles) denotam a fase do Pré Game. Fase onde existe um aprofundamento no negócio e na tecnologia com a intenção de clarear um pouco o caminho.

Nesta fase o aprendizado é fundamental. Tratar esta fase de uma forma mais dinâmica, participativa e descontraída pode auxiliar a absorvição do Time sobre o conteúdo a ser ensinado. Eis aí um bom ponto onde você pode usar uma prática lúdica.

Ano passado eu criei e neste ano apliquei e desenvolvi um Jogo chamado Domain Game: https://agilementoring.wordpress.com/2011/07/05/domain-game-uma-dinamica-para-todos/

O jogo é uma prática lúdica que visa disseminar o conhecimento sobre um domínio a todo o Time, que envolve também a participação dos Clientes e Experts, estimulando a interação entre eles, a colaboração e motivando-os.

E o uso das práticas lúdicas não param por aí.

Seja em Workshops ou Treinamentos, a utilização de tais práticas ajudam muito a manter um ritmo gostoso no ensino, de forma leve e descontraída.

Como isto está bem ainhando ao Core Ágil, não demorou muito para vários gurus da área criarem um grupo para trocarem ideias e experiências. Nasce assim o Google Group Agile Games:

http://www.hanoulle.be/2010/06/agile-games-google-group/

http://groups.google.com/group/agilegames?pli=1

Eu acompanho o grupo e já tive várias oportunidades de usar jogos descritos lá. O pessoal realmente se supera 🙂

Descorrendo mais sobre práticas lúdicas no dia-a-dia de um Time ágil, não é apenas no Pré Game que é possível utiliza-las.

Ao decorrer da Sprint, você pode utilizar de práticas lúdicas para auxiliar o Time no entendimento de uma User Story, auxiliar a criar cenários de testes (adoro fazer analogias a RPG para isso).

E existe mais um ponto num ambiente ágil onde é muito viável utilizar práticas lúdicas e particularmente, acredito que seja fundamental utiliza-las. Retrospectivas.

Como sabem, a Retrospectiva é o momento onde um Time busca olhar e entender para tudo o que se passou em uma iteração. Neste momento o Time buscará colocar em prática o must da Inspeção e Adaptação.

Instigar aos membros do Time para fazer isto não é fácil. É muito comum com o passar do tempo um Time perder o interesse numa Retrospectiva, achando que ela se tornou monótona. É fundamental para um Scrum Master, um líder ou mesmo para o Time em si saber maneiras de manter o ânimo numa Retrospectiva, com eficiência e eficácia para manter o ciclo da melhoria contínua.

Eu gostava de usar algumas práticas como:

Conclusão de frases:

Eu criava algumas frases e deixava lacunas para os membros do Time completarem. Geralmente as frases eram brincadeiras que buscavam o sentimento/opinião dos membros do Time sobre o ambiente do produto, exemplos:

  • Se o meu projeto fosse um animal, ele seria um(a) _________________________________________________
  • Se eu fosse o Super Man, a Criptonita desta Sprint foi a/o ____________________________________________
  • Se eu fosse a Mulher Maravilha, utilizaria o meu laço mágico para agarrar a/0 ______________________________
  • Rosas são vermelhas, violetas são azul (são??) neste Srint eu queria _____________________________________
  • Se eu fosse o Thor, utilizaria o meu Martelo para acabar com a _________________________________________

Quando o Time é mais novo, gosto de fazer práticas para lhes ensinar sobre auto-gerenciamento, colaboração e ROI.

Dinâmicas como formar uma fila com base em alguma premissa, construir alguma coisa juntos e separados, com material dividido entre eles, brincar de Passa ou Repassa, sobre o que estão fazendo, se está agregando valor.

Dentre cursos, treinamentos, workshops que participei, legal levantar algumas pessoas que utilizam muito bem isto:

  • Alexandre Magno: durante seus CSM e CSPO e workshops, ele utiliza várias dinâmicas para explicar o Core do Ágil e Scrum
  • André Nascimento: Durante seus workshops de Scrum ele utiliza várias dinâmicas, inclusive a Famosa Dinâmica do Avião de Papel
  • Manoel Pimentel: Durante o Agile Coach Professional, ele se supera utilizando 1001 práticas
  • Hugo Corbucci e Mariana Bravo: Lean Lego Game, uma fantástica brincadeira para ensinar os conceitos do Lean
  • Matheus Hadda: Utiliza várias práticas para ensinar Scrum, como a Horta e também para ensinar sobre o Canvas Business Model.

Eu também utilizo do Lúdico para realizar Análise de Negócios, seja através de perguntas ou pequenas dinâmicas que faço com o pessoal entrevistado.

E é isso pessoal.

E você conhece mais algumas práticas lúdicas? Já utilizou alguma? Como foi?

[]s e até a próxima.

Análise de Negócios (ágil ou não), um grande desafio

Neste post vou comentar sobre meu novo desafio, que é uma retomada as origens.

Comecei na carreira como Analista de Requisitos e depois me enveredei mais a Scrum Master. Estou retomando agora com a alcunha de Analista de Negócio.

Bem, como gosto de fazer, vamos imitiar o Jack e ir por partes.

Análise de Negócio, o que é?

Segundo o IIBA é:

“A Análise de Negócios é o conjunto de atividades e  técnicas utilizadas para servir como ligação entre  partes interessadas no intuito de compreender a  estrutura, políticas e operações de uma organização  e para recomendar soluções que permitam que a  organização alcance suas metas”.

(IIBA®, 2009, pg 3)

Esta não é uma tarefa fácil, porém, é muito prazerosa.

Analisar o negócio requer contato direto e aberto com as pessoas. Não pense que o negócio se traduz através de processos descritos ou mapeados, pois não se traduz mesmo. Analisar o negócio não é apenas verificar as interações homens-máquinas que uma pessoa faz ou descobrir tarefas manuais que podem ser automatizadas ou informatizadas.

Muitos confudem isto. Acreditam que por entender o contexto da interação da pessoa com o processo ou descobrir ações manuais que podem ser informatizadas, estão fazendo um grande trabalho de análise. Isto não é. No máximo, é um trabalho de observação, que também é importante mas não deve ser a única ação de um Analista de Negócio.

 Para entender a diferença entre Observação e Analise, vamos ao significado das palavras:

Observação:

 Ato ou efeito de observar, segundo o dicionário

A observação é uma das etapas do método científico. Consiste em perceber, ver e não interpretar. A observação é relatada como foi visualizada, sem que, a princípio, as idéias interpretativas dos observadores sejam tomadas. By Wikipedia.

Observação é comumente descrita como o estudo em que o pesquisador frequenta o local onde o fenômeno ocorre. O observador procura se interar sobre as atividades do grupo estudado, vivendo junto com eles estas experiências afim de averiguar detalhes.

Análise:

Estudo detalhado, decomposição em partes.

Análise (do grego ανάλυσις, transl. análysis, “dissolução”) é o processo de decomposição de uma substância ou tópico complexo em seus diversos elementos constituintes, a fim de se obter uma melhor compreensão sua. By Wikipedia.

Processo lógico que consiste na investigação das estruturas básicas de uma informação.

A Análise é mais profunda do que que a observação, embora a observação faça parte da análise.

Observar as atividades e interagir com as pessoas provem uma base de início para a análise, que tem um intuito da compreensão do todo, compreensão das ações entre as parte e as reações que geram. Uma vez isto acontecido, você aumenta a capacidade de formular soluções e potencializa a comunicação.

Logo, se você não gosta de sair da sua mesa e estar em contato direto com o ambiente a ser estudado, é melhor você não querer (ser) um Analista de Negócio. A imersão no meio ambiente estudado deve ser profunda.

Analisar requer interação e contato com as passoas, logo se relacionar com elas é importante (e importantíssimo na Visão Ágil da Análise, visão que compartilho). Logo, se você não gosta muito de pessoas ou conversar, terá problemas.

 E agora vamos falar do que é Negócio:

Em apertada síntese, podemos dizer que, entende-se por negócio toda e qualquer atividade econômica com o objetivo de gerar lucro.

Etimologicamente, e num sentido mais lato, a palavra negócio deriva do latim, e quer dizer a negação do ócio. Negócio não trata apenas de negócio financeiro ou comercial, mas sim toda a atividade humana que tem efeitos jurídicos. By Wikipedia

Eu gosto muito da origem da palavra Negócio “negação ao ócio”. Logo, Negócio significa atitude ativa. Se você quiser ser (ou é) um Analista de Negócio, este deve ser o seu mantra, seu mandamento número 1:

“Negarás ao ócio”

Para ser um Analista de Negócios, é ideal que você realmente seja ativo, pró ativo, interessado, participativo, dinâmico e mais um monte de palavras que querem dizer “Não fique parado”.

De lambuja, nós teríamos um segundo mandamento (ou dica, não quero ser pretensioso de ditar leis :P).

“Estarás presente”

É meu caro amigo, uma análise adequada não se faz sentado, com o bumbum numa cadeira. Levanta-te, vem para o meio, parafrasenado Jesus.

Como o papai dos Negócios, Peter Drucker define bem, todo Negócio tem um objetivo claro, Criar um Cliente.

Existem outras abordagens para o Objetivo de um Negócio, como gerar Lucro, mas particularmente eu fico com o titio Pete nessa. Um negócio tem por objetivo criar um cliente e satisfazer suas necessidades através de seu ciclo de vida.

” É o cliente que determina o que é um negócio. Apenas o cliente, cuja disposição para pagar por um bem ou serviço converte recursos economicos em riqueza e coisas em bens. Aquilo que o cliente compra e considera de valor nunca é apenas um produto. Tem uma utilidade, i.e., o que o produto ou serviço faz por ele.” By Wikipedia.

Aqui começa o desafio, compreender o Negócio.

 

Para tal, compreender seu Cliente é essencial. Quem é o seu Cliente e quem é o Cliente do Negócio. Isto até parece “A Origem” (Inception) mas é a verdade.

Você, como Analista de Negócio, representa uma Empresa (a sua mesmo ou a em que trabalha) e tem um Cliente. Até aqui tudo OK. Porém, a análise do negócio que você vai realizar tem o seu próprio Cliente.

Buscar este Cliente é um passo importantíssimo para iniciar e manter uma boa análise. A análise Ágil ou Tradicional, valida suas descobertas em ciclos (a ágil em ciclos mais curtos e rápidos) e as descobertas ocorrem de forma iterativa e incremental. Validar quem é o Cliente do Negócio é uma ação que você deve fazer sempre, a cada ciclo. Uma vez que o Cliente se mostrou ser outro, as coisas mudam.

Não trace um plano para analisar o negócio ou achar o seu Cliente. Uma vez um boxeador famoso (que eu esqueci quem é) disse algo assim:

“Todos tem um plano até levar um soco no queixo”.

O análise é um processo de descoberta, formulação de hipoteses, falseamento de hiposteses e ocorre de forma não linear. Logo, não espere ter um plano definido ou ache que a análise vai decorrer sobre a forma de um Diagrama de Atividades ou Fluxogramas.

O produto da análise pode ser demonstrado assim, mas o processo da análise não é desta forma.

A interação com as pessoas torna tudo mais divertido e místico. Pessoas tem dias bons, dias ruins, falam por entrelinhas, e para fazer uma análise legal, é bom o Analista ficar atento a isto.

Eu gosto de realizar práticas e/ou perguntas lúdicas, para entender as entrelinhas. Gosto de conversar com as pessoas em diferentes horários do dia, em dias diferentes o mesmo assunto. Tento fazer isto não ser exaustivo e repetitivo, mas faço isso pra ir colhendo pequenos feedbacks, ora abstraíndo sentimento, ora quero todo o sentimento que as pessoas têm.

Não quero aqui, neste post pelo menos, falar sobre as diferenças entre a Análise de Negócio Ágil e a Tradicional. Existem ótimas referências para isso:

E se um deles disser que eu escrevi merda aqui, acredite neles 😛

Um dia vou escrever algo sobre essas diferenças, quero pensar mais sobre isso, pois, quando comecei a anos atrás e fazia a “Análise Tradicional” e não tinha conhecimento de técnicas e ferramentas que eu tenho hoje, e isto é natural, sempre dei grande importância as pessoas, ao tato e contato, e todos sempre tentavam minimizar o tempo de feedback.

O desafio da Análise de Negócio é imenso, mas muito recompensador.

Pretendo em próximos post falar mais sobre o tal do Analista de Negócio, Requisito, Funcional, Processo ou sei lá o que mais. Alguns dizem que é diferente, outros que é igual.

[]s e até a próxima.

Caipira Ágil – A alegria de se fazer este evento

Neste post quero comentar sobre a alegria de ter realizado junto com outros amigos o Caipira Ágil.

Em menos de um ano conseguimos ter uma ideia, ver o seu valor e então apostar nela.

No Encontro Ágil 2010, Renato Freire, Vitor Hugo, Alan Braz e eu tivemos a ideia de realizar em Campinas um evento do mesmo foco. Um evento que fosse mais dinâmico, participativo e colaborativo. Com o evento, buscaríamos alavancar a comunidade de desenvolvimento de software na RMC (Região Metropolitana de Campinas). Durante o papo com eles no Encontro Ágil, foi dito o nome “Caipira Ágil” e seguiu-se de gargalhadas. Sentimos que o nome tinha poder 😀

Durante um HHA (Happy HourÁgil) em Campinas, conversamos com mais pessoas sobre a ideia e com isto o Renne Rocha e o Alberto Leal se juntaram a nós e ai formou-se o grupo dos organizadores.

Para facilitar a comunicação, montamos um grupo no Google e então começamos a botar a mão na massa.

A tarefa não foi fácil. Alguns já tinham até oganizado alguns tipos de eventos antes, mas nada como o vindouro Caipira Ágil. Nossa primeira atitude foi definir uma visão do que seria e pra que seria o evento. Segue um trecho dessa visão:

Alavancar a comunidade de desenvolvimento de software localizada na RMC, incentivando e estimulando a realização de eventos, Dojos, encontros, grupos de usuários e estudos. A RMC é um pólo industrial muito importante, com grandes empresas e importantes faculdades, mas é muito pobre na realização de eventos.

Com a visão em mente, começamos a corrida. Definições de grades, patrocinadores, horário, data, comida, e etc.. Tenha certeza que esta foi a parte mais simples e mais desgastante. Aprendi muito sobre como li dar com opiniões diferentes, definições em grupos e etc.

Convocamos aqueles que achamos que agregariam ao evento para realizar os Workshops, viabilizamos todo os gastos do evento com os patrocínios sem finalidade alguma de obter lucro com o ele. Com o valor pago pela inscrição, buscamos oferecer uma refeição de qualidade e durante todo o evento (o que sinceramente achei um grande diferencial do Caipira).

Fizemos uma coisa interessante: Quem realizasse inscrição no evento, poderia submeter lighting talks. Um ponto que foi relamente bem legal no evento.

Nossa meta era de ter 150 pessoas inscritas no evento. As inscrições ficaram no ar por cerca de 2 meses e o evento aconteceria logo após a maratona do Agile Brazil e TDC.

Agora compartilho com vocês os números do evento, que nos deixaram muito orgulhosos:

Tivemos 186 inscrições, sendo que 131 foram confirmadas. No dia do evento, tivemos cerca de 130 pessoas, tendo inscrições feitas no dia. Para se ter uma ideia, o Encontro Ágil 2010, em sua terceira edição teve em torno de 200 pessoas.

Tivemos profissionais de aproximadamente 80 empresas diferentes. Sem duvida, uma das nossas metas foi atingida.

Tivemos um ótimo evento. As talks foram muito boas, bem legais e divertidas, com muita improvisação. Workshops fantásticos, um Dojo com mais de 30 pessoas, open spaces interessantes e até sessões de Ignite Presentations.

Quero agradecer de coração todos aqueles que participaram do evento, que ajudaram no evento, que falaram sobre o evento e que pensaram no evento.

Como dissemos ao final do Caipira Ágil: “O Evento terminou, mas não seus objetivos”. Vamos buscar manter ativa esta comunidade, com mais eventos, encontros, conteúdos e tudo o que for possível.

Para ver as fotos do evento, slides de apresentações, videos e tudo mais, acesso o Blog do Caipira Ágil.

Já adiantamos que em breve teremos um evento sobre Startups em Campinas (Estartapi Caipira, sô!). Acompanhe a gente no Blog do Caipira Ágil e fica atento a tudo mais que vem por aí.

[]s.