Metodologias

Métodos Ágeis: É Importante a Certificação?

g2996Neste artigo vou abordar a importância da certificação em métodos ágeis. O uso de métodos ágeis como uma abordagem para gerenciamento de projetos tem aumentado dramaticamente nos últimos anos. O Gartner prevê que os métodos ágeis serão utilizados em 80% de todos os projetos de desenvolvimento de software.

Uma pesquisa feita pelo PMI mostrou que o uso de práticas ágeis tem aumentando drasticamente ao longo dos anos. Além disso, a pesquisa demonstra o valor que métodos ágeis podem ter na redução de defeitos do produto, melhorando a produtividade da equipe, melhoria na entrega e aumento do valor comercial.

O PMI-ACPSM está posicionado para reconhecer e validar o conhecimento desta importante abordagem. Com a disseminação do gerenciamento de projetos e do constante desenvolvimento de suas ferramentas, os profissionais da área vem se confrontando com um mercado próspero–porém muito complexo.

Devido ao crescimento desse mercado ocorreu também a expansão de diversos cursos de especialização na área de gerenciamento de projetos, praticamente em todas as cidades de médio/grande porte existem dezenas desses cursos. Tendo em vista à evolução do gerenciamento de projetos, o PMI, reconhecendo as necessidades do mercado, oferece diferentes certificações, entre elas a PMI –Agile Certified Pratictioner (PMI-ACP) resultado do ambiente de negócios dinâmico em que hoje as diferentes organizações atuam.

O aumento do número de cursos por um lado proporciona o fomento da área e a formação de massa crítica, porém a falta de padronização e muitas vezes a dissonância com as práticas do Guia PMBOK® criam dúvidas sobre a qualidade de muitos cursos e consequentemente sobre o conhecimento de alguns profissionais.

A grande necessidade de ganhar competitividade estimula as empresas a operar em mercado mais amplos, cooperando e competindo para melhorar sua qualidade e preço, isso gera muitos gastos e para compensar os mesmos, há uma grande necessidade em agregar valor à empresa. Essa realidade vivida pelo setor mais tradicional do gerenciamento de projetos se adéqua melhor quando se utiliza o método ágil, por esse setor ser relativamente novo quando comparado ao gerenciamento de projeto tradicional.

Pensando um pouco sobre a questão do desenvolvimento, esse desenvolvimento se faz presente em diversas áreas do conhecimento técnico e assim, são utilizadas certificações profissionais, pois essas representam o reconhecimento da habilidade e experiência no uso das técnicas e aplicação de conhecimentos, assim, mantendo um diferencial e adicionando confiabilidade ao currículo de cada profissional. Deve ser visto em seu sentido mais amplo a comprovação formal dos conhecimentos, habilidades, atitudes e capacidade do profissional, requeridos para a execução de uma determinada atividade.

As melhores práticas do gerenciamento de projetos difundidas e consolidadas, em sua forma tradicional, começaram a serem questionadas. Em uma área do gerenciamento de projetos envolvida intensamente com desenvolvimento tecnológico de software como o gerenciamento ágil de projeto, as mudanças técnicas são constantes e extremamente rápidas.

Para atender as demandas desses projetos tecnológico o gerenciamento ágil de projetos utiliza ferramentas que focam as entregas ao invés das extensas documentações.

Onde estão os valores e princípios?

Para os Valores, temos:

  • Indivíduos e interações 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;

Para os Princípios, temos:

  • Maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado;
  • Mudanças nos requisitos são bem vindas, mesmo tardiamente no desenvolvimento;
  • Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente;
  • Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo;
  • Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto;
  • Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho;
  • O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face;
  • Software funcionando é a medida primária de progresso;
  • Os processos ágeis promovem desenvolvimento sustentável;
  • Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente;
  • Contínua atenção à excelência técnica e bom design aumenta a agilidade;
  • Simplicidade — a arte de maximizar a quantidade de trabalho não realizado — é essencial;
  • As melhores arquiteturas, requisitos e designs emergem de equipes auto organizáveis;
  • Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo;

