Princípios SAFe

  1. Take an economic view
  2. Apply systems thinking
  3. Assume variability; preserve options
  4. Build incrementally with fast, integrated learning cycles
  5. Base milestones on objective evaluation of working systems
  6. Visualize and limit WIP, reduce batch sizes, and manage queue lengths
  7. Apply cadence, synchronize with cross-domain planning
  8. Unlock the intrinsic motivation of knowledge workers
  9. Decentralize decision-making

http://www.scaledagileframework.com/safe-lean-agile-principles/

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?

Algumas coisas sobre SCRUM

O que é o SCRUM?

É um framework para gerenciamento de projetos e desenvolvimento ágil de software (não é somente para o gerenciamento de software que se pode adotar o SCRUM, entretanto sua adoção é maior nesta área).

É um framework, não uma solução completa! Logo, você deverá adaptá-lo para usar com máxima eficiência.scrum-org-logo

SCRUM baseia-se no desenvolvimento iterativo e incremental, ajudando a guiar o time durante o desenvolvimento do software.

A equipe é o foco e não o processo.

O SCRUM adota uma abordagem empírica (aceita que o problema não pode ser totalmente entendido ou definido, focando na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes).

O SCRUM possui um conjunto de valores, princípios e práticas que auxiliam a equipe de projeto a entregar produtos ou serviços de valor em um ambiente complexo, instável e desafiador.

Por que adotar o SCRUM?

  1. É objetivo e simples.
  2. Tem uma baixa curva de aprendizado.
  3. Define papéis e responsabilidades de forma clara e consistente.
  4. No entanto, não é um processo previsível. É um processo empírico.
  5. Identifica de forma mais fácil os problemas existentes.

O SCRUM não é um processo previsível, ele não define o que fazer em toda circunstância (Ken Schwaber, 2004).

No SCRUM o desenvolvimento é feito de forma iterativa e incremental. Desta forma, a evolução é constante.

Desenvolvimento Incremental – Adiciona funcionalidades ou partes de maneira incremental. É como adicionar tijolos a um muro. Depois de vários incrementos você tem um grande muro.

Desenvolvimento Iterativo – Constrói-se algo. Depois avalia-se e em seguida faz-se alterações.

Os eventos SCRUM

No SCRUM existem quatro eventos formais que podem ser utilizados para realizar a inspeção e a adaptação:

  1. Reunião de planejamento da sprint;
  2. Reunião diária;
  3. Revisão da sprint;
  4. Retrospectiva da sprint.

O SCRUM em 100 palavras

  • Scrum é um processo ágil que permite manter o foco na entrega do maior valor para o negócio, no menor tempo possível;
  • Isto permite a rápida e contínua inspeção do software em produção;
  • As necessidades do negócio é que determinam as prioridades do desenvolvimento de um sistema. As equipes se auto-organizam para definir a melhor maneira de entregar as funcionalidades de maior prioridade;
  • Entre cada 2 a 4 semanas todos podem ver o real software em produção, decidindo se o mesmo deve ser liberado ou continuar a ser aprimorado por mais uma “Sprint”.

Fonte: http://runningagile.com/2007/12/02/scrum-in-100-words/

No SCRUM temos

3 papéis:

  1. Scrum Master
  2. Dono do Produto (Product Owner)
  3. Time de Desenvolvimento (Development Team)

4 artefatos:

  1. Backlog do Produto (Product Backlog)
  2. Backlog da Sprint (Sprint Backlog)
  3. Incremento (Increment)
  4. Histórias de Usuário (User Stories)

5 eventos:

  1. Sprint
  2. Planejamento da Sprint (Sprint Planning)
  3. Reunião Diária (Daily Scrum)
  4. Revisão da Sprint (Sprint Review)
  5. Retrospectiva da Sprint (Sprint Retrospective)

O Manifesto Ágil

O SCRUM baseia-se no Manifesto Ágil, na qual possui alguns valores.

Valorizamos indivíduos e Interação entre eles, mais que os processos e ferramentas
Valorizamos software em funcionamento, mais que documentação abrangente
Valorizamos colaboração com o cliente, mais que negociação de contratos
Valorizamos responder a mudanças, mais que seguir um plano

Mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Para maiores informações sobre o Manifesto Ágil e os 12 princípios, acesse: http://manifestoagil.com.br.

NagMobile

Este artigo foi importado do site http://linux.brunorusso.eti.br, que foi desativado. Este artigo, foi originalmente publicado em: 25/07/2011.

NagMobile

