Organização¶

As organizações foram divididas em departamentos independentes, cada uma com sua especialidade, objetivo e prioridade: Gestão de Pessoas, Finanças, Tecnologia da Informação, Administração etc. Dentro de cada departamento, as pessoas foram divididas em unidades ainda mais especializadas.

Versus

O time multidisciplinar tem o objetivo de reduzir os efeitos causados pelos silos, o que nos leva a pensar, em um time, com todas as competências, habilidades e autorizações necessárias para construir e evoluir produtos e serviços.

Time multidisciplinar¶

Com o tempo, deixamos de ter profissionais do tipo Especialistas em parte, passamos a ter Profissionais do Tipo Especialistas-Generalistas e podemos até ter profissionais do Tipo Especialista em várias áreas do Produto.

Treinamento Em Agile E Scrum¶

O 60PPORTUNITIES possui colaboradores capacitados e certificados em Scrum Master e Scrum Product Owner (Scrum.org, ScrumStudy), e estamos focando no treinamento *Agile for Teams e Leaders* para que entendamos e apoiemos mais as equipes.

Melhoria no 60PPORTUNITIES¶

• Para usar o Scrum com eficácia, fizemos um planejamento inicial para garantir que teríamos as pessoas, processos, suporte e ferramentas certas. Este planejamento contou com: Cristiane Valardan (Scrum Leader) com diversos treinamento em SCRUM e lançamento de Horas, Marcus Pessoa (Capacitação em Teste de Software) e Antonio Aureliano/Denis Medina (Gráficos).
• Definimos que iríamos utilizar o Microsoft Azure-Devops e que havia a necessidade em treinar o pessoal. Todos passaram a ter licenças de Stakeholder para Basic;
• No início criamos PROJETOS e posteriormente chamamos de PRODUTOS. Pedimos que TODOS os PRODUTOS, fossem devidamente migrados do Gitlab para o Azure-Devops.
• Melhoramos, não mudamos o processo MÃE do Azure-Devops e mantivemos TUDO em Inglês, igualamos as queries, Dashboards e a forma de pensar.
• Todos os produtos com pelo menos 2(dois) repositórios, sendo: - [x] Front-End; - [x] Back-End; - [x] Documentação;
• Os projetos com DOCUMENTAÇÃO deveriam se ligar ao repositório de PORTIFÓLIO.

Defina o Produto¶

O problema não está na eficiência do time e sim na eficácia das suas entregas, ou seja, entregar algo de valor e impacto para o cliente, dessa forma, ele utiliza o produto e só então consegue dar feedback sobre o quão próximo ou distante estamos de resolver seus problemas.

Meça o progresso com base no valor entregue:

Se você completa todas as tarefas e nada melhora, isso não é sucesso.

Para um bom Produto e chega de Agile¶

• Criamos seitas em torno de cada método, isso não é time contra, que adoravam aquele método e falam mal de outros métodos.
• Os métodos podem colocar boas ideias na prisão, nomeadamente na sua própria prisão.
• O Agile realmente não introduziu nenhuma nova prática técnica. Pode-se dizer que o desenvolvimento iterativo usando sprints e trabalhando em pequenos períodos para entregar resultados concretos já existia. Foi usado desde o início dos anos 1980. Houve trabalhos científicos em torno do modelo espiral de desenvolvimento de Barry Beam.
• O movimento Agile basicamente matou qualquer abordagem antiga e eles estavam mais focados em como as pessoas trabalham juntas, basicamente engenharia social.

Produto no Azure-DevOps¶

Um PRODUTO é local para os usuários planejarem, acompanharem o progresso e colaborarem na criação de soluções de software. Um PRODUTO representa um contêiner fundamental em que você pode armazenar dados e código-fonte.

Um PRODUTO terá pelo menos DOIS times/equipes BASE, um sendo SUSTENTAÇÃO e pelo menos UM TIME para a realização de NOVAS FEATURES e/ou PROJETOS controlados na BBTS.

• Exemplo: https://dev.azure.com/ORGANIZAÇÃO/PRODUTO

Equipe/Time¶

