Gestão de processos e projetos ágeis

How to Fix Your Documentation Problems?

2014-12-10T17:32:00.003-02:00

Fonte: http://www.payton-consulting.com/fix-documentation-problems/

O que esperar do futuro pós nuvem?

2014-11-24T08:47:00.000-02:00

Aqui estão algumas tendências não muito distantes

Ainda hoje, Cloud Computing é vista como uma perturbação da ordem estabelecida. Mas um dia - que não está muito longe - ela vai representar status quo. Como será ele?

Aqui estão algumas tendências que podemos esperar:

1 - Escalas enormes

Todos os sistemas serão projetados para processar quantidades gigantescas de dados. Cada aplicativo será elástico, para responder às mudança de fluxo nas correntes de bytes. Quando sistemas forem desenhados, ninguém perguntará sobre capacidade, porque partirão do pressuposto de que a capacidade poderá ser infinita. Portanto, os esforços de design vão presumir isso, não importa quantos dados uma aplicação possa estar gerenciando ou quantas máquinas virtuais a topologia do programa possa conter, ele deverá ser capaz de expandir para suportar mais. Em essência, podemos presumir que sistemas serão projetados para um mundo da “ilusão da infinita capacidade”.

2 - A Internet das coisas será realidade

O CTO da Cisco previu que, em um futuro próximo, um trilhão de dispositivos estarão ligados à internet. Há muitas pessoas que preveem que estamos entrando na era pós-PC.Significa que além dos aparelhos com os quais os humanos vão interagir da forma tradicional, como os smartphones, tablets, etc, estaremos cercados por um número muito maior de dispositivos de propósito específico, dedicados a execução de determinadas funções, que se comunicarão com programas centralizados rodando na nuvem, e que por sua vez irão interagir com algo que nós, ou alguém usando nosso proxy, vai achar valioso.

Por exemplo, não vamos precisar olhar para o nosso relógio para saber a nossa pressão sanguínea. O relógio vai medir a pressão e enviá-la para o sistema de monitoramento, que vai gerar um alerta para o profissional de saúde, baseando-se em uma experiência médica e nas especificidades da nossa saúde individual. Usaremos cada vez mais dispositivos como este relógio, equipados com sensores, e ubíquos, a ponto de sequer prestarmos atenção a eles, a menos que haja necessidade.

Não é fácil entender como isso vai acontecer. Mesmo os trabalhadores dessa indústria, que deveriam entender a dinâmica do processo, subestimam constantemente o que vai acontecer. Uma década atrás, em um debate com o CEO de uma empresa de chips análogos que equipava o protótipo de um refrigerador inteligente, ele chegou a afirmar que, no futuro, o refrigerador teria uma interface na qual você poderia fazer sua lista de compras baseado em diferentes níveis de observação dos alimentos armazenados. Duvidei de que que a caixa de leite poderia determinar que estaria com nível baixo e então contatar o refrigerador para adicionar leite à lista. Ele respondeu que essa funcionalidade sairia muito caro, na época, para uma caixa de leite. Uma resposta que levava em conta suas tradicionais suposições sobre custo/funcionalidade para a discussão, em vez de extrapolar a tendência que, efetivamente, hoje se impõe.

Em retrospecto, é claro que ele estava subestimando como as coisas aconteceram. Na verdade, é claro que eu estava subestimando as coisas. Hoje é claro que a caixa de leite vai conversar com o aplicativo da lista de compras in-cloud e essa app iria contatar o mercado selecionado para organizar seu pedido semanal de caixas de leite. É por isso que a internet das coisas vai resultar em “aplicativos” muito além do que podemos imaginar.

3 - O custo dos componentes de TI cairá vertiginosamente

Não me refiro a chips ou drives de disco. Falo de cada elo da corrente de fornecedores de TI. Sistemas operacionais, middleware, softwares serão muito mais baratos. Se não, eles serão substituídos por programas open source gratuitos.

Por que posso prever tal coisa? É óbvio: se você vai prever a escala antes, os componentes individuais vão baixar de preço. Hoje, escuto muitas pessoas opinando que vendedores de software “não permitiriam” a mudança para a nuvem para reduzir seus preços ou lucratividade. Tenho novidade para os que compartilham essa opinião: Os fornecedores não têm escolha. Se os atuais fornecedores resistirem à tendência, novos participantes com preço amigável irão substituí-los.

Paradoxalmente, os gastos totais em TI aumentarão muito. Em certos setores de cloud computing há muita discussão sobre o Paradoxo de Jevon, que afirma que redução de custos de um bem ou serviço,em vez de reduzir gastos totais, na verdade, os aumenta. O crescimento terá como motor o fato de que as funcionalidades em TI insuflam as ofertas de negócio atuais. Toda nova oferta de negócios contém TI, portanto, o aumento de todas as iniciativas vai aumentar o investimento em TI. A diferença entre essa situação e as circunstâncias atuais é que o setor de TI não será uma função de apoio à função do escritório, mas pré-requisito para lidar com clientes. A Tecnologia da Informação vai atingir seu tão desejado papel de parceira de unidades de negócios.

4 - TI reestruturará a TI

O lado ruim de ser parceiro de negócios está no negócio. O surgimento de novos provedores de nuvem públicas gerou um benchmark de comparação para a oferta de serviços feita epla equipe interna de TI. Não ser capaz de oferecer transparência comparável aos serviços comerciais, facilmente contratados, será o beijo da morte.

Na decisão da estratégia de implementação o custo será um entre muitos fatores, incluindo privacidade, requerimentos como largura e latência de banda para os aplicativos, etc, que podem determinar se o aplicativo é implementado interna ou externamente. A suposição de que a decisão padrão de implementação seja a interna, se tornou uma fantasia. CIOs espertos vão reconhecer que seu papel é gerenciar a infraestrutura, não possuindo equipamentos. Já os menos informados vão ser ultrapassados pelos próprios usuários. O que já começa a acontecer.

Junto com essa tendência de contratação na cloud direto pelas áreas de negócio, o maior desafio que as organizações de TI encontrarão no caminho para a era pós-cloud é o suporte aos sistemas legados. Eles representam uma enorme habilidade de TI para se alinhar com as demandas de usuários do negócio. No mundo pós-nuvem não será suficiente gerenciar aplicativos legados com o menor gasto possível. Mesmo com esse investimento, esses aplicativos carregam um alto custo de estrutura e manutenção. Custo esse muito mais alto que as ofertas de cloud disponíveis. Nesse cenário, a equipe de TI terá que ser muito mais agressiva e pró-ativa para fazer todas as coisas necessárias. Todo CIO precisa avaliar os sistemas atuais e montaram um plano para reduzir o custo, incluindo entre as opções a migração para um SaaS equivalente ou a terceirização de operações para um provedor mais barato.

5 - PaaS será o local onde estar

Muitas pessoas pensam da computação em nuvem como máquinas virtuais sob demanda. A indústria está se movendo rapidamente para além disso. Os desenvolvedores de aplicativos perdem seu tempo quando têm de contratar arquitetos para implementar escalabilidade e elasticidade. A infraestrutura deve lidar com isso, liberando os desenvolvedores de aplicativos para focar na funcionalidade do negócio, não no encanamento. O caminho para isso é a adoção do modelo de Plataforma-como-serviço (PaaS).

No pós-nuvem o departamento de TI dependerá muito de PaaS, usando uma organização interna ou externa para gerenciar a funcionalidade básica e a infraestrutura. Será talvez a única forma de gerenciá-los da maneira mais eficiente e de baixo custo sem abrir mão de proporcionar um ambiente aumente a produtividade dos desenvolvedores de aplicativos.

6 - Haverá escassez de bons desenvolvedores de aplicativos

O Paradoxo de Jevon significa uma explosão de demanda em TI. Em particular, uma demanda de criadores de aplicativos. Pessoas que saberão como construir ofertas de negócios integrando múltiplos aplicativos em um novo, implementando chamadas para APIs de serviços externos que terão uma demanda muito alta. Mesmo o surgimento do PaaS - paradoxalmente - aumentará a demanda por desenvolvedores de aplicativos.

cio.com.br

5 Common Problems with Scrum adoption

2014-11-23T23:53:00.000-02:00

During the recent past, it has been a rat race that many organizations wanted to go the agile way of working, irrespective of their ability to change and work towards being agile. Often, organizations try to adapt to Scrum (since it is one the most popular framework in agile), but fail miserably due to several reasons. Some of the common problems are listed below.

No support from Senior Leadership

Often, senior leaders may be willing to support the transition, but turn negative after they fully understand the effort it takes for an organization to become truly agile. Leadership must be willing to “lead from the front” by providing necessary support and spearheading the organizational change and communication.

Existing Organizational Structures and Hierarchies

Existing structures can hinder successful adoption. The biggest pit fall is the organization leadership tries to tweak Scrum to force-fit into the existing organization structure and hierarchy. Some of the tweaks that are like to happen are;

Managers jumping to role of Scrum Master still using a command and control style of leadership,

Individuals working in silos without a team concept,

Product Owners being pushed into the job without knowing the roles, responsibilities, and time committments.

Scrum Master being unduly influenced by managers.

The existing process overhead in the organization may be too much for the team to carry on every sprint. No one really bothers to simplify the existing processes to the extent that the team starts self-organizing and delivers working software. The teams selectively apply scrum principles and eliminate the ones which are difficult to adapt given the circumstances. The Product owners often don’t have the seniority and decision making power they need to be successful.

Distributed teams

