Início Clientes e Requisitos no InfoQ Brasil
Notícias
Feed RSS-
Como ter foco no cliente com equipes autônomas
As organizações tradicionais estão sofrendo com as formas ineficazes de trabalhar que não permitem que as pessoas colaborem de maneira estruturada. As empresas precisam encontrar formas de capacitar as equipes autônomas e multifuncionais, capazes de fornecerem produtos e serviços com o impacto esperado mais rapidamente, disse Mia Kolmodin, fundadora da Dandy People.
-
O cliente não está sempre certo, e nem você
Na recente conferência Agile 2018, Natalie Warnert proferiu uma palestra intitulada "O cliente não está sempre certo, e nem você!", a qual abordou conceitos instigantes sobre como ter certeza de estarmos construindo a coisa certa. Apresentou três armadilhas nas quais as equipes se encaixam - cliente incorreto, solução prematura e afogamento em informações, além de conselhos sobre como evitá-los.
-
Diferentes perspectivas sobre o Mínimo Produto Viável
Há um entendimento comum entre as organizações adeptas do desenvolvimento ágil, é necessário desenvolver produtos que sejam "bons o bastante". Scott Sehlhorst explica as diferentes perspectivas de "bom o bastante".
-
Documentação na agilidade: quanto e quando escrevê-la?
Os valores do manifesto para o desenvolvimento ágil de software "software em funcionamento ao invés de documentação abrangente". Esse valor primário da agilidade nos questiona sobre "quanto" e "quais" tipos de documentos são necessários e "quando" eles devem ser escritos.
-
Reduza o desperdício através da mudança do método cascata para método ágil
O desenvolvimento de software enxuto diz: toda iniciativa que não está criando valor para o cliente é considerado desperdício. Como a transição do método cascata para um método ágil pode ajudar as empresas a reduzir o desperdício?
-
Agilidade solitária: tornando-se Agile antes da própria equipe
É comum que organizações realizem uma transformação ágil que atinge toda uma equipe ou departamento. Mas existem profissionais que começam a utilizar práticas ágeis individualmente, ou que trabalham de forma ágil em equipes de apenas uma pessoa. Como essas pessoas podem adotar práticas ágeis e quais os tipos de benefícios que podem obter com isso?
-
A flexibilidade do Agile: ponto forte ou calcanhar de Aquiles?
Será que o princípio "responder a mudanças mais do que seguir um plano" é um ponto forte ou uma flexibilidade que não funciona na prática? O que acontece com projetos ágeis com dificuldades em gerenciar mudanças e clientes esperando flexibilidade demais? Será que o Agile não cumpre suas promessas, ou é a forma que as equipes e organizações têm adotado o Agile que causa os problemas?
-
Valor de negócio: como priorizar o backlog e o que ele realmente significa
Ron Jeffries, um dos três fundadores do Extreme Programming (XP), esclarece qual é o verdadeiro valor para uma empresa, auxiliando a priorização correta do backlog de desenvolvimento de um produto.
-
Dominando os Requisitos Não-funcionais
É comum em equipes ágeis que haja dificuldades em estimar e especificar requisitos não-funcionais, como escalabilidade, interoperabilidade, facilidade de manutenção, desempenho, portabilidade e segurança. Em posts e artigos recentes, especialistas apresentam recomendações e boas práticas para lidar com esses requisitos em projetos ágeis.
-
Estimativa de tempo e custo realmente funcionam?
Sempre houve um grande dilema entre a estimativa de prazo e de dinheiro que envolve um projeto de TI, reclamações por ambas as partes cliente/desenvolvedores justificando que tal análise ou estimativa não era exata(bem, uma estimativa já não é exata por definição) também é algo frequente. Porém será que métodos como APF não podem ajudar quando o assunto é gerar uma estimativa?
-
Será que os Casos de Uso tem lugar no SCRUM ?
No Scrum, os requisitos são normalmente chamados de user stories. Mas seria CERTO utilizar casos de uso com Scrum? E, em caso afirmativo, sob que circunstância você deveria fazer esse uso?
-
Quem quer esta User Story?
Em algumas user stories podemos definir facilmente que são os beneficiados. Mas como cumprir o modelo padrão "Como ... Eu quero ..." se não podemos expressar quem quer aquela tarefa pronta?
-
Como o Product Owner deveria participar das sessões de Planning Poker?
Em uma discussão recente na lista do Scrum Development, Tri Nguyen perguntou se os products owners devem participar da reunião de planning poker. Existe um consenso geral sobre isso?
-
User Manifesto - Uma extensão do manifesto ágil
Em seu site, Alistair Cockburn propôs a criação de uma extensão para o Manifesto Ágil, voltada para o usuário / cliente, a partir de um discussão na cidade de Salt Lake junto com Jeff Patton, que em conjunto com outras pessoas iniciaram este trabalho. O trabalho é ainda preliminar, mas já foram criadas quatro opções, que são basicamente as mesmas, mas dispostas de maneira diferente.
-
Tratando Requisitos Não-Funcionais em Scrum
Requisitos não-funcionais descrevem qualidades do sistema ao invés de seus comportamentos. Scott Ambler causou muita discussão quando ele recentemente declarou "O conceito de product backlog do Scrum funciona bem para requisitos funcionais simples, mas... se torna insuficiente para requisitos não-funcionais e restrições de arquitetura." em um artigo no Dr. Dobb's Portal.