O início de um projeto é provavelmente sua fase mais crítica. Entender corretamente as verdadeiras necessidades dos clientes desde o início é um grande passo para o sucesso. Cada erro de compreensão pode levar a múltiplos erros no futuro e a um alto custo de correção ou mesmo de abandono. Muitas técnicas são recomendadas para serem utilizadas nessa fase, porém uma das mais simples é a mais eficiente. Inicialmente conhecida como a técnica do 5W, hoje é chamada de 6W2H.

Essa sigla representa 8 questões que devem ser respondidas em qualquer projeto ou tarefa que fazemos: who, what, when, where, why, wins, how, how much.

WHO, ou quem, discute sobre as pessoas envolvidas na ação. No caso de uma tarefa normalmente estamos querendo indicar o responsável pela tarefa, ou seja, quem tem que garantir que algo vai acontecer. No caso de projeto “quem” pode significar muita gente e temos que identificar pelo menos algumas classes: quem pede, quem autoriza, quem paga, quem recebe, quem usa, quem se beneficia, quem pode ser prejudicado. Imagine um gerente de vendas comprando um sistema de venda operado em smartphones que será pago pelo departamento de marketing. Veja quantos estão envolvidos?

WHAT, ou o quê, discute conceitualmente o que vai ser feito. Normalmente é uma descrição do que deve ser alcançado sem nenhuma relação a forma como vai ser feito, o HOW, ou como. Em desenvolvimento de software a divisão entre “o quê” e “como” é normalmente encontrada na diferença entre a análise e o projeto. As histórias do usuário deveriam ser sempre ligadas ao “o quê”, cabendo à equipe a definir “como”, porém temos que aceitar que em um método ágil muitas vezes a história do usuário inclui decisões tecnológicas que seriam “um pecado” em métodos como a Análise Essencial.

WHEN, ou quando, e WHERE, ou onde, são importantes de uma forma diferente, pois normalmente agem não como requisitos, mas sim como restrições. “Quando” normalmente se refere a prazos de entrega, enquanto “onde” se refere a locais de execução ou de entrega.

Finalmente, os novatos dessa lista: WIN e HOW MUCH.

Obviamente “HOW MUCH“, ou “por quanto”, indica o valor do investimento do projeto. Isso é importantíssimo para definir não só o ROI do projeto, mas também várias questões de implementação e execução. Uma coisa é você pedir uma bijuteria  para ir a uma festa, outra coisa é uma jóia de ouro feita a mão por um designer conhecido. O investimento a ser feito em um projeto fala muito do tipo de tecnologia esperada, da segurança a falhas e da complexidade e funcionalidade esperada.

Já o WINS, o mais novo termo agregado à lista, e que não é bem uma pergunta, procura indicar os benefícios esperados do projeto. Cada vez mais o foco do desenvolvimento de um projeto tem mudado do que deve ser feito para o benefício que deve ser alcançado. Principalmente no caso de projetos ágeis, onde o valor entregue é o guia do desenvolvimento, esse conceito é mais importante. Entenda os benefícios de seu cliente e estará pronto para discutir o valor do produto.

6W2H, uma técnica simples de aprender, fácil de usar, de alta comunicabilidade. Uma técnica usada em projetos tradicionais, porém totalmente ágil.

The post Na Sprint zero, entenda seu projeto com 6W2H appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Hoje continuo a falar mais um pouco das questões de gerência tradicional de projetos e o Scrum.

Particularmente, vamos tratar do papel do Gerente de Projetos em contrapartida a gerência de projetos com Scrum.

Tenho lido muitas publicações em fóruns e blogs de discussões sobre o tema, com opiniões as mais diversas possíveis.

Mesmo na prática, em organizações nas quais tivemos a oportunidade de auxiliar no processo de implantação do Scrum, há uma percepção inicial de que “sem gerente não pode haver gerência”.