Scrum works well for co-located teams, distributed teams present a different set of challenges. Senior leadership face a stiff resistance in breaking the distributed team culture, since managers do not trust the remote teams completely. In addition, the distributed portion of the team is often under the control of a 3rd party vendor with a completely different management chain.

The biggest challenge with distributed team is that they don’t behave as ONE team. It is very much important that frequent contact among the team members, may be very effective, even though it is electronic. To make scrum adoption successful, it is a prerequisite that organizations must invest in high fidelity communication equipment infrastructure to enable smooth communication between the distributed teams. Added to that, organizations may also understand the necessity of tools for continuous integration, code reviews, unit testing and automation. Scrum may not work well if tools that improve the quality of the product are not in place. The desired results may be disappointing until the necessary tools in place to helps the teams to become distributed teams hyper productive.

Regional Organizational culture

Regional culture always plays a dominating role deciding the Scrum adoption. Asian cultures like India, Vietnam, Thailand, Philippines, China, Japan, Malaysia, and Singapore struggle to adapt Scrum as per Scrum guide. These cultures are particularly inclined towards hierarchy status and titles. When promoting agile methods, which warrant high transparency and honesty, it is very difficult to make the changes in culture necessary. In some Asian cultures the word “Servant Leader” has a negative meaning of lesser social status. Added to the chaos, imposing performance appraisal bell curves also make people to show case their individual heroism than the team work.

Unavailability of human skills

There is a dearth of agile skills in the open job market. Experienced and high functioning product owners, scrum masters, technical leads, and team members are in short supply. Agile methods also embrace the need for specialized technical skills like test automation, build automation, devops and continuous delivery. These skills are very much in demand in the marketplace, and so every organization is competing to attract people with these skills.

Suggestions to overcome common problems:

Executive management need to understand that, being Agile is not a goal unto itself, Agile should be used as an enabler to accomplish business goals.

Engage enterprise Agile Coaches with significant experience in facilitating the right outcomes. Fully leveraging these coaches will make a huge difference to organizations rather than trying to solve these issues with internal staff.

Executive management need to understand that Agile transformation is a major organizational change and not merely project level coaching. So every support functions in an organization need to support agile transformation.

Lot of executive support and direction may be required for agile adoption, to push the change top down the layers and they have to continuously monitor the progress and remove organizations impediments that surface time-to-time.

The past transformation approaches show that, some organizations take a top-down approach while others take bottom-up, however, the results show that no single approach works perfectly, it largely depends on how organizations absorbs the change within its culture.

There needs to localized strategies made for every country culture, given the regional cultural differences, to make the agile transformation successful, while keeping the end goal same.

Not having the right human skills in an organization will impact the agile transformation significantly. It is important that organizations keep their skilled people on standby, before they start the transformation.

Do not force-fit agile into the existing organization structure and hierarchy, in fact there are many organizations out there, who tweak agile frameworks that fit into their existing structure and hierarchy, which is the biggest pit fall.

http://www.payton-consulting.com/

Agile Team Working Agreements

2014-11-23T14:19:00.002-02:00

http://www.payton-consulting.com/

Dez passos para a implantação de projetos de Business Intelligence

2014-07-25T10:36:00.000-03:00

É essencial aprender com os erros de outros para que um projeto não falhe.

No passado, as companhias gastavam muito dinheiro com BI, mas nem sempre conseguiam alcançar os resultados pretendidos. Prova disso, as reclamações dos usuários sobre a falta da qualidade dos dados e a dificuldade de utilização dos sistemas e ferramentas de BI, assim como relatórios incompletos ou dados imprecisos que impactam a tomada de decisões. Estas debilidades são causadas por fraquezas funcionais e organizacionais na implementação de projetos de Business Intelligence.

Particularmente para novos projetos de BI, é essencial aprender com os erros de outros para que o projeto não falhe. A Information Builders compilou 10 regras de ouro para a implementação.

1. Definir os requisitos funcionais.

Comparações por indicadores de desempenho (KPI – Key Performance Indicators) são o centro de qualquer aplicação de BI. A equipe do projeto, composta por colaboradores do departamento de TI e de outros departamentos especializados, deve determinar que informação deve ser disponibilizada pelas aplicações de BI, quando é necessário estar disponível e em que formato.

2. Definir os grupos de utilizadores.

A equipe do projeto deve definir quem são os utilizadores da solução de BI. Existem geralmente três grupos de utilizadores: utilizadores gerais de relatórios; os produtores e analistas que avaliam os dados; e finalmente os gestores que decidem os objetivos.

3. Envolver os utilizadores numa fase inicial.

Na fase inicial, o departamento de TI deve criar um protótipo simples da solução. Desta forma, pode ser feita uma revisão para assegurar que os requisitos essenciais serão incluídos desde o início. Na implementação de um projecto de BI, os colaboradores dos departamentos especializados devem sempre ser incluídos paralelamente, uma vez que são esses indivíduos que, no futuro, irão trabalhar com as aplicações. Quando se testar o protótipo, esses colaboradores podem determinar se o projeto segue o escopo.

4. Ter apoio da Gestão.

A equipe do projeto deve ter apoio da gestão. Esta é a única forma de garantir que os objetivos corporativos a curto e longo prazo sejam incorporados. A implementação é monitorizada pela comparação de indicadores de desempenho (KPI) permanentes dos rácios operacionais mais importantes.

5. Identificar os Indicadores de Desempenho (KPI) requeridos.

São necessários valores operativos para a gestão dos processos de uma companhia. A equipe de projecto deve defini-los em conjunto com o departamento especialista. No manuseamento e produção de materiais, por exemplo, indicadores de desempenho tais como “custo do material por cada componente” ou “volume de negócio por colaborador” são variáveis provadas. Isto torna mais fácil determinar se os objetivos foram alcançados ou não.

6. Garantir a integração e qualidade dos dados.

Integração dos dados é um fator decisivo para o sucesso de um projeto de BI. A equipe deve identificar os sistemas operacionais nos quais a informação requerida está disponível e como os dados devem ser acessados. Para informação atualizada, o acesso direto é a melhor opção. Se a qualidade dos dados brutos não for suficiente, isso deverá ser melhorado com as ferramentas de software apropriadas para acessar todas as fontes de dados.

7. Descubra que ferramentas de BI já estão disponíveis na empresa.

Quando um novo projeto é iniciado, é necessário determinar se as ferramentas existentes para os usuários finais devem continuar a ser utilizadas ou se devem ser substituídas completamente. Na maioria dos casos, a padronização num único sistema de BI é preferível para garantir consistência na disponibilização da informação dentro da empresa.

8. Escolher o Software de BI correto.

Com uma Proof-of-Concept (PoC), a equipe de projeto decide o software mais adequado, baseando-se geralmente em um briefing específico. Este procedimento permite à equipe de projeto garantir com maior grau de certeza de que o software se adequa ao seu negócio.

9. Limitar o tempo de execução do projeto.

Aqui aplica-se a velha regra: “Tudo o que dure mais que seis meses deixa de ser um projeto e passa a ser um problema.” Quando se implementa um novo projeto de BI, os departamentos especializados devem estar centrados e proceder em claros passos definidos. Os subprojetos devem ser desenvolvidos para que os primeiros módulos executáveis e operacionais estejam disponíveis depois de dois ou três meses.

10. Um projeto de BI é um processo constante.

Os requisitos das companhias mudam constantemente e o mesmo se aplica a uma aplicação de BI. Todas as soluções de BI têm de ser continuamente desenvolvidas e otimizadas em uma base permanente. Esta é a única forma que têm de cumprir os requisitos.

“O BI é, antes de tudo, uma tarefa de controle, compras, marketing e vendas. Os departamentos de negócio estão familiarizados com os requisitos individuais em termos de gestão da performance funcional e sabem que parâmetros e dados necessitam para controlar os seus processos de negócio”, afirma Klaus Hofmann zur Linden, Technical Manager Germany da Information Builders em Eschborn. “O departamento de TI deve construir a infra-estrutura para as aplicações de BI e assegurar uma operação de confiança”.

Fonte: CIO

Manifesto das Regras de Negócio

2013-07-26T19:48:00.001-03:00

Os princípios da independência da regra

por Business Rules Group

Artigo 1. Requisitos como elementos principais, nunca secundários

1.1. As regras são um cidadão de primeira classe no mundo dos requisitos.

1.2. As regras são essenciais para os modelos de negócio e para os modelos de tecnologia, sendo uma parte separada e específica dos mesmos.

Artigo 2. Independentes dos processos, não contidas neles

2.1. As regras são restrições explícitas de comportamento e/ou proporcionam suporte ao comportamento.

2.2. As regras não são processos nem procedimentos, pelo que não devem estar contidas em nenhum deles.

2.3. As regras aplicam-se transversalmente a processos e procedimentos. Deve existir um corpo coeso de regras, que se aplique de forma consistente a todas as áreas relevantes de atividade de negócio.

Artigo 3. Conhecimento explícito, não um sub-produto

3.1. As regras constroem-se sobre fatos, e os fatos sobre conceitos que são expressos por termos.

3.2. Os termos expressam conceitos de negócio; os fatos constituem asserções sobre estes conceitos; as regras restringem e suportam estes fatos.

3.3. As regras devem ser explícitas. Nunca se deve assumir nenhuma regra sobre nenhum conceito ou nenhum fato.

3.4. As regras são os fundamentos que definem o que o negócio sabe de si mesmo – isto é, são o conhecimento base do negócio.

