O Pensamento Enxuto na Análise de Negócios
Upcoming SlideShare
Loading in...5
×
 

O Pensamento Enxuto na Análise de Negócios

on

  • 2,534 views

Palestra realizada em 3 de setembro de 2010 no evento "Pensando Lean" (São Paulo). Baseada nos princípios do pensamento enxuto e somente em duas áreas do conhecimento da Análise de Negócios ...

Palestra realizada em 3 de setembro de 2010 no evento "Pensando Lean" (São Paulo). Baseada nos princípios do pensamento enxuto e somente em duas áreas do conhecimento da Análise de Negócios (Planejamento e Análise Corporativa), esta apresentação explora como a DESCOBERTA e a ENTREGA devem estar ambas no foco da análise de negócios em projetos ágeis.

Statistics

Views

Total Views
2,534
Slideshare-icon Views on SlideShare
2,234
Embed Views
300

Actions

Likes
1
Downloads
139
Comments
0

10 Embeds 300

http://blog.bluesoft.com.br 81
http://bluesoft.wordpress.com 74
http://cantinhodoagile.blogspot.com 72
http://cantinhodoagile.blogspot.com.br 59
http://www.infoblogs.com.br 5
http://www.cantinhodoagile.blogspot.com 3
http://infoblogs.com.br 2
http://cantinhodoagile.blogspot.pt 2
http://blog2.bluesoft.com.br 1
http://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    O Pensamento Enxuto na Análise de Negócios O Pensamento Enxuto na Análise de Negócios Presentation Transcript

    • 2010 “O Pensamento Enxuto “O Pensamento Enxuto na Análise de Negócios” na Análise de Negócios” Continuous Discovery and Delivery of Business Transformations
    • Você sabe o que é Análise de Negócios?
    • Definição baseada no IIBA: “Análise de Negócios é um conjunto de práticas e ferramentas que permitem compreender a estrutura, as políticas e as operações de uma organização a fim de se recomendar soluções que possam contribuir para a realização de seus objetivos.” 2004-2009
    • Ok! Ok! Não é exatamente isso aí que muita gente faz por aí Agile Development Business Intelligence Analista deNegócio Analista de Negóócio Negó Neg Analista de Sistemas Business Process Management Analista de Sistemas Business Rules Analista de Requisitos Analista de Requisitos Product Owner Decision Analysis and Game Theory Product Owner Enterprise Architecture Governance and Compliance Frameworks Gerente de Produto Gerente de Produto Arquiteto deNegócio Arquiteto de Negóócio Negó Neg IT Service Management Lean and Six Sigma Gerente de Projeto Gerente de Projeto Consultor de Gestão Consultor de Gestão Organizational Change Management Project Management Designer de UX Designer de UX Analista de Processo Analista de Processo Quality Management Service Oriented Architecture Software Engineering (particularly Requirements Eng.) Software Process Improvement Software Quality Assurance Strategic Planning Usability and User Experience Design
    • Business Analysis Knowledge Areas Determinar como será realizada Determinar como será realizada BABOK® Guide Version 2.0 aa análise de negócios análise de negócios Compreender oo problema Compreender problema ee definir uma solução viável definir uma solução viável Determinar qual solução éé a Determinar qual solução a Identificar as necessidades mais adequada para as mais adequada para as Identificar as necessidades necessidades do negócio ee preocupações dos preocupações dos necessidades do negócio “stakeholders” “stakeholders” Manter oo acordo entre stakeholders Manter acordo entre stakeholders ee a equipe de desenvolvimento a equipe de desenvolvimento sobre oo escopo da solução sobre escopo da solução Determinar oo que deve ser Determinar que deve ser desenvolvido para atender as Suportar oo desempenho desenvolvido para atender as Suportar desempenho necessidades dos “stakeholders” necessidades dos “stakeholders” da análise de negócios da análise de negócios
    • Mas os profissionais de Análise de Negócios não são adeptos do modelo WATERFALL?
    • Em 2006, por reconhecer que a abordagem ágil está influenciando significativamente a forma como produtos de software são desenvolvidos, o IIBA determinou que a versão 2.0 do BABOK (2009) se tornasse compatível com essa visão. Plan Driven X Change Driven BABOK Agile Extension será publicada em 2011
    • Let’s play Let’’s play Let’ Let a game! a game!
    • Grandes Lotes x Pequenos Lotes Setup da Equipe Analista Projetista Programador Testador Cliente Objetivo do Jogo Entregar para o cliente 10 requisitos de software analisados, projetados, codificados e testados no menor tempo possível.
    • Resultados do Experimento Operação em Grandes Lotes Aná Análise Projeto Programaç Programação Testes 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 Duração Total = 40 UT 1º. Feedback = 31 UT Em 77,5% da operação ainda temos 90% das funcionalidades com alto risco. Operação em Pequenos Lotes (Fluxo Unitário) Aná Análise 1 2 3 4 5 6 7 8 9 0 Ganho de Velocidade = 40 / 13 = 3,07 Projeto 1 2 3 4 5 6 7 8 9 0 Lead Time Final = 13 / 40 = 32,5% Programação Programaç 1 2 3 4 5 6 7 8 9 0 Testes 1 2 3 4 5 6 7 8 9 0 Tempo para Feedback = 4 / 31 = 12,9% Duração Total = 13 UT 1º. Feedback = 4 UT Em 30,8% da operação ainda temos 60% das funcionalidades com risco zero.
    • Questões para nossos Gestores 1. É do interesse de sua organização realizar projetos de software de forma tão lenta? 2. Se realmente não é do interesse, o que mantém a cultura da organização apegada ao desperdício? 3. As “partes interessadas” nos projetos de software tem alguma noção dos riscos que elas correm? 4. Você acredita que esse baixo desempenho e alto risco podem afetar os resultados do negócio? 5. Qual poderia ser o interesse da Análise de Negócios diante deste cenário?
    • “Não somente o escopo da solução, mas a forma como ele é entregue a seus usuários pode afetar os resultados do negócio.” X
    • Questionamento No. #1 Como o Pensamento Enxuto pode afetar o Planejamento das Atividades de Análise de Negócios?
    • Dude’ The Dude’s Law Why Value = By David How Hussman
    • 1º. Conduzindo a Organização para uma Cultura Iterativa-Incremental de Valor de Negócio Tom Gilb http://stakeholdervalues.com/Value+Product+Owner Ciclo de 1 a 3 semanas Ciclo de 1 a 3 semanas Analista de Negócios Product Champion Parte Interessada SCRUM Visão de Produto Visão de Negócio Visão de Produto Visão de Negócio Verificação da Verificação da Verificação da Verificação da Priorização Priorização Product Owner Facilitador Priorização Priorização Visão de Visão de Negócio Produto Gestão do Valor Gestão do Desenvolvimento Gestão do Valor Gestão do Valor Gestão do Valor Gestão do Desenvolvimento NEGÓ NEGÓCIO PRODUTO NEGÓ NEGÓCIO
    • 2º. Conduzindo Stakeholders para o Pensamento JIT Concepção Geral Concepção Geral Aprovação Aprovação Business Case Business Case Project Charter Project Charter JIT Setup de Ambiente Setup de Ambiente Ciclo de Produção Ciclo de Produção Ciclo de Produção Ciclo de Produção Auto-Organização Auto-Organização Detalhamento Progressivo Detalhamento Progressivo Detalhamento Progressivo Detalhamento Progressivo Sprint 0 Sprint 1 Sprint 2 Validation Requirements Workshop de N+2 Retrospective de N Sprint N Daily Scrum Sprint Review de N DS DS DS DS R DS DS DS DS R SR SR P1 RW1 VAL1 RW2 VAL2 P1 RW1 VAL1 RW2 VAL2 P2 P2 Dia 1 Dia 2 Dia 3 Dia 4 Dia 5 Dia 1 Dia 2 Dia 3 Dia 4 D5 Dia 1 Sprint Planning 2 de N Sprint Planning 1 de N Requirements Sprint N+1 Workshop de N+1
    • 3º. Estimular o Fluxo Contínuo e Puxado das Demandas de Negócio Henrik Kniberg QCon, QCon, San Francisco Nov 18, 2009
    • 4º. Contribuir para o Balanceamento da Produção Estoque inicial Desenvolvedores com uma Desenvolvedores com uma Estoque inicial ligeira baixa capacidade detalhado em alto nível. detalhado em alto nível. ligeira baixa capacidade Stelios Pantazopoulos, Project Vital Signs (http://www.projectvitalsigns.com/) Analistas fazendo estoques QA ee Cliente validando Analistas fazendo estoques QA Cliente validando de requisitos detalhados continuamento oo produto de requisitos detalhados continuamento produto
    • 4º. Contribuir para o Balanceamento da Produção David J. Anderson http://www.agilemanagement.net/Articles/Weblog/Archives/June2009.html
    • 5º. Estimular a Melhoria Contínua da Cadeia Logística do Fluxo de Valor
    • Redução do Lead Time Reduç Dude’ The Dude’s Law Why Value = By David How Hussman
    • Questionamento No. #2 Como o Pensamento Enxuto pode afetar a Análise de Negócios Corporativa?
    • By David Hussman
    • Pensamento Focado na Entrega de Valor e na Redução de Desperdícios Valor é visto através dos olhos daqueles que pagam pelo uso e que se beneficiam com os sistemas que desenvolvemos. Desperdício é qualquer coisa que deprecie os recursos no tempo, esforço, espaço ou dinheiro sem acrescentar valor ao cliente.
    • Geralmente, novos recursos são “empurrados” para o ambiente, mesmo não agregando valor para seus usuários, tampouco para o negócio ... By Chris Matts “Feature Injection” Se trabalharmos orientados ao verdadeiro valor agregado, somente acrescentaremos recursos num produto de software quando o valor de negócio for puxado pelo cliente.
    • Você sabe o que realmente tem valor negó para um negócio?
    • A Hierarchical Model for the Project Scope
    • Ideal Software Product guided by Identity and Mission that has business value guided by Beliefs and respects developed by Personal Values improves Capabilities supports and Strategies supported by Actors Behavior generates determine Results Market or relative to Environment Authored by Luiz C. Parzianello based on Robert Dilts’ Logical Levels
    • A Business Transformation Model Release #1 Release #2 Release #3 Release #4 Time Time New Capabilities: New Capabilities: ••Who? Business Roadmap Who? Business Roadmap ••What? What? STRATEGY ••Why? Why? < My User Story > New Results: New Results: ••What? In order to <new or improved business capability> capability>, What? ••Where? Where? as a <role>, I need to <new or improved behavior> by <role> ••When? When? using <a software product or component> component>. ••How much? How much? Business Value: X Other Attributes: ABCD … Value: Attributes: New Behaviors: New Behaviors: ••Who? Criteria: Acceptance Criteria: Constraints: Constraints: Product Roadmap Who? Product Roadmap OPERATIONS ••What? What? ••How? How? - Funct. Reqs.? - Non-Funct. Reqs.? New Features: - BDD? - Business Rules New Features: ••What? What? ••How? How? ••Why? Why?
    • Método Científico Cientí “Até que se prove o contrário, a maioria dos requisitos Até contrá são hipóteses aguardando comprovação” hipó comprovação”
    • “First be sure you are building the right thing. Then make sure right.” you are building the thing right.” “The Poppendiecks” Poppendiecks” “What defines a winner is not how fast we deliver, but how fast we learn from what we deliver” Jason Gorman
    • Crité Critérios de Sucesso para serem observados ao final de um Projeto de Software: Software Cliente satisfeito com o investimento; Fornecedor satisfeito com o lucro; Usuários satisfeitos e elogiando o produto; Equipe satisfeita e orgulhosa dos resultados; Equipe ainda mais competente; Todos prontos para um novo projeto!
    • A prática não deve ser meramente um meio ou um caminho para se alcançar um objetivo, a iluminação. A prática (meio ou caminho) é, por si só, o objetivo (iluminação), assim como o objetivo (iluminação) por si só é a própria prática. Ensinamento Zen
    • Muito obrigado! Luiz Claudio Parzianello parzianello@gmail.com http://twitter.com/lcparzianello http://www.slideshare.net/parzianello