Já identificamos em trabalhos anteriores que as barreiras culturais têm sido consideradas como uma das principais dificuldades na adoção do Scrum.

Nas nossas experiências, essas dúvidas e ansiedades foram se dissipando com a prática e com a evidenciação dos resultados alcançados.

O framework Scrum  especifica uma estrutura com cerimônias, artefatos e papéis definindo como as equipes devem trabalhar em ambientes com constantes alterações e com surgimentos de novos requisitos.

E é com base nessa especificação que chegamos a um entendimento de que mudam os papeis, mas as atividades de gerência permanecem, só que agora atribuídas ao SM, P.O. e Equipe.

Vamos tomar como exemplo algumas das atividades mais peculiares do Gerente de Projetos:

•  Atribuição de tarefas e prazos aos membros da equipe.

Times também são auto-organizáveis. Ninguém – nem mesmo o ScrumMaster – diz ao time como transformar o Backlog do Produto em incrementos de funcionalidades entregáveis.

• Identificação, documentação, gerenciamento e solução todos os problemas que possam surgir.

As Reuniões Diárias melhoram a comunicação, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rápida de decisões e melhoram o nível de conhecimento de todos acerca do projeto.

• Controle da qualidade num nível de qualidade aceitável.

O ScrumMaster educa o Time Scrum treinando-o e levando-o a ser mais produtivo e a desenvolver produtosde maior qualidade. Tanto a composição do time quanto as metas de qualidade devem permanecer constantes durante a Sprint.

• Cobrança de cada membro da equipe para que as tarefas atribuídas estejam sendo realizadas com sucesso.

Scrum exige que os Times desenvolvam um incremento de funcionalidade do produto a cada Sprint. Esse incremento deve ser potencialmente entregável, pois o Product Owner pode optar por implantar a funcionalidade imediatamente.

• Verificação das etapas do projeto visando a evolução para as fases seguintes.

  As Sprints contêm e consistem na reunião de Planejamento de Sprint, o trabalho de desenvolvimento, a Revisão da Sprint e a Retrospectiva da Sprint. As Sprints ocorrem uma após a outra, sem intervalos entre elas.

•  Verificação e a finalização do projeto e a realização de um levantamento dos erros e acertos.

Durante a Revisão da Sprint, o Time Scrum e as partes interessadas colaboram sobre o que acabou de ser feito. A reunião inclui ao menos os seguintes elementos. O Product Owner identifica o que foi feito e o que não foi feito. O Time discute sobre o que correu bem durante a Sprint e quais problemas foram enfrentados, além de como esses problemas foram resolvidos.

A finalidade da Retrospectiva é inspecionar como correu a última Sprint em se tratando de pessoas, das relações entre elas, dos processos e das ferramentas. A inspeção deve identificar e priorizar os principais itens que correram bem e aqueles que, se feitos de modo diferente, poderiam ter deixado as coisas ainda melhores.

Vimos, portanto, que podemos redistribuir e atribuir as diversas outras atividades do Gerente de Projetos aos papeis do Scrum em suas cerimônias. Apesar de suas naturezas diferenciadas, o Scrum pode se alinhar a esses aspectos da gerência tradicional de projetos repensando os papeis e as atividades no processo.

E você? Tem ou teve alguma experiência ou comentário sobre tais dificuldades que queira compartilhar conosco?

Então não deixe de comentar aqui seus questionamentos e de assistir aos vídeos do Papo Ágil, na Universidade Scrum.

Encontro vocês num próximo post. Até lá!

The post O Gerente de Projetos e os papeis do Scrum appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Hoje vou falar um pouco de outra questão frequentemente discutida que é o Scrum e a gerência tradicional de projetos, pois considero um assunto bastante interessante e polêmico.

Sempre que visitamos um cliente ou potenciais clientes ou conversamos com pessoas e profissionais que gerenciam ou trabalham em projetos, sempre se fala das questões da gerência tradicional comparativamente aos métodos ágeis.