3.5. As regras necessitam de ser alimentadas, protegidas e geridas.

Artigo 4. Declarativas, não procedimentais

4.1. As regras devem ser expressas de forma declarativa em frases de linguagem natural, perceptíveis pela audiência conhecedora do negócio em causa.

4.2. Se algo não pode ser expresso, então não é uma regra.

4.3. Um conjunto de enunciados só é declarativo se não contém uma sequência implícita.

4.4. Todo o enunciado de regras que precise de outros elementos para além de termos ou fatos, requere assunções sobre uma implementação de sistema.

4.5. Uma regra é distinta de qualquer medida definida para o seu cumprimento. A regra e a forma do seu cumprimento são questões distintas.

4.6. As regras devem definir-se independentemente de quem é responsável pelo

seu cumprimento, e de onde, quando e como se fazem cumprir.

4.7. As exceções às regras são expressas por outras regras.

Artigo 5. Expressões bem formadas,não Ad Hoc

5.1. As regras de negócio devem ser expressas de forma a que os especialistas do negócio possam validar a sua correção.

5.2. As regras de negócio devem ser expressas de forma a permitir verificar reciprocamente a sua consistência.

5.3. As lógicas formais, como a lógica de predicados, são fundamentais para a expressão formal, bem formada, das regras em termos de negócio, assim como para as tecnologias que implementam estas regras.

Artigo 6. Arquitetura baseada em regras, não uma implementação indireta

6.1. Um sistema baseado em regras de negócio é construído intencionalmente para permitir a mudança constante das regras de negócio. A plataforma sobre a qual o sistema é executado deve suportar esta evolução contínua.

6.2. Executar diretamente as regras – por exemplo através de motores de regras – é uma estratégia de implementação melhor que transcrevê-las de forma procedimental.

6.3. Um sistema de regras de negócio deve ser sempre capaz de explicar as razões pelas quais chega a uma conclusão ou toma uma ação.

6.4. As regras baseiam-se em valores de verdade. A forma como se determina ou mantém o valor de verdade de uma regra é mantida oculta dos usuários.

6.5. A relação entre eventos e regras é geralmente de muitos-para-muitos.

Artigo 7. Processos orientados às regras, não programação baseada em exceções

7.1. As regras definem a fronteira entre uma atividade de negócio aceitável e não aceitável.

7.2. As regras requerem frequentemente um tratamento especial ou seletivo das violações detectadas. Qualquer atividade derivada da violação de uma regra constitui uma atividade como qualquer outra.

7.3. Para assegurar a consistência e a reutilização máxima, o tratamento de atividades de negócio não aceitáveis deve separar-se do tratamento das atividades de negócio aceitáveis.

Artigo 8. Ao serviço do negócio, não da tecnologia

8.1. As regras tratam de práticas e orientações do negócio; portanto, as regras são motivadas pelas metas e os objetivos de negócio, e são moldadas por diversas influências.

8.2. As regras implicam sempre um custo para o negócio.

8.3. O custo da aplicação das regras deve ser valorizado e balanceado, tendo em consideração os riscos assumidos pelo negócio, e as oportunidades perdidas no caso de não as aplicar.

8.4. “Mais regras” não é necessariamente melhor. Normalmente é preferível ter poucas mas “boas regras”.

8.5. Um sistema eficaz pode basear-se num número pequeno de regras. Posteriormente,podem adicionar-se regras mais específicas de forma que ao longo do tempo o sistema se torne mais inteligente.

Artigo 9.“De, por e para” as pessoas do negócio, e não “de, por e para” as pessoas de TI

9.1. As regras devem provir das pessoas conhecedoras do negócio.

9.2. Os especialistas do negócio devem dispor de ferramentas que os auxiliem a formular, validar e gerir regras.

9.3. Os especialistas de negócio devem dispor de ferramentas que os ajudem a verificar consistência recíproca entre regras de negócio.

Artigo 10. Gerir lógica de negócio, não plataformas de Hardware/Software

10.1. As regras de negócio são um ativo vital do negócio.

10.2. A longo prazo, as regras são mais importantes para o negócio que as plataformas de Hardware/Software.

10.3. As regras de negócio devem ser organizadas e armazenadas de forma que possam ser facilmente redistribuídas para novas plataformas de Hardware/Software.

10.4. As regras, e a capacidade de as alterar de forma eficaz, são fatores chave para melhorar a adaptabilidade do negócio.

Fonte: Copyright, 2003. Business Rules Group. Versão 2.0, Novembro 1, 2003. Editado por Ronald G. Ross.
www.BusinessRulesGroup.org

Cresce a demanda por profissionais de TI com visão de negócios

2013-03-26T12:06:00.000-03:00

Ter conhecimento do negócio facilita a conversa com o gestor e a administração de projetos

O número de empresas que planeja contratar profissionais de tecnologia continua crescendo. É o que revela a pesquisa Previsões para 2013, realizada pela COMPUTERWORLD nos Estados Unidos, com 334 executivos de TI. Mais de 30% deles (33%) disseram que planejam aumentar seus quadros nos próximos 12 meses. Este é o terceiro ano consecutivo que a percentagem de respondentes com planos de contratação aumenta. Em 2012, o incremento foi de 29%, 23% em 2010 e 20% em 2009. Todos comparados aos anos anteriores.

O mercado está aquecido também no Brasil, em razão da expansão de muitas empresas, especialmente impulsionada pela proximidade dos megaeventos esportivos que serão sediados em solo nacional [Mundial de futebol e Olimpíadas]. Cenário, portanto, favorável para quem busca uma oportunidade. Mas as chances não são para todos. É necessário ter as habilidades corretas, que estão na mira de CIOs e executivos de TI.

Segundo Mariana Horno, gerente sênior da divisão de Legal, RH e TI, da Robert Half no Brasil, consultoria especializada no recrutamento de talentos, por aqui os profissionais de TI devem apresentar conhecimento técnico aprofundado e certificações correlatas a esse conhecimento específico.

“Além disso, o perfil comportamental tem sido importantíssimo. É necessário, na maior parte das vezes, boa comunicação, ser mão na massa e dedicado”, garante. A executiva diz perceber atualmente uma movimentação corriqueira, demandando profissionais no segmento de meios de pagamento, e-commerce e indústria farmacêutica.

“O primeiro trimestre do ano costuma ser mais moroso no processo de contratação, por conta das férias de verão e do Carnaval. Porém, é bom buscar oportunidades e a possibilidade de conseguir um emprego é alta”, relata, acrescentando que é preciso ter paciência, pois pode ser que o tempo de processo demore um pouco mais por conta do número reduzido de dias úteis no período.

“Hoje, temos, em média, entre 20 e 25 vagas de TI por mês. Esse número é um pouco variável, pois há algumas em andamento e outras que chegam durante a semana”, avisa.

De acordo com Cristiani Martins, diretora comercial da Atlantic Solutions, consultoria da área de TI, percebe-se hoje forte demanda por profissionais especializados em web. “Os chamados desenvolvedores Java cloud estão em alta”, afirma e destaca que para o crescimento na carreira, hoje é necessário ter capacidade para gerenciar projetos, conhecimento de processos (ITIL) e, especialmente, visão de negócios. “Treinamos muitos profissionais e eles costumam buscar especialização em governança de TI e em Java Mobile.”

“Quando você olha para qualquer tendência de pesquisa ou de mercado, TI é sempre um dos dois primeiros ou três tópicos mencionados como ponto brilhante no mercado de trabalho, e é muito simples o motivo”, diz John Reed, gerente-executivo sênior da Robert Half nos Estados Unidos. Segundo ele, é porque ela define os rumos da empresa, visto que melhora a produtividade e acelera a realização de melhores decisões de negócios. “Portanto, as empresas estão investindo nisso, e você tem de ter pessoas experientes nessa tarefa”, recomenda.

Para o diretor de TI do Grupo Fleury, Claudio Laudeauzer, quando se fala em habilidades de profissionais de TI no grupo, leva-se muito em conta a paixão pelo que faz, trabalho em equipe, simplicidade de ações, criatividade e visão ampliada.

“Damos preferência a quem possui MBA, porque tem visão focada em business. Além da técnica, teve a oportunidade de trocar ideias e experiências com os colegas”, destaca. “Aqui, a tecnologia não é por tecnologia.”

Laudeauzer diz que, no atual mundo digital, são necessários profissionais antenados com tendências como aplicativos móveis e mídias sociais, que tragam oportunidades para o Fleury. “O mundo está mudando e precisamos fazer o melhor para o cliente e surpreendê-lo.”

O Grupo Fleury planeja fortalecer a equipe em 2013 e conhecimentos em mobilidade e segurança da informação são algumas das exigências. “Mas teremos de treinar esses colaboradores para o novo cenário, contudo, dentro da corporação. Não adianta impor regras, temos de educar”, ensina. E alerta: “Temos de transmitir a paixão pelo trabalho. O ambiente estará seguro com a conscientização.”

Para as contratações no próximo ano, o executivo diz que as competências técnicas vão depender das necessidades internas, mas existe demanda para profissionais especializados em BI, BA, CRM, e tudo o que aprimore o relacionamento com o cliente. “É preciso ter capacidade de transformar dados em informação. Em qualquer tipo de negócio.”

O momento na Spaipa, fabricante e distribuidora Coca-Cola, também é de crescimento. Por isso, há busca por talentos, segundo Claudio Antonio Fontes, Cio da companhia.

