Caí de paraquedas num projeto e sou responsável por requisitos, e agora?

Publicado originalmente em 23 de março de 2017, no Linkedin

Outro dia estava eu ali num fórum, quando uma pessoa entrou e perguntou: A partir de amanhã serei analista de requisitos, não sei por onde começo!

Parece incomum mas acontece com frequência: Quantas vezes a gente já se deparou com um desafio que não sabe nem como começar? Que tipo de ajuda você espera quando isso acontece? No fórum vi muita gente recomendando leituras. Bom, leituras são imprescindíveis para o bom conhecimento de qualquer profissional. Mas e quando você está na fogueira? Como faz? Aqui está um passo-a-passo simples de como sair do outro lado num mar de problemas. Continue lendo “Caí de paraquedas num projeto e sou responsável por requisitos, e agora?”

Mas, afinal, o que é sucesso?

Publicado originalmente em 9 de março de 2017, no Linkedin

Primeiramente, me perdoe pelo erro de português na imagem. Se você chegou a este texto, assim como eu você duvida do conceito de sucesso dos dias de hoje. A imagem do texto menciona sacrifício, trabalho duro, bons hábitos, dedicação, pra chegar ao sucesso. Mas o que é sucesso?

Muitas frases “motivacionais” são lançadas dentro do LinkedIn e de todas as redes sociais para tentar direcionar pessoas ao sucesso. E as pessoas persistem, trabalham duro, se dedicam… Mas pra quê mesmo?

Antes de concordar com a imagem, proponho uma reflexão: Essa pessoa tem sucesso ou é feliz? Será que sucesso é sinônimo de felicidade? Continue lendo “Mas, afinal, o que é sucesso?”

Perca peso com Scrum, pergunte-me como

Publicado originalmente em 17 de janeiro de 2017, no Linkedin.

Primeiramente, desculpe o trocadilho no título. É que o que eu tenho para contar dessa vez é tão sensacional, que eu queria que você visse. Quem nunca teve problemas com o peso, não é mesmo? Se você não tem, sinta-se privilegiado. Não é exatamente o meu caso.

Setembro de 2015: Eu, com herança genética, sedentarismo e má alimentação, já estava obesa nível 2. Eu precisava fazer alguma coisa. As doenças cardiovasculares já batiam em minha porta. A obesidade pode ser bem cruel, às vezes. Foi então que resolvi me dedicar totalmente à rotina de reeducação alimentar e atividade física. Com corridas e corte de calorias, a princípio, foram 6kg e tcharam! Estacionei. Não conseguia mais perder um só grama.

Fevereiro de 2016: Procurei uma nutricionista, que tinha foco em nutrição comportamental – guarde bem esse nome. Dra. Ana Scaramella olhou com reprovação para a minha dieta e começamos a fazer mudanças. Desde o primeiro dia até hoje (janeiro de 2017) foram mais 5kg e a perda de peso bastante saudável, com eliminação completa dos fantasmas das doenças cardiovasculares e uma percepção de que a perda foi muito maior.

Mas onde é que entra o Scrum na jogada? Calma, eu já vou explicar. A nutricionista – nutri – como costumamos chamá-la, tem foco em nutrição comportamental, lembra? O foco do projeto de emagrecimento é a mudança completa do mindset, e, depois da leitura do livro do Jeff Sutherland, liguei os pontos.

A nutri trabalha da seguinte forma (e você pode fazer isso em casa, se quiser!):

  1. Define uma meta a ser cumprida – um backlog. Qual é a sua meta? 1, 2, 5, 15kg? Depois da meta definida, a pergunta é: Quanto você acha que consegue nos próximos 30 dias? Daí sai a sua meta do sprint e meta do release.
  2. A nutri também define 3 metas diárias – junto comigo – que eu preciso conferir diariamente. A minha daily scrum meeting comigo mesma.
  3. A cada 15 dias, há o sprint review, onde conto como foram meus primeiros 15 dias, e existe a pesagem e tiragem de medidas. Também há a retrospectiva, onde revisamos o processo e fazemos ajustes, como por exemplo: Qual é seu principal ofensor no processo de emagrecimento? O que foi muito bom nesses 15 dias?

O processo em si é bem simples, mas trago aqui para discussão pois nessa experiência percebo que o Scrum, apesar de ter uma série de cerimônias, não necessariamente implica em um processo fechado e que não podemos mudar. Meu emagrecimento tem como objetivo a mudança de pensamento, o equilíbrio pessoal.

Vejo que o Scrum não é uma ferramenta apenas para desenvolvimento de software: ele pode ser usado como uma ferramenta de mudança de cultura, onde aos poucos vemos cada uma dessas etapas como natural, e melhoramos a cada dia.

E você, o que acha da aplicação do Scrum em projetos do seu dia-a-dia?

7 dicas para conquistar definitivamente seu cliente

* Publicado originalmente em 28 de dezembro de 2016, no LinkedIn

Este artigo é muito mais que uma simples técnica de levantamento de requisitos. Não importa qual posição você esteja: seja desenvolvedor, Gerente ou CEO da companhia, invariavelmente você poderá “estar” Analista de Negócios, e meu artigo hoje é pra te ajudar a chegar do outro lado, com base na minha experiência, é claro!

Mas Stakeholder, que bichinho é esse? Stakeholders são as pessoas ou áreas interessadas no projeto. O BABOK diz:

Uma pessoa ou grupo que tem uma participação ou interesse no sucesso 
de um projeto. 
As partes interessadas também são fontes importantes para os requisitos 
do projeto e podem ser responsáveis por uma ou mais atividades de projeto 
ou entregas.

