Como levantar os requisitos do sistema?

Geralmente quem vem das metodologias tradicionais, tende a dizer que não é possível iniciar um projeto sem ter certeza de tudo que todos os requisitos serão levantados, pois precisam ter uma visão do todo. 

Devemos nos questionar sobre o seguinte: Ter visão do todo significa conhecer todos os itens no maior nível de detalhes? É preciso desenhar milhões de UML, prototipar telas, escrever, escrever, escrever....?

Ainda ontem, vi o desenho da monalisa (mais uma vez) e me lembrei disso... Eu estou vendo como será o produto só não sei ainda os pequenos detalhes! Lógico que muitas pessoas vão dizer que pequenos detalhes fazem a grande diferença! E fazem mesmo, mas fazem tanta diferença que são mudados o tempo todo, então para que perder tempo com algo que será mudado o tempo todo? Devemos trabalhar junto ao Product Owner (cliente), fazendo entregas constantes mostrando como está ficando o produto que ele quer, pois cada detalhe que precisar ser ajustado, será muito mais fácil se ele ainda não estiver 100% completo.

Pensando em coisas mais concretas do que software, pense no seguinte: Você vai construir uma nova parede em sua casa. Você ao pedreio que quer uma parede 2x2 e diz que vai ter 2 tomadas nela, dividas igualmente neste espaço. Bom muito simples, mas pense que enquanto ele está fazendo a parede vc foi comprar aquele super sofá, quando ele terminou vc colocou o sofá no lugar e viu que ele tampou as duas tomadas! Agora é tarde, para alterar os locais destas tomadas você vai pagar um alto custo (e se encomodar).

Se você estivesse partindo de princípio ágeis (Scrum), você teria visto como estaria ficando cada entrega da parede, e quando o pedreiro estivesse mostrando a parede sem acabamento (reboco) mas com as tomadas, você viria que estavam erradas e pediria para reposicionar. Sairia muito mais barato e vc não teria grandes dores de cabeça.

Esta é a ideia de trabalhar utilizando Scrum. Entregas constantes mostrando ao cliente como o produto está ficando. Você conhece o todo, mas não precisa de muitas especificidades, não precisa fazer trabalho que não será de grande valor agregado. Claro que existem documentações importantes e nós termos várias! Mas vamos deixar isto para outros posts.

Abraços!

Vou ser PAPAI!!!!

É isso mesmo!!!

Vou ser papai! Descobrimos hoje as 13:15.

Grande abraço a todos, porque agora eu vou é comemorar!

O que é trabalhar de forma ágil (Agile)?

Hoje um colega me fez esta pergunta. Na verdade a pergunta não foi bem essa, mas de forma sucinta foi isso. Claro que antes veio todo o cerco por volta de trabalhar usando Scrum, quadro com post-its e tudo mais.

Respondi que trabalhar de forma ágil, usando Scrum, era basicamente cortar as 'gorduras' ou formalismos existentes no dia-a-dia tradicional e que não agregam valor no fim do projeto e ainda entregar partes funcionais do produto antes de ter concluído ele por completo dando visibilidade ao cliente.

Exemplifiquei da seguinte forma: Imagine algo simples como fazer uma banqueta de madeira... no método tradicional eu farias vários desenhos até que um deles agradasse a você, quando estivesse com isso concluído, faria um projeto definitivo da banqueta com medidas precisas, desenhado no autocad e tudo mais que tivesse direito. Agora pare um instante e pense: Para você aprovar um dos desenhos lá se foi um dia por exemplo, para eu passar para o projeto definitivo e autocad, mais um dia. Até agora você não sabe como será a banqueta de verdade, e o pior é que ela nem começou a ser produzida! Este passo de produção seria dado logo após a sua aprovação final do meu projeto no autocad (ehehe). Ai você pensa 'Maravilha! Aprovei o projeto agora é só esperar chegar!'. Em termos seria isso, mas quando chegar você pode ser altamente feliz ou dizer que aquilo que foi materializado a partir de sua ideia, não era bem da maneira que você queria (o que é muito comum) e faz sugestões e ajustes e insere coisas novas como um apoio de pé... e por ai vai.

Agora analisando esta situação temos três equipes distintas: dono do produto, analista/arquiteto e produção. Cada um aqui com tarefas bem distintas, certo? Bom, por isso eles precisam trabalhar tão longe? Não! E isso que a visão ágil vai fazer colar os integrantes juntos nos momentos necessários. Este mesmo processo da banqueta na visão ágil ficaria assim: Você me diz mais ou menos como quer sua banqueta, então produzimos um pé dela, 3Hs depois de termos conversado você estará vendo este pé e ai já pode dizer se quer mudar algo nele, se quiser.. nós já mudamos e enquanto isso a equipe de produção está trabalhando no tampo que é mostrado em 5Hs após a nossa conversa e já com um pé montado com as mudanças solicitadas! Então se tiver algo mais a ser modificado, novamente, mudamos e com estas informações a equipe já está mudando e terminando os outros pés, que no fim do dia você está vendo a sua banqueta quase que totalmente pronta! Faltando detalhes que você ainda pode opinar para ter o produto que você tanto quer! Ou seja no final de 1,5 dias você vai ter sua banqueta como você queria!

Conclusão: Economizamos tempo, pessoas, dinheiro e ainda saímos muito satisfeitos! Pese nisso na modelo tradicional você gastou 2 dias só planejando e com Agile (Scrum) você teve o produto em 3/4 deste tempo!!!