“O perfil técnico passa por algumas áreas. Mas recrutamos profissionais especializados em diferentes tecnologias para bancos de dados e ERP, por exemplo. Isso porque a ideia é abrimos o leque para conhecimento em outras plataformas, incluindo sistemas operacionais”, revela.

Fontes destaca que o profissional deve ter formação técnica muito forte e conhecimento profundo nos diversos níveis. “De júnior a sênior, tem de ser bom no escopo que ocupa, compondo as habilidades necessárias para cada uma das funções”, diz.

Inglês e espanhol são requisitos padrão no setor, segundo Fontes. “Alguns colegas já pedem também o alemão”, relata, acrescentando que preferencialmente busca candidatos em polos de formação como universidades federais e estaduais e particulares de maior reconhecimento nacional.

“Estamos de olho no profissional disposto a fazer trabalhos colaborativos. Quanto mais ele estiver preocupado com o outro, nos interessa bastante”, revela, brincando que está à procura dos “arquitetos” de “alguma coisa”. “Virou a palavra da moda.”

Ele afirma que busca perfis que se alinhem aos projetos eletrônicos da empresa, que envolvem portabilidade ou mobilidade. “Eles têm de ter conhecimento de processos, um mix de analista funcional, com conhecimento técnico e das ferramentas aplicáveis a eles, para facilitar as tomadas de decisão, além de capacidade para gerenciar projetos”, aponta. “E, claro, com visão de negócios.”

Com estratégia diferenciada e de tradição, o Bradesco colhe seus frutos na Fundação Bradesco, sintetiza Aurélio Boni, vice-presidente-executivo de TI do Bradesco. “Nosso sistema de carreira é bem fechado e a fundação forma nossos profissionais.”

Segundo ele, a unidade recebe não somente parentes dos funcionários do banco, mas também reserva uma parte para o público externo. “Lá, é possível começar bem cedo. Meus dois filhos ingressaram na Fundação com quatro anos de idade, formaram-se e tiveram a oportunidade de trabalhar na instituição”, conta.

Boni afirma que o perfil que o Bradesco quer hoje de seus profissionais da área de TI é bastante moderno e reúne habilidades que possibilitem perfeito entendimento e desenvolvimento em um mundo dependente de aplicativos móveis. “Porque essas tecnologias são facilitadoras de atendimento ao cliente. Hoje, são uma exigência”, alerta.

Ele engrossa o coro unânime dos CIOs sobre a visão de negócios, que considera vital no atual cenário. “E isso não se aprende da noite para o dia. Ter conhecimento do negócio facilita a conversa com o gestor, fica mais fácil até mesmo direcionar os projetos”, relata.

Ele revela que com essa habilidade, é possível o gestor endereçar cada tipo de projeto para um profissional específico. “Promove mais segurança ao chefe da equipe, na certeza de que o trabalho será entregue. Gera confiança. É preciso ainda trabalhar em colaboração e, fundamentalmente, ter visão globalizada e muito clara do negócio”, categoriza.

Para Tania Nossa, CIO da Alcoa, atuante na área de minério de ferro, a empresa busca nos profissionais características como pensamento ilimitado, preferência pelo risco, inovação, determinação, capacidade de aprendizado, orientação para mudanças, foco em resultados e entusiasmo pelo trabalho. “E, além disso, saber compartilhar dos valores da Alcoa”, destaca a executiva que também se prepara para os novos desafios que surgirão com a chegada do novo ano e a prática de tudo o que está planejado para acontecer.

Fonte: CIO

2012-09-24T21:21:00.002-03:00

A vantagem de um Analista de Negócios para um Arquiteto de Negócios

O deserto entre TI e negócio é o nosso reino.

Temos que lutar com a semântica linguística e expulsar definições. Começamos como Analistas e podemos avançar para Arquitetos.

Nós não somos estritamente técnicos e não estamos estritamente funcionais. A definição do que fazemos normalmente é escrever em linguagem semi-tech (requisitos). Mas como é que vamos escrever esses requisitos, o que nos torna diferentes? Como podemos ver as coisas e por que vê-las da maneira que nós fazemos?

Qual é o potencial da profissão de Analista de Negócios?

O que fazemos para os supervisores, gerentes, diretores e acionistas nos ouvir?

Como é que vamos passar de Analista de Negócios para Arquiteto de Negócios?

É o que queremos?

Deixe-me definir a diferença entre um analista e um arquiteto, elas são sutis, mas vou descrever apenas alguns pontos críticos que percebo:

- Um analista de negócios gera relatórios para desenvolvedores ou gerentes de projetos de TI, quando digo relatórios, considero os insumos semi-tech que traduzem as necessidades mandatórias e não-mandatórias de uma solução. O arquiteto de negócios reporta aos gestores ou alta direção insumos que podem ser de negócios ou de TI, mas são independentes do projeto.

- Alguns documentos do analista de negócios são em parte, requisitos definidos e desenvolvidos pelos usuários. Documentos gerados por um arquiteto de negócios podem definir uma estratégia de negócio usando requisitos previstos pelos usuários.

- O analista de negócios opera dentro dos limites de uma arquitetura pré-determinada técnica. Arquiteto de negócios é uma parte do processo de decisão para definir a arquitetura técnica.

Algumas coisas mais:

- Um arquiteto é considerado uma voz neutra e por isso em alguns casos toma decisões mais críticas do que um analista de negócios.

- Um arquiteto deve ter a capacidade de pensar tanto na forma estratégica e táctica enquanto um analista é normalmente tático.

- Um arquiteto deve estar ciente das estratégias empresariais enquanto um analista é normalmente preocupado com projetos específicos independentes da estratégia da organização.

Assim, vemos que cada tipo de "BA" é necessário.

Agora, como você pode se tornar o melhor BA que pode ser?

Ou como você passar de analista de arquiteto?

Acredito que muitos analistas de negócio tem competência técnica e estrutural para assumir esses 2 "papéis", aliás conheço muitos profissionais que tem essa habilidade.

Comentem...

Fonte: http://www.businessanalyst.com/

Product Owner no Scrum: a Alma do Negócio

2012-09-04T14:50:00.000-03:00

O trabalho do Product Owner (PO) é possivelmente o menos compreendido e o mais subestimado entre os praticantes mais novos do Scrum. É ele quem transmite uma visão de negócios e prioriza os objetivos de forma a entregar valor. O PO é quem dá a direção e o propósito a um produto, envolvendo a equipe para a criação, desenvolvimento e evolução. Por isso está diretamente ligado ao sucesso (ou não) de um projeto de tecnologia.

Tendo isto em mente, o primeiro grande fator para o sucesso de um Product Owner é a coragem. Pode parecer clichê, mas não há como fugir disso. Como o PO é o responsável por equilibrar os vários interesses sobre determinado projeto, ele pode ficar tentado a atender apenas aos mais bem posicionados na hierarquia da empresa ou àqueles que mais diretamente se relacionam com ele. Sem coragem, o PO pode inconscientemente abrir mão da oportunidade de sucesso, parando de ouvir os clientes finais ou até mesmo idealizando um produto grande demais com resultados inferiores.

O PO e o cliente

Para gerenciar um produto, em particular um software, é preciso entender que mesmo um especialista precisa do feedback do usuário final. É o cliente, e apenas ele, quem poderá validar o que o há de inovador em um sistema. Aquilo que já é conhecido, ou que já foi medido anteriormente, pode até dar certo sem a validação do cliente, mas o que for o diferencial competitivo do seu produto, não. Fica no diferencial, em suas características únicas, o maior potencial de geração de valor; por isso, ouvir o cliente o tempo todo é fundamental.

A sintonia com o cliente é o que permite que o PO consiga capturar e transmitir a direção correta para os outros stakeholders e para a equipe de desenvolvimento. O contato entre a equipe e os stakeholders com o cliente final sempre será limitado, se comparado ao do PO. Por isso, o PO não deve se privar de "estar na rua", falando com seu público-alvo. Para manter essa sintonia viva e constante, precisa orientar a equipe na direção de entregas pequenas e frequentes. O produto deve ser criado de forma incremental e a cada passo as funcionalidades produzidas devem passar por um ciclo de feedback envolvendo os usuários finais. É importante observar que, quanto antes uma funcionalidade estiver em produção, sendo utilizada por usuários verdadeiros, melhor será o produto.

Qualidade relativa e qualidade absoluta

Outro ponto que pode desviar o caminho de sucesso dos gestores de um produto de software é a qualidade. Discussões intermináveis sobre este assunto são frequentes entre a equipe e o PO, com ou sem a participação de outros stakeholders. Tais discussões, além de improdutivas, podem crescer e se transformar em antagonismo, o que as tornam destrutivas para o produto, e também para a união e a motivação dos envolvidos.

O principal motivo de divergência reside em uma sutileza sobre o que é qualidade em um produto de software. Como em qualquer outro produto, qualidade é um conceito relativo. Os padrões de qualidade e os custos de se fazer um novo produto são variados e dependem de fatores como regulamentos, leis e o público-alvo. Para usar um exemplo do dia-a-dia, a qualidade exigida em um carro popular não é a mesma que a de um carro de luxo.

Podemos dizer que o PO entende qualidade como o nível de aceitação de seus clientes enquanto consumidores daquele novo produto. Este tipo de qualidade está, de certa forma, sob o controle do PO, e influencia suas decisões. Muitas vezes, a equipe não entende este parâmetro; apenas quer fazer o seu trabalho bem feito. Na verdade, é comum que a equipe leve em consideração outro tipo de medida: a qualidade no seu ciclo de desenvolvimento. Apenas para citar um exemplo, no caso de uma indústria automobilística, o PO estaria preocupado com a aceitação de determinado veículo pelo público, sendo que a equipe está mais comprometida com a qualidade do fluxo de produção.