Uma boa elicitação de requisitos começa com um mapeamento de stakeholders eficiente. Não tem mapeamento de stakeholders? Volte duas casas! Ou para o início do projeto!

Mas se você tem o mapeamento de stakeholders, aí vão minhas dicas para que você saia do outro lado no escopo do seu projeto.

Ouça

Veja só: Você foi chamado porque alguém tem um problema. Você é responsável por entender o problema e ajudar a resolvê-lo. O que você deve fazer neste momento? OUÇA! Deixe as perguntas para depois. Ouça, mesmo que não entenda o todo. Grave se possível. Mas deixe as pessoas falarem.

Formule questões diretas

Com base naquilo que você ouviu, faça abordagens diretas. Não faça perguntas abertas ou amplas, como “Mas o problema é esse mesmo?” ou “E se a gente não fizer o que você está falando?”. Continue tentando entender o problema do stakeholder.

Você não sabe mais que seu stakeholder

Seja humilde. As pessoas estão trabalhando e talvez você tenha uma abordagem melhor do que a deles e que possa vir a ajudá-los. Talvez você possa parecer só um arrogante mesmo. Então cuidado com a abordagem e se coloque sempre como aquele que vai ajudar. Do contrário, seu stakeholder vai te deixar – literalmente – falando.

Exercite a empatia

Coloque-se no lugar do seu stakeholder. Perceba as expressões faciais quando o stakeholder estiver te explicando algo. Geralmente eles dão dicas de linguagem corporal daquilo que mais os incomoda. É claro que existem abordagens de priorização, técnicas para medição de ROI, etc. Porém, no momento da entrevista, você identifica a dor do stakeholder quando ele está falando sem parar naquilo que o incomoda.

Às vezes, seu stakeholder só precisa de um sistema para ajudá-lo porque está trabalhando todos os finais de semana… Às vezes, uma mudança simples de processo ajuda. E se você deixa passar esse tipo de ‘desabafo’, pode perder algo importante a respeito do seu stakeholder.

Não use a palavra usuário

Ok, essa é bem particular. Nós de sistemas, tendemos a chamar as pessoas das áreas de negócio de ‘usuários’. Particularmente, quando deixei de usar o termo obtive melhores resultados nas minhas elicitações. Em minha opinião, a palavra usuário coloca um limite entre TI e Negócio que não pode existir. A palavra coloca as pessoas em patamares distintos. O negócio é nosso parceiro, eles são os exímios conhecedores daquilo que estamos trabalhando. Nós é que estamos servindo-os, e não o contrário.

Seja transparente

Quando um stakeholder te fizer uma pergunta, seja transparente na resposta. Seja a respeito do andamento do projeto, sobre a possibilidade de implementação de um requisito, seja sobre escopo inverso ou qualquer outro tema. Avise seu stakeholder se ele estiver sonhando alto demais durante uma reunião de elicitação. Isso vai ajudar criar um clima de confiança entre você e ele.

Se possível, faça amizade

Você pode não ser do tipo que é super aberto a amizades, mas quando você alcança um nível de proximidade maior com seu stakeholder, pode conseguir mais informações e atingir níveis excepcionais de satisfação do cliente.

E você, já conquistou seu stakeholder? O que você faz para atingir a excelência no atendimento ao seu cliente final?

Um framework para requisitos ágeis

*Publicado originalmente em 2 de dezembro de 2016, no LinkedIn

Em 12 anos de Análise de Negócio, passei pelos mais diversos projetos. Projetos grandes, projetos pequenos, programas inteiros ou apenas manutenções.

Todos eles possuem algo em comum: a grande quantidade de frameworks a serem utilizados. Casos de Uso, Tabelas de Caso de Uso, protótipos. Tudo previsto em metodologias como RUP e como o Waterfall Clássico. Mesmo assim, os problemas seguiram aparecendo: Problemas de entendimento, problemas com desenvolvimento… Já não dava mais pra seguir desse jeito. Pausa.

2016. Nesse ano eu passei a trabalhar com metodologias ágeis e as primeiras dúvidas começaram a surgir: Como escrever as histórias? Como garantir que os requisitos foram 100% capturados? Em minha mente sempre ecoou o fato de que a responsabilidade pelas perguntas certas era minha. Eu possuo o domínio da técnica. O BABOK também diz: Essa responsabilidade é do Analista de Negócios. E agora?

O costume de sempre elicitar os requisitos – e ser a única responsável por eles -, me deixava preocupada o tempo todo. Então, resolvi procurar o treinamento de Requisitos Ágeis com o Marcelo Neves. Meu objetivo com o curso era descobrir frameworks para escrita de histórias de usuário, épicos, técnicas, essas coisas.

E o que aconteceu foi um belo de um tapa na cara. Tapa na cara porque, além do INVEST, não há mais nada que determine se uma história está bem escrita ou não. Porque quem define se a história está bem escrita é o Time de Desenvolvimento. Porque no Scrum, o Time ajuda a definir se a história tem tudo o que precisa.

Porque em metodologia ágil, a interação entre pessoas é mais que processos e ferramentas.

Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano - Manifesto Ágil

Então, se você veio até aqui buscando uma indicação de framework para requisitos ágeis, eu só tenho uma ajuda pra você. O INVEST. Uma história de usuário deve ser:

Independente, Negociável, Ter Valor, Estimável, Pequena (Small) e Testável.

Já adianto que conseguir todos eles ao mesmo tempo não é uma tarefa fácil. Mas confie em você e no time. Aos poucos, a prática leva à maturidade – e à perfeição.

