Priscila Chagas

Autor: Priscila Chagas

  • 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

  • E o RUP?

    O que é RUP? A sigla RUP quer dizer “Rational Unified Process”, ou, em português, “Processo Unificado Rational”. Mas isso não significa que o RUP seja realmente um processo, mas sim, um framework de boas práticas. Digo isso porque o RUP apenas sugere algumas boas práticas para o desenvolvimento de software, e não implica que nenhum software será entregue caso as práticas do RUP não sejam seguidas.

    Cheguei a ler o RUP 5.0 inteiro, no que compete a papéis do analista, e pude observar que o RUP possui todas as orientações para o desenvolvimento de um software.

    O que as pessoas querem saber quando te perguntam: Você sabe RUP?

    O RUP, além de ser um framework de boas práticas, possui uma série de templates de artefatos a serem entregues nas diversas fases do desenvolvimento de software. Quando alguém te pergunta se você conhece RUP, está se referindo ao seu conhecimento quanto ao uso destes artefatos em cada fase do projeto.

    Mas não são artefatos demais?

    Sim, são. Porém, existem alguns artefatos que são “padrão” de uso e exigidos na maioria dos processos de desenvolvimento de software, e outros que são apenas complementos, ficando o usuário do RUP livre para decidir quais artefatos serão necessários.

    Como o RUP, que é um “manual”, consegue saber da necessidade diária do meu projeto?

    Aí é que está a mágica: ele não sabe. Mas possui uma série de técnicas que são comuns à maior parte dos projetos, e pode ser adaptado conforme a necessidade.

    RUP é o Waterfall, ou Processo Sequencial Clássico?

    Essa é uma das maiores confusões em relação ao RUP. O rup possui as quatro fases de desenvolvimento do software, a seguir:

    • Iniciação
      • A meta dominante da fase de iniciação é atingir o consenso entre todos os envolvidos sobre os objetivos do ciclo de vida do projeto. A fase de iniciação tem muita importância principalmente para os esforços dos desenvolvimentos novos, nos quais há muitos riscos de negócios e de requisitos que precisam ser tratados para que o projeto possa prosseguir. Para projetos que visam melhorias em um sistema existente, a fase de iniciação é mais rápida, mas ainda se concentra em assegurar que o projeto seja compensatório e que seja possível fazê-lo.
    • Elaboração
      • A meta da fase de elaboração é criar a baseline para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da fase de construção. A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que têm grande impacto na arquitetura do sistema) e de uma avaliação de risco. A estabilidade da arquitetura é avaliada através de um ou mais protótipos de arquitetura.
    • Construção
      • A meta da fase de construção é esclarecer os requisitos restantes e concluir o desenvolvimento do sistema com base na arquitetura da baseline. A fase de construção é de certa forma um processo de manufatura, em que a ênfase está no gerenciamento de recursos e controle de operações para otimizar custos, programações e qualidade. Nesse sentido, a mentalidade do gerenciamento passa por uma transição do desenvolvimento da propriedade intelectual durante a iniciação e elaboração, para o desenvolvimento dos produtos que podem ser implantados durante a construção e transição.
    • Transição
      • O foco da Fase de Transição é assegurar que o software esteja disponível para seus usuários finais. A Fase de Transição pode atravessar várias iterações e inclui testar o produto em preparação para release e ajustes pequenos com base no feedback do usuário. Nesse momento do ciclo de vida, o feedback do usuário deve priorizar o ajuste fino do produto, a configuração, a instalação e os problemas de usabilidade; todos os problemas estruturais mais graves devem ter sido trabalhado muito antes no ciclo de vida do projeto. No fim do ciclo de vida da Fase de Transição, os objetivos devem ter sido atendidos e o projeto deve estar em uma posição para fechamento. Em alguns casos, o fim do ciclo de vida atual pode coincidir com o início de outro ciclo de vida no mesmo produto, conduzindo à nova geração ou versão do produto. Para outros projetos, o fim da Transição pode coincidir com uma liberação total dos artefatos a terceiros que poderão ser responsáveis pela operação, manutenção e melhorias no sistema liberado.

    Mas isso não significa que cada fase só executará uma vez, ou que elas tenham dependência para início. O gráfico das baleias mostra exatamente como deve ser o ciclo de vida do projeto:

    Como é possível verificar, a modelagem de negócios acontece durante todo o projeto, por exemplo. A parte de requisitos é forte durante as fases de Iniciação e Elaboração, mas continua durante todo o projeto, assim como as demais disciplinas. Isso diferencia o RUP do Waterfall, que possui uma única iteração ao longo do projeto, com interdependências entre fases.

  • 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.

  • Como atender os usuários utilizando Pacotes de Software

    Quais tipos de requisitos são necessários para escolha de um pacote de software de prateleira (COTS package)?

    Desenvolver requisitos para escolher um software de prateleira é diferente de desenvolver requisitos para um sistema feito "em casa", mesmo que uma RFP (request for proposal) não seja nada mais que um pacote de requisitos. Estas dicas ajudarão com requisitos para escolha de um pacote.

    Ajude seus usuários a encontrar seus objetivos e necessidades primárias antes de agendar demonstrações.

    Vendedores de software dão demonstrações excelentes de seus produtos. Eles mostram funcionalidades surpreendentes, coisas que os usuários de negócio nem sabiam que existiam. Isso pode ocasionalmente distrai-los das necessidades principais que motivaram a procura por um produto no mercado. Trabalhe com os stakeholders para definir objetivos prioritários e utilize uma abordagem ágil de priorização. Por exemplo, os stakeholders definiram a lista de funcionalidades que eles precisam e então priorize as top 5 ou 10. Faça com que eles concordem que você não escolherá um pacote até que as 5 ou 10 necessidades sejam satisfeitas, não importa o quão impressionante seja a demonstração! Dê as necessidades aos vendedores para que eles possam guiar a apresentação pelas necessidades.

    Converse com a área técnica para verificar suas necessidades e limitações. Você pode economizar tempo eliminando fornecedores que não se encaixam no plano de arquitetura antes das demonstrações começarem.

    Requisitos não-funcionais são a chave.

    Juntamente com os requisitos não-funcionais fornecidos pelo negócio, as limitações e requisitos não-funcionais fornecidos pela área técnica são alguns dos requisitos mais importantes para incluir na RFP. Todo pacote contábil fornece planilhas de contas, então sua escolha será baseada em outras necessidades. Por exemplo:

    – Qual a velocidade de acesso a uma conta?

    – As contas podem ser alteradas?

    – Qual o nível de precisão garantido para os cálculos?

    – Qual a dificuldade para fazer um relatório personalizado?

    – Os dados podem ser exportados para outros pacotes?

    Interfaces são caras.

    Em alguns ambientes, interfaces entre o pacote de software e o legado serão custosos, consumindo tempo de parte do projeto. Identificar todas as interfaces antes da escolha e ter uma estratégia manual ou técnica para cada migração de dados. Descobrir que um pacote não consegue se comunicar com outro depois de implantado é um erro muito caro.

    Reconheça lacunas.

    Nenhum pacote pronto de software satisfará todas as necessidades dos usuários. Discuta as escolhas com todos os stakeholders e certifique-se que as expectativas são realistas.

    Este material foi traduzido da newsletter do IIBA®, pela autora deste blog.

  • InfoQ: Como terminar histórias sem deixar bugs para trás

    Artigo muito bom da InfoQ sobre histórias em Scrum.

    InfoQ: Como terminar histórias sem deixar bugs para trás.

  • Se ninguém te entende… a culpa é sua. Ou nossa.

    Minha mãe não entende o que eu faço para viver. Minha namorada também não. A maioria dos meus amigos que não são da área também não. Para todos eles eu trabalho com computadores. E ponto.

    Antes que vocês achem que eu estou em crise, o problema é pior, porque não é meu, é nosso. Realmente este texto é sobre uma crise, a crise de identidade da nossa área, a área de desenvolvimento de software. Essa crise nos ataca de fora para dentro. Isso porque nós, desenvolvedores, não temos nenhuma dúvida de quem somos, do que fazemos, para que fazemos, porque isso é importante, útil e por aí vai.

    charge-problema.jpg

    O problema é que a grande maioria de nossos clientes não entende nenhum desses aspectos. Eles sabem que "mexemos" no computador, essa caixa misteriosa que faz coisas, resolve problemas e às vezes quebra.

    Sem o mínimo de conhecimento da nossa área pelos clientes, negociar se torna uma tarefa tremendamente difícil. Terminamos sendo obrigados a utilizar metáforas de áreas mais próximas ao cliente para que o ele possa entender nossos jargões e processos.

    O problema é que, como toda tradução por similaridade, o resultado é cheio de imperfeições. E o ruído dessa tradução ruim é um dos motivos de muitos projetos se tornarem muito mais complicados do que deviam.

    Esse é um dos motivos pelos quais terminamos presos a práticas da engenharia civil (muita gente deve ter sentido um arrepio ao ler isso).

    Por exemplo, quando falamos em "construir" um software, já começamos a nos enredar por metáforas que inicialmente parecem claras, mas não são. Afinal, se algo vai ser "construído", é como uma "obra". "Obra" tem prazo. Se eu construo uma casa em dois meses com dez operários, com vinte eu faço na metade do tempo. Então, com vinte desenvolvedores…

    Pronto, confusão feita. Como tirar a metáfora da cabeça do cliente agora? Como conseguir introduzir conceitos como escopo negociável, entregas parciais, e todas estas outras práticas que são inerentemente da nossa área?

    Acho que a solução vai parecer utópica, mas é bem verdadeira. Precisamos dar visibilidade ao que fazemos, ao processo de como um software é desenvolvido. Daí o cliente teria base para entender as metáforas, pois as entenderia adaptadas ao nosso contexto.

    "Marcelo, você está ficando doido. Você quer ensinar o cliente a programar?" Isso seria ótimo, mas não é isso.

    Os "não engenheiros" entendem a complexidade de construir uma ponte, mesmo sem nunca ter construído uma. Os "não médicos" entendem de como uma operação pode ser complicada, e como tem consequências.

    Isso ocorre porque essas áreas, de uma maneira ou outra, conseguiram expor para o mundo dos "não da área" seu funcionamento, alguns dos seus processos, os desafios do seu dia a dia e por aí vai.

    O funcionamento da engenharia civil é exposto pela sua presença maciça ao redor de todos nós. Todo mundo já construiu ou conhece alguém que construiu algo. A medicina perdeu boa parte de seus "mistérios" com os seriados médicos. Depois de Plantão Médico, Grey’s Anatomy e House, todo mundo arrisca seus diagnósticos.

    Precisamos também tirar essa aura de mistérios do nosso trabalho e aproximá-lo das pessoas. O ensino de programação básica nas escolas (tão comum fora do Brasil) seria uma excelente opção. A criação de textos, blogs e livros que fizessem uma ponte com os leigos também seria algo excelente. E o principal, se cada um de nós gastasse um pouco de tempo explicando a alguém próximo (pai, mãe, namorada, amigo) o básico, os meandros do desenvolvimento, acho que com o tempo novas possibilidades de comunicação surgiriam.

    Porque é muito mais fácil negociar com alguém que tem um mínimo de noção do que você está falando. Quando o engenheiro fala que não pode mudar aquela pilastra de lugar, as pessoas entendem. Quando o médico fala que a operação no menisco vai ter um pós-operatório de dois meses, ninguém questiona.

    Seria bom se pudéssemos simplesmente falar com o cliente, e não convencê-lo de que são necessárias três semanas para alterar aquela funcionalidade, não é? Bom, só depende da gente. A caminhada é longa, então é melhor começarmos logo. Ou então continuaremos chorando, falando que ninguém nos entende

    ***

    Fonte da figura: www.cartoonstock.com/directory/c/computer_programer.asp

    mf.gif via iMasters por Marcelo Costa

  • Empresas modernas não bloqueiam redes sociais

  • A realidade e os perigos do Bullying Corporativo

    A realidade e os perigos do Bullying Corporativo O assunto que trago para vocês não é muito agradável, mas de extrema importância para a tão necessária e valorizada qualidade de vida. Diariamente, muitos trabalhadores passam por imensos constrangimentos dentro de seu universo de trabalho e nem sempre se dão conta sobre a gravidade desses fatos. Um risinho hoje, uma exclusão amanhã, aquele apelido desconfortável… Atitudes assim podem ser indícios do chamado Bullying Corporativo.

    Esse tema, amplamente discutido na mídia nos últimos meses por conta dos absurdos ocorridos nas escolas, também está presente no universo corporativo, causando sérios prejuízos para suas vítimas. Bullying é uma palavra de origem inglesa que se refere a agressões verbais, psicológicas ou mesmo físicas “disfarçadas” de brincadeiras. Ocorre quando um grupo ou um indivíduo supostamente mais forte exerce poder sobre um indivíduo mais fraco.

    São vários os indícios de Bullying Corporativo:

    • Chantagem;
    • Comentários maldosos sobre a aparência, orientação sexual, local onde mora e roupas usadas;
    • Pressão durante a execução de atividades;
    • Depreciação da qualidade do serviço realizado;
    • Insinuações de incompetência;
    • Uso abusivo de poder hierárquico.

    Essas agressões podem ser identificadas entre colegas de trabalho e mesmo entre gestores e seus colaboradores. Algumas razões que levam os agressores a praticarem essa violência são a sua baixa autoestima e a necessidade de demonstrar poder perante aos amigos. Enfim, trata-se de uma manifestação de poder e força onde um indivíduo acaba escolhendo outro para “servir de modelo” aos demais.

    As conseqüências para a vítima são inúmeras, chegando a depressões graves e até mesmo síndrome do pânico. A solução para acabar com esse tipo de violência pode ser a intervenção do setor de Gestão de Pessoas. Mas para que isso ocorra é preciso que a vítima não se cale e relate o problema em busca de ajuda e orientação, mesmo que o Bullying venha de seu superior hierárquico. Difícil decisão, eu sei.

    Para a psicóloga Clarice Barbosa, “a melhor forma de acabar com as ações do Bullying é não se intimidar ou ter medo. É preciso que a vítima tenha provas, como gravações, para poder provar dentro da empresa o que está ocorrendo. Quanto mais provas ela tiver, mais ela vai poder expor essa pessoa. Mas se fica fragilizada, a outra pessoa ganha poder, além disso, é possível consultar um advogado para saber como se proteger. É preciso atenção para identificar o problema nas empresas.

    Não sou especialista em Bullying, por isso falei brevemente sobre o assunto, mas acredito que disse o necessário para alertar você sobre a sua existência dentro das empresas e a importância de acabar com essas práticas que comprometem a vida e a dignidade de muitos trabalhadores.

    Você já passou ou conhece alguém que foi vítima de Bullying Corporativo? O que pensa sobre esse assunto? Compartilhe conosco sua experiência e opinião.

    Crédito da foto para freedigitalphotos.net.

  • A diferença entre analista de sistemas e de negócios

    Negócios e sistemas para desenvolvimento: o trabalho do analista de sistema deve ser em sintonia com o analista de negócios, que possui maior percepção dos processos internos da empresa.

    Por Ricardo Veríssimo

    Este texto é sobre a diferença entre analista de sistemas e analista de negócios (sem contar com a função analista programador, da qual não concordo).

    Ao participar em uma consultoria para melhoria de processos de controle interno e administração em uma empresa da área médica, presenciei um acontecimento muito sintomático para exemplificar as atuações nos campos de análise de negócios e análise de sistemas.

    Segue em resumo a conversa entre três atores da vida real: um coordenador de TI (contratante de um sistema), uma analista de sistemas (contratada do sistema a ser desenvolvido) e uma coordenadora de marketing (na baia de trabalho ao lado).

    O coordenador e o analista discutem os requisitos e funcionalidades para uma parte de um sistema e repetem:

    – Isso! Assim vai ficar ótimo.

    A coordenadora, que escutava a conversa na baia ao lado (e que para o bem da empresa era intrometida), disse:

    – Assim não vai funcionar, pois os médicos não vão usar desta forma por este e aquele motivo.

    Nesta história a coordenadora agiu como a analista do negócio – pois conhece como os processos acontecem realmente e tem o domínio do negócio. Essa é a diferença entre analista de negócios e analista de sistemas.

    Sou da área de TI, mas infelizmente é grande o número de profissionais que acreditam saber tudo e não lançam mão de analistas de negócios dentro da própria empresa para conhecimento e melhoria do que está sendo desenvolvido.

    Analista de sistemas deve saber as melhores práticas de desenvolvimento, conhecer técnicas de desenvolvimento e levantamento de requisitos, mas não precisa conhecer de todos os ramos e nichos de mercado. Isso é para o (a) analista de negócio.

    Na empresa deste caso existe um sistema cheio de problemas nos processos de negócios, pois foi usada a figura do analista programador. O resultado: os erros do programador estão sendo descobertos pelo cliente, pois a análise do criador na criação parece que não foi imparcial. Será que alguém acredita que existe análise imparcial nestes casos?

    Será que existe engenheiro pedreiro? Por outro lado, muitos pedreiros chegaram a ser engenheiros.

    Um bom programador pode e deve se tornar um analista e vai ajudar muito os programadores. Mas nada garante também que um bom programador será um bom analista e vice-versa, assim como nada garante que um bom vendedor de loja será um bom gerente.

    Minha opinião neste assunto não é, e nem pretende ser, a única e a verdadeira. Não espero que ninguém concorde comigo e todas as críticas são bem-vindas e serão respondidas. Os comentários dos leitores da Webinsider são importantes e ajudam a melhorar e aprender mais com os leitores. Abraços a todos e até o próximo artigo. [Webinsider]

  • InfoQ: Será que os Casos de Uso tem lugar no SCRUM ?

    Veja isso:

    InfoQ: Será que os Casos de Uso tem lugar no SCRUM ?.