Você cria uma equipe que corresponde a um grupo de colaboradores focado em produtos, serviços ou áreas de recursos específicos. Você adiciona equipes para fornecer as ferramentas necessárias para gerenciar a lista de pendências, planejar sprints, configurar painéis, definir alertas e definir favoritos da equipe.

• Equipe SUSTENTAÇÃO : As Sprints serão MENSAIS, lançamentos de horas;
• Equipe PROJETO : As Sprints serão de 2(duas) semanas.

Diferença de Modelos¶

• Waterfall
• Ágeis
• #NoProjects e A Culture of Continuous Value
• IT4IT

Métricas¶

Enquanto o lead time mede todo o processo desde a chegada da nova demanda, o tempo de ciclo analisa as áreas do processo em que as equipes estão agregando valor ao trabalho em questão.

Tudo = Nada¶

• Tudo(Demandas Expressas, TEAMS, Bugs) ou somente PDTIC?
• Muitas atividades NÃO planejadas.

Nomenclatura do Repositório¶

Por padrão iremos impedir que certos caracteres sejam incluídos no nome do repositório. Embora não haja uma maneira errada de nomear um repositório, alguns nomes são melhores que outros. O comprimento do repositório não deve conter mais de 64 caracteres Unicode e não pode ser idêntico a nenhum outro nome de repositório Git no projeto. Todas essas sugestões estão sendo seguidas pelo criador automático. Usando isso como diretriz, dividimos o repositório em 3(três) seções separadas por underscore. Esse formato consiste em seções que definem:

• PRODUTO, FINALIDADE e ESTRUTURA DA LINGUAGEM.

Deve se perceber as seguintes características: descritivo, legibilidade, consistência, contextual, extensibilidade, reuzabilidade e sucinto.

OBSERVAÇÃO: Os repositórios serão em maiúscula separando as seções por underscores - SCREAMING SNAKE CASE

#noprojects¶

Traz um ponto de vista diferente e uma forma alternativa de encarar o trabalho, concentrando-se principalmente nos resultados do negócio e, ao mesmo tempo, entregando o trabalho como um fluxo contínuo de valor, em vez de um empreendimento temporário.

A realidade é que a maioria dos requisitos incluídos no plano do projeto (ou backlog, se você estiver adotando uma abordagem ágil) são, na melhor das hipóteses, suposições absurdas sobre o que algum usuário representativo pode querer, validadas por um assunto específico.

Comece definindo os resultados pretendidos em termos de métricas que realmente importam, em vez de métricas de vaidade fáceis de medir.

• Identifique o primeiro pequeno passo ou experiência que validará as suposições que você está fazendo para alcançar os resultados.
• Execute essa etapa.
• Meça os resultados.
• Inspecione o processo e adapte-o à realidade do que aprendeu. Por fim, repita para a próxima etapa, gire ou pare se tiver feito o suficiente, atingido o valor máximo ou aprendido o suficiente.

• Estas ideias baseiam-se no profundo respeito pelas pessoas como principal fonte de inovação e valor nas organizações.

• Tudo é uma mudança; trate-o adequadamente. A mudança é feita por, para e para as pessoas. Trate os com respeito e eles criarão valor. Isso é #noprojects.

Grande parte do trabalho que você faz hoje, especialmente o trabalho de conhecimento, é único e inovador e tem mais em comum com o talentoso fabricante de alfinetes do que com uma fábrica de alfinetes.

• Equipe de entrega de valor é uma equipe (ou rede de equipes) dedicada, estável e multifuncional, responsável por um resultado.

Por que 95% dos novos produtos lançados no mercado falham (e como você pode evitar que isso aconteça com você)¶

No saco dos fracassos estão o Google Glass (depois de milhões de dólares de investimento ninguém sabe o que aconteceu com eles), a New Coke que a Coca-Cola lançou no mercado em 1985 (na verdade era uma nova fórmula na qual substituiu o açúcar comum pelo milho rico em frutose) ou o lançamento em 1982 da Colgate Kitchen Entrees (aliás, a Colgate, empresa que se dedica à venda de produtos de higiene oral, decidiu lançar a sua gama de alimentos prontos).

Por esta razão, 92% das startups afundam nos primeiros 3 anos após o início.