Neste caso, ainda que as fábricas (ou unidades de fabricação) dos carros populares e luxuosos também tenham suas diferenças, elas são de fato bem mais parecidas do que a distância que existe entre os dois produtos finais: um carro pode ser desenhado para não dar defeito nunca, enquanto outro, se durar cinco anos, já estará ótimo para o fabricante. Para construir as fábricas destes carros é um pouco diferente, no entanto; ambas, é claro, foram feitas para durar e entregar vários modelos por muitos anos. Em software, não podemos abrir mão da qualidade, já que ela é determinante para a aceitação de um produto.

A qualidade do ciclo de desenvolvimento deve ser vista como absoluta, e é essa qualidade que a equipe luta para manter, enquanto muitas vezes os stakeholders não sabem do que a equipe está falando. A falta de qualidade no ciclo de produção gera um acúmulo de dívida técnica, que funciona como uma dívida de juros altos e compostos, ou seja, quanto mais postergamos o valor da dívida, maior será, e com crescimento exponencial.

A dívida técnica, quando acumulada, diminui a capacidade de mudar de direção e de se adaptar às necessidades dos negócios, que surgem em todo momento. Acaba com a agilidade. Em pouco tempo, a equipe começa a perder a velocidade de desenvolvimento e o tempo de vida útil do sistema se reduz, com crescentes custos de manutenção e evolução e capacidade de inovação seriamente limitada. É do interesse do PO manter a agilidade e a velocidade do seu projeto, então não criar dívida técnica é fundamental para todos.

Portanto, o PO deve conseguir explicar bem se a cada entrega estamos fazendo o carro popular ou o carro de luxo. E a equipe também deve deixar claro se o foco está no carro em si ou na fábrica que faz os carros.

PO, equipe e produto

A tentação de ir além do produto mínimo viável (MVP, na sigla em inglês) deve ser combatida a todo momento. É o óbvio: "o produto mínimo deve ser mínimo". O PO terá mais chance de sucesso se conhecer muito bem os seus clientes e, ao mesmo tempo conhecer muito bem o produto e a equipe responsável pela criação efetiva do software. Ser um PO significa conhecer em detalhes cada funcionalidade do produto que lidera e ser capaz de explicar aos stakeholders o que está acontecendo a qualquer tempo.

Com este entendimento nos detalhes e o feedback constante, o PO ganha embasamento para perceber novos e melhores caminhos, estabelecendo hipóteses que necessitam de um curto ciclo de entrega e feedback. Com uma boa equipe, o PO poderá validar tais inovações de forma rápida e eficaz.

Ao mesmo tempo, é necessário cuidado para não confundir o conhecimento dos detalhes com o microgerenciamento. A equipe de desenvolvimento tem capacidade e conhecimento técnicos para entregar o software pedido, e o PO se beneficia quando evita dizer à equipe como fazer o seu trabalho. O PO, em primeiro lugar, deve falar de negócios! Ele passa para a equipe suas necessidades não em termos técnicos, mas do ponto de vista do cliente, da empresa. Quando o PO permite à equipe com conhecimento técnico tomar as decisões que lhe cabem, não só a solução técnica é melhor; ele também poderá contar com uma equipe muito mais motivada e envolvida com o resultado do projeto. E assim, todos ganham.

Conhecer bem a equipe significa entender do que ela é capaz, especialmente saber traduzir as demandas de negócio para as técnicas e vice-versa . Quanto mais se estabelece este conhecimento mútuo, melhor é a comunicação e o PO se torna mais eficiente para planejar.

Deixe de empurrar funcionalidades

Com isso, chego ao ponto final: o planejamento. Planejar um produto de software é algo realmente complexo. É fundamental para o PO entender que, a partir do seu orçamento, ele não deve acreditar em um plano pré-determinado, com um conjunto de funcionalidades já estabelecidas. Ele gerencia seu orçamento semanalmente, mensalmente. Isso significa que, ao invés de uma lista de funcionalidades, o PO deve entregar objetivos de negócios.

Como e por meio de quais funcionalidades tais objetivos serão alcançados, não é conhecido no início do projeto. É apenas a execução do projeto que poderá responder. A visão prescritiva é o maior inimigo da inovação, de um produto de software e, consequentemente, do PO.

É preciso olhar além da imagem inicial que se tem do papel do PO. Pensar em uma lista de funcionalidades é menor que pensar em uma lista de objetivos. Aprovar uma funcionalidade é menor que o uso do seu cliente e um objetivo de negócio alcançado. Olhando com mais calma, o PO é mais que um papel, é a Alma do Negócio.

Fonte: INFOQ

O relacionamento entre os analistas de negócio e desenvolvedores de software.

2012-07-02T19:42:00.003-03:00

O problema mais difundido entre as “torres” na grande maioria dos casos está nos braços dos analistas de negócio, conforme estudo realizado pelo Phoenix Chapter of IIBA. Em 90% dos casos, os BA´s (business analysts) não conseguem comprometer os desenvolvedores de software com a real necessidade da área de negócios precisa.

Grandes organizações consideram os BA´s, como o MAESTRO DA TI, mas o ônus de orquestrar uma área com alto valor agregado e com grandes e competentes elementos envolvidos, considero uma arte, pois lidar com toda a carga de responsabilidade em representar a área de negócios e sintonizar os Desejos x as Necessidades é seu maior desafio, e é aí que pecam os BA´s.

Os desenvolvedores de software com toda a sua expertise técnica tem uma importância ímpar no desenvolvimento das ações, sua competência sistêmica e vivência lógica agregam o devido valor quando a proximidade entre ambos é conquistada. Comparo o desenvolvedor de software ao violinista e a área de negócios à plateia, enquanto o BA ao elemento que transforma a música em arte, apenas colhendo de ambos os lados o melhor de cada um.

Segundo consultores do Phoenix Chapter of IIBA os BA´s são construtores naturais de relacionamentos. As partes interessadas no negócio tendem a valorizar suas contribuições e procuram envolvê-las nos projetos. Mas quando chega o momento de defender seu "direito" a um papel no projeto, em alguns casos os próprios membros da equipe questionam o valor que trazem à mesa.

Tudo isso me fez pensar sobre a relação dos BA´s versus desenvolvedores de software e como podemos melhorá-la. Embora gostaríamos de pensar (ou esperar) que os cuidados de desenvolvedores de software sobre a linha de fundo da organização, fosse olhar as coisas sob a perspectiva de como poderia ser melhor o contato com a área de negócios... Acrescento: Proximidade e bom relacionamento, integrando conteúdo e olhando sempre para o maior objetivo (que não são os das áreas e sim o da organização). O de considerar que a TI é apenas um provedor de serviços, um grande fornecedor de soluções, esse sim deve ser o real sentimento comum entre de desenvolvedores e analistas de negócios.

Agora, segue o desafio:

Se eu fosse um desenvolvedor, por que eu me importaria?

Se eu fosse um analista de negócios, como eu me comportaria?

Se eu fosse da área de negócios, o que eu esperaria?

Se nós, como BA´s pudéssemos ajudar a reduzir o retrabalho, que, sem dúvida, deve ser feito, pergunto: Como mudar o sentimento da maioria dos desenvolvedores que somente é motivado por "horas trabalhadas", ou seja, dispender seu tempo em escrever e reescrever códigos, e quanto mais seu tempo é gasto no mesmo pedaço de código, menos intelectualmente interessante fica o trabalho.

Com isso, os pedidos de mudança sempre significam um cronograma de projeto ampliado, que mais frequentemente significam também horas extras de desenvolvimento, em suma o maior fator motivador dessa classe: Horas trabalhadas multiplicadas por X reais, resultando em FATURAMENTO.

Eu nunca conheci um desenvolvedor que gostava de participar de reuniões e de se integrar, muitas vezes ele está lá, envolvido em proporcionar um pouco de entrada na direção, mas realmente esperando a resposta exata de que necessitam para que possa construir a solução.

Naturalmente seu foco é perdido, e aí que mora o risco (o escopo desse post), pois exatamente nesse momento é que o MAESTRO DA TI, deve trazer a responsabilidade do momento e promover a sintonia do solicitante e do solicitado.

Como você planeja seu levantamento e processo de análise de requisitos? Você acha que um desenvolvedor de software, deve participar dessa ação? Outra pergunta a fazer é: você precisa de um desenvolvedor em uma reunião de kickoff de projeto?

Por fim, como numa orquestra o MAESTRO depende de seus músicos, esses que dependem de seus instrumentos e sua plateia, e essa que vê no MAESTRO o condutor da sinfonia, é como encaro o departamento de TI.

Deixo no ar, duas perguntas:

Você como analista de negócios, já enfrentou desafios semelhantes em ser respeitado como esse MAESTRO dentro de sua própria organização de TI?

Você como MAESTRO DA TI, já comunicou o valor de uma área de análise de negócios para um desenvolvedor de software?

Dedico este post em homenagem ao meu amigo Paulinho.

Fonte: http://www.infoq.com/

O que é Análise de Negócios?

2012-04-13T12:18:00.002-03:00

Vídeo explica de forma simples e lúdica o que é a análise de negócios.

Publicado por Fabrício Laguna, da Gigante consultoria.

1ª Treinamento SCRUM aos sábados.