Comentando a palestra “Análise de Negócios em Projetos Ágeis”

Ontem fui assistir à palestra do Claudio Kerber sobre análise de negócios ágil. Confesso que a idéia de entregar software rodando (software rodando, software rodando) mais rápido seduz, em um primeiro contato.

Porém houveram alguns pontos da palestra em que discordei do inteligentíssimo palestrante, que vou discorrer a seguir.

A melhor maneira de testar um conceito de um requisito é fazendo um protótipo funcionando do software que será entregue, numa versão “rascunho”.

Nessa ocasião, foi dado o exemplo da criação do sistema sob discussão numa página em Php, descobrir eventuais problemas do software e com a engenharia reversa, desenhar o caso de uso para que o time trabalhe.

Questionei a iniciativa pois a maioria dos analistas de negócio que conheço, conhecem código, e assim como eu, não possuem habilidade técnica para tal. Foi-me sugerido então, aplicação num Excel, Access, o que seria perfeitamente possível.

Porém, ainda discordo da prática, pois acredito que me utilizando de software para provar um requisito, apesar de parecer boa prática, corro o risco de me distanciar das necessidades do usuário e “puxar a sardinha” para o desenvolvimento. Mesmo que software rodando seja um bom argumento, há o outro lado da moeda: O stakeholder aceitar o software entregue, mesmo não atendendo 100% suas necessidades, só porque “veio rápido” e é possível “se adaptar ao software”.

Se o mundo acabasse hoje, e houvessem apenas baratas e desenvolvedores, sairia software.  Mas, se o mundo acabasse hoje e houvessem apenas baratas e analistas de negócios, não haveria software.

Hora de “puxar a sardinha” pro meu lado, não é? (rs) Se o mundo acabasse hoje e houvessem apenas baratas e desenvolvedores: Bem, não acredito que sairia software. Desenvolvedores, em sua maioria, possuem perfil detalhista e grande dificuldade de comunicação com áreas usuárias. Numa estrutura onde já houvessem stakeholders responsáveis pelo levantamento de requisitos  e priorização dos mesmos, pode até ser que isso aconteça. Num mundo onde desenvolvedores possuam grande capacidade de visualizar soluções e não componentes, também.  Desenvolvedores tendem a fazer o que é desafiador a eles, não o que agrega valor ao cliente. Bem, num mundo onde só há baratas, desenvolvedores fariam um software qualquer.

Num mundo onde só existem baratas e analistas de negócios, também não haverá software, a menos que o analista de negócios seja aquele que desenvolve algo para testar o conceito. Aí sim, teríamos software. Mas,  como eu não concordo com essa prática, minha conclusão é:

Analistas de Negócios e Desenvolvedores são habilidades complementares e não sobrevivem sozinhas, salvo raras exceções.

Como eu saí do caos completo e fui agregando valor ao meu trabalho utilizando UML e RUP, para mim parece estranho ignorar todo o resto porque simplesmente “não funciona”. Os processos do RUP, PMBOK, funcionam tão bem quanto Scrum, Kanban e Agile se aplicados corretamente. Todos os processos permitem flexibilização e aplicação de acordo com o dia-a-dia. A flexibilização também é uma faca de dois gumes:  Abre precedente para falácias sobre os processos, e aplicação dos mesmos de forma incorreta. O que mais se ouve no mercado é “trabalhamos com as melhores práticas do mercado: RUP e PMBOK”, “Usamos metodologia ágil”, ou “Temos um Scrum adaptado”. Não preciso dizer que em nenhum dos casos as empresas sequer arranham as metodologias citadas. A metodologia usada nesses casos, geralmente, é a TVN (Te vira negão).

O que é legal no Agile

Divisão do escopo

A divisão do escopo do software em pequenas partes é uma boa idéia. A iteração já era prevista no RUP, mas utilizada de forma incorreta.  Dividindo o escopo em pequenas partes, podemos validar com antecedência se o requisito levantado está sendo atendido adequadamente, eliminar riscos, etc.  Neste caso, o cliente precisa “comprar” a idéia e topar homologar a versão quinzenalmente. Entretanto, não vejo como dividir escopo em projetos de migração de dados e projetos “Big Bang”.

Indivíduos e interação entre eles mais que processos e ferramentas

É certo que ruídos de comunicação podem ser responsáveis por arruinar todo um projeto. Aquilo que é uma seção no PMBOK, é premissa no Agile. Deveria ser premissa em todos os projetos. A alta interatividade entre o próprio time possibilita entrega de valor mais rápido.

Software rodando

Sem dúvida esta é a mais legal das vantagens do Agile. Surpreender o cliente e obter feedbacks do que está bom ou não, é o que mais motiva a comunidade ágil a continuar. Poder melhorar a cada iteração é uma grande vantagem.

Feedbacks constantes

No Agile é possível verificar erros imediatamente, obter feedbacks da liderança rapidamente e o crescimento profissional e aprendizado é exponencial. Também deveria ser uma prática a ser adotada em qualquer projeto.

Colaboração com o cliente mais que negociação de contratos

Colaboração com o cliente, e colaboração do cliente, seriam as melhores ferramentas para trabalhar num projeto de software. Quebrar barreiras e diminuir distâncias é um desafio na análise de sistemas desde que ela existe.

Conclusão