Por um lado, dentre as metodologias ágeis o Scrum é a mais usada e com grandes perspectivas de aumento na sua adoção.

O framework Scrum não especifica nem ferramentas e nem técnicas de desenvolvimento, mas sim uma estrutura com cerimônias, artefatos e papéis definindo como as equipes devem trabalhar em ambientes com constantes alterações e com surgimentos de novos requisitos.

Ele propõe alguns níveis de gerenciamento em maior ou menor nível de detalhe, desde o planejamento diário, o gerenciamento da Sprint e até o gerenciamento do projeto.

Por outro lado, sabemos que o gerenciamento de projetos de software é, sem dúvida, um aspecto essencial para o seu sucesso e que por inúmeras causas os projetos falham, sejam eles ágeis ou tradicionais. A falta de entendimento, a experiência, os fatores culturais, as pressões externas, o treinamento insuficiente, dentre outras causas de falha são comuns a ambas as abordagens. Também sabemos que cronogramas irreais são provavelmente um dos principais fatores que influenciam no aumento das taxas de projetos rotulados como contestados ou fracassados.

O Scrum atua fortemente no gerenciamento de tarefas, no planejamento diário e no planejamento da Sprint. Dependendo do projeto e da organização isso talvez não seja suficiente e a adaptação do Scrum tem tudo a ver com essa necessidade, pois ela nos fala do “ajuste do processo ou do material sendo processado”.

O Scrum que foi originalmente concebido para o desenvolvimento de software, atualmente tem sido adotado em diversas áreas como: Recursos Humanos, Finanças, Publicidade, Engenharias, Laboratórios e em muitas outras.

Além disso, ele tem evoluído em termos de simplicidade e de adaptação.

Contudo, o Scrum não é o mais adequado para todo tipo de projeto e nem poderá atender integralmente a todas as necessidades de adaptação de todos os processos do PMBOK.

Até hoje, sempre que foi demandado, conseguimos adequar o framework Scrum aos requisitos dos projetos tradicionais. Já tivemos algumas oportunidades de falar disso em outros posts sobre Versões Scrum e Cronogramas Macros de Projetos, Um pouco mais sobre Versões Scrum e Cronogramas Macros de Projetos  e Diferenças entre Valores Ágeis e Tradicionais, somente para citar alguns.

No final das contas, fica tudo bem quando tudo acaba bem ou mesmo, mais ou menos bem. Mas, quando as coisas dão errado há que se eleger os “culpados” e é claro que as pessoas não têm culpa de nada. Daí a culpa é das ferramentas, ou dos processos ou dos modelos ou do método…

Quanto maior e mais complexo o projeto, mais difícil poderá ser gerenciá-lo. A verdade é que dentre os vários aspectos gerenciais importantes destaca-se o fato que alguns projetos exigem “gerentes” e “equipes” mais experientes e comprometidas, sejam eles ágeis ou tradicionais.

Enfim, apesar de possuírem naturezas diferenciadas no que se refere ao foco, escopo e aos princípios, o Scrum pode atender aos aspectos da gerência tradicional de projetos de forma complementar. Evidentemente, dependendo do esforço requerido e dos benefícios a serem alcançados.

E você? Tem ou teve alguma experiência ou comentário sobre tais dificuldades que queira compartilhar conosco?

Então não deixe de comentar aqui seus questionamentos e de assistir aos vídeos do Papo Ágil, na Universidade Scrum.

Encontro vocês num próximo post. Até lá!
 

The post O Scrum e o Gerenciamento Tradicional de Projetos appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Converso com muitas pessoas sobre o Scrum e obtenho as mais diferentes reações. Desde entusiastas aos mais céticos, uma reação muito comum é “Meu chefe nunca vai concordar com isso”. Fico pensando porque essa reação é maioria e uma das explicações que eu acredito é a drástica mudança de desenvolvimento que o Scrum propõe quando comparados as outras metodologias, chamadas de tradicionais. Quando colocadas lado a lado, encontramos focos e valores diferentes.