O PMI apresenta uma certificação (como citada anteriormente), que cumpre o propósito de padronizar e disseminar o gerenciamento ágil de projetos, reunindo as seguintes exigências de conhecimentos práticos e teóricos dos certificados: educação secundária (ensino médio ou equivalente) ou superior, 2.000 horas de trabalho em projetos adquiridos nos últimos 5 anos, 1.500 horas de trabalho em projetos -usando técnicas ágeis -adquiridos nos últimos 2 anos, 21 horas de treinamento em Gerenciamento Ágil de Projetos.

Os conceitos Ágeis através de diferentes métodos e processos, foram sendo incorporados no gerenciamento de projetos e sua utilização aplicada em diversas organizações. Não poderia deixar de adicionar ao texto, as principais vantagens do gerenciamento ágil de projetos:

  • Retorno mensurável do investimento mais cedo, entrega iterativa de incrementos dos produtos;
  • Alta visibilidade do andamento do projeto, permite a identificação precoce e resolução ou monitoramento de problemas;
  • Envolvimento contínuo do cliente em todo o ciclo de desenvolvimento do produto;
  • Melhoria na satisfação e motivação dos times de desenvolvimento do projeto;
  • Poder ao proprietário da empresa para tomar decisões necessárias para atingir as metas;
  • Adaptação à evolução das necessidades de negócio, dando mais influência sobre as mudanças de requisitos;
  • Redução dos resíduos do produto do processo;
  • Maior pontualidade na entrega. Estimativas mais realistas, clientes mais envolvidos e satisfeitos

A intensiva competitividade na área de desenvolvimento de software faz com que as empresas busquem sempre o aperfeiçoamento de seus serviços para poder vencer a concorrência. Prazo e qualidade, além é claro de melhor aceitação e adaptação a mudanças são importantes diferenciais que podem ser atingidos utilizando-se metodologias ágeis de desenvolvimento. Embora não seja a solução para todos os problemas, a metodologia ágil mostra uma maneira de trabalhar bastante organizada e iterativa, podendo inclusive contribuir para um ambiente de trabalho mais amigável, portanto é uma boa opção para se obter os diferencias desejados.

Em um mundo qualificado pelo desenvolvimento tecnológico e pela dispersão do uso de software em praticamente todas as áreas do conhecimento humano, faz-se necessário um novo tipo de gestão para os projetos.

O mundo hoje depende de projetos e, para muitas organizações, são eles que garantem o dia de amanhã e permite-lhes sobreviver e crescer.Assim sendo, os métodos ágeis veem respondendo de forma positiva a essas necessidades, por focar os esforços da equipe no produto final e nas necessidades do cliente, relevando à segundo plano o processo de documentação exaustivo. Uma vez que as empresas estejam ao par de tais metodologias e as principais ferramentas utilizadas na Gestão de Projetos aprendido na prática o que tange às certificações, então será possível um maior alcance nas credenciais e certificações.

O PMI veem trabalhando para criar um padrão para os métodos ágeis através do PMI-ACP Examination Content Outline e da certificação PMP-ACP. Outro ponto relevante do PMP-ACP é a re-certificação, a qual difunde as práticas do gerenciamento ágil e estabelece a necessidade de constante aprimoramento dos profissionais certificados.

Espero que tenham gostado do artigo.

Márcio Pulcinelli @ OminaVIncit


Referências:

[1] LEFFINGWELL, Dean and MUIRHEAD, Dave, Tactical Management of Agile Development: Achieving Competitive Advantage. 2004. Boulder, Colorado

[2] SOARES, Michel dos Santos, Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. Unipac-
Universidade Presidente Antônio Carlos, Faculdade de Tecnologia e Ciências de Conselheiro Lafaiete

[3] Agile Manifesto, Disponível em http://agilemanifesto.org/

[4] SCHWABER , Ken, What Is Scrum?