Acredito que Agile, mais do que uma metodologia, é uma cultura que poderia, em grande parte, ser implantada nas fábricas de software e em clientes. Comunicação, agilidade, vontade de trabalhar, entregar valor e colaborar com o cliente, embora óbvias, são coisas que muitas vezes são esquecidas num projeto de software, tanto na cultura ágil quanto na cultura tradicional de gestão de projetos. Gerentes falastrões, analistas pouco preocupados com o resultado ou inexperientes, desenvolvedores cansados e clientes não envolvidos não darão resultado em nenhuma metodologia.

RUP com XP: Como tornar isso possível?

Baseado no material do RUP.

O RUP (Rational Unified Process) é uma estrutura de processo que o Rational Software aperfeiçoa com o passar dos anos e tem sido amplamente utilizado para todos os tipos de projetos de software, do pequeno ao grande. Recentemente um número crescente de processos “agile” – como XP (eXtreme Programming), SCRUM, FDD (Feature-Driven Development) e a Metodologia Crystal Clear têm obtido reconhecimento como métodos eficazes para a criação de sistemas menores. (Consulte www.agilealliance.org para obter informações adicionais sobre a Agile Alliance.)

A comunidade agile sintetizou um número de “boas práticas” que são especialmente aplicáveis às equipes de projeto pequenos no mesmo local. Embora o RUP seja destinado às equipes de projeto de qualquer tamanho, ele pode ser aplicado com êxito aos projetos pequenos. Em geral, o RUP e os processos da comunidade Agile têm uma visualização semelhante às boas práticas principais requeridas para desenvolver software de qualidade, por exemplo, aplicando o desenvolvimento iterativo e enfatizando os usuários.

