Agilize-se

 Você pode aumentar o conhecimento sobre seus usuários e cliente com o uso de Personas. Personas são perfis baseados nos usuários e clientes do produto. A criação de Personas ajuda a identificar os usuários e clientes importantes para o sucesso do projeto. Personas ajudam a melhorar o entendimento dos usuários, suas responsabilidades, suas atividades, seus problemas atuais, suas necessidades de informação e suas expectativas em relação ao produto. Este conhecimento é importante para melhorar a comunicação e o entendimento dos usuários e também a tomada de decisão sobre o projeto. Além disso, ajuda muito a otimizar as funcionalidades do produto  para cada perfil, garantindo que as necessidades, problemas e expectativas de cada perfil sejam atendidas. As personas do produto devem ser identificadas logo no início do projeto a fim de as informações e conhecimento obtidos a respeito das personas possam direcionar e orientar todo o trabalho que será feito durante o projeto. Toda Per...

  Historias do usuário são descrições simples, curtas e objetivas de funcionalidades esperados no software pelo usuário. As Histórias do usuário são escritas pelo Product Owner em linguagem de negócio e devem ser uma breve descrição de uma necessidade do cliente. É importante deixar claro que uma história do usuário não é uma especificação de software e nem tem a intenção de descrever em detalhes aspectos relacionados com a tecnologia usada para construção do software. Aspectos técnicos não devem ser escritos em uma história do usuário, apenas descrições em alto nível em linguagem de negócio e que descrevam brevemente a funcionalidade. Apesar de serem uma breve descrição de funcionalidades esperadas, as histórias do usuário devem ter informações suficientes para que seja possível validar se foram atendidas. Toda história de usuário deve ter critérios de aceite bem definidos. Os critérios de aceite são validações, regras e críticas que deve ser atendidas para que se possa considerar...

  Quando falamos em desenvolvimento de software todo trabalho iniciado e não concluído deve ser considerado um desperdício e deve ser evitado. "Pare de começar a comece a terminar". Sterling Mortensen. A idéia é parar de começar trabalhos que nunca são concluídos, que nunca são entregues ao usuário, e concluir o que foi iniciado, entregando ao usuário algo que agrega valor para o negócio. Quando a equipe está sobrecarregada, atuando em muitas frentes, a produtividade é afetada, a qualidade também pois a mudança de contexto, quando a pessoa muda de tarefa, compromete o foco no trabalho e os erros começam a aparecer e o trabalho nunca é concluído pois o retrabalho é constante e a falta de foco não permite que a pessoa se concentre, se dedique integralmente a uma tarefa para que possa concluí-la no prazo. Segundo a chamada "Lei de Little" existe uma relação diretamente proporcional entre o trabalho em progresso e o tempo para concluir o trabalho. Ou seja, quando mais t...

  Quando falamos de métodos ágeis, o planejamento pode ser feito feito de forma iterativa ou fluxo contínuo. O planejamento feito com iterações permite que as atividades do projeto sejam estruturadas de acordo com o andamento do projeto.  No planejamento do projeto são definidas releases que determinam as entregas do projeto. Cada release, por sua vez, é dividida em uma ou mais iterações que são ciclos curtos de trabalho, onde ao final de cada iteração, a equipe produz algo de valor para o negócio. Em alguns projetos, pode ser necessário várias iterações em uma release antes de se realizar uma entrega com valor para As iterações são chamadas de Sprint no Scrum e tem duração de uma semana a um mês, o que vai depender de cada organização e da complexidade do projeto. Em geral uma iteração deve ser o mais curta possível de forma a permitir que a equipe produza algo de valor para o negócio. Essa abordagem ajuda a equipe a acelerar naturalmente ao longo do projeto. Em toda Sprint é...

  Um dos principais problemas no desenvolvimento de software é o levantamento prematuro de requisitos que é muito comum em processos de desenvolvimento em cascata. Ao se tentar fazer todo o levantamento das necessidades do sistema, no início do projeto, de uma só vez, acabamos por adiar por tempo demais a construção do software, para só depois, após ter o entendimento completo de todas as necessidades do usuário, requisitos funcionais e regras de negócio, dar prosseguimento as demais tarefas do projeto. Esta abordagem gera um desperdício de tempo e recursos pois ao se tentar definir todos os requisitos no início do projeto, de uma única vez, se consome muito tempo e quando o desenvolvimento enfim é iniciado pode acontecer de os requisitos já terem mudado ou não serem mais necessários. Este é o pior tipo de desperdício, quando tudo o que se construiu não atende ao cliente pois a necessidade mudou ou ainda não é mais necessário. Um dos benefícios dos métodos ágeis é que eles usam o p...