quinta-feira, 9 de fevereiro de 2012

Pra que serve o analista de negócios?

Quem já trabalhou em um projeto complexo e demorado de desenvolvimento de software sabe que o envolvimento de um analista de negócios pode significar a diferença entre o sucesso e o fracasso de um projeto.

De um modo geral, a maioria dos analistas de negócio possui os requisitos e a competência como principal linha de conduta em sua apresentação e abordagem. Se você acredita que para que um projeto de software tenha sucesso ou fracasso com base na qualidade dos requisitos, então você também deve acreditar que para esses mesmos projetos a base é ter em seu cenário o analista de negócios.

Todos concordam sobre a importância do papel do analista de negócios, mas poucos sabem exatamente o que eles fazem qual o seu papel. Em síntese: são responsáveis pela comunicação e colaboração entre a área de negócios e a TI, tendo como um de seus principais atributos a responsabilidade de agir como um canal entre as partes e a equipe.

No intuito de entender melhor o mundo dos analistas de negócio, a http://requirementssolutions.com/ realizou uma pesquisa global a fim de identificar quais são as principais atribuições de um analista de negócios e considerando que o tempo integral de um profissional desse gabarito corresponde a um “mix” de atividades apurou que: Gerenciar requisitos (70%), Elaborar casos de uso (55%), Remodelar/redesenhar os processos de negócio (50%) e Desenvolver protótipos/telas da aplicação (40%) fazem parte de um único dia de trabalho, e concluem que, 100% do dia não é suficiente para executar suas principais atividades. (Entrevista realizada com 1700 profissionais)

Muito se enganam os que pensam que nas metodologias ágeis o analista de negócios deixou de existir, na verdade, fundamentalmente as atividades por eles exercidas são mais variadas, ou seja, o quadro de atribuição cresce e ao mesmo tempo diversifica (tema que abordarei em outro post), mas o objetivo crucial desse elemento sempre será melhorar a comunicação entre desenvolvedores, arquitetos de sistemas e participantes do projeto. Tradicionalistas consideram que a atuação de um analista de negócios independe do método (ágil ou tradicional), é imprescindível, e afirmam que sua presença é a garantia do sucesso e no caso de ausência o fracasso do projeto.

Outros estudos comprovam que os melhores analistas de negócio são organizados e grandes comunicadores, têm a capacidade de destilar as informações críticas das partes interessadas do projeto, muitas vezes pelo seu talento nato ou por uma ampla gama de técnicas de abordagem e modelagem do cenário.

Quando comecei a atuar com TI, percebi que o analista de negócios seria a profissão que tornaria esse profissional em um dos mais essenciais de toda uma organização, o único que realmente têm a competência para ver os dois lados sem os vícios peculiares e que cuja meta seria aplicar a tecnologia para apoiar iniciativas de negócios que ajudariam a empresa em aperfeiçoar recursos, aumentar lucros e diminuir os custos operacionais.

Como opinião pessoal, acredito que uma organização possa formar sua área de análise de negócios (inclusive sou líder e formador de um time na entidade que atuo), porém desenvolver as capacidades e as habilidades de um analista de negócios remete a tempo e maturação, não é qualquer um que tem a condição de exercer essa função e apenas com muito treinamento e “ritmo de jogo” que lapidamos esse profissional.

  • Os analistas de negócios devem ser capazes de facilitar a aplicação conjunta de design nas sessões que envolvem grupos compostos de negócios e técnicos. Eles precisam ativamente encorajar as pessoas a contribuir com suas idéias;
  • Precisam fazer o mapeamento do processo, isto é, concentrar as conversas e formatar em um contexto geral a lógica seqüencial das ações e a continuidade operacional das atividades;
  • Aplicar os dados de modelagem para organizá-los e fazer fluir as informações através dos processos de negócios, na verdade, uma modelagem de dados lógica.

Construir a credibilidade

O analista de negócios atua como um rosto do cliente para a equipe de desenvolvimento, ele deve ser suficiente credível à equipe e a mesma deve ter fé absoluta em suas ações.

Após vários anos de carreia atuando em uma fábrica de software, aprendi que a equipe de desenvolvimento deve confiar plenamente no analista de negócios, essa confiança se adquire com a devida transparência, proximidade e coerência.

  • Interagir com desenvolvedores regularmente e manter uma relação direta e sadia, ele deve saber que você esta lá e em qualquer momento pode ser acionado para os devidos esclarecimentos dos requisitos;
  • Compartilhar com a equipe de desenvolvimento e com a área de negócios o contexto de sua atividade/detalhamento realizada, pois essa será sua sustentação “técnica/funcional”, e crédito será percebido quando comprometer ambos os lados no atendimento de seus desejos, necessidades e satisfação de suas expectativas.
  • Pode ser considerado um diferencial, explicar aos times de desenvolvimento e qualidade de software a regra de negócio, e demonstrar seu domínio da informação, essa atitude reflete sua segurança e capacidade de garantir o contexto dos requisitos.
  • Por fim, ser honesto e direto em assumir o desconhecimento de determinado assunto e humilde em solicitar quantas vezes for preciso à devida explanação do tema.

Esse é um tema muito rico e caloroso, a oportunidade que tive de estudar sobre o assunto e dissertar minha opinião reforçam como é bom ser um analista de negócios.

Fonte: http://www.businessanalyst.com/, http://www.agilemodeling.com/ e http://www.cio.com/

quinta-feira, 26 de janeiro de 2012

Perigos da separação entre o QA e a equipe ágil.