As seguintes seções explicam como aplicar algumas das “boas práticas” identificadas na comunidade Agile para projetos com base em RUP que gostariam de se beneficiar de algumas dessas práticas. Nesse caso, o foco estará especificamente nas práticas apresentadas pela metodologia eXtreme Programming (XP). (Para obter informações adicionais sobre o XP, consulte o Web site: http://www.extremeprogramming.org.)

Práticas XP

O XP inclui quatro “atividades” básicas (codificação, teste, escuta e design), que na verdade são alinhadas mais intensamente às disciplinas do RUP. Essas atividades de XP são executadas usando um conjunto de práticas que requerem a execução de atividades adicionais, que estão mapeadas em outras disciplinas do RUP. As práticas do XPs, de acordo com o Extreme Programming Explained são:

  • O jogo do planejamento: Determine rapidamente o escopo da próxima liberação, combinando as prioridades de negócios e as estimativas técnicas. Quando a realidade superar o plano, atualize-o.
  • Pequenas Liberações: Coloca um sistema simples em produção rapidamente, em seguida, libera novas versões em um ciclo muito curto.
  • Metáfora: Guia todo o desenvolvimento com uma história simples compartilhada de como todo o sistema funciona.
  • Design Simples: O sistema deve ser projetado o mais simplesmente possível a qualquer momento. Qualquer complexidade extra deve ser removida assim que for descoberta.
  • Teste: Os programadores escrevem testes de unidade continuamente, que devem ser executados sem problemas para que o desenvolvimento prossiga. Os clientes escrevem testes demonstrando que as características foram alcançadas.
  • Recriação: Os programadores reestruturam o sistema sem alterar seu comportamento para remover a duplicação, aprimorar a comunicação, simplificar ou incluir flexibilidade.
  • Programação aos Pares: Todo o código de produção é gravado com dois programadores em uma máquina.
  • Propriedade Coletiva: Qualquer pessoa pode alterar qualquer código em qualquer lugar do sistema a qualquer momento.
  • Integração Contínua: Integra e constrói o sistema muitàs vezes por dia, sempre que uma tarefa é concluída.
  • 40 horas por semana: A regra é não trabalhar mais de 40 horas por semana. Nunca faça hora extra duas semanas seguidas.
  • Cliente On-site: Inclui um usuário real, ativo na equipe, disponível em tempo integral para responder perguntas.
  • Padrões de Codificação: Os programadores escrevem todo o código de acordo com as regras, enfatizando a comunicação por meio do código.

As atividades realizadas como resultado da prática de “jogo de planejamento”, por exemplo, mapearão principalmente para a disciplina de gerenciamento de projeto do RUP. Mas alguns tópicos RUP, como a implantação do software liberado, estão fora do escopo do XP. A obtenção de requisitos está ainda mais fora do escopo de XP, já que é o cliente quem define e fornece os requisitos. Além disso, devido aos projetos de desenvolvimento mais simples com os quais lida, a XP pode tratar de forma mais superficial as questões que o RUP aborda em detalhes na disciplina de Gerenciamento de Configuração e Mudança e na disciplina de Ambiente.

Práticas XP Compatíveis com RUP

Nas disciplinas em que o XP e o RUP se sobrepõem, as seguintes práticas descritas no XP podem ser e, em alguns casos já são, empregadas no RUP:

  • O Jogo de Planejamento: A orientação de XP sobre planejamento poderia ser utilizada para alcançar muitos dos objetivos mostrados na disciplina do Gerenciamento de Projeto do RUP para um projeto muito pequeno. Isso é especialmente útil para projetos sem muita formalidade e que não precisam produzir artefatos de gerenciamento de projeto intermediários de modo formal.
  • Design Teste Primeiro e Recriação: Essas são boas técnicas que podem ser aplicadas na disciplina de implementação do RUP. A prática de XP para testes, que requer teste anterior ao design, é uma forma excelente de esclarecer requisitos em um nível mais detalhado. Como veremos na próxima seção, a refatoração pode não ser compatível com sistemas maiores.
  • Integração Contínua: O RUP suporta essa prática por meio de construções nos níveis de subsistema e de sistema (dentro de uma iteração). Os componentes testados em unidades são integrados e testados no contexto do sistema emergente.
  • Cliente On-site: Muitas das atividades do RUP se beneficiariam muito por terem um cliente on-site como um membro da equipe, que pode reduzir o número de produtos liberados intermediários necessários, especialmente os documentos. Como meio preferido de comunicação cliente-desenvolvedor, a XP destaca a conversação, que tem como base a continuidade e a familiaridade para ser bem-sucedida; no entanto, quando um sistema, mesmo pequeno, tiver que ser transferido, mais de uma conversação será necessária. A XP permite fazer isso como uma reflexão posterior (por exemplo, projetar documentos no final de um projeto). Como não impede a produção de documentos ou outros artefatos, a XP defende que devem ser produzidos apenas aqueles que são realmente necessários. O RUP concorda, mas continua a descrever o que é necessário quando a continuidade e a familiaridade não são ideais.
  • Padrões de Codificação: O RUP tem um artefato-diretrizes de programação-que quase sempre seria considerado obrigatório. (Os perfis de risco são os principais fatores de adaptação.)
  • Quarenta Horas por Semana: Como na XP, o RUP sugere que trabalhar horas extras não deve ser uma condição crônica. A XP não sugere um limite rígido de 40 horas, admitindo diferentes margens de tolerância para o período de trabalho. Os engenheiros de software costumam trabalhar muitas horas sem gratificação extra, trabalham apenas pela satisfação de verem algo concluído, e os gerentes não necessariamente precisam colocar arbitrariamente um ponto final nisso. O que eles nunca devem fazer é impor essa prática ou se utilizar dela. Eles devem reunir métricas sobre as horas realmente trabalhadas, ainda que não compensadas. Se o registro de horas trabalhadas de um funcionário for alto durante um período prolongado, isso certamente deve ser investigado. Entretanto, essa questão deve ser resolvida entre o gerente e o indivíduo, dentro do contexto das circunstâncias em que ocorrem, admitindo preocupações que o restante da equipe poderia ter. Quarenta horas é apenas uma diretiva, mas convincente.
  • Programação aos Pares: O XP afirma que a programação aos pares é benéfica para a qualidade do código e que uma vez que essa habilidade é adquirida, ela torna-se mais agradável. O RUP não descreve o mecanismo de produção de código em um nível tão refinado, embora seja possível usar a programação em pares em um processo baseado no RUP. Algumas informações sobre a programação aos pares, assim como teste anterior ao design e refatoração, são fornecidas com o RUP, na forma de white papers. Obviamente, não é obrigatório usar essas práticas no RUP. No entanto, em um ambiente de equipe, com uma cultura de comunicação aberta, podemos arriscar um palpite de que seria muito difícil discernir os benefícios da programação em pares (em termos de efeito sobre o custo total do ciclo de vida). É normal que as pessoas se reúnam para discutir e resolver problemas em uma equipe bem integrada, sem que sejam obrigadas a fazer isso.

A idéia de que um bom processo deve ser imposto no nível “micro” não costuma ser bem recebida e pode não ser adequada a algumas culturas empresariais. Por isso, qualquer imposição rígida não é defendida pelo RUP. Entretanto, em algumas circunstâncias, o trabalho em pares, e algumas das outras práticas de equipe defendidas pela XP, é obviamente vantajoso, como cada membro de equipe pode ajudar o outro; por exemplo:

  • no início da formação da equipe, quando as pessoas ainda estão se conhecendo
  • em equipes que não tenham experiência em uma determinada tecnologia nova
  • em equipes mistas formadas tanto por pessoal experiente como por novatos

Mapeamento dos Artefatos para um Pequeno Projeto

Quando adaptamos o RUP para um projeto pequeno e reduzimos os requisitos do Produto de Trabalho de acordo, como isso se compara ao equivalente dos artefatos em um projeto XP? A Tabela abaixo mostra um conjunto típico de artefatos RUP em um pequeno projeto RUP.

Artefatos de XP Artefatos RUP
(Exemplo para Pequenos Projetos)
Histórias
Documentação adicional a partir de conversações
Visão
Glossário
Modelo de Casos de Uso
Restrições Especificações Suplementares
Testes de aceitação e testes de unidade
Dados de teste e resultados de teste
Plano de Teste Caso de Teste Conjunto de Testes (incluindo Script de Teste , Dados de Teste )
Log de Teste
Sumário de Avaliação de Testes
Software (código) Modelo de Implementação
Releases Produto (Unidade de Implantação)
Notas Sobre o Release
Metáfora Documento de Arquitetura de Software
Design (CRC, esboço UML)
Tarefas técnicas e outras tarefas
Documentos de design produzidos no final
Documentação de suporte
Modelo de Design
Padrões de codificação Diretrizes Específicas para Projetos
Espaço de Trabalho
Estrutura de teste e ferramentas
Caso de Desenvolvimento
Configuração do Ambiente de Teste
Plano de liberação
Plano de iteração
Estimativas de história e de tarefa
Plano de Desenvolvimento de Software
Plano de Iteração
Orçamento e plano geral Caso de Negócio
Lista de Riscos
Relatórios em andamento
Registros de tempo para o funcionamento da tarefa
Dados de métricas (incluindo recursos, escopo, qualidade, tempo)
Rastreamento de resultados
Relatórios e notas sobre reuniões
Avaliação de Status
Avaliação de Iteração
Registro de Revisão
Defeitos (e dados associados) Controles de Mudança
Ferramentas para gerenciamento de código Repositório do Projeto
Espaço de Trabalho
Pico (solução) Protótipos
Protótipo da Interface com o Usuário
Prova de Conceito Arquitetural
A própria XP (suas recomendações e diretrizes) Lista de Idéias de Teste
Diretrizes Específicas para Projetos
[Não incluído no XP] Modelo de Dados
Material de Suporte do Usuário.

Embora a granularidade dos artefatos varie nos dois lados, em geral os artefatos no RUP para projetos pequenos (do tipo com o qual a XP lidaria tranqüilamente) são mapeados sem problemas para os de um projeto de XP.

Observe que a tabela também inclui alguns artefatos que não são cobertos pelo XP, mas são necessários em muitos projetos. Isso inclui o Modelo de Dados e os artefatos relacionados à implantação, como o Material de Suporte ao Usuário.

Atividades

O RUP define uma Tarefa como trabalho executado por uma Função – seja utilizando e transformando os artefatos de entrada ou produzindo artefatos de saída novos e alterados. O RUP continua enumerando essas atividades e as categoriza de acordo com as disciplinas RUP. Essas disciplinas incluem: requisitos, análise e design, implantação e gerenciamento de projeto (entre outras).

As atividades estão relacionadas ao tempo por meio dos artefatos que produzem e consomem: uma atividade pode logicamente ser iniciada quando suas entradas estiverem disponíveis (e em um estado de maturação apropriado). Isso significa que os pares de atividades produtor-cliente podem se sobrepor no tempo, se o estado do artefato permitir. Eles não precisam obedecer a uma seqüência rígida. As atividades se destinam a fornecer diretrizes claras sobre como um artefato deve ser produzido ou alterado e podem ser usadas para ajudar o gerente de projeto no planejamento.

Combinadas por meio do RUP, já que são descritas em termos de ciclo de vida, artefatos e atividades são “boas práticas”: princípios de engenharia de software que comprovadamente produzem softwares de qualidade criados para orçamento de programação previsíveis. Através de suas atividades (e artefatos associados), o RUP suporta e realiza essas melhores práticas. Elas são temas executados através do RUP – que sustentam os principais princípios que fundamentam o RUP. Observe que a XP utiliza a noção de “práticas” também, mas, como veremos, não corresponde exatamente ao conceito de boas práticas do RUP.

A XP apresenta uma visão de desenvolvimento de software que é atraentemente simples, composta por quatro atividades básicas (codificação, teste, monitoramento e design) que devem ser ativadas e estruturadas de acordo com algumas práticas de suporte (conforme abordado no capítulo 9 do livro Extreme Programming Explained). Na verdade, como observado anteriormente, as atividades de XP estão mais relacionadas em escopo às disciplinas do RUP do que às atividades do RUP. Muito do que acontece em um projeto de XP (além de suas quatro atividades básicas) é resultado da elaboração e da aplicação de suas práticas.

Portanto, há equivalência entre as atividades de XP e RUP, mas as “atividades” de XP não estão formalmente identificadas ou descritas como tal. Por exemplo, analisando o Capítulo 4, “Histórias de Usuários”, no Programação Extrema Instalada, você encontrará o título, “Definir Requisitos com Histórias, Escritas em Cartões” e em todo o capítulo há uma mistura da descrição do processo e da orientação sobre o que são histórias de usuários e como (e por quem) elas devem ser produzidas. E continua assim; nas várias seções dos manuais de XP (com títulos que são uma mistura de ênfase em artefato e ênfase em atividade), os “itens produzidos” e os “itens feitos” são descritos em graus variáveis de prescrição e de detalhes.

O grau de prescrição aparentemente alto do RUP é resultado da abrangência e maior formalidade no tratamento de atividades e de suas entradas e saídas. Não falta prescrição à XP, porém, na sua tentativa de permanecer leve, a formalidade e os detalhes são simplesmente omitidos. A falta de especificidade não é vantagem nem desvantagem, mas a falta de informações detalhadas no XP não deve ser confundida com simplicidade. A falta de detalhes pode ser ótima para desenvolvedores mais experientes, mas, em muitos casos, a fartura de detalhes é uma grande ajuda para membros da equipe que sejam novos ou que ainda estejam tentando acompanhar o ritmo da abordagem da equipe quanto a desenvolvimento de software.

Com Atividades, assim como com Artefatos, é importante manter o foco no que estamos tentando alcançar. Executar uma atividade às cegas nunca é uma boa prática. As atividades e as diretrizes associadas estão à disposição para quando você precisar delas para atingir seus objetivos, mas não devem ser usadas como desculpa para não ter de descobrir qual é o seu objetivo. Esse pensamento é bem articulado em XP e acreditamos que deva ser aplicado a todos os usuários de RUP.

Funções

No RUP, as atividades devem ser executadas por funções (ou, mais precisamente, por indivíduos ou grupos exercendo funções). As funções também têm responsabilidade por artefatos específicos; a função responsável normalmente criará o artefato e garantirá que as mudanças feitas por outras funções (se permitidas) não danifiquem o artefato. Um indivíduo ou um grupo de pessoas pode assumir apenas de um a vários papéis. Uma função não tem que ser mapeada para uma única posição ou “slot” em uma organização.

A Programação Extrema Explicada identifica sete funções aplicáveis ao Programador XP, Cliente, Testador, Rastreador, Técnico, Consultor e Diretor e descreve suas responsabilidades e as competências requeridas das pessoas que as executarão. As referências também são feitas a essas funções em alguns dos outros manuais de XP . A diferença no número de papéis no XP e no RUP é fácil de explicar.

  • A XP não aborda todas as disciplinas do RUP.
  • Os papéis de XP equivalem mais a posições dentro de uma organização (possivelmente com várias responsabilidades) do que a papéis do RUP. Por exemplo, o Programador do XP, na verdade, executa várias funções do RUP: Implementador, Revisor de Código e Integrador, que requerem competências ligeiramente diferentes.

Funções XP e RUP em um Pequeno Projeto

Quando as funções RUP são mapeadas para um projeto pequeno, o número de funções parecidas com XP as quais elas correspondem é reduzido consideravelmente em que o número de posições ou títulos de tarefas é 5. A Tabela abaixo (retirada do RUP) mostra este mapeamento com a Função XP correspondente.

Função XP Exemplo do Membro da Equipe do Pequeno Projeto RUP Função RUP
Técnico
Consultor
Diretor
Sally Slalom, Gerente Sênior Coordenador de Projeto
Gerenciador de Implantação
Revisor Técnico
Gerenciador de Configuração
Gerenciador de Controle de Mudanças
Cliente Envolvido (conforme documentado na Visão ) Revisor de Gerenciamento
Revisor Técnico (requisitos)
Cliente
Diretor
Rastreador
Tom Telemark, Engenheiro de Software Sênior Analista de Sistemas
Especificador de Requisitos
Designer da Interface com o Usuário
Arquiteto de Software
Revisor Técnico
Gerenciador de Teste
Analista de Teste

Funções do Desenvolvedor (com menos ênfase)

Programador
Testador
Susan Snow, Engenheira de Software

Henry Halfpipe, Engenheiro de Software Júnior

Designer
Implementador
Revisor Técnico
Integrador
Designer de Teste
Testador
Redator Técnico
Rastreador Patrick Powder, Assistente Administrativo Responsável por manter o site do projeto na Web, auxiliar a pessoa que exerce o papel de Gerente do Projeto no planejamento/programação de atividades e ajudar a pessoa que exerce o papel de Gerente de Controle de Mudança a controlar mudanças nos artefatos.   Também pode auxiliar outras funções conforme necessário.

Tabela 3: Mapeando Funções XP para Funções RUP em um Projeto Pequeno

Utilizando Práticas XP com o RUP

O RUP é um framework de processo a partir do qual determinados processos podem ser configurados e, em seguida, instanciados. O RUP deve ser configurado, esta é uma etapa obrigatória, definida no próprio RUP. Especificamente falando, devemos comparar uma versão adaptada do RUP com XP, ou seja, com o RUP adaptado às características do projeto que a XP explicitamente estabelece (e as que podem ser inferidas). Um processo de RUP adaptado dessa forma poderia acomodar muitas das práticas de XP (como programação em pares, refatoração e teste anterior ao design), mas ainda não seria idêntico à XP, por causa da ênfase do RUP em arquitetura, abstração (em modelagem) e risco e de sua estrutura diferente no tempo (fases e iterações).

A XP é dirigida intencionalmente para a implementação de um processo leve para projetos pequenos. Ao fazer isso, ela também inclui descrições (pelo menos nos livros) que não são totalmente elaboradas. Em uma implementação de XP, sempre haverá itens que precisam ser descobertos, inventados ou definidos rapidamente. O RUP acomodará projetos que estejam adequados ou além do escopo da XP em escala e tipo. Como mostra este roteiro, na verdade, o RUP é perfeitamente compatível com a maioria das práticas descritas na literatura sobre XP.

Lembre-se de que a essência da XP é o foco na organização, nas pessoas e na cultura. Isso é importante em todos os projetos e, certamente, é aplicável aos projetos que usam o RUP. O uso conjunto dessas práticas seria muito vantajoso para projetos pequenos.

Análise de Negócios em Projetos Ágeis, por @oclaudiobr

Quem se interessa pelo assunto, pode correr pra palestra que vai rolar dia 27/01. Seguem as informações:

Mais valor. Mais rápido.

Objetivo

“Análise de negócios é análise de negócios”, contudo, em um contexto ágil, parece que estamos fazendo análise de negócios em uma montanha russa. A boa notícia é que é realmente divertido (para quem tem estômago).

Público Alvo: Profissionais interessados em entregar mais valor mais rápido para as organizações através de
soluções de software.

Palestrante: Claudio Brancher Kerber

Data e Horário: 27 de Janeiro (quinta-feira), às 19:10h (credenciamento a partir das 18:30h)

Investimento:
R$ 70,00.
Desconto de 50% (R$ 35,00) para pagamentos efetuados até 26/01/2011
R$ 30,00 para Associados do IIBA Internacional (somente para pagamentos efetuados até 9/12/2010)

Forma de Pagamento: Depósito Bancário ou Transferência

Local: Fundação Carlos Alberto Vanzolini – Av. Paulista, 967, 5° Andar, Bela Vista, São Paulo (próximo ao metrô Trianon-MASP)

Inscrições1) Enviar e-mail para eventos@saopaulo.theiiba.org
Assunto “Inscrição – Análise de Negócios em projetos ágeis”
Informar:
1)      Nome
2)      E-mail
3)      Telefone com DDD
4)      Número de Membership Emitido (Associados IIBA Internacional)
5)     Aguardar email do Comitê de Eventos IIBA-SP com instruções para pagamento.