[5] www.scrumalliance.org

[6] PMI. Profissional Certificado em Métodos Ágeis.Disponível em:http://brasil.pmi.org/brazil/CertificationsAndCredentials/PMI-ACP.aspx/.


Um Pouco Sobre Estimativa Ágil

Pensando na Estimativa Ágil

O principal ponto é pensarmos em um objetivo que desejamos atingir.
Quando começamos a planejar como atingiremos um objetivo, pensamos nas tarefas que precisamos completar e no que é necessário em termos de recursos – esforço, tempo, dinheiro. É importante frisar que a estimativa é a base de todos os projetos, seja ele, Ágil ou tradicional.
A confiabilidade de um cronograma está diretamente ligada às estimativas utilizadas para sua elaboração. Obviamente, que as estimativas não têm por objetivo serem 100% precisas, por isso chamam-se estimativas.

Métodos Diferentes?

Áreas diferentes possuem métodos diferentes de estimativa. Pegamos como exemplo o desenvolvimento de sistemas, um método denominado Análise de Pontos de Função é utilizado, algumas vezes, para estimar os módulos do software. Na construção, o método de estimativa de escolha é o Método de Quantidade Total e assim cada área tem a sua forma de medir as estimativas. Geralmente, o SCRUM usa StoryPoints como referência.

A Estimativa Relativa no SCRUM é feita por uma equipe que utiliza uma ou mais histórias de referência, com as quais trabalhou no passado e cujo esforço despendido e complexidade são conhecidos. Todas (ou quase todas) as novas histórias de usuário são estimadas em relação às histórias de referência.

Nesse processo de estimativa:

  1. o ProductOwner explica a história com informações e definições adicionais.
  2. todos os membros da equipe estimam a história relativamente.
  3. um consenso é alcançado.

0 processo de estimativa fará mais sentido à medida que formos abordando os outros demais conceitos de estimativas SCRUM.

O que é Estimativa Participativa?

É importante falar sobre esse tipo de estimativa. No livro A sabedoria das multidões, James Surowiecki citou uma história em que uma multidão, em uma feira agrícola, estimou o peso de um boi. Calculou-se a média dos palpites individuais, que chegou mais próxima do peso real do boi do que as estimativas individuais da maioria dos integrantes da multidão e as estimativas separadas, feitas por especialistas de gado. Tenha isso em mente.

Mesmo a equipe SCRUM sendo menor do que muitos considerariam uma multidão, o conceito é exatamente o mesmo utilizado no parágrafo anterior. Devemos usar a sabedoria coletiva da equipe para fazer a estimativa. E se pararmos para pensar, esse conceito é bem diferente do conceito de estimativa tradicional.

Entenda que ao estimar módulos de um software, por exemplo, uma pessoa com credencial de Especialista Certificado em Pontos de Função (CFPS) vai desenvolver estimativas de software quase que independentemente.

Utilizando o SCRUM é diferente. As pessoas não estimam softwares “aleatoriamente”. Uma abordagem típica de estimativas coletivas ou participativas é o “poker planning”.

Poker Planning

O poker planning começa com todos os integrantes de uma equipe SCRUM segurando uma série de cartas. Essas cartas têm números escritos, geralmente seguindo a sequência Fibonacci. Depois que o Product Owner explica a história de usuário que está sendo estimada, a equipe faz perguntas até que a definição da história esteja clara. Um membro da equipe designado pode registrar decisões relativas às definições.

Uma vez que a equipe compreendeu, completamente, a intenção da história, deve escolher, em alguns minutos, a carta que representa os Story Points para a história em questão. A equipe mantém a carta sobre a mesa, virada para baixo. O moderador costuma ser o SCRUM Master.

Quando o moderador indicar, todos os integrantes da equipe mostram suas cartas. Se um ou mais integrantes chegaram a um número muito baixo ou muito alto, têm a chance de explicar seu raciocínio.