Este pequeno projeto nada mais é que uma “interface” para o nagios, com informações “resumidas” de forma que seja possível monitorar o ambiente ou as principais informações do ambiente através de uma única tela, ideal para ser utilizada em dispositivos móveis.

A necessidade surgiu a partir do momento que foi necessário acessar a interface do Nagios de uma forma mais gerencial.

Estes scripts foram testados no iPhone e no Android 2.1

Este projeto está disponível no diretório Exchange do Nagios – http://exchange.nagios.org/directory/Addons/Frontends-%28GUIs-and-CLIs%29/Mobile-Device-Interfaces/NagMobile/details

Download

Versão 0.4 disponível para Download.

nagmobile-0.4.tar.gz – http://www.brunorusso.eti.br/nagMobile/src/nagmobile-0.4.tar.gz

md5 – 3fc65e68fb0cae77a687069901fc0525

Versão 0.3 disponível para Download.

nagmobile-0.3.tar.gz – http://www.brunorusso.eti.br/nagMobile/src/nagmobile-0.3.tar.gz

md5 – 2f58c120a0e2b3e67eb1553cb1254bd7

Versão 0.2 disponível para Download.

nagmobile.tar.gz – http://www.brunorusso.eti.br/nagMobile/src/nagmobile-0.2.tar.gz

md5 – fb0ac33d4b9b2de53a641d9241bfd61b

Doação

Gostou desse programa?

Ele foi útil para você?

Ajude-me de forma que outros programas iguais a este sejam criados.

Pré-requisitos

Para o correto funcionamento são necessários os softwares abaixo:

Instalando

A instalação é simples, basta descompactar o arquivo no diretório web do nagios.

  • Por exemplo, caso o o diretório do nagios seja:
/var/www/htdocs/nagios

basta descompactar o nagmobile criando o diretório:

/var/www/htdocs/nagios/mobile
  • Após descompactar, altere os parâmetros abaixo do arquivo config.php.
$SERVER_NAME = "URL to access default nagios";
$SERVER_NAME = "http://127.0.0.1/nagios"; <-- example
$USER_NAGIOS = "user to access web interface";
$USER_NAGIOS = "nagios";  <--example
$PASS_NAGIOS = "password to user";
$PASS_NAGIOS = "nagios"; <--example
$DOC_ROOT = "directory where nagmobile was installed";
$DOC_ROOT = "/var/www/htdocs/nagios/mobile"; <-- example

Não altere nenhuma outra variável.

Dica: Toda variável deve estar entre aspas duplas ”“ e deve terminar com o símbolo de ;
  • Para finalizar a configuração, inclua no arquivo config_url.php a url dos grupos de serviços ou de hosts que deseja monitorar.
http://127.0.0.1/nagios/cgi-bin/status.cgi?hostgroup=Windows&style=overview
http://127.0.0.1/nagios/cgi-bin/status.cgi?hostgroup=Linux&style=overview
http://127.0.0.1/nagios/cgi-bin/status.cgi?hostgroup=Routers&style=overview

Pronto! A instalação está concluída. Para acessar a Interface utilize a URL que você acessa o nagios acrescentando /mobile.

Screenshots

NagMobile

Como é o seu funcionamento

No Nagios, os serviços e hosts podem ser agrupados por grupos identificados como hostgroups e por serviços, identificados como servicesgroups.

Cada grupo, criado possui uma URL única. E através dessa URL é que o NagMobile identifica e exibe as informações necessárias.

NagMobile - Fluxo do Sistema

BUG

Encontrou algum erro, nesta página ou no script? Envie um mensagem para: contato@brunorusso.eti.br

Eu ficarei feliz com a sua ajuda ;-)

ChangeLog

2010-11-16 Bruno Tadeu Russo <contato@brunorusso.eti.br>
 - Version 0.4
 - Fixed an error at line 19 of file config.php (lack of the symbol;) - Thanks to Lance Rea
2010-11-12 Bruno Tadeu Russo <contato@brunorusso.eti.br>
 - Version 0.3
 - Added link to the index.html in the image and the bottom of the page.
 - A message can be displayed at the top of the page just after the picture with the logo through the BANNER variable set in config.php
 - added auto refresh every 120 seconds
2010-10-27 Bruno Tadeu Russo <contato@brunorusso.eti.br>
 - Version 0.2
 - Changed the way it is done processing the url when replacing. This is necessary because the character "/".
 - Add variable $SERVER_NAME_CONV, to replacing URL.
 - Now the variable $ doc_root is necessary to complete the other variables.
 - Create Logo.png.
 - Writing the user manual and configuration.
