sábado, 25 de junho de 2011

Quando Analista de Negócios não faz o seu Papel

teatro 

Uma das grandes causas de fracasso de um projeto é a péssima analise do negócio. Isso acontece quando analista de negócios não faz o seu papel de facilitador entre o cliente e a equipe.

Não estou afirmando que analista de negócios deve saber tudo sobre o negócio. Mas procurar o cliente e as partes interessadas para aprender sobre o negócio e elaborar os requisitos do cliente, são processos que fazem parte do seu trabalho. Mantendo uma comunicação freqüente entre o cliente, as partes interessadas e a equipe.

Geralmente, o fracasso da analise do negócio é causada pela pouca comunicação com o cliente, as partes interessadas e a equipe. Conseqüentemente, analista de negócios acaba levantando requisitos sem valor para desenvolvimento do produto, frustrando o cliente com produto sem valor e a equipe pelo fracasso do projeto. Situação lamentável que leva ao retrabalho e a possível demissão do analista de negócios.

Ta-ta for now

Dependência e Comunicação Fraca em um Projeto

mãos

Era uma vez um grande projeto feito com base na cultura cascata. Esse projeto era composto por vários módulos como cadastro, vendas, compras, estoque, contabilidade, financeiro e outros. Existiam várias equipes e conseqüentemente pessoas trabalhando nele, mas muitas pessoas em um projeto nem sempre é a solução, pois a dependência com o cadastro era um grande gargalo que atrasava os demais módulos e a comunicação era extremamente fraca.

Saliento também que existia dependência entre os demais módulos, mas nada era comunicado e o ambiente não era informativo. Para ajudar a equipe de teste era totalmente isolada das demais equipes e ficava sem caso de uso para testar. Cenário lamentável.

Se projeto fosse feito usando a cultura ágil grande parte dos problemas seriam resolvidos. O módulo de cadastro teria maior prioridade de conclusão com mais de uma equipe trabalhando no módulo. As entregas seriam por iterações com aplicação de reuniões diárias curtas, boas práticas de engenharia de software, boa comunicação, ambiente informativo e cada equipe composta por um testador. Com certeza, já no módulo cadastro alguns requisitos seriam eliminados por não agregar valor, claro com a participação ativa do cliente em todas as iterações necessárias para o projeto.

Após a conclusão do módulo cadastro, as equipes poderiam trabalhar nos demais módulos, sem o caos da dependência com o cadastro e as demais dependências mapeadas e informadas.

Ta-ta for now

quinta-feira, 23 de junho de 2011

Ser Rejeitado e Continuar Amando o que Faz

reject

Assisti novamente o discurso de colação de Grau em Stanford - 2005, realizado por Steve Jobs. Nesse discurso ele contou três histórias de sua vida, e uma chamou bastante atenção: "Eu fui rejeitado, mas continuava amando."

Steve Jobs foi o criador do Macintosh na garagem dos pais, que deu origem Apple. Porém Steve Jobs foi demitido da Apple por divergências com um funcionário qualificado, contratado com a finalidade de impulsionar o crescimento da empresa.

Analisei a rejeição e conclui que ela tem um lado bom, acredite em mim. Steve Jobs e outros profissionais tiverem que recomeçar após rejeição. O que estimula a busca do conhecimento, a persistência, a criatividade e a inovação.

No caso de Steve Jobs impulsionou a criar a NeXT e a Pixar. E também encontrou amor de sua vida.

Steve Jobs voltou novamente para Apple, e hoje os cobiçados IPhone, IPad e Macbook são frutos da inovação dele e de colaboradores.

Por isso sempre persista. E busque o conhecimento para inovar e colher bons frutos.

Fonte:

“Steve Jobs - Discurso de colação de Grau em Stanford, 2005.”:

http://www.youtube.com/watch?v=rPIFP6_cimQ

Ta-ta for now

domingo, 19 de junho de 2011

A Cultura de Equipe Começa na Família

baby

A família é a primeira equipe de uma criança, não importando o tamanho ou a composição da família. Uma criança vai aprender  valores, princípios, auto-organização e socialização no dia a dia da família. E cabe a família estimular o espírito de equipe na criança, através de brincadeiras e jogos e, trabalhar a idéia que todos os membros da equipe são responsáveis pelo fracasso ou sucesso da equipe. Um bom exemplo de auto-organização estimulado pela família é quando uma criança é estimulada a guarda seus brinquedos em um organizador após brincar.

A fase da escolinha é que fornece a primeira convivência da criança com outras fora do ambiente familiar e, ajuda na formação do espírito em equipe. A criança começa a ouvir a opinião de outras e também opinar, sendo a primeira socialização fora de casa. As professoras da escolinha podem trabalhar o espírito de equipe nas crianças através aplicações de jogos e brincadeiras coletivas.

Já no ensino fundamental, médio e faculdade predomina o trabalho em grupo para infelicidade da formação do estudante. No trabalho em grupo, cada integrante pega um pedaço do trabalho, sem interação e sem colaboração entre os alunos. Para estimular o trabalho em equipe entre os alunos, cabe aos mestres incentivarem a colaboração e interação entre os alunos e assim formarem futuros integrantes de equipes.