2012-03-06T08:39:00.002-03:00

No último dia 04/03/2012 iniciamos nossa 2ª turma de treinamento em SCRUM, em parceria com a Athem e Sucesso-SP.

Agradeço a presença e confiança de todos.

Modelagem Ágil: aperfeiçoando a comunicação e a compreensão

2012-02-29T11:24:00.005-03:00

Estatísticas alarmantes mostram que os projetos de TI chegam a custar 400% mais que o previsto, realizando apenas 25% dos benefícios prometidos. Embora pesquisas do Standish Group mostrem alguma melhora neste quadro, estamos ainda muito longe do sucesso em projetos de TI.

Podemos classificar o fracasso dos projetos em duas categorias:

Técnico:

A solução não atende aos requisitos do projeto (escalabilidade, performance, confiabilidade, custo etc.);
Devido aos desafios técnicos, prazos são ultrapassados, até que os patrocinadores perdem a confiança e encerram o projeto.

Funcional:

A equipe não compreende os requisitos fornecidos;
Os requisitos fornecidos não são os requisitos corretos.

Parte dos problemas se deve a um pensamento simplista de causa e efeito entre os domínios do problema e da solução. Acredita-se que, compreendido o problema, basta encontrar uma solução.

A Modelagem Ágil é coerente com o Manifesto Ágil e seus princípios. Portanto, é uma prática que pode fazer parte do seu repertório de ferramentas ágeis.

Entretanto, os atuais projetos de TI são maiores em escopo, custo e prazo, além de serem mais complexos, envolvendo muitos sistemas e departamentos de uma ou mais empresas. A compreensão do problema e da solução caminham juntos, ou seja , à medida que são propostas soluções, compreende-se melhor o problema.

Esse processo iterativo de análise nos domínios do problema e da solução é ainda mais complexo do que a visão simplificada anterior, por envolver divers a s partes interessadas com pontos de vista e capacidades de compreensão diferentes.

A figura acima resume as causas de fracasso do ponto de vista funcional mencionadas no início. E o fracasso funcional é uma das grandes causas dos fracassos técnicos. Portanto, as seguintes dimensões são cruciais para o sucesso nos projetos:

Compreensão

Compreendemos o domínio do problema?
Compreendemos o domínio da solução?
Compreendemos a transição entre esses dois domínios?

Comunicação

As partes interessadas são capazes de comunicar os requisitos para aqueles que irão desenvolver a solução?
Os membros da equipe que desenvolverá a solução são capazes de comunicar os detalhes da solução entre eles?
A equipe de desenvolvimento é capaz de comunicar os desafios e alternativas para as partes interessadas?

Os ideais básicos do Agile (manifesto , princípios e bom senso) surgiram da necessidade de reforçar as dimensões de compreensão e comunicação.

A figura anterior ilustra o Manifesto Ágil, em que (nunca é demais lembrar):

Indivíduos e interações são mais importantes que processos e ferramentas;
Responder a mudanças é mais importante que documentação;
Colaboração com o cliente é mais importante que negociação de contratos;
Software funcionando é mais importante que seguir um plano.

Embora a modelagem seja uma técnica importante em desenvolvimento de softwarem inclusive em metodologias ágeis, frequentemente é subestimada ou mal entendida. Na luta contra o desenvolvimento centrado em processos burocráticos e contra o desenvolvimento baseado em ferramentas, a modelagem acabou sendo atacada também. Precisamos corrigir essa má impressão.

Um bom começo é definição de modelagem, basicamente, a modelagem é a simplificação da realidade. Não significa utilizar determinada notação, ferramenta ou processo, permite compreender e focar nos aspectos importantes, sem detalhes desnecessários.

Considerando essa definição, podemos avançar e descrever a ideia de modelagem ágil. Isto posto, adotamos uma abordagem ágil usando modelos que nos auxiliam a compreender e comunicar.

Aspectos relevantes de Modelagem Ágil:

O processo de modelagem e os modelos suportam comunicação e compreensão;
A Modelagem Ágil busca criar modelos simples usando ferramentas simples (adote a simplicidade);
O foco é entregar software, não modelos. Modelos devem ser usados quando e onde adicionam valor. Se eles não agregam valor nem nos auxiliam no sentido de entregar software funcionando, então não devem ser utilizados;
Modelos devem ser mantidos pelo tempo necessário. Se um modelo serviu ao seu propósito e deixa de ser necessário, jogue fora. Isso permite manter a agilidade sem burocracia. Por outro lado, se seu modelo pode ainda ser útil, guarde ou recicle.
A Modelagem Ágil utiliza múltiplos modelos para diferentes perspectivas, níveis de abstração e públicos. Cada modelo é criado a partir de um objetivo e para satisfazer determinado público.
A Modelagem Ágil combina modelos formais e informais conforme a situação, público-alvo e objetivos. Por exemplo, um modelo poderia ser composto de formas simples desenhadas a lápis ajudando o essencial de um sistema, ou utilizando diagramas detalhados de classes do UML.

Conclusões

Para valorizar pessoas e suas interações é preciso fortalecer a comunicação. Em vez de investir em novas ferramentas ou adotar processos prescritos, sugerimos uma abordagem diferente, a Modelagem ágil. A utilização de métodos de modelagem facilita a compreensão do problema e da solução, além de melhorar a comunicação entre os stakeholders e resposta a mudanças.

Fonte: INFOQ

Pra que serve o analista de negócios?

2012-02-09T17:32:00.002-02:00

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

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

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

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

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

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

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

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

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

Construir a credibilidade

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

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

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

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

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

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

2012-01-26T14:56:00.003-02:00

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

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

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

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

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

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

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

O que você acha?

Fonte: www.infoq.com

Scrum Alliance vai fortalecer certificação CSM

2012-01-09T10:30:00.000-02:00

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

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

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

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

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

Fonte: INFOQ

Feliz 2012.

2012-01-02T15:35:00.003-02:00

Um 2012 repleto de alegrias e boas oportunidades a todos.

Nesse ano muitos posts e grandes temas.

Aquele abraço e muita saúde.

2011-11-07T11:26:00.000-02:00

Em parceria com a Sucesu-SP e a Athem, entre 07 e 11 de novembro realizamos o 1º treinamento: Fundamentos para gestão ágil no gerenciamento de projetos com SCRUM.

Foi simplismente um sucesso.

Agradeço a todos os participantes e organizadores.

Usabilidade no desenvolvimento de software

2011-09-21T11:58:00.003-03:00

Usabilidade: é um termo usado para definir a facilidade que os indivíduos podem empregar uma ferramenta ou objeto a fim de realizar uma tarefa específica importante.

A usabilidade é uma metodologia científica, aplicada na criação e remodelação de interfaces de aplicações (sites, intranets, aplicativos, jogos e produtos no mundo Web), com a finalidade de torná-los fáceis de aprender e usar.

Um software cujo manuseio seja fácil e rapidamente aprendido, dificilmente será esquecido, que não provoque erros operacionais, ofereça um alto grau de satisfação para seus usuários e, resolva eficientemente as tarefas para as quais foi projetado, pode ser considerado um sistema com grande potencial de usabilidade. Ou seja, considerar o design de um produto não apenas pela sua engenharia óptica, mais primordialmente pela sua usabilidade e a viabilização da ‘Cultura de Uso’.

Dessa forma, percebe-se a importância do desenvolvimento de software baseado em práticas de usabilidade, visando assim uma melhor aceitabilidade destes sistemas por parte dos seus futuros usuários.

A usabilidade é entendida como uma categoria relacionada à qualidade do produto de
software e, é afetada por aspectos de outras categorias como funcionalidade, confiabilidade e eficiência.

Antigamente, a experiência do usuário (UX, de user experience), não tinha uma prioridade alta na maioria dos projetos de desenvolvimento, mas isso mudou. Hoje em dia, os usuários têm muita experiência com a Web e com software. Eles desejam um design que seja fácil de aprender e de usar e que se ajuste ao seu fluxo de trabalho.

O termo "experiência do usuário" descreve a experiência subjetiva de uma pessoa quando ela está interagindo com um produto. Diariamente discute-se a usabilidade informalmente quando relatamos uma ótima experiência em um restaurante ou uma péssima no cinema. Mas quando projetamos ou avaliamos a experiência do usuário de um produto interativo, precisamos de uma maneira mais estruturada de ver o produto e analisá-lo.

Para os designers de UX, o sucesso significa criar produtos que sejam úteis, utilizáveis e desejáveis. Para ser útil, o produto deve fornecer valor ao usuário, em termos de desenvolvimento, isso significa que o produto deve implementar a funcionalidade certa. E os produtos desejáveis são aqueles com que os usuários sonham. Quanto mais desejável for um produto, mais tempo e energia o usuário dedicará a ele.

Em geral as pessoas confundem UX com design visual, equiparando-a com cores, fontes e estética. Naturalmente, o design gráfico é um dos componentes da experiência do usuário, mas o processo de design de UX é muito mais profundo. Essencialmente, a UX consiste em como a funcionalidade é implementada em termos de interação usuário-sistema.

Enquanto o analista de negócios tende a se preocupar com o que o produto deve fazer, o designer de UX se concentra em como a função deve ser apresentada por meio da UI (user inteface). Como os usuários têm habilidades e necessidades diferentes, o designer de UX determina quais segmentos de usuários precisam ser atendidos. O designer vai reunir dados sobre os segmentos de usuários e pode criar “personas” (biografias fictícias de usuários com base em dados reais), que ajudam a concentrar as discussões durante o processo de design.

