10 maiores impedimentos organizacionais na adoção de SCRUM
A Scrum Aliance publicou um artigo excelente sobre os 10 maiores impedimentos organizacionais na adoção do SCRUM. Cada ponto de vista, foi defendido por especialistas de diversas empresas. Vou citá-los e colocar minha opinião a respeito de cada um. Fiquem a vontade em criticar,e dar sugestões.
Gostaria de salientar que as traduções foram livres e realizadas por mim.
10. Failure to Remove Organizational Impediments (Falha ao remover barreiras organizacionais)
Muitas empresas na quais trabalhei tem esta dificuldade, ou seja, problemas em promover mudanças a fim de melhorar o processo de trabalho, é como o autor captou a visão de cada uma “é assim que sempre fizemos negócios”, e “não queremos mudar porque já investimos muito nisto”. Para ganhar competitividade muitas vezes é necessário estar a frente do seu tempo. É um risco, mas se der certo você estará na frente dos seus concorrentes. Aqui posso citar o caso de uma grande seguradora, em 1994 a empresa tinha que decidir se utilizaria Windows e plataforma Microsoft, ou , se escolheria outra tecnologia. A decisão foi por Microsoft, na época, uma aposta. A aposta funcionou, em pouco tempo era a única seguradora com diversos processos automáticos e emissão na hora de apólice, com quadro de funcionários enxuto fazíamos o trabalho de grandes seguradoras. Muitas seguradoras já fazem isto, mas começamos bem antes, e, portanto, uma empresa inovadora e competitiva.
9. Misguided Cost Savings and Synergy Efforts (Economia de custos sem orientação e sinergia de esforços)
Este é interessante. Manter equipes com propósitos definidos, por exemplo, como citado, para quais ferramentais que foram homologados e que outras equipes devem usar. Não vejo problema em definir uma ou mais ferramentas, mas no fato de obrigar que outros times usem algo sem ao menos serem consultados. Acho fundamental antes de qualquer tipo de adoção, o envolvimento de todas as equipes, para que possamos ver em conjunto o que agrega e o que atrapalha, e assim, fazer com que todos comprem a idéia. POCs servem para isto. Alguém já viu ferramentas ou metodologias que são adotas por um tempo e depois caem no esquecimento? Por que será?
8. Lack of Training (Necessidade de treinamentos)
Empresas geralmente acham que treinamentos, coaching ou mentoring, são totalmente dispensáveis, isto fica claro em momentos de crises, as que têm este tipo de política, cortam em primeiro lugar treinamentos. O que não é legal é aplicar diversos treinamentos sem nenhum tipo de objetivo, pois com o tempo são totalmente perdidos,e aí sim, dinheiro jogado fora. Quando se deseja entrar em uma nova onda, na qual a equipe ainda não tem fluência, e de vital importância montar um planejamento de implantação, e em seguida selecionar os tipos de capacitações necessárias. Em 2004 na empresa que trabalhei, havia a necessidade de montar uma equipe de arquitetura. Com planejamento, inicialmente foram realizados alguns cursos e para emplacar, solicitamos um trabalho de mentoring, ou seja, condução de um projeto bem orientado e realizado a quatro mãos, que gerou um resultado final compensador.
7. Single-Function Groups (Grupos funcionais únicos)
Em grupos ágeis a comunicação é pilar principal e muitas vezes criar grupos especializados em alguns assuntos, podem coagir outras equipes. Quem nunca viu em uma empresa, aquele grupo denominado “Deuses”, o detentores de conhecimentos privilegiados, os inacessíveis,etc. Para mim, tudo balela, geralmente um grupo de egocêntricos, e no final da contas, pessoas com medo de ceder conhecimento e perder a posição. Em todos estes anos, percebi que o interessante e compensador é evangelizar e disseminar conhecimento.
6. Local vs Global Optimization(Otimização local versus otimização global)
A autora, pelo meu entendimento, critica o fato de montar estratégias locais em vez de globais, ou seja, esquecendo o alinhamento estratégico da organização como um todo e somente atuando pontualmente na organização. Exemplos estes como premiações, controles rígidos conservadores de projetos entre outros.
5. Assumption that Book Learning is Enough (Assumir que aprender com livros é o suficiente)
Vale algo que alguém falou para mim,”..os livros são fundamentais, porem, nos ensinam apenas a metade”. Ler alguns livros não significa que você se tornará um especialista. Nada como o conhecimento acadêmico aliado a prática, quando há a consolidação, temos o estado da arte. Outro ponto que auxilia em muito no aprendizado é o apoio de pessoas que já passaram por situações similares e que já aprenderam muito em outros projetos, o famoso orientador. Vamos aprender com quem já sofreu, não vale a pena reinventar a roda.
4. Individual Performance Evaluation and Reward (Avaliação individual de performance e premiações)
Se mal conduzido, pode jogar qualquer iniciativa no ralo. Quando se coloca prêmio(dinheiro, viagem, etc..) por algo realizado, muitas vezes para chegar em tal meta, “atalhos” são tomados, fora a concorrência interna e picuinhas. Times ágeis devem trabalhar em conjunto, com objetivo único, sem qualquer tipo rincha interna em prol de uma solução sólida.
3. Unrealistic Promises(Promessas irreais)
Típicas de alguns gerente de contas. “Sem problemas, para construir toda a sua intranet levo apenas 1 mês”, ou ,” implantar SOA é simples, em apenas 2 meses teremos serviços atômicos, bem definidos, reutilizáveis e com governança. “. Temos que ser pragmáticos, se for necessário um ano, precisamos falar, se for para fazer mal feito, melhor não fazer e continuar do jeito que está.
2. Assuming Agile Is All About Developers (Assumir que Agile é tudo sobre desenvolvedores)
Trabalhar com metodologias ágeis não é somente escolher uma abordagem TDD, programação em pares, entre outras técnicas de desenvolvimento. Gerenciamento de projetos ágeis envolvem toda uma mudança de paradigmas na organização, desde gestão de pessoas a relacionamento com clientes. Se não houver alinhamento estratégico entre os diversos times, é impossível atingir objetos significativos.
1. Silver bullet thinking and superficial adoption(Pensar que é bala de prata e adoção superficial)
Diversas consultorias de TI realizam fortes incursões de marketing afirmando que adotam metodologia ágil e todos os problemas de software como: funcionalidades não entregues, entrega fora do prazo e acima do custo estão resolvidos. No último Chaos Report do Standish Group 2009 podemos ver que ainda temos problemas. Ágil não resolve, ou levamos os problemas de uma abordagem para a outra? Como mencionei no item anterior, se não houver uma adoção sólida, seguindo boas práticas, com envolvimento real do cliente e alinhamento estratégico de todo o time, não tem jeito, o projeto afunda como todos os outros.
Trabalhamos em parceria com um consultoria que “utilizava” SCRUM, só que não tínhamos: reuniões diárias, feedbacks e muito menos um processo iterativo e incremental. No final das contas, foi um projeto cascata que ainda deixa um gosto amargo na boca.
Em resumo, acho que os autores foram muito felizes com o artigo e conseguiram captar a essência dos problemas, e que acho que podem ser aplicados a outros assuntos além de implantação de SCRUM. Vocês já sofreram com alguns dos itens mencionados?
[]’s
Fábio Margarito Martins de Barros
Integração contínua – Parte 2
Neste segundo artigo da série, vamos iniciar a montagem de um ambiente voltado para integração contínua utilizando ferramentas Open Source.
A primeira etapa será a instalação da primeira ferramenta, o Cruise Control(CC), ferramenta Open Source de automação e gerenciamento de Build. O Cruise Control foi desenvolvido inicialmente pela empresa ThoutghtWorks e liberado como versão gratuíta para a comunidade. O CC, conta com uma arquitetura totalmente extensível, e possui três módulos distintos:
Build loop: é o coração do sistema, ele inicia processos de build e envia notificações aos usuários, como , problemas durante o build. A inicialização do processo de build poderá ser, por exemplo, quando o CC detecta uma mudança no sistema de controle de fontes (ex, Source Safe, SubVersion entre outros). O processo de build é composto por um workflow de tarefas, ex:
- Baixar os fontes
- Compilar
- Executar testes unitários
- Realizar cópia de arquivo
- Aplicar versão nos Fontes da aplicação
- Efetuar publicação da aplicação.
Todas as tarefas de build do projeto são mapeadas através do arquivo de configuração do CC que veremos em outro post. Cada tarefa, graças a arquitetura flexível do CC, poderá ser delegada a diversos plugins. Um dos plugins mais famosos é o NAnt, plugin de Build que também utilizaremos em momento oportuno.
JSP reporting: é o módulo responsável por exibir informações e artefatos gerados pelo processo de build. As informações são exibidas através de uma interface web de fácil utilização. Podemos visualizar informações tais como: tempo de build, data do build, erros, avisos, dados sobre testes unitários entre outras informações.
Dashboard: como o próprio nome diz, é um painel de instrumentos que tem o objetivo de mostrar status do build de um projeto. Este módulo também exibe os dados através de uma aplicação web rica em informações, que também pode ser acessada via
RSS.
A figura abaixo,retirada do site do Cruise Control, mostra a arquitetura detalhada do aplicativo:
OBS: Um pré-requisito é a instalação do Java Runtime Enviroment, que pode ser obtido no site do Java.
Então vamos começar a brincadeira, baixe o Cruise Control e execute o instalador, e clique em “Next”
Selecione o “Path” de instalação, vou manter o padrão. Clique em “Install”
Após procedimentos de instalação, o instalador pede que inicializemos o serviço do Cruise Control, através do Painel de controle de serviços. Clique em “Ok” e em seguida “Close”
Vá a Painel de Controle/Ferramentas Administrativas, e escolha a opção “Serviços”. Na listagem, procure o serviço do Cruise Control
Antes de iniciar é aconselhável configurar uma conta sob a qual o serviço irá rodar, esta conta deverá ter permissões restritas às atividades do servidor de Build. Para configurar é muito simples, basta clicar com o botão direito, escolher a opção “Propriedades”, escolher a guia “Log On” e informar o usuário.
Para iniciar, basta clicar com o botão direito do mouse e selecionar a opção “Iniciar”. Com o usuário configurado, inicie o serviço. Para sabermos se a instalação ocorreu com sucesso, vamos acessar o console de gerenciamento do Cruise Control através do endereço http://localhost:8080/dashboard/. Teremos a página abaixo:
No próximo post, vamos começar as configurações necessárias do Cruise Control.
[]'s
Fabio Margarito