segunda-feira, 13 de junho de 2011

Como Remover Desperdícios no Produto Backlog?

waste

Desperdícios consomem recursos valiosos e tiram o foco no que é importante. Para remover os desperdícios no produto backlog são necessários os seguintes passos:

  • Reduzir o inventário no produto backlog: Minimizar a quantidade de itens detalhados no produto backlog e incluir apenas itens que são essenciais para criar um produto de sucesso;
  • Evitar o excesso de produção: Focar nas funcionalidades mínimas necessárias para trazer vida ao produto, criando assim um produto valioso para cliente;
  • Minimizar os defeitos, transferências e criatividades não utilizadas através do envolvimento dos membros da equipe e das partes interessadas no preparo do produto backlog. Isso ajuda descobrir e descrever itens do backlog, evitando a entrega de requisitos sem valor para o produto do cliente. E também garante a clareza dos requisitos, reduzindo assim os defeitos, aproveitando a criatividade e os conhecimentos dos integrantes da equipe e das partes interessadas. Além de priorizar o produto backlog e assegurar que os riscos técnicos e as dependências são contabilizados.

Fonte:

“THE LEAN PRODUCT BACKLOG – ELIMINATE WASTE:”

http://www.romanpichler.com/blog/lean-and-kanban/the-lean-product-backlog-eliminate-waste/

Ta-ta for now

sábado, 11 de junho de 2011

Propriedades do Kanban

Propriedades do Kanban:

  • Físico: É um cartão físico;
  • WIP: Limita o trabalho em processo e impede a superprodução;
  • Fluxo Contínuo: Informa a necessidade de produção antes que cliente esteja sem estoque;
  • Pull: Fluxo puxado;
  • Auto-organização;
  • Visual: Mostra o estado atual do processo de forma visual;
  • Sinal: O estado visual sinaliza as ações no processo;
  • Kaizen: A visualização do fluxo do processo estimula a melhoria continua;
  • Anexado: Ele está ligado e se move com as partes físicas fornecidas.

Fonte:

“Kanban Applied to Software Development: from Agile to Lean”

by Kenji Hiranabe:

http://www.infoq.com/articles/hiranabe-lean-agile-kanban

Ta-ta for now

segunda-feira, 6 de junho de 2011

Vaga para SOFTWARE DEVELOPMENT ENGINEER IN TEST na Microsoft

A Microsoft esta contratando Software Development Engineer in Test, para o time de localização de ERP. O local de trabalho é em São Paulo, SP. Email para mais informações aos cuidados de Daniela Lemos: daniela.lemos@talengy.com.br

Job Description

SOFTWARE DEVELOPMENT ENGINEER IN TEST

Global Financials Management (GFM)

Company Description:

Microsoft

www.microsoft.com

Founded in 1975, Microsoft (Nasdaq “MSFT”) is the worldwide leader in software, services and solutions that help people and businesses realize their full potential.

Reporting Relationships:

Senior Test Lead.

Location:

São Paulo, SP - Brazil

About the Position:

Microsoft is making a huge R&D investment in Enterprise Resource Planning (ERP) applications business. Along with the functional expansion in depth and breadth of the Business Applications, Microsoft Dynamics is taking the ERP Business globally in order to compete and win in the major and strategic Markets around the globe. To succeed in this mission, we must take our testing to new levels. If you’re a highly motivated individual who is eager to make an impact on quality and how we scale our testing efforts for business applications, we have a role for you on the Dynamics AX team.

GFM LATAM team is responsible for delivering local legal requirements for Latin America and also driving Dynamics AX to become a top-notch competitor in the Region. We are looking for a motivated, customer focused, technical and accountable individual that will drive feature set testing; participate in test automation and engage with customers and partners to ship a great product.

Job Summary:

The ideal candidate will have business knowledge, programming skills, a passion for creating quality software, and solid collaboration skills to ensure that high quality processes and products are created. If you love technical challenge, like to work in an environment where managers recognize and promote potential; have tester’s skill and instinct but also want to utilize your programming skills and debugging skills, then this job is for you.

As SDET (Software Development Engineer in Test), your key responsibilities will include:

  • Define test strategies for new features
  • Write test design specifications for testing automation
  • Implement test automation seeking for the best balance between scenario priorities, coverage and test run window.
  • Implement higher level business abstraction testing API’s
  • Participate in functional specification and design documents review to influence and ensure testability and high quality features
  • Execute automated and manual tests and analyze the results
  • Analyze, debug, and report defects and then verify fixed defects by creating regression test cases

Skills & Expertise Requirements:

  • Excellent technical skills, attention to detail, strong debugging and problem solving skills;
  • Bachelor degree or higher in CS, CIS, MIS or similar field, or at least 3 years of equivalent work experience;
  • Ability to write production-quality code in either C# or C++ or similar language;
  • Strong cross-group collaboration and communication skills;
  • Self-driven and ability to work with minimal direction;
  • Show strong initiative, willingness to learn, quickly fill in personal experience gaps, and should strive to become a domain expert;
  • ERP functional knowledge and prior experience with test automation is a plus.

Ta-ta for now