7 coisas erradas ao tentar implementar Scrum nas empresas

As metodologias ágeis para desenvolvimento de software vem ganhando força e são usadas em empresas de todos os portes no Brasil e no mundo.

Nos métodos ágeis há menos centralização em documentação, podendo-seatribuir mais atenção ao código do software, são mais adaptativos e menos prescritivos. Podem ser necessárias técnicas complementares associadas para garantir seu sucesso. Já os métodos tradicionais buscam planejar grande parte do processo de desenvolvimento de software e por um extenso período de tempo.

Empresas tradicionais vem substituindo seus processos pelo ágil. Algumas delas acreditam que adotar o ágil será como uma mágica e que rapidamente todos os problemas serão resolvidos.

Se sua empresa lida com diversos projetos e equipes de desenvolvimento grandes, você não deve contratar um único Scrum Master, não se estiver imaginando que esta pessoa será capaz de destruncar problemas de todas as equipes da empresa que estiverem trabalhando em diversos projetos. Além disso, se o Scrum Master vestir camisa de gerente e tiver uma conduta mandatória sobre o time, não se estará praticando o ágil de verdade e ele vai fracassar.

Se a empresa deseja adotar o ágil, não adianta querer apressar as coisas, impor uma velocidade ou esperar que ele amadureça rapidamente. É preciso um certo tempo para isso e, aos poucos, ele pode ser adaptado às suas necessidades.

Assim como não é indicado um único Scrum Master para empresas grandes e vários projetos, um único product owner para dar conta de muitas equipes ao mesmo tempo também é um problema. O product owner precisa estar presente e participar ativamente com a equipe, para evitar falhas na comunicação e o desenvolvimento de algo que o cliente na verdade não quer.

Em minhas aulas no curso de engenharia de software eu reservo bastante tempo para bater na tecla sobre a essência do ágil. Enquanto os envolvidos não respiram a essência da colaboração, do trabalhar em equipe, da inexistência de um tradicional gerente de projetos que é responsável por tudo, ninguém consegue fazer o ágil funcionar corretamente. No ágil não deve existir um gerente ou alguém mais importante que outro: toda a equipe compartilha uma meta e um verdadeiro trabalho em equipe.

Sobre a eficiência do ágil, um relatório de 2011 CHAOS do Standish Group revelou que projetos ágeis são bem sucedidos três vezes mais do que projetos não-ágeis. Este relatório vai tão longe a ponto de dizer: "O processo ágil é o remédio universal para o fracasso do projeto de desenvolvimento de software. As aplicações de software desenvolvido através do processo ágil tem três vezes a taxa de sucesso do método em cascata tradicional e uma porcentagem muito menor de tempo e custo derrapagens."

Os resultados são de projetos realizados entre 2002 e 2010. Mas quando falamos na adoção do ágil, as empresas que buscam introduzi-lo como uma metodologia costumam cometer alguns erros. Antes de falar sobre alguns desses erros, importante comentar que a Version One levantou as principais falhar dos projetos usando o ágil:

Se formos ver, as principais razões são marginais, circundam o método em si. A falha do projeto não foi, por exemplo, a falta de documentação ou a comunicação com o cliente. O que é mencionado é a questão da transição de metodologia, não sobre os valores do ágil. Mexer com o que está enraizado é sempre complicado.

Estando claro que o ágil em si, de acordo com os dados, não contribui para fracassos, quais seriam então os fatores que levam à eles nas empresas que tentam adotá-lo?

Dizer que usa Scrum, mas ainda trabalha como cascata 

Uma sprint tem um tempo fechado e o objetivo de realizar uma entrega parcial de um incremento. Montar sprints como etapas ou fases é aproximá-la do modelo cascata e perde-se o benefício da melhoria contínua e do processo de entregar parcialmente e agregar valor ao produto a cada ciclo.

Impor prazos ao invés de defini-los com a equipe 

No Scrum trabalha-se com sprints que tem tempo fixo, não com prazo fechado. A equipe deve decidir o que será priorizado e definir o que será entregue primeiro. A pressão da entrega, neste caso, existirá a cada ciclo, não somente no final do projeto.

Realocar membros da equipe para outros projetos 

Ao trocar pessoas de equipes perdem-se as lições aprendidas, sincronia e desempenho.

Deixar de fazer reuniões diárias 

Esse momento é essencial para o planejamento e desenvolvimento das entregas, da qualidade e dos impedimentos. Quem não faz reunião diária arrisca o surgimento de falhas na comunicação e pode comprometer a entrega da sprint.

Empurrar impedimentos com a barriga 

O Scrum incentiva que todo impedimento seja comunicado e resolvido o quanto antes.