Isso é processo ágil! Isso é pensar ágil! E por fim... o Scrum vai te ajudar e muito com isso.

Pense nisso ;)

Daily Meeting caindo no esquecimento?

Antes de mais nada preciso agradecer ao meu amigo Abu, que me apresentou Scrum e me fez voltar a querer partir novamente para o lado gerêncial, mostrando com é possível gerênciar e estar inserido na equipe, podendo acompanhar bem de perto o trabalho e entender seus desafios de perto, sem ser aquele cara que olha todos de cima para baixo e simplesmente manda executar o trabalho. Grande abraço amigo!!!

Uma das coisas que costumam deixar de funcionar no processo do Scrum é o Daily Meeting!
E por qual motivo isso deixa de funcionar? Geralmente porque as pessoas acabam ficando cansadas, de todo o dia sair de seus locais de trabalho (quando preciso), e ficarem todos de pé para ficar lembrando o que fizeram no dia anterior, o que pretende fazer hoje e se há ainda algo que esteja impedindo suas tarefas.
Agora vamos refletir sobre tudo isso... ficar de pé a princípio é para termos uma reunião breve e objetiva, sem perdermos muito tempo. Isso até pode funcionar, mas não garante nada! O processo tem que ser moldado conforme o perfil do time. De que adianta ter os integrantes ali de saco cheio porque tem que ficar de pé? A reunião será tão objetiva quanto os integrantes do time desejarem, claro que o Scrum Master pode pedir foco quando achar necessário. Mas veja pelo meu caso, já ministrei muitas aulas então falar de pé não é problema! EHEHEH Os integrantes do meu grupo optaram por cada um tomar suas posições, ou seja, quem desejar permanecer de pé, ótimo, quem não quiser pode ficar sentado, e isso não muda em nada o quão produtiva será o Daily Meeting.
Agora os demais itens: O que foi feito no dia anterior, o que será feito hoje e quais o impedimentos, são os famosos 'maus necessários', pois eles permitem não só ao Scrum Master, mas toda a equipe ter uma visibilidade do que está acontecendo e como o projeto está andando, além de ser um grande momento de troca de experiências onde é possível que um integrante se comprometa em ajudar outro caso já tenha alguma experiência favorável. Neste momento o Scrum Master precisa ficar atento para que não comece uma troca de informações ávidas em que faça todo o grupo ficar observando aquela conversa ou ainda virar um verdadeiro brainstorm! Uma boa maneira de sempre lembrar o que foi e será feito é olhar o quadro de acompanhamento com os post-its. Ao contrário do que muitos pensam aquilo lá não é só para mostrar que o time está fazendo algo, é sim uma grande ferramenta de visão para todo o time.

A melhor dica que se pode ter é: Não deixe de fazer se quer um dia o Daily Meeting, pois, a equipe tende a cair na preguiça por esta perda.

Abraços!

Tabalhar sem parar. Vício ou necessidade?

Hoje estava lendo uma reportagem (revista Mercado Brasil ago/08), a respeito de pessoas consideradas 'Workaholics'.
Este termo proveniente da língua inglesa remete a indivíduos que possuem uma espécie de vício em seus trabalhos. Podemos citar como exemplo alguém que trabalhe umas 12Hs por dia e chegue em casa e por um impulso quase que incontrolável, resolve voltar a trabalhar mesmo que de casa. Trabalhando remotamente ou rascunhando possíveis soluções para os problemas encontrados durante o dia. Trabalhadores incansáveis que muitas vezes buscam a perfeição em suas atividades, podem ser estes considerados Workaholics.
Por um lado estes podem ser considerados ótimos funcionários, pois se demonstram muito interessados pelos problemas da empresa e os faz quase que pessoais. Porém, por outro lado isso pode acarretar grandes níveis de estresse ao funcionário, tornando-o pouco produtivo e outras vezes passando seus problemas para o restante da equipe. Ou seja você pode acabar com uma equipe caso tenha um Workaholic que passe seu estresse (não detectado) para os demais. Claro que existem exceções, onde os Workaholics são considerados verdadeiros 'estimulantes' para os demais membros, mas isto varia de cada indivíduo.

O Scrum Master da equipe deve estar atento não só ao andamento de itens de backlog, planilhas, acompanhamento do processo, etc. Mas também aos integrantes do time que devem possuir uma boa sinergia, para que este seja realmente um time e não um amontoado de pessoas que realiza uma tarefa.
Este tipo de 'leitura' pode ser adquirido todos os dias no Dayli Meeting, e durante o dia-a-dia é claro, mas principalmente no Dayli Meeting que é o momento onde o Scrum Master pode perceber alterações de humor, cansaços aparentes e até descontentamentos com papeis. Agile não pode ser só o processo de execução, mas também a velocidade em que as coisas podem mudar e impactar no projeto. Se o Scrum Master não for hábil o suficiente para identificar problemas com a equipe e resolve-los rapidamente podemos ter um bom atraso em uma Sprint que irá impactar nas outras demais.
Muitas vezes uma simples troca de papel dentro de uma equipe faz dois integrantes ficarem muito mais satisfeitos e com uma boa elevação na auto estima. Pense nisso, Agile é todo o processo e os famosos 'porcos' são praticamente a essência do processo, o Scrum Master é meramente a pessoa que garante todo o processo (um trabalhão eu concordo) e isso inclui as pessoas. Então o quanto mais ágil for a tomada de decisão e a identificação dos problemas, mais eficaz e FELIZ será a equipe e consequentemente o Product Owner.

Abraços!