Muita coisa mudou desde que elicitar, levantar, analisar e fazer especificação de requisitos era a melhor forma de começar o projeto de um software. Estamos cada vez mais incorporando o mundo orgânico das jornadas de usuários, da iteração em torno do problema que se quer resolver e do progresso alimentado pelo feedback de uso real dos nossos produtos. Bem-vindo ao século XXI.
[soundcloud url=”https://api.soundcloud.com/tracks/260055892″ params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false&show_artwork=false” width=”100%” iframe=”true” /]
Sobre esse episódio
Os Métodos Ágeis vieram cheio de ideias e novas formas de criar produtos de software.
Com eles vieram as receitas: sprints, stand ups, kanbans, reviews, e muito mais. Foi suficiente?
Muitos de nós confiamos nas receitas e, de repente, nos víamos perdidos em uma incompatibilidade clara entre elas e a realidade do nosso ambiente de trabalho.
– “Aqui não conseguimos fechar o escopo por 2 semanas”
– “Nosso cliente não está presente”
– “E quando tem manutenção e desenvolvimento juntos?”
– “Temos múltiplos projetos simultâneos e uma equipe pequena. Como fazer?”
O fato é que métodos como Scrum, XP ou FDD foram criados para cenários com condições específicas. Há vários pressupostos ali que, se não observados, limitam ou inviabilizam o seu uso. É preciso olhar para o que está por trás das receitas e focar nos problemas específicos que você tem, já que os métodos podem não ter sido criados para resolver tais questões muito amarradas ao seu contexto.
Entender os conceitos que fazem os métodos serem do jeito que são é o primeiro passo para entender como adequá-los a sua realidade específica.
E um dos conceitos mais mal-compreendidos é como esses métodos abordam a questão do progresso e da evolução do desenvolvimento de um produto.
É a disputa entre o mindset do mecanismo versus o mindset do organismo.
Sem essa compreensão, seu próximo projeto será somente uma boa cascata interrompida a cada bloco de 2 semanas.
E não é isso que a gente quer, não é mesmo?
Ouça então a esse episódio do Software Zen Cast e entenda o que mudou para que você mude também a forma como vai criar seu novo produto.
Nesse episódio
– Porque elicitação e levantamento de requisitos não nos leva a boas soluções de software;
– Como esse modelo gerou um processo de desvalorização do programador e como isso foi ruim para nossa indústria;
– O resgate da importância do desenvolvedor
– As descobertas da gestão moderna de desenvolvimento de produtos
– O novo modelo: solução do problema certo em um ambiente colaborativo unido por uma meta compartilhada
– Entendendo a mudança central: Mecanismo vs Organismo