2010-10-20 Bruno Tadeu Russo <contato@brunorusso.eti.br>
 - Version 0.1
 - Beta version, many bugs.
Nagios, the Nagios logo, and Nagios graphics are the servicemarks, trademarks, or registered trademarks owned by Nagios Enterprises.

Ententendo como utilizar o site Slackbuilds.org

Este artigo foi importado do site http://linux.brunorusso.eti.br, que foi desativado. Este artigo, foi originalmente publicado em: 22/11/2009. Apesar da “idade” deste artigo, o seu conceito ainda é válido.

Introdução

O Slackware é a distribuição mais antiga em atividade, possui um conceito muito interessante quando comparada às demais distribuições, que é o conceito KISS (Keep it simple, stupid). O slackware é desenvolvido por um pequeno grupo de pessoas (até onde eu sei são 8 pessoas ao todo que participam do desenvolvimento da distribuição). Devido a esse e outros motivos, o Slackware não possui uma quantidade grande de pacotes, principalmente pacotes para programas pequenos, ou que não são tão essenciais. Ao mesmo tempo, o Slackware possui uma facilidade muito grande para a criação de seus pacotes, que são criados através de simples scripts denominados de SlackBuilds.

Muitas pessoas, criam seus próprios pacotes através do SlackBuilds.

Em 2006 surgiu o site slackbuilds.org, que nada mais é que um repositório de SlackBuilds prontos para serem utilizados, e o mais importante é que os SlackBuilds são validados, ou seja, são 100% confiáveis, visto que irá gerar o pacote é você. Não há pacote pronto!

Atualmente, o projeto SlackBuilds.org é mantido por um pequeno grupo de pessoas. Esse pequeno grupo, avalia os scripts SlackBuild dos pacotes enviados por diversos usuários do mundo todo. Assim que os scripts enviados passam pela análise da equipe, são disponibilizados para os demais usuários.

Como o Slackbuils é organizado

Atualmente o repositório oficial do Slackbuilds.org, possui um pouco mais de 70MB de scripts, prontos para serem utilizados. Os scripts são organizados nos seguintes grupos:

  • Academic
  • Accessibility
  • Audio
  • Business
  • Desktop
  • Development
  • Games
  • Graphics
  • Libraries
  • Misc
  • Multimedia
  • Network
  • Office
  • System

Em cada grupo podemos encontrar um ou mais scripts prontos, organizados da seguinte forma:

./pacote
  |-- README
  |-- pacote.info
  |-- pacote.SlackBuild
  |-- pacote.desktop
  |-- pacote.png
  |-- slack-desc

onde,

  • README, possui informações básicas sobre o pacote, é importante ler este arquivo antes de iniciar a criação do pacote.
  • pacote.info, possui informações que serão utilizadas pelo script de criação do pacote, além de informações sobre o autor do pacote e o responsável pela aprovação dos pacotes.
  • pacote.desktop, informações para que um ícone do programa seja adicionado ao menu do ambiente gráfico.
  • pacote.png, ícone da imagem que será utilizada para representar o programa no menu gráfico.
  • slack-desc, arquivo contendo as informações do pacote para serem exibidas durante a instalação.

Alguns pacotes possuem outros arquivos, como por exemplo o doinst.sh. Tudo isso depende do pacote! 😉

Criando um pacote através do slackbuilds

Para criar um pacote, através dos scripts do Slackbuilds, execute os passos a seguir.

Neste exemplo, vamos criar o pacote do aplicativo lyx

1. Primeiro vamos baixar o script, dentro de um diretório ~/tmp, para criar o pacote.

mkdir ~/tmp
cd ~/tmp
wget http://slackbuilds.org/slackbuilds/13.0/office/lyx.tar.gz

2. Agora vamos descompactar o arquivo baixado.

tar xzvf lyx.tar.gx
cd lyx

3. Agora é preciso baixar o pacote (código-fonte) do programa, no nosso caso o lyx.

wget ftp://ftp.lyx.org/pub/lyx/stable/1.6.x/lyx-1.6.3.tar.gz

4. Agora é necessário conceder permissão de execução para o arquivo lyx.SlackBuild

chmod +x lyx.SlackBuild

5. Tudo pronto para o início da criação do pacote. Para iniciar, basta executar:

./lyx.SlackBuild

Se tudo der certo, será criado um arquivo dentro do diretório /tmp, com o nome

lyx-1.6.3-x86_64-1_SBo.tgz

7. Para instalar o pacote, execute.

installpkg /tmp/lyx-1.6.3-x86_64-1_SBo.tgz

Pronto! Pacote criado e 100% compatível com a distribuição instalado em seu sistema.