4 razões pelas quais sua implementação ágil não está funcionando

Em uma interessante postagem, Robert Pieper, descreve 4 razões pelas quais a implelemtação ágil pode não funcionar de maneira adequada.

  1. You’re not limiting risk
  2. Lead time
  3. Consistent cost overruns
  4. No one knows why

Agile frameworks are designed to help you be light on your feet, but they don’t promise you’ll succeed in using them as intended. – Robert Pieper

O post completo do Robert Pieper pode ser lido em: https://blog.scrum.org/4-reasons-agile-implementation-isnt-working/.

Segurança: análise de riscos (ISO/IEC 27002)

A análise de riscos é utilizada para identificar os riscos que a organização possui. Um risco, dano ou perda da informação é determinado pelas ameaças, ou melhor, a chance desta ameaça ocorrer e suas consequências.

Quando a ameaça se materializa, o risco se efetiva.

Vulnerabilidade – fraqueza, associada aos ativos da organização.
Ameaça – uma ocorrência; um fato; explora a vulnerabilidade

PROBABILIDADE é igual a uma CHANCE

Quanto MAIOR a Probabilidade MAIOR o Risco

Risco – é o potencial em que uma dada ameaça irá explorar as vulnerabilidades para causar perda ou dano imediato.

Gerenciamento de Risco – processo que trata as ameaças, riscos e medidas de segurança. É um processo contínuo na qual identifica, examina e reduz a um nível aceitável uma ameaça.

Os objetivos da analise de riscos, são:

  • Identificar ativos e valores;
  • Determinas as vulnerabilidades e ameaças;
  • Determinar os riscos e as ameaças que podem causar danos nos processos operacionais;
  • Determinar o equilíbrio entre custos de um incidente e custo das medidas de segurança.

Análise de Risco Quantitativa

Pretende calcular com base no impacto do risco, a perda financeira e a probabilidade de que uma determinada ameaça torne-se um incidente de segurança.
Os custos das medidas, não devem ser maiores que o valor do objeto a ser protegido do risco.

Análise de Risco Qualitativa

É baseada em cenários e situações. A chance é analisada com base nos sentimentos das pessoas.
Medidas podem ser tomadas para reduzir o risco residual a um nível aceitável.

Medidas para reduzir o risco

As medidas podem ser de redução da chance do evento ocorrer ou da redução de suas consequencias ou a combinação das duas.

Tipos de Medidas de risco

  • Redução: usada para reduzir ameaças;
  • Preventivas: usadas para prevenir incidentes;
  • Detecção: usadas para detectar incidentes;
  • Repressivas: usadas para parar as consequencias de um incidente;
  • Corretivas: usadas para recuperação de danos causados por um incidente.

Lições aprendidas, são realmente aprendidas pelas equipes?

Um item importante que existe em toda a empresa, mas é muito notório em projetos chama-se: “Lições Aprendidas”. Como o próprio nome diz, devemos aprender algo sobre algum item/entregável/status/comunicação/etapa do projeto que ocorreu durante alguma fase do projeto.

É através das Lições Aprendidas que podemos tornar recorrentes os resultados desejados; e impedir a recorrência dos resultados indesejados

Durante os últimos anos, pude participar de vários projetos, alguns com o escopo pequeno ou simples, outros complexos. Alguns com equipes formada por recursos juniores outros com equipes formadas por profissionais seniores e com grande experiência em sua área de conhecimento.

Em alguns projetos é obrigatório a entrega formal de um documento contendo todas as lições aprendidas pela equipe do projeto aos patrocinadores do mesmo.

Lessons Learned (original: http://www.thefreedomchase.com/wp-content/uploads/2014/04/Entrepreneurial-Lessons.jpg)Em todos os projetos, ocorreram situações onde uma resposta precisava ser aplicada, porém não tínhamos nos preparados para tal situação. Uma ação teve que ser tomada/executada e com isso um resultado foi obtido. Mas, se ocorrem situações em que não houve um planejamento prévio, significa que o planejamento falhou? Pode ser que sim, pode ser que não. Depende do caso…

Bom, mas o que devemos aprender com esta etapa do projeto que não deveria ser esquecida ou ignorada?

Entendo que podemos aprender a evitar que determinadas circunstâncias se repitam, isso vale para a mesma empresa ou não e/ou para projetos semelhantes. Não devemos ter como lições aprendidas a resposta para uma situação. Devemos usá-la como um conhecimento prévio, de modo que determinadas circunstâncias não ocorram novamente.

Escrever, relatar e documentar é algo que muitas empresas não identificam valor, pois a própria empresa não tem a cultura de documentar e ler. Logo, pra que escrever?! Entretanto, existem clientes que precisam saber o que o prestador do serviço aprendeu durante a execução do projeto.

Mas o que devemos levar em conta quando vamos listar/estudar as lições aprendidas?

Vejamos alguns exemplos:

  • O que aprendemos sobre o projeto em geral?
  • O que aprendemos sobre gerenciamento de projetos?
  • O que aprendemos sobre comunicação?
  • O que aprendemos sobre o orçamento?
  • O que aprendemos sobre como trabalhar com os patrocinadores?
  • O que aprendemos sobre como trabalhar com os clientes?
  • O que aprendemos sobre as atividades que ocorreram de forma como foram planejada?
  • O que aprendemos sobre as situações que não ocorreram de forma satisfatória?
  • O que aprendemos que devemos mudar?

Gerenciando a Continuidade do Serviços de TI

Plano_continuidadeO Gerenciamento da Continuidade do Serviços de TI (GCSTI) é parte integrante do processo de Gerenciamento da Continuidade do Negócio (GCN). O GCSTI é parte do GCN, pois o GCSTI depende da informação oriunda do GCN.

Se o “negócio”, não gerencia a continuidade de si mesmo, imagina a TI!?

O GCSTI é mais um processo da ITIL e um dos seus objetivos é assegurar a sobrevivência do negócio minimizando o impacto de um desastre ou uma falha.

Algumas empresas insistem em afirmar que possuem um GCSTI. Grande parte não tem o GCN. Faz parte, infelizmente este é o cenário de parte das empresas brasileiras.

Um GCSTI não é contratar dois Data Centers e links redundantes.

Um GCSTI precisa ter:

  • Gestão (administração);
  • Infraestrutura Tecnológica;
  • Procedimentos de Operação;
  • Time técnico qualificado e treinado;
  • Segurança;
  • Contingenciamento de sites;
  • Retorno a operação normal.

É lógico que não basta ter estes itens descritos acima. Algumas atividades são necessárias para que ele funcione corretamente. Uma delas é a realização de Testes de Continuidade.

Possuir sites redundantes nem sempre é financeiramente justificável, desta forma alguns riscos podem ser assumidos.

Não é um processo fácil de ser implementado dentro da empresa. Muitas áreas da empresa precisam estar envolvidas, ou melhor comprometidas. E isso não é fácil.

Se você acha que um GCSTI não é importante, veja este cenário:

Devido à forte chuva da madrugada, um raio atingiu o quadro elétrico afetando a sala dos servidores não disponibilizando os mesmos aos usuários. Vamos ao cálculo de 1 dia de indisponibilidade do serviço.

1000 funcionários x 1 dia (8 horas) x R$ 40,00/hora = R$ 320.000,00/dia