O jogo de cartas continua até que os integrantes da equipe cheguem a um consenso sobre a estimativa mais adequada, não necessariamente exata, para a história. Esse processo não só gera as estimativas, mas, a partir da discussão e da colaboração, pode levar a um melhor entendimento comum e a uma apropriação da iteração.

Ernst Weber e Gustav Fechner levantaram, no século XIX,  a hipótese de que a percepção humana da intensidade, a exemplo do som e da luz, é mais proporcional, aproximadamente, ao logaritmo da intensidade do que da intensidade em si. O mesmo princípio é empregado quando a série de Fibonacci é utilizada para enumerar as cartas usadas no Planejamento de Pôquer. É um texto complexo porém a utilização das cartas é simples.

Estimativa Ágil Usando Série de Fibonacci

350px-Poker_fibonacci

Pensemos no esquema gráfico visto na seção anterior. As cartas levam os números 1, 2, 3, 5, 8, 13, 21, ….

Cada número é a soma dos dois números anteriores. Em alguns casos, os números são arredondados, para cima ou para baixo, para o 5 ou 0 10 mais próximo. Frequentemente um 0 e um 1/2 também são adicionados. 0 (zero) representa uma história que não exige nenhum esforço apreciável para desenvolver. Por exemplo, uma outra história, já sendo concluída, finalizará essa história.

Geralmente, o ponto de interrogação é usado para indicar que um integrante da equipe não tem conhecimento suficiente da história para estimá-la e, e assim, necessita de mais discussão e maior detalhamento da história.

O símbolo do infinito é usado para indicar que uma história é grande demais para ser estimada, ou um épico, precisa ser dividida em histórias menores.

Veja que equipes SCRUM diferentes desenvolvem métodos, protocolos, processos e cartas diferentes, que funcionam melhor para cada equipe. Ou seja, o objetivo é fazer a estimativa relativa e participativa usando uma escala não linear, como a sequência de Fibonacci.

No próximo artigo falarei sobre Gráficos Burndonw. Espero que tenham gostado deste artigo.


Cobit e os Desafios da TI

cobit(1)

Neste artigo trago alguns desafios que o CobiT endereça no alinhamento estratégico da TI com as áreas de negócio da empresa.

Diversas organizações (normalmente grandes e médias empresas) investem grandes somas de dinheiro e recursos na área de TI. De fato, a área de negócio necessita contar com o suporte de TI para as operações de seu negócio e assim, alcançar os objetivos estratégicos da empresa. As organizações diariamente encaram o desafio de ter que se adaptar as demandas dinâmicas dos negócios e ainda precisam lidar com os riscos inerentes a própria complexidade da área de TI.

Manter a TI funcionando corretamente de forma otimizada gerando valor para o negócio, minimizar os custos atrelados a tecnologia e ao próprio contingente de recursos, gerenciar a complexidade do ambiente, definir o alinhamento correto entre a própria TI e as demais áreas de negócio, manter sempre alinhada a questão da conformidade regulatória e gerir a segurança das informações e da própria organização são alguns dos desafios enfrentados hoje e onde o CobiT é bastante útil.

cobit~fsOs problemas típicos no que diz respeito a manter a TI funcionando, advém de possíveis falhas técnicas para os processos críticos para o negócio como por exemplo, o processamento de pedidos estar fora do ar, pessoal incapaz de lidar com o dia a dia das atividades que devem ser executadas, e ainda clientes incapazes de se comunicar com a empresa para solicitar novos produtos e serviços. Estes são alguns problemas que podem ter como resultado a perda de negócios, reduções nos lucros e até danos na reputação da organização.

As empresas sempre precisam garantir a continuidade dos seus serviços críticos de negócio, caso contrário o fracasso é inevitável.