“Muitas inovações falham porque introduzem produtos e/ou soluções sem que haja realmente necessidade. “Não há mercado para as soluções que eles criaram.”

Steve Jobs levou a Apple ao topo porque sabia o que o consumidor queria . O que era importante para ele não era a tecnologia, mas sim a experiência do usuário . Em 2006 ele disse: “Há muita tecnologia em busca de cliente .

Por outras palavras, muitas empresas fazem coisas porque é tecnicamente possível, mas no final ninguém se importa e ninguém quer comprá-las. Acho que o difícil é descobrir o que pode ser feito e o que as pessoas querem.”

Arquitetura infraestrutura dados e Inteligência Artificial¶

Eu, não adotaria o TOGAF (The Open Group Architecture Framework) e sim o IT4IT (The Open Group IT4IT Reference Architecture).

Se você tem que motivar funcionários, você não está contratando direito.¶

CRIE um ambiente onde profissionais motivados:

• Produto em si: A chave é identificar e comunicar o que torna seu produto significativo, seja qual for esse significado. Quando os desenvolvedores entendem completamente essa responsabilidade e importância, isso geralmente leva a um engajamento e dedicação mais profundos ao seu trabalho. Eu vi equipes transformarem sua atitude quando realmente entenderam como seu código impacta a vida de pessoas reais.
• Artesanato Técnico: Equipes se orgulham de construir um código excelente. Resolvendo problemas algorítmicos complexos ou implementando soluções arquitetônicas elegantes, a excelência técnica.
• Espírito de Equipe: Senso de pertencimento a algo especial. Envolve construir uma cultura onde a participação na equipe seja significativa e valorizada.

Dizer “não” não é tão ruim¶

Consistência de Compromisso (CC): O desafio é fazer perguntas que permitam respostas positivas e negativas, onde um "não" naturalmente convida à explicação.

• Você gosta de picles em conserva? Elaborar perguntas para encorajar explicações em vez de respostas rápidas de "sim" é uma ótima maneira de aprofundar conversa. PENSE NISSO.

• Baca-Motes, K., Brown, A., Gneezy, A., Keenan, E., & Nelson, L. (2013). Comprometimento e mudança de comportamento: evidências do campo. Journal of Consumer Research , 1070 - 1084.

• Fisher, W., Ury, WL, & Patton, B. (2011). Chegando ao Sim: Negociando Acordos Sem Ceder. Penguin Books.

Product Owner a uma equipe, por que não capacitá-lo?¶

Ela tinha uma visão cristalina e metas fortes, mas não escrevia cada item do Product Backlog sozinha. Limitar um Product Owner a uma equipe em um produto grande não torna as coisas mais fáceis – cria mais burocracia. Em vez de pensar em limitar, pense em empoderar!

Deixe o Product Owner guiar várias equipes quando fizer sentido e dê a eles os recursos para delegar. Dessa forma, eles permanecem focados na visão e as equipes permanecem alinhadas na entrega de valor.

Pensamento de Produto¶

• As equipes recebem problemas para resolver em vez de projetos para concluir.
• Se envolvem na entrega de soluções que beneficiam os clientes e os negócios.
• Ponderam as decisões sobre novos recursos e trabalho de suporte em relação ao valor geral do produto.
• Se adaptam às necessidades do cliente continuamente, criando melhores resultados para todos.
• Criando uma Visão de Produto
  • Quem eles VOCÊS veêm como seus usuários e quais desafios específicos esses usuários enfrentavam?
  • Como vocês poderiam fornecer valor que abordasse diretamente esses desafios?
  • Quais seriam os benefícios comerciais, para esta visão?
• Definida a jornada, qual seria a a Meta do Produto?
  • O Time define uma meta concreta e atingível;
• Os primeiros itens identificados focaram no que os usuários queriam fazer.
• A equipe construiu mais itens do Product Backlog em torno do trabalho de infraestrutura
• Se a equipe está enfrentando dificuldades com prioridades pouco claras e dívida técnica crescente, é hora de abandonar a mentalidade de projeto e adotar uma abordagem focada no produto, liberando o potencial da sua equipe e entregar valor contínuo.