Uma grande dificuldade na implantação do Scrum é a mudança de hábito e de cultura da empresa. Muitas vezes, a cultura existente é centrada no plano, ou seja, dá mais valor aos procedimentos e métodos bem aplicados do que o valor gerado pelo resultado. Essa filosofia é chamada de desenvolvimento movido ao plano, onde é dada muita importância aos artefatos bem construídos e etapas bem realizadas. Esse tipo de desenvolvimento é muito difundido por diversas metodologias e existem diversos motivos para elas continuarem existindo.

O Scrum se encaixa em outro tipo de desenvolvimento: O desenvolvimento centrado em valor. O seu objetivo está em agregar valor ao cliente. Toda a estrutura do framework está montada para permitir responder rapidamente a mudanças e se ajustar ao desejo do cliente.

No Scrum, o planejamento é considerado muito importante: Ter uma visão do produto é essencial. No entanto, o plano, a maneira que será executado para atingir o objetivo esperado, não é. Esse plano pode, e deve, ser alterado caso o objetivo mude, buscando atender melhor aos desejos do cliente. Dessa maneira, ele está mais preocupado em fazer o software certo do que fazer certo um software.

Podermos perceber nesse ponto que uma grande dificuldade na implantação do Scrum é essa mudança da maneira de pensar da organização. No manifesto ágil é descrito o que as metodologias ágeis consideram mais valiosos. É importante perceber qual o grau de concordância que a sua empresa tem com esses valores para antecipar a dificuldade que será adotar o Scrum.

A primeira adoção do Scrum é sempre traumática. Nesse ponto, acredito que seja melhor adotar em pequenos projetos ou até mesmo dentro de um pequeno setor como experiência. A supervisão de pessoas que já adotaram a metodologia antes com sucesso é muito importante para aumentar a chance de êxito e tornar a metodologia bem vista diante toda a empresa.

The post Diferenças entre valores ágeis e tradicionais appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Gerenciar projetos mistos (com e sem a utilização de metodologia ágil) é uma realidade que aos poucos, nós estamos conseguindo mudar. Os benefícios alcançados com a utilização de métodos ágeis são bem mais visíveis e mensuráveis ao passo que projetos tocados de maneiras, digamos, “convencionais” têm se tornado mais cansativos e com menos visibilidade sobre o quanto já temos pronto e quais serão os próximos pontos a serem iniciados.

Neste percurso encontramos alguns fatores que dificultam a adoção da metodologia, desde clientes que não querem sair da zona de conforto, querendo apenas mais do mesmo, até clientes que querem sistemas prontos em 24H. Abaixo exemplifico como nós contornamos tais problemas:

Mostre que funciona – Sempre temos uma “carta na manga”, algum projeto que foi finalizado com sucesso utilizando metodologia ágil. Mostramos todos os benefícios obtidos e falamos sobre como isso pode ser útil no novo projeto proposto, afinal ele é um caso de sucesso em potencial.

Trabalhe a quatro mãos – Mantenha sempre o cliente por perto, ele sempre vai ter algo a falar sobre o projeto e os questionamentos levantados podem ser proveitosos para o projeto. Nos casos do cliente ser interno, melhor ainda.

Tudo no seu tempo – Clientes que precisam de tudo para ontem precisam saber que o fato de ficar pronto não significa que vá ficar bom. Mostre que o planejamento torna a aplicação que está sendo desenvolvida muito mais confiável. Lembre-o que durante a apresentação do sistema ele estará presente também, logo, se houver algum problema, ele também poderá sair prejudicado. Além disso é importante deixar claro que durante o processo de desenvolvimento tudo será transparente para ele.

Maurilio Junior, formado em Análise e Desenvolvimento de Sistemas, atuando como Líder de Projetos na CNseg.

The post Facilitando a adoção de metodologia ágil appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.