Outro ponto de extrema importância é a questão da geração de valor para a organização. Tendo em vista os investimentos significantes feitos na área de TI e consequentemente a importância estratégica dos projetos de TI, essas mesmas organizações precisam garantir que a TI forneça valor para o negócio. Os grandes problemas na maioria dos projetos de TI, que excedem expectativas orçamentárias ou de prazo de entrega são: requisitos definidos de forma ineficientes (quando não errados), sistemas muito complexos para implementar, esforço necessário subestimado, gerenciamento de projetos de forma imatura, além de outros aspectos não tão diretos. As empresas precisam identificar quais os projetos mais adequados e executá-los dentro do prazo e orçamento para que desta forma possa entregar o valor adequado para a organização.

COBITA questão dos custos é crítico e um desafio para a área de TI. Os principais motivos para despesas elevadas são: os custos associados aos ativos de TI não são compreendidos por toda a organização, orçamentos operacionais aumentam devido à complexidade dos contratos de licenciamento, manutenção e da própria terceirização, existe carência por profissionais capacitados, grandes perdas financeiras ocorrem devido a projetos fracassados e ainda pode-se observar os gastos de TI pelas unidades de negócios e departamentos de TI não são coordenados. Desta forma, a gestão dos custos de TI precisam ser gerenciados da mesma forma que os demais custos significativos do negócio. Requer processos e alocações de recursos eficazes e também eficientes, tais como, pessoas e tecnologia.

Outro desafio para a TI está relacionado com a gestão das complexidades da própria TI. Ou seja, é necessário manter as competências técnicas, gerenciar as diversas infraestruturas técnicas, adaptar-se à mudanças rápidas e novos desenvolvimentos, gerenciar os relacionamentos externos com os fornecedores de serviços e produtos. Assim, a TI deve estar organizada e gerenciada para que as organizações possam ser capaz de lidar com as complexidades e evitar custos excessivos.

O alinhamento da TI com os negócios é de extrema importância. Na maioria das empresa, a diferença entre o que os usuários esperam e o que a TI pode fornecer existe por algumas razões: requisitos de negócio definido de forma deficiente, incapacidade de definir prioridades, complexidade dos projetos, falta de responsáveis do negócio comprometidos, falta de definição dos condutores de negócio para as soluções e também uma lacuna nas comunicações entre TI e negócio. Sendo assim, as organizações precisam garantir que TI tenha uma parceria com o negócio para, desta forma, entregar valor.

Conformidade regulatória é outro fator que define os desafios de TI. Os regulamentos que governam as operações de negócio impactam fortemente os sistemas de TI. A TI precisa estar ciente de todos os requisitos legais e regulatórios nacionais e internacionais (dependendo de cada caso) a que eles estão relacionados. Como exemplo, tempo a governança corporativa, relatórios financeiros, privacidade corporativa e segurança das informações. As organizações precisam garantir a conformidade legal e contratual para não ter sua credibilidade abalada.

O desafio de TI relacionado com a segurança é um ponto de atenção constante, pois o desejo de tornar a informação disponível através do uso de tecnologia conduz a riscos na segurança. Alguns fatores são: O uso da internet e de redes que expõe sistemas internos para o mundo, vírus e hackers, o aumento do uso mal intencionado das informações, as complexidades técnicas dos ambientes de TI e os problemas associados com a segurança, pouca conscientização sobre as questões de segurança dos usuários. Sendo assim, as empresas precisam garantir uma segurança adequada em seu ambiente de negócios e TI.

Para tratar destas questões, o CobiT fornece um modelo de governança corporativa de TI para que seja possível um alinhamento estratégico entre TI e negócio, onde garante que os objetivos sejam alcançados, estabelecendo que os riscos sejam gerenciados de forma apropriada verificando a utilização apropriada e com responsabilidade dos recursos da empresa.

 

 

 

Espero que tenham gostado.

Márcio Pulcinelli @ OminaVincit!


Diagrama de Atividades e Sua Utilização

UML---HighLembro-me que uns anos atrás, quando comecei a estudar a UML, os diagramas de atividade não eram muito bem compreendidos pela maioria dos analistas. Era como se aquela peça tivesse sido colocada no lugar de algo que não pertencia ao quebra cabeças da UML, entretanto depois de algum tempo quebrando a cabeça para entendê-lo, passou a ser uma das peças mais importantes para a fase após a identificação dos requisitos do sistema.

