WS Tech

I tried to maintain an Angular app since beginning with Docker, creating on it and turning into a docker-compose app. I used an Angular 12 app to do this. We need Docker

First of all I need to create Dockerfile with my Angular application.

FROM node:16-alpine3.11
RUN npm i -g npm && npm i -f @angular/cli
WORKDIR /var/app
Doing this we will have the initial container to create our application. So, we can build our container. I built my container tagging it with name "angular"
docker build -t angular .

Generating our Angular App

Doing that we will have our container to create the angular app

docker run --rm -v $(pwd):/var/app angular ng new my-testing-app --skip-git true

It will take a long time, and it will be normal. Note I used --skip-git true option. I didn't installed git on my container. We can do this later, by the way.

That's it! We already have our application without install angular on machine. That machine we built will serve also to run the app

Docker Composing

Let's create the docker-compose.yml file right now:

version: '3.9'
networks:
  development:
services:
  app:
    container_name: app
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - ./my-testing-app:/var/app
    networks:
      - development
    ports:
      - 4200:4200
    expose:
      - "4200"
    stdin_open: true
    environment:
      - MODE=dev
    command: [ 'ng', 'serve', '--host', '0.0.0.0' ]

Note I used the app name my-testing-app to identify my app. The docker-compose file is out of my app directory, but you could put inside the app directory, changing the volume address to . without project directory.

Done on it, we can run our docker-compose:

docker-compose up

You can go to your browser and type localhost:4200 on your address bar and, done! Up and running angular app.

You can create your api project, and all infrastructure to your app on docker-compose.yml file.

Esta semana realizei um processo inusitado na Creative Pack. O objetivo era ajudar alguns setores da empresa a encontrar novos papéis e redefinir alguns já existentes no processo de Holocracia que possuímos.

Algumas pessoas na empresa passavam por dificuldades de entender o que de fato estavam entregando e isso estava gerando ansiedade nas equipes e consequentemente estávamos não só entregando muita coisa, como muita coisa desestruturada.

Pois bem, me foi dada a missão de tratar os processos das pessoas como uma jornada e assim escolhi utilizar Story Mapping como processo de gestão das pessoas. O Story Mapping foi escolhido por se tratar de um mapeamento de jornada, o que de alguma forma, é um processo de execução de trabalho das pessoas na empresa.

Laboratório

Foi desenvolvido um laboratório utilizando Story Mapping e que durou quatro horas com os times que se candidataram ao processo. Foram 3 equipes da empresa.

Começamos o laboratório definindo exatamente quais os goals que esses círculos tem ao desenvolver seus trabalhos. Cada equipe precisou pensar nos seus processos e pensar quais são os pontos altos dos trabalhos que elas executam. Cada equipe elencou entre 4 e 6 grandes pontos dos seus ciclos de trabalho.

A segunda parte foi a criação do backbone, onde as equipes desenvolveram o ciclo completo dos seus trabalhos a fim de tornar visível tudo o que faziam, sem um detalhamento maior. Apenas dando visibilidade como uma jornada de fato. Pensamos em criar cada cartão desse backbone iniciando com um verbo para dar clareza de que cada item se tratava de um passo dentro do processo deles.

Quando chegamos ao detalhamento, as equipes já se impressionavam com o volume de trabalho que elas executavam sem nem mesmo se dar conta. Essa visibilidade ficou mais evidente quando de fato começamos o detalhamento, onde eles poderiam colocar não só os processos em detalhes, como gestão de recursos, materiais, pessoas e processos que eram feitos sem que houvesse maior visibilidade com o trabalho deles.

O processo, como sempre, foi bem longo e cansativo, mas as equipes conseguiram finalizar com tudo aquilo que eles viam nos processos e pesquisaram para entender se fazia realmente parte do processo das suas tarefas ou não.

Para finalizar o laboratório, separamos os goals em contextos. onde traçamos uma linha vertical por cada um dos goals e os cartões com pedaços do backbone que faziam parte daquele contexto. Assim, chegamos a algumas conclusões importantes: Os goals se tornaram os papéis dos círculos, que poderiam ou não ser incorporados uns aos outros com base no que seria proposto para cada papel.

Mas o mais importante no processo todo, foi percebermos que o backbone se tornou as responsabilidades de cada papel em seu contexto. Ficou muito mais claro entender até onde cada papel deve exercer suas atividades e em qual momento uma atividade deveria ser delegada, inclusive por saber qual era o papel que receberia o resultado daquela responsabilidade, o que diminui a possibilidade de criação de tensões por conta do não entendimento de papéis.

Os cartões do detalhamento puderam ser agrupados em tarefas, recursos, materiais e decisões para que se tornasse ou parte do checklist do papel ou parte de um projeto do papel, uma vez que algumas atividades poderiam ser apenas acessório para que o checklist fosse elucidado.

Conclusão

Percebemos que apesar de não ter sido criado para isso, o Story Mapping se demonstrou uma excelente ferramenta de mapeamento para os papéis holocráticos. A partir deste ponto, é possível criar uma governança dento de cada círculo e definir os papéis com muito mais facilidade, uma vez que temos os papéis, suas responsabilidades, os checklists e os projetos. Fica a cargo de cada papel energizado definir suas métricas com base nas suas responsabilidades.