Desafios do Desenvolvimento Ágil para o Governo
•Transferir como PPTX, PDF•
1 gostou•595 visualizações
O documento discute princípios e desafios dos métodos ágeis de desenvolvimento de software, enfatizando a importância da colaboração com o cliente, adaptação às mudanças e valorização de indivíduos e interações sobre processos e ferramentas.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Desafios do Desenvolvimento Ágil para o Governo
Semelhante a Desafios do Desenvolvimento Ágil para o Governo (20)
Mais de Stéfano H. dos Santos
Desafios do Desenvolvimento Ágil para o Governo
- 2. WWW.DIGITHOBRASIL.COM.BR MANIFESTO ÁGIL Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano
- 3. WWW.DIGITHOBRASIL.COM.BR MANIFESTO ÁGIL Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano
- 4. WWW.DIGITHOBRASIL.COM.BR QUEM SERÁ O PRODUCT OWNER? PROBLEMAS » Não PODEM se comprometer » Não QUEREM se comprometer
- 5. WWW.DIGITHOBRASIL.COM.BR QUEM SERÁ O PRODUCT OWNER? AÇÕES » Colaborador da empresa » P.O. mergulhado no ambiente do cliente » Tornando-se o próprio cliente » Nosso jeito de trabalhar
- 6. WWW.DIGITHOBRASIL.COM.BR PODER » Informação centralizada » Acesso limitado aos usuários » Informações insuficientes » Falso feedback PROBLEMAS
- 8. WWW.DIGITHOBRASIL.COM.BR PODER » Apoio da organização » Habilidade de negociação do time » Mapeamento do cliente AÇÕES
- 9. WWW.DIGITHOBRASIL.COM.BR O CLIENTE NEM SEMPRE SABE O QUE PRECISA! PROBLEMAS
- 10. WWW.DIGITHOBRASIL.COM.BR O CLIENTE NEM SEMPRE SABE O QUE PRECISA! Estou falando de conhecimento: » Legislação » Conceitos PROBLEMAS » Risco ao projeto
- 11. WWW.DIGITHOBRASIL.COM.BR O CLIENTE NEM SEMPRE SABE O QUE PRECISA! Estou falando de conhecimento: » Legislação » Conceitos » Time sobrecarregado PROBLEMAS
- 12. WWW.DIGITHOBRASIL.COM.BR O CLIENTE NEM SEMPRE SABE O QUE PRECISA! Apoio da organização: » Treinamentos » Consultorias AÇÕES
- 13. WWW.DIGITHOBRASIL.COM.BR RESISTÊNCIA NO USO DO SOFTWARE » Pouco interesse » Hábitos antigos » Input de dados históricos » Falta de feedback Não uso!!! PROBLEMAS
- 14. WWW.DIGITHOBRASIL.COM.BR RESISTÊNCIA NO USO DO SOFTWARE » Acompanhamento do uso (Analytics) » Análise dos casos » Suporte no input de dados históricos » Usuários na Sprint Review AÇÕES Não uso!!!
- 17. WWW.DIGITHOBRASIL.COM.BR O que nossos clientes estão falando?
- 18. WWW.DIGITHOBRASIL.COM.BR “Considero muito importante minha participação nesse processo de construção do sistema. Assim podemos ajustá-lo de acordo com as necessidades.” “Nossa participação nas reuniões permite a rápida detecção de possíveis problemas e percebemos que nossas solicitações são rapidamente atendidas.” “O constante contato com os desenvolvedores permite agilizar a compreensão deles sobre o nosso negócio. Isso nos dá mais segurança de que o sistema está sendo corretamente construído.” “O sistema está permitindo maior transparência das informações, garantindo que todos os interessados tenham um acesso pronto e fácil. Podemos trabalhar de forma preventiva, garantindo que erros sejam detectados antes de se tornarem um problema.” “Estar presente nas reuniões é ótimo. É o momento de revisar o trabalho realizado, sugerindo correções sempre que necessário.”
- 19. WWW.DIGITHOBRASIL.COM.BR NÃO USE MÉTODOS ÁGEIS!
Notas do Editor
- Há aproximadamente 3 anos começamos a trabalhar com agilidade em todos os projetos para nossos clientes.E entre nossos clientes, está o governo.Justamente por isso, submeti este relato, para compartilhar um pouco da nossa experiência trabalhando com desenvolvimento ágil para o governo. Focando nos desafios impostos pelo comportamento desse cliente e as ações que tomamos para superá-los.Então, eu não vou falar sobre lei de contratação ou licitação. Até porque eu não tenho conhecimento sobre isso.
- Para começar, vou resgatar os valores do manifesto ágil.Quando nós trabalhamos com agilidade, procuramos seguir alguns princípios e passamos a valorizar algumas coisas.E quando trabalhamos com desenvolvimento ágil para o governo, esses valores são colocados à prova, devido a algumas peculiaridades desse embiente.
- Mais especificamentedois deles: Colaboração com o Cliente e Responder a Mudanças. E quem é ágil, não abre mão de trabalhar seguindo esses valores.Vocês acham que é possível ser ágil desconsiderando esses valores? Acho que não né!?E é justamente aqui que se concentram nossos problemas.
- Nosso primeiro desafio apareceu logo no primeiro projeto, na formação do time.Utilizamos Scrum e precisamos de um SM, uma equipe de desenvolvimento e de um PO. Tinhamos o SM e a equipe de desenvolvimento e precisávamos de um PO. Idealmente, se pararmos pra pensar, ninguém melhor do que o dono do produto para fazer o papel de Dono do Produto.Mas nós não conseguimos engajar uma pessoa do cliente para exercer esse papel. E isso acontece por um desses dois motivos: Porque Não podem se comprometer ou porque não querem se comprometer.
- Para contornar esse problema só tivemos uma alternativa, convidar um colaborador da empresa para exercer esse papel.Nessa forma de trabalho, esse PO tem que mergulhar no ambiente do cliente, a fim de entender seu negócio para poder priorizar o backlog corretamente maximizando o ROI. E deu tão certo que este se tornou nosso jeito de trabalhar. Em todos os nossos projetos, trabalhamos assim.Bom, agora que temos um time completo, precisamos dominar o negócio do cliente, para ter as informações suficientes para começar a escrever as estórias de usuário e iniciar o desenvolvimento.
- Mas ao visitar o cliente, nos deparamos com uma força que atua fortemente nesse ambiente. O Poder. Em nossos clientes, quem está na posição de gestor, coordenador ou chefe não abre mão desse poder. E infelizmente esse comportamento nos atrapalha. Nos atrapalha porque há uma centralização da informação por aqueles que tem o poder, que nos limita o acesso aos outros usuários que possuem informações importantíssimas. Isso faz com que não tenhamos as informações suficientes para o trabalho e pior, podemos receber um falso feedback.Em um dos projetos que trabalhamos, nós passamos o projeto todo colaborando com o cliente, fazendo pequenas entregas, recebendo feedbacks e etc, como manda o figurino. Quando chegou no final do projeto, o que aconteceu?
- Isso porque, devido a essa centralização da informação, não envolveu a participação de outras pessoas que também faziam parte daquele processo de trabalho.Mas por sorte conseguimos fazer as correções necessarias.
- Para resolver, ou amenizar, esse problema, o apoio da empresa, dos diretores e gestores, abrindo os caminhos foi fundamental. A habilidade de negociação do time, principalmente do PO, que negocia muito com o cliente, também é muito importante. Outra ação interessante foi o mapeamento dos do cliente. Um de nossos POs, fez um mapeamento do cliente no quadro Scrum, mostrando os departamentos, as coordenadorias, a hierarquia existente e outras informações que são importantes para que o restante do time soubesse quais departamentos estavam envolvidos no processo. Recentemente eu li também no blog ScrumEx um post muito interessante sobre isso, que mostra uma maneira bem prática e completa de fazer isso. Vale a pena conferir. Se quiserem, depois eu passo o link.
- Quando conseguimos ter acesso a todos os usuários, e esperávamos conseguir as informações que precisávamos, nos deparamos com outro problema. O cliente nem sempre sabe o que precisa. Mas aí você pode dizer. Mas isso eu já sabia. É assim todo lugar, por isso eles nos contratam. E eu concordo.
- Mas eu estou falando de conhecimento. Muitas vezes o cliente não conhece, a legislação (que não são poucas) e os conceitos envolvidos. E isso significa risco ao projeto, pois se fizermos algo em desconformidade com a legislação, podemos ter problemas.
- E quando isso acontece quem absorve essa carga? O time! E nesse momento temos que tomar cuidado, pois o time pode ser levado a exaustão. Tendo que estudar, além da parte técnica, que quem não abre mão da qualidade sabe que não é fácil, assumir também essa carga para fazer um software que realmente seja útil e correto para o cliente.
- Infelizmente não conseguimos resolver definitivamente esse problema, mas conseguimos minimizar. Pra isso, o apoio da organização é fundamental e sempre que necessário disponibiliza treinamentos e concultorias nos assuntos relacionadas ao negócio do cliente. E isso faz com que essa carga seja menor, o aprendizado mais rápido e confiável.E por fim, agora que temos um time completo, acesso a todos os usuários, informações para construir os primeiros incrementos, o que acontece?
- Muitos usuários simplesmente não usam o software. Não usam por uma série de motivos, por falta de interesse, devido a hábitos antigos e também devido ao input de dados. Mas para nós, o pior é que por consequência, não temos feedback daqueles que realmente usam, ou deveriam usar.
- Trouxemos os usuários para a Sprint Review. Não somente os gestores, mas principalmente os usuários finais. Quando tiramos um servidor de seu ambiente de trabalho e trazemos ele para um ambiente onde ele pode e deve opinar, opinar sobre o processo, sobre o software e etc, ele valoriza isso. E quando ele percebe que suas solicitações e sugestões estão implementadas no software em apenas duas semandas, nós ganhamos um colaborador. Ele passa a usar porque passa a ser parte do software que está sendo construído. Perdi as contas de quantas vezes vi os usuários sorrindo por ver aquilo que ele sugeriu fazendo parte do sistema. Os usuários desse ambiente sentem falta disso, pois geralmente não não consultados pra nada. E quando tem a oportunidade, dão valor.
- Percebam que os problemas que passamos não estão relacionados a parte técnica ou à tecnologia, nem mesmo diretamente ligados a contratos ou a essa parte burocrática. Estão todos reacionados a comportamentos que há nesse ambiente. E fazendo mudanças no nosso jeito de trabalhar, conseguimos causar mudanças no cliente, nos usuários. Possibilitando a aplicação da agilidade em projetos de software para o governo.
- Então sim, é possível!
- Para responder essas pergundas, especialmente para o Agile Brazil, eu conversei com alguns usuários e trouxe alguns desses depoimentos pra cá
- Isso mostra que mesmo não conhecendo agilidade, Scrum ou seja lá o que for, os clientes valorizam essa forma de trabalhar e o que estamos entregando.E pra finalizar, gostaria de dar um CONSELHO a vocês. Já que estamos no maior evento sobre agilidade da américa latina...
- Presentation slide for courses, classes, lectures et al.
- Presentation slide for courses, classes, lectures et al.
- Presentation slide for courses, classes, lectures et al.