REGRAS: Não será realizada reserva de vaga.
Não será realizada inscrição por telefone e/ou no local do evento.
Não haverá devolução da taxa de inscrição e/ou o crédito da mesma em caso de desistência.
A efetivação da inscrição dependerá do envio dos dados do comprovante de pagamento.
Depósitos ou transferências deverão ser feitos até 4ª feira – dia 26/01/2010, dentro do horário do expediente bancário.
As inscrições feitas dia 27 de janeiro deverão ser pagas pessoalmente, conforme regra de valor integral, durante o horário do credenciamento – das 18:30h às 19:10h, do dia 27 de janeiro.
O pagamento feito pessoalmente deverá ser somente em espécie, no valor integral de R$ 70,00 para Associado e Não-Associado do IIBA e estará sujeito a disponibilidade de vaga caso não tenha feito inscrição por e-mail.
Patrocinadores:
Interdual Análise de Negócios
Rezende Fontes e Braga – Sociedade de advogados
Fundação Vanzolini
DoMore! soluções em produtividade

Habilitar uso seguro de redes sociais no trabalho desafia a TI

Gestores são pressionados a afrouxar as regras de acesso às comunidades virtuais como o LinkedIn, o Facebook e o YouTube.
Por Network World/EUA

A tentação de bloquear o acesso às redes sociais no ambiente de trabalho é grande, mas não tem futuro. Os departamentos de TI são pressionados a afrouxar as regras de acesso às comunidades virtuais como o LinkedIn, o Facebook e o YouTube.