Mas então, o que é e para que é usado o diagrama de atividades? É fácil de entender, que uma atividade é um determinado estado de estar fazendo alguma coisa em um determinado momento no tempo. E aqui pode ser usado como um processo do nosso dia-a-dia (mundo real). Como, por exemplo, pedir uma pizza por telefone, ou uma execução sistêmica (processo de software) tal como a execução de uma rotina em C++/Java/C# e etc. para calcular distâncias orbitais entre os planetas, calcular o imposto de renda e etc.

O diagrama de atividades foi criado para descrever a sequência de atividades, tendo também suportes para comportamentos condicionais e paralelismo. Os comportamentos condicionais são delineados pelos desvios chamados de “branches” e pelas intercalações chamadas de “merge”.

Um “branche” é uma transição de entrada, que deve ser única, com várias transições de saídas. É importante observar, que somente uma transição de saída pode ser tomada por vez, de modo que a operação deve ser mutuamente exclusiva. Exemplo, a utilização de [else] como uma sentinela indica que a transição “else” deverá ser usada se a condição for falsa.

image

Um “merge” tem múltiplas transições de entrada e somente uma única saída. Sendo assim, um “merge” marca o final de um comportamento condicional iniciado pelo “branche”. Gosto sempre de frisar que não é necessário explicitar o losango para desvios e intercalações, uma atividade pode ter múltiplas transições de saída e múltiplas transições de entrada, por isso, use o losango se você desejar deixar claro cada desvio e intercalação em relação as regras de negócio.

Para efetuar o comportamento paralelo usa-se Separações “Forks” e Junções “Joins”. Vamos primeiro falar das separações e em seguida das junções.

Um “Fork” tem uma transição de entrada e diversas transições de saída (ao menos duas). Quando acionamos uma transição de entrada, ou seja, executamos um trigger, todas as transições de saída podem ser executadas em paralelo (não quer dizer que elas serão executadas simultaneamentes).

image

Isso significa dizer que a sequência entre elas não é relevante. Quando você tem uma separação (Fork), o que importa são os caminhos individuais de cada uma das separações. Um exemplo seria, no caso de dois departamentos de uma empresa trabalhando para entregar um determinado produto ao cliente, ou seja, um departamento poderia estar trabalhando na embalagem do produto enquanto outro poderia estar trabalhando na emissão da nota fiscal.

É importante dizer que o diagrama de atividades permite que se escolha a ordem que se vai executar as atividades. Ele determina as regras essenciais de sequência que devem ser seguidas. Um fluxograma, por exemplo, não tem habilidade para lidar com processos e atividades em paralelo. O que é de grande importância para a modelagem de regras de negócios.

Existe uma linha de modelagem de requisitos que troca as descrições de casos de uso por diagramas de sequencia. Eu inclusive vejo com bons olhos esse formato de trabalho, uma vez que substitui conteúdo textual, muitas vezes ambíguo, pro uma linguagem formal e gráfica, evitando erros de conceito e ainda agilizando o processo no momento de se alterar um determinado requisito de negócio que está obsoleto.

Ainda citando a utilidade dos diagramas de atividade, eles são muito úteis para modelar programas (rotinas) que fazem uso de mult-thread ou processamento paralelo, ainda mais nos dias de hoje em que temos processamento em grid, cloud computing, processadores com multicores e etc. Cada vez mas se faz necessário modelos para processamento paralelo, e é aí que os diagramas de atividade ganham mais força.

Para finalizar o comportamento de uma separação (“Fork”) é preciso sincronizar cada uma das separações que foram abertas. Apresentamos este conceito com a junção (“Join”). Com a Junção, a transição seguinte só ocorre quando todos os estados nas transições de entrada tenham completado suas atividades passando assim ao próximo estágio do fluxo.

image