Usando entrevistas e observação, o designer de UX vai identificar as tarefas que são executadas pelos usuários, como eles abordam essas tarefas e as palavras que são usadas para descrevê-las. Esses dados podem ser resumidos como cenários, histórias dos usuários ou storyboards.
Design da interação: Define como o usuário interage com o produto. Determina o comportamento do produto em resposta às ações tomadas pelo usuário e enfoca a navegação do produto, bem como os controles específicos que são usados.

Arquitetura de informações: Define como as informações são organizadas e apresentadas.
Pesquisa de usuários: O processo de estudar os usuários a fim de desenvolver um design que atenda às suas necessidades, capacidades e preferências. Os métodos são variados e normalmente empregam algumas técnicas de entrevista junto com a observação. Também são usados registros de usuários e fontes secundárias. Pesquisas e grupos de foco também podem ser usados, embora muitos designers de UX os evitem.
Design visual: Os designers visuais podem ser artistas gráficos em vez de designers de UX. Embora o impacto visual seja importante, também é essencial que o design visual não prejudique a legibilidade ou a usabilidade.
Teste de usabilidade: O processo de observar os usuários executando determinadas tarefas em um protótipo ou uma imitação da UI. Tradicionalmente, o teste de usabilidade era realizado em um laboratório com os observadores atrás de um espelho. Contudo, cada vez mais, os testes de usabilidade estão usando tecnologia de webcast.

Sinergia com a metodologia ágil

Sob o ponto de vista conceitual, os motivos para a criação de uma boa UX são aumentar a eficácia e a eficiência, reduzir a sobrecarga e a reformulação do desenvolvimento e agregar o maior valor possível, seja para operações internas ou para clientes externos.

Não é eficaz pedir que os usuários determinem o que o sistema deveria fazer e de que modo. Essa abordagem coloca nos usuários a carga de traduzir suas próprias necessidades para o que eles acham que o software deveria fazer, restringindo a descoberta de alternativas melhores, que um designer ou um desenvolvedor seriam capazes de sugerir.

O design centrado no usuário (UCD, user-centered design) agrega valor ao enfocar o entendimento das pessoas — seus objetivos, suas tarefas e suas atividades — e usando esse valor como a base para a criação.

Sob o ponto de vista prático, existe muita sinergia com a metodologia ágil. Ambas são essencialmente iterativas. Ambas exigem a colaboração constante das pessoas.
Mas lembrem-se: quem desenvolve não está apto a testar a usabilidade da aplicação desenvolvida.

Em breve mais sobre usabilidade.

Aquele abraço.

Fonte:http://msdn.microsoft.com/
http://www.scriptfacil.com.br/
http://www.ufpa.br

Fixe o prazo e o orçamento, flexibilize o escopo

2011-09-15T13:30:00.001-03:00

Olá amigos, estou lendo um livro chamado "Getting Real" (Caindo na Real), o livro aborda o desenvolvimento ágil de software. Vou compartilhar com vocês um trecho bem interessante.

Fixe o prazo e o orçamento, flexibilize o escopo

Lance dentro do prazo e do orçamento

Aqui vai uma maneira fácil de lançar dentro do prazo e do orçamento: mantenha-os fixos. Nunca jogue mais tempo ou dinheiro em um problema, apenas diminue o escopo.

Existe um mito que diz o seguinte: podemos lançar no prazo, no orçamento e no escopo. Isso quase nunca acontece e quando acontece a qualidade normalmente sofre.

Se não puder encaixar tudo dentro do prazo e orçamento planejados então não aumente o tempo e o custo. Em vez disso, puxe o escopo para trás. Sempre existe tempo para adicionar coisas mais tarde – o mais tarde é eterno, o agora está voando.

Lançar alguma coisa grande que está um pouco menor em escopo do que o planejado é melhor do que lançar alguma coisa medíocre e cheio de buracos porque precisou atingir uma janela mágica de prazo, orçamento e escopo. Deixe a mágica para Houdini. Você tem um negócio de verdade para administrar e um produto real para entregar.

Aqui vão os benefícios de fixar o prazo e orçamento e manter o escopo flexível:

Priorização
Precisaremos descobrir o que é realmente importante. O que vai chegar ao lançamento inicial? Isso força uma restrição que o pressionará a tomar decisões difíceis em vez de ficar hesitando.

Realidade
Configurar expectativas é a chave. Se tentar fixar o prazo, orçamento e escopo, não será capaz de entregar com um alto grau de qualidade. Claro, provavelmente poderá entregar alguma coisa, mas “alguma coisa” é o que realmente quer entregar?

Flexibilidade
A habilidade de mudar é a chave. Ter tudo fixado torna as mudanças difíceis. Injetar flexibilidade de escopo apresentará opções baseadas em sua experiência real de construir o produto. Flexibilidade é seu amigo.

Nossa recomendação: abaixo o Escopo. É melhor fazer meio-produto do que um produto meia-boca (mais sobre isso depois).

Um, dois, três...

"Como um projeto chega estar um ano atrasado? Um dia de cada vez." - Fred Brooks

Trecho do livro: Getting Real - 37signals

Versão completa em português.

Kanban no desenvolvimento ágil de software by Dilbert.

2011-08-25T17:23:00.004-03:00

Fonte: Universitários de POA

WORKSHOP - SCRUM

2011-08-15T14:10:00.005-03:00

Olá, gostaria de convidá-lo a participar de um evento que vamos ministrar referente a SCRUM.

O treinamento tem como principal propósito, introduzir os profissionais ao mundo dos métodos ágeis e prepará-los para a curva de aprendizado que envolve esse meio. Entender porque os métodos ágeis têm recebido tanto destaque nos últimos anos, e como aplicar de forma prática a teoria em ação.

Durante o curso, os participantes irão entender de forma simples e direta como uma framework pode transformar os resultados de uma empresa, além de aprender como aplicar SCRUM em diversos tipos de projetos independente da segmentação e área de negócio.

Por fim, com este treinamento o aluno terá uma clara percepção da essência dos métodos ágeis: seus valores e princípios.

Inscreva-se: Clique aqui

Papéis no SCRUM.

2011-08-12T09:10:00.005-03:00

No Scrum existem 3 papéis principais:

Product Owner

Comumente o cliente ou o gerente de um projeto maior. As suas principais responsabilidades são definir as funcionalidades, os prazos, estabelecer as prioridades de entrega, ajustar prioridades e funcionalidades e, por fim, aceitar o produto entregue.

Scrum Master

Responsável pela aplicação do Scrum na equipe. Remove obstáculos à conclusão dos trabalhos, controla o bom andamento das atividades e acompanha a aplicação das funcionalidades e a qualidade do que está sendo produzido. Atua como ponto de contato entre a equipe, os clientes e a gerência do projeto.

Equipe

Geralmente entre 5 a 10 membros. Inclui perfis multidisciplinares e auto-gerenciáveis (desenvolvedores, designers, testadores, analistas, arquitetos), que atuam em tempo integral no sprint.

O pontapé inicial para a definição de um sprint é o seu planejamento. Itens como capacidade de equipe, o backlog, tecnologia atual e funcionalidades são levadas em consideração por toda a equipe.

Nesse processo, é gerada a priorização do backlog e o plano, as diretrizes de como a equipe irá chegar ao seu objetivo final. O principal artefato gerado por essa etapa é o sprint backlog. Já formatado e com as devidas priorizações, responsáveis, tempos e datas de entrega.

Com o sprint backlog gerado, a equipe já pode começar a trabalhar nos produtos. Diariamente e feita uma reunião informal (preferencialmente com todos de pé) de cerca de 15 a 20 minutos, onde a equipe pode colocar ao Scrum Master os obstáculos que encontraram para a conclusão de suas atividades do dia anterior.

É importante salientar que essa reunião não deve servir para discussão de funcionalidades ou problemas alheios às atividades do dia anterior em si, para não perder sua essência e foco.

O gerenciamento de cada sprint é feito pelos próprios membros da equipe. Qualquer membro dela pode modificar, incluir ou eliminar tarefas e cada um fica responsável por escolher quais tarefas irá executar e atualizar diariamente as horas gastas e a estimativa de horas restantes para conclusão das atividades.

Ao final do sprint é celebrada uma reunião de revisão, onde a equipe apresenta os resulatados obtidos durante o sprint. Nessa reunião, que é informal e sem grandes apresentações, todo o time participa e discute os progressos e os problemas encontrados, onde pode-se planejar de forma mais efetiva para atingir os resultados do próximo sprint.

Fonte: http://webinsider.uol.com.br

Quer aprender mais sobre o tema? Clique aqui

Como lidar com a ausência (indisponibilidade) do Product Owner

2011-07-26T11:39:00.003-03:00

Uma questão bastante abordada e discutida quando pensamos em projetos que utilizam do SCRUM como ferramenta de processo, é a ausência (indisponibilidade) do Product Owner. Se levarmos em consideração que PO é o "cara" que melhor conhece o produto, que tem clara a prioridade do que deve ser feito, é a pessoa que demanda as necessidades do negócio, considero natural que esta "entidade" não seja tão acessível quanto pregamos no SCRUM.

Como resolver esta questão?

Abaixo uma matéria escrita por Paulo Rebelo no site INFOQ explana um pouco mais sobre o assunto.

Como lidar com a ausência de um Product Owner efetivo