Todos ganhanm quando há uma equipe ágil focada no produto e com o mesmo compromisso de entrega de valor de negócio. Ganha principalmente o cliente. Um dos piores males ocorre, entretanto, quando um dos membros não faz parte integral do time. Observamos muitas situações em que o analista de qualidade estava em outra área, separada da equipe de desenvolvimento. E isso acontecia, perigosamente, em muitos projetos.
Conseqüências da separaçãoO problema começava na divisão por área do conhecimento. Outra questão era a aparente separação hierárquica: o analista de qualidade se preocupava mais em aferir e cobrar um processo de qualidade em si do que propriamente entregar, em conjunto com a equipe, um produto de qualidade que atendesse ao cliente.

Da forma que estava sendo feito, o processo de qualidade já interferia por si só em um dos princípios do manifesto ágil, pois desconsiderava as pessoas e a comunicação aberta. Focava, em vez disso, em impor um conjunto de regras e padrões burocráticos, que impediam o progresso produtivo e incremental. Já cheguei a presenciar o analista de qualidade dizendo que o contrato de QA (Quality Assurance) precisava ser seguido, mesmo que isso acontecesse em detrimento de toda a agilidade que a equipe estava realizando.

Essa situação tornou o projeto lento, muito formal e pernicioso para a equipe, causando conflitos incessantes entre o analista de qualidade e todos os demais. E quando se questionava o trabalho do profissional QA, ele respondia apenas que devia seguir o fluxo e o processo adotado.

Onde existem múltiplos "departamentos" trabalhando com objetivos antagônicos, o resultado é uma guerra entre essas divisões, com cada parte buscando ter mais poder que a outra, infelizmente.

A situação se agravava quando o analista de qualidade cobrava do ScrumMaster quanto ao posicionamento dos bugs da aplicação. Chegava a formalizar toda a comunicação por email, com a intenção de se "blindar" de eventuais problemas que surgissem no projeto.
Não é mais saudável, ágil e produtivo termos uma equipe única em prol de um objetivo comum?
Um problema comumMichael Azoff tratou desse assunto em sua revisão dos últimos 10 anos do Agile, onde abordou o que evoluiu e regrediu neste período. Parece, portanto, que não é somente aqui no Brasil que ocorre o problema, e que existem de fato "gargalos" gerados pela separação dos times de QA e de desenvolvimento.

Ron Jeffries também aborda o assunto em seu artigo sobre Quality Assurance, no qual responde a questões de um gerente da área de qualidade sobre como o QA se "encaixa" no Extreme Programming. Jeffries recomenda que o QA se concentre no planejamento e na execução de testes funcionais, apoiando o cliente na homologação das entregas do produto final. Sugere ainda que o gerente de qualidade realize um treinamento e se integre ao time. Com isso, o time fica com um objetivo único: entregar um software que funcione e que satisfaça o cliente.

Enfim, em um cenário ágil, o analista de qualidade poderia cumprir com as seguintes responsabilidades:
• Integrar-se ao time, colaborando na prevenção de possíveis bugs, além de discutir com os desenvolvedores sobre as funcionalidades;
• Validar funcionalmente as histórias de usuários (user stories), baseando-se nas expectativas do usuário e não a simplesmente na totalidade de bugs encontrados;
• Realizar os testes de aceitação do usuário com o Product Owner;
• Descrever os testes de aceitação, a fim de que os desenvolvedores ajudem a automatizá-los;
• Escrever testes automatizados e integrá-los a uma ferramenta de integração contínua;
• Ajudar a definir indicadores de qualidade e assegurar a qualidade do produto.

O que você acha?


segunda-feira, 9 de janeiro de 2012

Scrum Alliance vai fortalecer certificação CSM



A Scrum Alliance está promovendo mudanças para fortalecer a certificação CSM (Certified ScrumMaster). Agora os candidatos terão que ser aprovados no exame e haverá um programa de desenvolvimento profissional para que os profissionais certificados mantenham a certificação.

Atualmente, a certificação CSM da Scrum Alliance é conferida a indivíduos que participam de cursos com duração de dois dias e completam um exame pró-forma (não há reprovação). O processo de certificação será modificado em 2012 para incluir um exame com possibilidade de reprovação e um novo programa de desenvolvimento profissional (com Professional Development Units - PDUs) será implementado até janeiro de 2013, para que os CSMs mantenham suas certificações. CSMs necessitarão obter PDUs para manter suas certificações, abrindo-se a possibilidade para cursos mais avançados de Scrum.

Em um email para os Certified Scrum Trainers, Carol McEwan, diretora da Scrum Alliance, explica que o novo exame estará disponível a partir de 1 de janeiro de 2012. Para os três primeiros meses do ano, todos os candidatos que completarem o exame serão aprovados. A partir de 1 de abril de 2012, os candidatos a CSM terão 60 dias em que poderão realizar até duas tentativas para passar no exame. Caso o candidato precise realizar o teste por uma terceira vez, terá que pagar uma taxa de 25 dólares.

O exame em si será curto, contendo apenas 25 questões, cobrindo conhecimentos gerais de Agile e Scrum, papéis em Scrum, cerimônias e artefatos do Scrum. O candidato poderá fazer o exame online em qualquer localidade (não haverão centros de teste). Ao final do exame, uma lista com as respostas incorretas será mostrada. 

conteúdo e objetivos de aprendizado do CSM, nos quais o teste é baseado, estão disponíveis para download no site da Scrum Alliance.


Fonte: INFOQ

segunda-feira, 2 de janeiro de 2012

Feliz 2012.

Um 2012 repleto de alegrias e boas oportunidades a todos.
Nesse ano muitos posts e grandes temas.

Aquele abraço e muita saúde.

AC