Categoria: Uncategorized

Veja a notícia aqui.

Eu, como não sou boba nem nada, já baixei o PDF 🙂

Iniciando leitura!

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.

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.

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.

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.

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