Sempre as separações (“Forks”) e junções (“Joins”) devem se completar, ou seja, sempre que houver uma separação, uma junção deverá ocorrer em algum momento futuro. Existem algumas exceções para essa regra, mas basicamente essa é a regra da utilização de “Forks” e “Joins”.

Existe a possibilidade de adicionar ainda um thread condicional ao seu diagrama. Esse tema é um pouco complexo e deve ser muito bem pensado quando for modelado, mas é basicamente o seguinte: existe uma exceção para a regra de que todos os estados de entrada de um “Fork” devem ter suas atividades finalizadas antes que o “Join” possa ser efetuado. Aí que entra o thread condicional, você pode adicionar uma condição para um thread saindo de um “Fork”. Observe que se a condição para esse thread for falsa, esse thread é completado no que tange a junção (“Join”). Apresento abaixo um exemplo de Thread condicional para ilustração do que foi dito.

image

Outro conceito importante dos diagramas de atividade é a decomposição de uma atividade. Uma atividade pode e (dependendo do caso) deve ser decomposta para melhor entendimento das atividades que a compõe. Esta questão da decomposição das atividades fica a cargo do analista de negócios/sistemas, pois depende do grau de granularidade que se deseja obter na analise destes requisitos. Um exemplo que poderia ser dado para ilustrar é o de uma atividade de Entrega que pode ser decomposta em Entrega Regular e em Entrega Expressa. Dentro da ativdade “Entrega” detalha-se a atividade apresentando as sub-atividades pertencentes àquela atividade macro.

image

No próximo artigo abordarei mais dois conceitos: Concorrência Dinâmica e Raias (Swimlanes). O mais importante aqui (neste artigo) é entender que o diagrama de sequência é uma ferramenta bastante poderosa e sua aliada quando se fala em analise de sistema e negócio. Você pode (e deve) usá-la para analisar uma caso de uso, para compreender um determinado workflow, descrever um determinado algoritmo complicado e também lidar com aplicações de processamento paralelo.


Espero que tenham gostado do artigo.

Márcio Pulcinelli @ OminaVincit!


Planejamento da Arquitetura de TI

imageNeste artigo abordarei a questão da arquitetura de TI dentro do ambiente corporativo.

Atualmente uma empresa dá início as suas atividades quando você colocar os dois primeiros computadores juntos em rede, e a partir deste momento a complexidade cresce a cada instante. Práticas de “building blocks” de TI podem facilmente levar a uma rede corporativa mal planejada ou ainda ser compostas de projetos desenvolvidos como objetivos específicos sem ser levado em consideração o objetivo e direção em que a empresa deseja caminhar.

Um projeto de virtualização de servidores podem ter dificuldades de ser implementado se não for devidamente coordenado com os projetos de consolidação de servidores para se certificar de que ha largura de banda suficiente e recursos de host disponíveis quando os sistemas forem transferidos de um ambiente físico para os seus correlatos virtuais.

Claro que, estes cenários são simplesmente exemplos de potenciais conflitos que podem ocorrer quanto ao realinhamento empresarial e a redução de custos, estratégias de conduzir projetos independentes, sem coordenação e orientação a nível estratégico. Por este motivo, todo cuidado é pouco na hora de se construir a estratégia de TI/TIC na sua empresa. Além dessas questões, existem muitos outros conflitos que são muito mais sutis e não aparentes como uma incompatibilidade entre protocolos de comunicação que devem dar suporte a um novo equipamento ou falta de suporte executivo, que deixa a adoção de práticas empresariais em um frouxo estado de escolha.

Como encontrar a melhor solução para sua empresa?

Para inicio de conversa, não existe uma solução perfeita que se adapte completamente a estratégia de arquitetura corporativa. Se a tecnologia cumpre os requisitos, se adequa de forma eficiente, suporta processos de negócio, é rentável e pode ser apoiada e mantida, ela é uma solução aceitável, talvez até uma boa solução. Sendo assim, não há “melhor” tecnologia, apenas a melhor tecnologia para sua empresa e talvez essa tecnologia necessite de um amadurecimento evolutivo constante para chegar a um estado ideal.