Atrasar o prazo de entrega das sprints 

Tempo de duração de sprints deve ser fixo e não prorrogável. A prática força a equipe a mensurar mais próximo do real o tempo necessário para o desenvolvimento dos requisitos escolhidos.

Ter um Scrum Master não respeitado ou que não se impõe 

Se existe um cara que vai brigar pela equipe e para que o fluxo Scrum seja executado corretamente, é o Scrum Master. Esta pessoa precisa blindar a equipe contra a retirada de membros e a imposição de prioridades externas para evitar a perda do alto desempenho da equipe.

Em resumo, se você deseja inserir uma metodologia ágil em sua empresa, é preciso em primeiro lugar um treinamento intensivo sobre o assunto com todas as pessoas necessárias pra fazê-lo ganhar força e ser compreendido corretamente por suas equipes. Em segundo lugar, a partir da compreensão correta e plena sobre o método escolhido, os papeis, os artefatos e técnicas complementares associadas, é preciso querer muito que ele aconteça, relembrando a essência do ágil a todo momento, cuidando para não agir de modo autoritário sem querer, garantindo que cada um exerça bem seu papel e tornando a comunicação clara e fluída todos os dias.

Fonte: http://flaviagamonar.com/7-coisas-erradas-ao-tentar-implementar-scrum-nas-empresas/

Os tipos de chefe que só atrapalham uma empresa

Recentemente tive o prazer de ler um artigo na Exame.com sobre os tipos de chefes que atrapalham a empresa. Resolvi replicá-lo aqui... é muito interessante. Confira a seguir alguns tipos de chefe que só atrapalham seu negócio - e que você com certeza não quer ser.

1. O chefe imutável

O primeiro tipo de chefe que você não pode ser é o imutável. Aquele indivíduo que é sempre do mesmo jeito, não importa o que aconteça. É o gerente que é excessivamente duro, mesmo quando a empresa vai bem. Ou democrático e bonzinho quando as operações estão no vermelho e exigem velocidade e decisões difíceis. Os mercados e as situações com que um chefe tem de lidar se transformam o tempo todo, portanto, o líder tem de acompanhá-las, ou corre o risco de sucumbir a elas, por não saber transformar-se também.

2. O chefe que quer agradar o tempo todo

O segundo tipo a ser evitado é aquele chefe que deseja liderar e simultaneamente ser amado por todos. Esse tipo de liderança é uma aplicação da fórmula do fracasso: querer agradar a todos. Isso é impossível. Por conta das condições de restrição a que um negócio está submetido, sempre haverá pressões e decisões que vão desagradar alguém, na empresa, ou em seu entorno. O líder deve ser capaz de ver o que é melhor para o negócio e agir. E aguentar críticas faz parte da formação dos grandes líderes.

3. O chefe que não assume que errou

Outro tipo terrível é aquele que não assume erros. Aquele chefe que deseja sempre estar certo, mesmo quando os números e os eventos mostram que sua ação foi errada. Saber desculpar-se dos erros não é uma questão de humildade, mas de normalidade. Ninguém é infalível, mas falhar e não assumir erros, ou, pior, culpar outros por eles, é uma forma infeliz de liderar.

4. O chefe que não quer que a empresa cresça

Infelizmente, muitos gestores desejam ficar onde estão indefinidamente. Ou seja, para eles, se a empresa não vendesse mais, se os concorrentes não viessem atrás de seus clientes, seria ótimo: eles não desejam ser maiores do que são. O problema é que isso faz com que toda sua equipe fique também estagnada, e, em longo prazo, somente pessoas sem ambição vão querer trabalhar na empresa. O que, seguramente, vai comprometer seu futuro.

5. O chefe que não valoriza os melhores

Não reconhecer os indivíduos e a equipe pelo bom trabalho. Há líderes que relutam em reconhecer que o sucesso do departamento (ou da empresa) ocorreu porque ele (ela) conta com profissionais dedicados, inteligentes e empenhados em resolver os problemas dos clientes e da companhia. O líder que acha que o sucesso da empresa é exclusivamente por conta dele está fadado a acabar sozinho.

6. O chefe que não desenvolve seus funcionários (e nem ele mesmo)