Essa pressão vem de várias frentes diferentes e tem motivações igualmente variáveis. As equipes de marketing e comerciais, por exemplo, vão contatar seu público usando essas mídias. Na perspectiva do RH das organizações, funcionários com vivência nessas redes serão melhor avaliados, mas de nada valerá contratar esses colaboradores se não puderem exercer seus conhecimentos no trabalho.

Mudança de paradigma

O vice-presidente e analista-chefe da Forrester, Chenxi Wang, afirma que há um movimento grande de mudança de paradigma nas organizações, à medida que elas adotam modelos mais liberais de interação digital de seus funcionários. Falta apenas encontrar a mistura balanceada entre liberdade e segurança.

Especialistas no assunto sugerem que a abertura seja efetuada de maneira gradativa e com base em um planejamento. Se, por um lado, empresas afrouxaram sensivelmente o uso do email, muito pouco foi feito com o objetivo de transferir essa liberdade aos sites de relacionamento.

A primeira tarefa das empresas é estender as políticas de uso do email pessoal a todas as vias de comunicação digital, diz Bradley Anstis, que ocupa a cadeira de vice-presidente de estratégia digital da empresa M86 Security.

Cada caso um caso

No planejamento da abertura social devem ser considerados os níveis de acesso com foco em segurança. O YouTube, por exemplo, não precisa ser acessado por todos. O mesmo pode ser dito sobre os aplicativos para Facebook. Quem sabe, seja questão de configurar acesso em modo leitura apenas, o que impede que programas alheios aos interesses da empresa gravem qualquer bit no sistema corporativo. Como em tudo, educação é a pedra fundamental nessa questão e deve abordar o perigo de vazamento de informações confidenciais.

