fev 142014
 

Neste post fiz uma coletânea dos principais questionamentos que identificam se fazemos ou não uma boa administração do tempo.   Claro que não funcionamos como robôs e imprevistos acontecem, fazendo com  que em alguns momentos não consigamos aplicar os principais fundamentos da administração, mas o importante a ter em mente é que este questionário nos auxilia a identificar alguns dos “ladrões do tempo”.

Responda, reflita e você identificará com facilidade onde a resposta “ideal” é Sim ou Não: Continue reading »

fev 102014
 

Há 2 tipos de backlog no Scrum, que são semelhantes em estrutura, mas tem propósitos e níveis de detalhamento diferentes:

  • Product Backlog
  • Sprint Backlog

O Product Backlog lista os requisitos para o projeto priorizados de acordo com o valor entregue para o cliente; este backlog é gerenciado pelo Product Owner, e é atualizado ao longo do projeto, à medida que os requisitos são descobertos e refinados. Deve conter informações suficientes para que o time consiga realizar estimativas de desenvolvimento.

No início de cada iteração (sprint), o time revisa o Product Backlog de acordo com a priorização e identifica as estórias de maior prioridade que possam ser trabalhadas naquela iteração. Estas estórias passam a compor o Sprint Backlog para a iteração em questão.

O Sprint Backlog é gerenciado pelo time do projeto e deve conter uma lista detalhada de todas as tarefas que o time precisa completar, relativas a cada estória contida na sprint.

Portanto, enquanto o Product Backlog é criado uma vez e atualizado ao longo do projeto, um novo Sprint Backlog é criado ao início de cada iteração; e enquanto o Product Backlog é tipicamente atualizado semanalmente, o Sprint Backlog é revisado e atualizado diariamente.

 

[ Este post é parte de uma série de perguntas frequentes sobre assuntos relacionados a AGILE. Para pesquisar as demais perguntas já respondidas aqui no blog da OAT, busque pela tag AGILEFAQ  e para submeter uma pergunta, envie a sua questão para o email agile@oatsolutions.com.br ]

jan 162014
 

Olá pessoal! No post anterior, falamos sobre o ALM, suas origens e como vem sendo utilizado como ferramenta de produtividade em ambientes ágeis de desenvolvimento de software. Seguindo nessa vertente, nosso tema de hoje propõe a junção dos dois modelos, fazendo com que os conceitos do Agile e do ALM tradicional se encontrem.

Vale reforçar um fator muito importante antes de esmiuçarmos melhor as características de um ALM: por si só, esse tipo de ferramenta já embute uma série de premissas que se acoplam perfeitamente aos princípios do Agile!

Mas como isso ocorre? Simples! Apeguemos-nos ao que é comum aos dois: tanto o Agile, como o ALM, pregam o uso da colaboração, integração contínua, comunicação e melhoria contínua dos seus processos como princípios básicos de funcionamento de ambos. Assim, quando adicionamos ao ALM tradicional um conjunto de valores e estratégias ágeis, fazemos com a ferramenta passe a ter foco na interação humana (“peopleware”), aumentando assim seu poder de comunicação.

Continue reading »

jan 142014
 

LEAN não é apenas um conjunto de ferramentas e técnicas que podem ser aprendidas a partir de sessões de treinamento ou de certificação e, em seguida, implementado em uma organização para obter os resultados finais, portanto a implantação do LEAN  é abordada de diversas maneiras em diferentes tipos e tamanhos de organizações.

LEAN é uma cultura que tem de ser desenvolvida ao longo do  tempo.  O sistema de qualidade próprio da organização tem que ser praticado, padronizado e continuamente melhorado com os processos estáveis, verificados e validados para satisfazer as necessidades dos clientes, e a organização deve dar prioridade ao valor, como ele é definido pelo cliente.

Continue reading »

jan 132014
 

Se a resposta imediata para a pergunta acima for “no código fonte”, ou “nas minhas procedures” ou ainda “na cabeça do ‘querido usuário’ “, esse é um mal começo!
Ao menos, se serve de consolo, você não está sozinho: a maioria dos profissionais de TI (e dos departamentos de TI) desconhecem as regras de negócio dos processos aos quais atendem, ou não as tem declaradas de modo explícito/documentadas formalmente.

Continue reading »

jan 102014
 
Quadrante Mágico do Gartner - Ferramentas de ALM

Desde que o Manifesto para o desenvolvimento ágil de software foi apresentado para a comunidade em meados de 2001, um dos valores mais propagados tem sido a comunicação entre as equipes de projeto, afirmando que devemos privilegiar “Indivíduos e interação mais que processos e ferramentas”. Esse valor ágil provocou uma revolução junto às práticas de comunicação das equipes de desenvolvimento, trazendo para aos times menos formalismos e maior direcionamento às práticas interativas, aproximando o universo de desenvolvedores e clientes.

Continue reading »

jan 082014
 
É fato que Requisitos bem definidos dependem fortemente das técnicas empregadas durante as atividades de levantamento; por esta razão o Analista de Negócios (ou de Requisitos) deve possuir sólidos conhecimentos em diferentes técnicas que enriquecem a qualidade dos requisitos identificados, bem como aumentam a eficiência do processo de levantamento.
Neste post serão abordados alguns dos aspectos relacionados à qualidade dos Requisitos, com foco na forma de escrita dos mesmos.
dez 262013
 

Como citei no post anterior, uma das principais dicas para uma melhor administração do tempo, é saber a hora e como delegar tarefas.     Muitas vezes desperdiçamos nosso tempo assumindo cada vez mais tarefas que podem e devem ser delegadas/compartilhadas com outras pessoas, simplesmente por achar  que é mais rápido e fácil fazer sozinho.  As principais preocupações geralmente são;  o tempo necessário para detalhar a tarefa e o possível tempo extra gasto nas eventuais correções.   Deve ser avaliado que o “tempo gasto” na delegação de uma atividade pode e deverá se transformar no curto prazo em muito mais tempo livre para a realização de tarefas importantes que só podem ser realizadas pelo delegante. Continue reading »

dez 202013
 
Essa é uma frase muito repetida ultimamente, principalmente em meio a conversas sobre metodologias ágeis x formais, ou sobre abordagens de levantamento e modelagem de sistemas;  justamente por ser uma frase tão repetida e pelo fato do RUP (Rational Unified Process) ser tão conhecido e utilizado, valem algumas reflexões.
dez 182013
 
Já não é de hoje que a área de TI tenta superar suas deficiências com soluções “mágicas”.
Considerando que a documentação dos sistemas em tempo de projeto/modelagem é quase sempre negligenciada, mas que mesmo assim os sistemas são implantados(!), a “retrodocumentação” é muitas vezes necessária, principalmente quando os sistemas em questão são críticos para a empresa (o que leva à reflexão constante dos motivos pelos quais o sistema foi implantado sem documentação…mas isso é conversa pra outro post). Continue reading »