Por último, há aquele chefe que não desenvolve os indivíduos de seu time. É aquele líder que não se atualiza, não aprende nada de novo e não estimula seu time a fazer o mesmo. Como consequência, as novas tecnologias surgem, e ele não sabe usá-las. Seus concorrentes desenvolvem algo novo que coloca em risco a empresa, e ele não está preparado para responder. Além disso, por vezes, não deixa seus liderados se desenvolverem, cria limitações para que isso aconteça e acaba perdendo os melhores do time, ficando somente com os medíocres. Portanto, o bom líder é capaz de acompanhar as transformações do seu mercado, do mundo e das novas gerações. Tem grande habilidade em usar o estilo de liderança adequado para cada situação. Nunca para de aprender e, acima de tudo, sabe que seu papel é formar novos e bons líderes – preferencialmente melhores que ele mesmo. Tudo aquilo que um mau chefe não faz!

Procurando textos nos objetos do Oracle

Pessoal, algumas vezes precisamos buscar uma palavra no nosso banco de dados e não sabemos como fazer.

Pois bem, segue uma query que pode ajudar muito.

SELECT *
FROM ALL_SOURCE
WHERE UPPER(TEXT) LIKE '%TEXTO%'

Nessa query, ele irá procurar a palavra “TEXTO” em todos os objetos do banco, se encontra algum objeto que contenha, ele irá mostrar.

Espero que tenha ajudado.

Diferença entre comandos DDL, DML, DCL e TCL

DDL – Data Definition Language ( DDL) são usadas para definir a estrutura de banco de dados ou esquema. Alguns exemplos:

CREATE- para criar objetos no banco de dados
ALTER – altera a estrutura da base de dados
TRUNCATE – remover todos os registros de uma tabela, incluindo todos os espaços alocados para os registros são removidos
COMMENT – adicionar comentários ao dicionário de dados
RENAME – para renomear um objeto

DML – Data Manipulation Language ( DML) são utilizados para o gerenciamento de dados dentro de objetos do banco. Alguns exemplos:

SELECT- recuperar dados do banco de dados
INSERT – inserir dados em uma tabela
UPDATE – atualiza os dados existentes em uma tabela
DELETE – exclui registros de uma tabela,
CALL – chamar um subprograma PL / SQL
EXPLAIN PLAN – explicar o caminho de acesso aos dados
LOCK TABLE – controle de concorrência

DCL – Data Control Language ( DCL ) declarações. Alguns exemplos:

GRANT – atribui privilégios de acesso do usuário a objetos do banco de dados
REVOKE – remove os privilégios de acesso aos objetos obtidos com o comando GRANT

TCL – Transaction Control Language – (Controle de Transações) são usados ​​para gerenciar as mudanças feitas por instruções DML . Ele permite que as declarações a serem agrupadas em transações lógicas .

COMMIT – salvar o trabalho feito
SAVEPOINT – identificar um ponto em uma transação para que mais tarde você pode efetuar um ROLLBACK
ROLLBACK – restaurar banco de dados ao original desde o último COMMIT

O que é SQL ?

SQL (structured Query Language) é um conjunto de comandos de manipulação de banco de dados utilizado para criar e manter a estrutura desse banco de dados, além de incluir, excluir, modificar e pesquisar informações nas tabelas dele. A linguagem SQL não é uma linguagem de programação autônoma; poderia ser chamada de "sub linguagem". Quando se escrevem aplicações para banco de dados, é necessário utilizar uma linguagem de programação tradicional (C, Java, ASP, PHP, etc...) e embutir comandos SQL para manipular os dados.

Em um modelo relacional, apenas uma tipo de estrutura de dados existe: a tabela. Novas tabelas são criadas com a junção ou combinação de outras tabelas. Utilizando apenas um comando SQL é possível pesquisar dados em diversas tabelas ou atualizar e excluir diversas linhas das mesmas.

A linguagem SQL não é procedural, logo é possível especificar o que deve ser feito, e não como deve ser feito. Dessa forma, um conjunto de linhas (set) será atingido pelo comando e não cada uma das linhas, como é feito no ambiente procedural. Portanto, não é necessário entender o funcionamento interno do banco de dados e como e onde estão armazenados fisicamente os dados.

A linguagem SQL é dividida nos seguintes componentes:

Data Definition Language (DDL): permite a criação dos componentes do banco de dados, como tabelas, índices, etc..

Principais comandos DDL:
       
        CREATE TABLE
        ALTER TABLE
        DROP TABLE
        CREATE INDEX
        ALTER INDEX
        DROP INDEX

Data Manipulation Language (DML): permite a manipulação dos dados armazenados no banco de dados:

Comandos DML:
        
        INSERT
        DELETE
        UPDATE

Data Query Language (DQL): permite extrair dados do banco de dados:

Comandos DQL:
        
         SELECT

Data Control Language (DCL): provê a segurança interna do banco de dados:

Comandos DCL:

        CREATE USER
        ALTER USER
        GRANT
        REVOKE
        CREATE SCHEMA