Nosso papel não é nem será o de policiar a diversão e a alegria das pessoas, diz Anstis. Basta às empresas compreender isso e habilitar o uso seguro das redes sociais no trabalho, completa.

Pesquisa

Um levantamento realizado pela empresa FaceTime Communications com 1.654 gerentes de TI e usuários de redes sociais em 2010 revelou que a presença de redes sociais no ambiente de trabalho é certa para 62% dos respondentes. Recursos digitais, como a partilha de arquivos acontecem em 74% das empresas, respondem os usuários. Aos olhos de gestores, porém, essa realidade não é percebida. Apenas 32% destes responderam que existe a disponibilidade desse tipo recurso em suas estruturas. Outra discrepância é percebida quando o assunto são programas de chat. 95% dos usuários responderam que sim, usam esses programas ou sites em seu trabalho. Apenas 31% dos administradores de TI confirmam esse fato.

Outras ameças

Mas o vazamento de dados é apenas um dos pontos críticos. Há várias ameaças digitais que comprometem as organizações por violar determinadas regulamentações de segurança. É o caso dos botnets, de malwares e de tentativas de phishing. Para John Vecchi, líder de marketing de produtos da empresa Check Point, a web 2.0 traz consigo muitos desafios aos departamentos de TI. Especialmente no que tange à proteção dos dados, em que o surgimento de vários canais aumenta de forma quase exponencial o perigo de informações confidenciais ganharem a rede.

A regulamentação de mídias sociais pode, e deve, acontecer junto com a configuração das políticas de grupo e de usuário. Normalmente isso acontece via integração ao diretório corporativo. Ferramentas que não tenham opções de filtragem nesse nível não bastam para garantir a segurança dos dados. Outra questão de fundamental importância é gerir o acesso (leia-se o bloqueio) de malwares baseados em scripts e verificar a natureza de dados baixados e carregados na internet tudo com vistas a preservar as políticas internas.

Logo

Se, por um lado, é importante resguardar os bens da empresa dos riscos impostos pelo uso de redes sociais, é igualmente importante aceitar que o uso do Facebook, Twitter e do LinkedIn não têm como ser erradicados à base de cliques e de configurações em servidores. Os funcionários irão encontrar um jeito de entrar na rede, nem que seja para comemorar que venceram os esforços da organização e comentar quando perceberem na tentativa de separá-los de seus amigos.

O negócio é manter uma mente aberta sobre seus colaboradores e como percebem as mídias sociais, recomenda Wang. Acredito que seja fundamental informar os usuários sobre os riscos associados às redes de relacionamento, dar-lhes as ferramentas para que se protejam e deixar que tomem as medidas que acharem necessárias.