Como não poderia ser diferente, a tecnologia deve apoiar os negócios, e não o contrário. Tecnologia deve apoiar os processos de negócios e alinhar com os objetivos estratégicos da sua organização. A escolha da tecnologia não deve limitar a funcionalidade de sua organização ou objetivos futuros. Que isso fique bem claro. Não existe tecnologia hoje para atender a sua empresa? CRIE NOVAS TECNOLOGIAS para lhe dar apoio e suporte.

Proporcionando liderança

Para ser um arquiteto corporativo eficaz, você deve fornecer a liderança para o processo de tomada de decisão. Compreender o impacto gerado por cada seleção de tecnologia e facilitar a comunicação das estratégias, políticas, controlar a equipe de implementação e os clientes.

Um arquiteto corporativo deve possuir o alinhamento junto ao negócios e grandes conhecimentos tecnológicos, a fim de filtrar através de exigências e preferências dos usuários, ou seja, o que ele quer do que realmente é necessário para que este execute seu trabalho.

Uma outra consideração que coloco é que como um arquiteto, você deve identificar tendências tecnológicas futuras, oportunidades para apresentar sinais de avanço e de desenvolvimento ambicioso e ainda buscar requisitos de segurança em constante evolução para garantir que a empresa no estado atual está devidamente preparada para atender soluções e tecnologias que estão por vir em um futuro próximo. Se não houver um planejamento cuidadoso e testes exaustivos, a integração de novos itens como atualmente o imensamente popular tablet pode ser uma catástrofe em redes corporativas.

Você deve ter a firmeza necessária para persuadir as pessoas envolvidas e os principais interessados, ​​que algumas escolhas tem que ser feita a partir de uma perspectiva mais ampla, a fim de colher os maiores benefícios para a organização em geral. Você deve ser capaz de falar confortavelmente com diretores e usuários finais, mas também deve ter suficientes credenciais técnicas e compreensão para ser levado a sério pelas pessoas da linha de frente e os membros da equipe técnica.

A pior coisa que você pode fazer é apresentar estratégias para o corpo técnicos e demonstrar falta de experiência do mundo real no qual está lidando, sem suficiente capacidade técnica jamais será levado a sério. Quando se perde o respeito e apoio dos técnicos de TI pode ser impossível recuperar este respeito, e as melhores estratégias possíveis serão ignoradas ou contornadas. Para trabalhar de forma eficaz, você é obrigado a continuamente a aumentar as suas próprias habilidades de TI através de estudo e de novas formações.

Aqui fica um pensamento meu no que diz respeito a um membro não técnico, puramente gerencial. Nunca deve tentar ditar políticas técnicas ou estratégias porque falta compreensão da complexa teia de interligação que forma a rede da empresa dos dias de hoje. Sendo assim, tome muito cuidado com isso, pois este é um ponto sério a ser considerado.

Tenha em mente, que o líder técnico, que não consegue manter suas habilidades atuais rapidamente se torna um líder não técnico, devido à rápida evolução das tecnologias em uso e da maneira em que são consumidas pelos clientes e “trabalhadores do conhecimento”.

Lembre-se sempre de considerar como parâmetro, um arquiteto de TI cujas habilidades foram desenvolvidas antes da evolução do service-oriented design de arquitetura, computação em nuvem, virtualização de armazenamento e hardware e etc… Este arquiteto não será capaz de efetivamente reconhecer o valor potencial dessas tecnologias e ter o poder e o conhecimento de adiciona-las as operações da organização – ou entender as limitações, custos e impacto de integra-las na empresa existente.

Espero que tenha gostado deste artigo. Ele teve como objetivo uma breve apresentação ao mundo dos arquitetos corporativos e de TI.

Qualquer questão entre em contato. Até o próximo artigo!

Márcio Pulcinelli @ OminaVincit