O papel do Product Owner tem grande importância no Scrum, mas muitos dos profissionais que assumem esse papel não possuem o tempo necessário para acompanhar a equipe, não tendo disponibilidade sequer para a evolução do produto da forma que merece. Neste artigo, são exploradas alternativas para tornar mais efetivo o papel do Product Owner.

Papel e responsabilidades

Em Scrum, lembrando, temos três papéis bem claros: ScrumMaster, Product Owner e membro da Equipe (ou do Time). Nosso foco é no Product Owner, que possui basicamente as seguintes responsabilidades:

Conceber o produto, escrevendo suas histórias e funcionalidades gerais;
Priorizar as histórias de mais alto valor;
Estar disponível para a equipe, ajudando-a a entender os requisitos;
Aprovar as histórias realizadas pela equipe;
Definir as necessidades dos usuários;
Garantir o retorno de investimento para cada funcionalidade entregue;
Possibilitar que seja feito o mais simples possível, mantendo a funcionalidade necessária.

A efetiva contribuiçāo do Product Owner (PO), como se vê, é um fator chave para o sucesso do projeto. Mas será que os POs possuem a dedicação exigida para a entrega de um produto? Da mesma forma que a equipe e o ScrumMaster, o PO também precisa ter o foco necessário, sendo este um valor importante do Scrum.

É importante que o PO participe das reuniões diárias, e sua presença é obrigatória em Reviews e Plannings (lembrando que Review é a reunião de apresentação do que foi realizado pelo time, e Planning é a reunião de planejamento do que será feito em um determinado ciclo de entrega).

Recomenda-se ainda que o PO esteja disponível para a equipe, para lidar com eventuais dúvidas e sugestões. Além disso, na reunião de Product Grooming, contamos com o PO para trazer as respostas e os direcionamentos necessários.

No entanto, isso frequentemente não é o que acontece na prática, pois muitos dos Product Owners são extremamente ocupados, não possuindo o tempo para dedicação à equipe e principalmente ao produto. Muitos dos eleitos para a função de PO cuidam de outras atividades, outros produtos, até mesmo gerenciam outras equipes, dentre varias responsabilidades adicionais. Esse acúmulo de funções pode ser enormemente prejudicial para todos os envolvidos no projeto.

Alternativas

Como lidar com essa situação? Em muitos casos, o que se pode fazer é tratar o PO atribulado como um Business Owner, delegando as tarefas do PO de fato, com o foco no desenvolvimento do produto e na equipe. Saber delegar e confiar no profissional para o qual está passando essa responsabilidade traz retorno para o próprio Business Owner. O PO precisa se conscientizar (ou ser conscientizado) de que não é possível "encaixar" mais um papel em seu dia-a-dia. Deve-se ainda reforçar que esta é uma responsabilidade básica para o Scrum.

É neste último ponto que talvez esteja o problema: será que a implantação do Scrum nas empresas fica realmente clara e transparente para todos? Às vezes, "transformamos" o atual Gerente de Projetos em ScrumMaster, treinamos o time de desenvolvimento em técnicas ágeis, mas e o Product Owner? Não bastaria apenas treinar aquele que hoje responde pelo produto, pois é ele mesmo quem deveria exercer essa função?

Querendo ou não, a denominação de PO do Scrum é confundida por muitos, talvez pela tradução literal da palavra ("dono do produto"). Mas, o fato é que a escolha do PO pode ser decisivo para o sucesso de um projeto. Imagine um PO sem capacidade de determinar o retorno de investimento do seu produto; ou que não saiba o que gera mais valor.

Existem implantações de Scrum, nas quais já participei, em que existia um grupo de Product Owners e um Chief Product Owner (recomendo a leitura do artigo de Roman Pichler que trata do papel de Chief Product Owner). O Chief Product Owner é um profissional responsável por treinar, colaborar e conduzir os Product Owners. Na minha experiência, o modelo funcionou bem, pois os CPOs eram focados na função e por existir essa comunidade, compartilhavam muitas experiências. Os Product Owners faziam a interface com a área de negócio e o dono real do produto era considerado o Business Owner (leia mais sobre o conceito de Business Owner no artigo de Dean Leffingwell).

Outra opção para garantir uma boa condução do produto é a alocação de um analista de negócio. Esta pessoa faz o detalhamento dos épicos, temas e histórias; fica ao lado do time e responde às dúvidas de negócio, viabilizando a geração de valor para o produto, entre outras funções. Mas novamente aqui podemos cair em uma armadilha: o analista não é um Product Owner de fato, e muitas vezes requisitaria certo tempo do verdadeiro Product Owner. Isso porque não teria a mesma autonomia para priorizar ou aceitar as histórias, por exemplo.

O Problema da indisponibilidade

A falta de tempo do PO tende a se tornar um círculo vicioso, que na maioria das vezes acaba sobrecarregando o ScrumMaster. Se o PO não cumpre com a sua função como deveria, o ScrumMaster é quem acaba assumindo grande parte da responsabilidade. Não é raro encontrar um ScrumMaster refinando uma história para o time ou até mesmo criando-a.

Dito isso, algumas questões vêm à tona: será que foram dadas as condições necessárias para o PO realizar efetivamente o seu trabalho; ou seja, não deveria o PO ser um Business Owner, e permanecer em um papel com menos responsabilidades? Para isso acontecer, no entanto, precisaria ele contratar um PO e delegar essa função, ou deixar a resolução do impasse a cargo de quem implantou o Scrum?

A Implantação do Scrum nas Empresas

Toda a culpa parece ficar por conta do Scrum, o que não é verdade. Apesar de ser um framework baseado em princípios simples, o Scrum detém complexidade significativa e sua implantação em empresas exige cuidado e atenção a detalhes. Se a implantação não ocorrer de forma bem planejada, novos problemas surgirão e a impressão do Scrum ficará comprometida.

Os papéis e as responsabilidades de cada um devem ficar muito claros, não pode haver sobreposição de tarefas (por exemplo, um PO deve se dedicar a essa função). Além disso, treinamentos são necessários para todos, inclusive para os profissionais nas demais funções, que, de uma forma ou de outra, serão afetados pela implantação. E, talvez o mais importante, é a transformação cultural da empresa, e o aprendizado e a adaptação dos profissionais que a compõem.

Conclusões

O papel de Product Owner no Scrum é complexo, envolvendo múltiplas tarefas e responsabilidades. É preciso ter foco no produto a ser entregue e tempo de dedicação. Portanto, a escolha do Product Owner é de vital importância para todos os envolvidos. É o Product Owner quem direciona o produto. Mas se não tem o tempo necessário, e não for possível fazer mudanças na empresa para que o tenha, será melhor considerá-lo como Business Owner e contratar um Product Owner que realize essa função.

Fonte: http://www.infoq.com/br/articles/product-owner-efetivo

Métodos ágeis - JIRA como uma ferramenta de gerenciamento de projetos.

2011-07-21T15:27:00.021-03:00

Diferente do modelo tradicional para o controle de projetos, a metodologia ágil exige uma evolução tecnológica das aplicações e ferramentas para o gerenciamento de projetos. Um dos melhores exemplos com o qual atuo é o JIRA - Atlassian.

JIRA é altamente customizável, possuindo inúmeros recursos que ajudam em um projeto de gerenciamento de requisitos.

JIRA para Gerentes de Projeto
 Gerencie todos os seus projetos
 Gerencie muitos componentes em um único local
 Controle as atividades de sua equipe
 Monitore progressos em seus projetos
 Acesso on-line seguro

Gerenciar projetos e componentes
 Rastreie todos os seus projetos
 Gerencie sua lista de to-dos
 Número ilimitado de tarefas e sub-tarefas
 Descrições
 Arquivar anexos
 Mecanismo individual de workflow para: departamento, projeto e tipo de tarefa
 Customização de workflows

Controle as atividades de sua equipe
 Relatórios de monitoramento de tempo
 Road maps
 Painéis com atualizações de status
 Exportação de relatório de dados para Microsoft Word e Excel
 Exportação de relatório de dados como XML e RSS

Monitorar o progresso de seus projetos
 Dashboard para atualizações de status rápido
 Gráficos e relatórios sobre o seu dashboard pessoal
 Relatórios enviados automaticamente
 Atualizações por e-mail

Acesso on-line seguro
 Regimes de segurança granular
 Gerenciamento de segurança em nível empresarial

Time Tracking
 Definir uma estimativa para cada tarefa
 Log de tempo gasto em cada tarefa
 Registro de acompanhamento de tempo para cada fase do projeto
 Acompanhar tarefas de risco em um projeto
 Definir feeds RSS em tarefas de risco

Controle de atividades do projeto

Agilizar tarefas de gerenciamento de projeto
 Mostra a estrutura de hierarquia de issues
 Fornece avançados planners para Gerentes de Projetos
 Gerencie issues de risco em um projeto
 Integre JIRA com MS Project

Link hierarquias entre issues

Gerenciamento de risco/Gerenciamento de Projeto Ágil
 Definição de responsável por drag and drop
 Estimativa de Issue
 Planejamento da Iteração
 Gráfico Burndown
 Relatório sobre o estado da iteração

Vale ressaltar que cada gerente de projeto tem seu estilo e meio de gestão... as aplicações, ferramentas e controles são todos direcionados conforme seu maior conforto e meio de condução.

Em parceria com a ECORE, minha intenção desse post não é "vender" a aplicação, e sim disseminar o conhecimento sobre uma solução completa para a gestão de projetos, não nos limitando apenas ao velho e bom MS Project.

Fonte: http://blog.ecore.com.br