27 de mai. de 2009

Jornada T@rgetTrust de Metodologias Ágeis

Caro(a) amigo(a),

Se você é daquelas pessoas que ainda não ouviu falar de métodos ágeis ou gostaria de esclarecer diversas dúvidas que ainda pairam sobre sua cabeça sobre esse assunto que virou febre nas últimas conferências, revistas e listas de discussão, se inscreva na I Jornada T@rgetTrust de Metodologias Ágeis. Este evento será realizado no dia 9 de Junho, terça-feira, no Auditório da Assespro, localizado no Tecnopuc, o maior Parque Científico e Tecnológico da América Latina.

Neste evento, Daniel Wildt, Guilherme Lacerda e eu, apresentaremos um "pout-pourri" de diversos temas, estimulando a participação de todos e desafiando as crenças arraigadas das abordagens tradicionais de desenvolvimento de software.

Confira a programação abaixo e venha tomar um café conosco naquela tarde!

[]´s

Parzianello

Jornada T@rgetTrust de Metodologias Ágeis

Venha compreender a origem, os princípios e as práticas da mais nova
tendência mundial do mercado de software!

Data, Horário e Local

9 de Junho de 2009
Horário: das 13h30min às 18h30min
Tecnopuc - Auditório Assespro

Investimento

R$ 120,00 por pessoa até 29/05/09
Acima de 3 inscrições 10% de descontoINTRODUÇÃO

Apresentação

As Metodologias Ágeis deixaram de ser apenas o sonho de muitos gurus da Engenharia de Software e passaram a ser a realidade de muitas empresas que adotaram seus princípios e valores como estratégia de sobrevivência diante da crise econômica mundial. As Metodologias Ágeis procuram garantir a satisfação do cliente mediante a entrega rápida e contínua de software em funcionamento, promovendo a cooperação entre os profissionais de negócio (equipe do cliente) e de produto (equipe de software), a excelência técnica em todos os níveis e a rápida adaptação às mudanças do ambiente de trabalho.

As Metodologias Ágeis exigem dos profissionais de software uma grande maturidade para lidar com a formação de times auto-gerenciáveis e a busca contínua da perfeição de pessoas, ferramentas e métodos. Por tratar diretamente dos aspectos humanos do desenvolvimento de software, são incompreendidas e alvo de críticas infundadas de profissionais que desconhecem a evolução dos modelos de gestão organizacional.

Quem deve participar

As empresas e profissionais da área de software que procuram orientação sobre como aderir aos conceitos e práticas das principais Metodologias Ágeis existentes no mercado.

O que iremos apresentar

Programamos para você uma tarde repleta de informações e debates com a participação dos principais expoentes da comunidade gaúcha de Métodos Ágeis. Serão abordados os seguintes temas que compõem a essência da mudança cultural exigida para o novo profissional que desenvolve software:

  • História, Princípios e Valores das Metodologias Ágeis
  • O Pensamento Enxuto (Lean) como Base para a Cultura Ágil
  • O Gerenciamento de Projetos com Scrum
  • A Engenharia de Software com Extreme Programming
  • A Engenharia de Requisitos em Ambientes Ágeis

Como vamos realizar

13:00 - 13:30 Recepção
13:30 - 13:45 Abertura T@rgetTrust
13:45 - 14:30 Introdução
14:30 - 15:15 Pensamento Enxuto
15:15 - 16:00 Scrum
16:00 - 16:30 Coffee-Break
16:30 - 17:15 Extreme Programming
17:15 - 18:00 Requisitos de Software
18:00 - 18:30 Debates e Encerramento

O que você irá ganhar

  • 5 horas de atividades, incluindo coffee-break
  • Material didático
  • Material de apoio
  • Certificado de Participação

Facilitadores

DANIEL WILDT - É um profissional de tecnologia da informação com 10 anos de experiência profissional. Atua em uma empresa brasileira como CIO. Certificações: SCJP/SCEA Part 1, JBuilder, Delphi/Delphi.NET, ITIL V3 Foundations, Scrum Master (CSM). Atua como Coach para adoção de Metodologias Ágeis desde 2004, focando em Lean Development, Scrum, eXtreme Programming e Feature Driven Development. Ensina programação, Metodologias Ágeis e Qualidade de Software na FACENSA (http://www.facensa.com.br). Atividades em comunidades de prática com o Grupo de Usuários Delphi do RS (http://www.dug-rs.org), Grupo de Usuários de Metodologias Ágeis do RS ( http://www.guma-rs.org), Comunidade de Ensino e Aprendizado do portaljava.net (http://edu-gelc.dev.java.net) e projeto JEDI (Java Education and Development Initiative) como responsável na implantação e disseminação do mesmo no Rio Grande do Sul.

GUILHERME LACERDA - É Mestre em Sistemas de Informação, área de Engenharia de Software, pela UFRGS. Dedica-se atualmente em atividades de consultoria e treinamento em Engenharia de Software e Metodologias Ágeis. Coordenador do Curso de Sistemas de Informação da FACENSA. Professor Universitário de Graduação (FACENSA, UniRitter) e Pós-Graduação (UniRitter). Atuou como diretor de tecnologia de uma empresa do ramo de software livre e open source durante 9 anos. Pioneiro em Metodologias Ágeis no Brasil, onde atua desde 2001, com especial ênfase em Lean, SCRUM e eXtreme Programming. Palestrante em dezenas de eventos nacionais e internacionais sobre o tema. Participou da revisão técnica do livro "eXtreme Programming Explained", do Kent Beck, lançado em 2004 pela Bookman. Fundador do XP-RS/GUMA, onde atua na vice-coordenação. Editor do Portal InfoQ, edição Brasil.

LUIZ CLÁUDIO PARZIANELLO - Formado em Engenharia Eletrônica pela PUCRS e Mestre em Sistemas Eletrônicos pela POLI/USP. Possui 25 anos de experiência em informática, tendo dedicado os últimos 10 anos a atividades de treinamento e consultoria em Melhoria de Processos de Software. Estuda e implementa metodologias ágeis desde 2003, dando ênfase a Lean Management, Scrum, Extreme Programming e Engenharia de Requisitos. Tem atuado como consultor e instrutor para diversas organizações no Brasil e no Exterior. É vice-coordenador do Grupo de Usuários de Métodos Ágeis da SUCESU-RS e palestrante da Conferência Internacional Agile 2009, em Chicago.

Para mais informações, ligue para (51) 3325-2596 ou mande e-mail para atendimento@targettrust.com.br.

25 de mai. de 2009

Relatos de Buenos Aires

De volta à Porto Alegre, relato aqui minhas impressões sobre como foi o curso Requisitos de Software: Conceitos e Práticas para Equipes Ágeis.

Primeiramente, gostaria de registrar a grande surpresa que tive com a presença de 39 alunos de diversas empresas públicas e privadas da região, sendo a maioria de empresas de grande porte como Movistar Telefónica, Ministério de Educación, Centro Superior para el Procesamiento de la Información de la Universidad de la Plata, T-Systems, Maypun, entre outras. Dentre os perfis observados, existiam alguns poucos desenvolvedores e testadores, porém muitos analistas, gerentes de projeto, arquitetos de software e consultores.

Pois bem, dos 39 alunos, somente 5 conheciam e utilizavam algumas práticas ágeis em sua equipes. Os demais eram provenientes da corrente tradicional do desenvolvimento de software. O resultado foi um curso extremamente provocante e desafiador, pois eu tinha na turma consultores de gerência de projetos (PMI) e melhoria de processos (CMMI).

Fiquei contente de poder voltar à mesma sala em que eu havia sido aluno de Mary e Tom Poppendieck no ano passado, no curso Lean Software Development (Agiles 2008), só que agora era eu quem estava na posição de instrutor. Pois bem, tirando a enorme diferença da qualidade dos instrutores (hehehe! seria ridículo eu me comparar aos Poppendieck!), eu tive uma vantagem de alunos que se transformou num transtorno para todos, dado que a sala só comportava um máximo de 28 alunos sentados confortavelmente e tínhamos 39! Fiquei com pena de algumas pessoas amontoadas, sem contar com o calor que passamos diante de um ar condicionado que não dava muita vazão a toda essa demanda ...

Tirando esses e outros percalços logísticos, que na minha opinião afetaram a qualidade do evento, consegui conquistar uma grande turma de céticos e deixá-los encantados com uma nova forma de captar, analisar, especificar, validar e gerenciar requisitos:

  • Iniciei com minha aula introdutória sobre percepção humana e mapas mentais, e como as fragilidades dos requisitos estão diretamente relacionadas às necessidades de Maslow e crenças formadas por filtros sociais, individuais, generalizações, deleções e distorções. Como sempre, todos ficam chocados com a verdadeira origem de nossos problemas ...
  • Passei pela identificação dos elementos básicos de um processo de negócio para tratá-los como o real problema do desenvolvimento de software, apresentando meu modelo de Project Story. Outra vez, o A3 Problem-Solving Report tem se mostrado muito efetivo neste aspecto.
  • Apresentei conceitos e práticas relacionadas às User Stories, como técnicas linguisticas para se escrever boas histórias e estimar o tamanho relativo das mesmas. Ficou claro para muita gente que a User Story é poderosa e deve ser utilizada antes de partirmos para um modelo mais sofisticado de Use Case.
  • Discutimos os aspectos do planejamento a partir dos pressupostos de Sprint e Velocidade da Equipe, bem como da decomposição do problema em temas de negócio.
  • Por fim, apresentei como o gerenciamento de requisitos pode ser feito para sustentar uma logística de requisitos baseada no modelo Just-in-Time.

Depois de 12h de atividades (exposição e prática), conquistamos os seguintes resultados na avaliação dos alunos: 100% dos alunos considerou alta a competência do instrutor, quase 80% reclamou da falta de material de apoio (não imprimiram minha apostila!), 90% reclamou da sala de treinamento (Hotel Bauen) e 64% achou que o curso deveria ter sido feito com uma duração de 16h (minha carga horária original). Mesmo assim, com todos esses problemas, conseguimos um percentual de aprovação (alto desempenho) de 95% dos alunos, o que me deixou muito feliz. Em breve, repetirei esse curso para a comunidade acadêmica da Universidad de La Plata e o mercado empresarial de Córdoba.

Por fim, gostaria de agradecer a acolhida dos colegas argentinos e parabenizar o grande interesse dos mesmos pela capacitação profissional em Métodos Ágeis e Engenharia de Requisitos, dois temas primordiais para qualquer empresa que trabalhe com desenvolvimento de software e queira se adequar às novas demandas do novo mercado de informática.

Um Dica Final ... Se você for à Buenos Aires e ficar hospedado pelas redondezas da Corrientes com a Callao, não deixe de comer um bife de chorizo ao molho de mostarda acompanhado de uma bela taça de vinho Malbec no restaurante Niña Bonita ... sem comentários!

18 de mai. de 2009

Requisitos de Software: Conceitos e Práticas para Equipes Ágeis

Depois de participar do grande evento que foi o Ágiles 2008, na Argentina, retorno à Buenos Aires nesta quarta-feira para ministrar o curso "Requisitos de Software: Conceitos e Práticas para Equipes Ágeis".

Nesta edição, com 12h de duração, terei a oportunidade de abordar um pouco mais de conteúdo do que sua primeira edição apresentada no Porto Alegre Agil Weekend (sempre ministrei o Programa de Capacitação em Engenharia de Requisitos com 40h). Dentre o conteúdo a ser abordado nesta edição, destaco:

  1. Human Mind, com foco em modelos de percepção, pensamento e mudança;
  2. Problem Identification, abordando fontes de requisitos, escopo de processo, projeto e produto;
  3. Project Story, um modelo de captação e registro de requisitos de projeto baseado na ferramenta A3 Problem-Solving Report da Toyota;
  4. User Stories, como base para a definição dos requisitos funcionais de produto e agregação de valor ao negócio por meio dos Business Themes;
  5. Project Planning, e como é possível realizar um planejamento mais realista tendo como premissa os requisitos de produto e a capacidade da equipe;
  6. Requirements Management, sendo abordado de forma exclusiva com base nos princípios da gestão Just-in-Time e de práticas de 5S.
Para quem quiser saber mais sobre o conteúdo programático deste curso, que deverá ser consolidado em jornadas de 16h no Programa de Capacitação em Metodologias Ágeis, a ser lançado pela TargetTrust ainda neste semestre, amplie o Mapa Mental exibido abaixo.

SOBRE O CURSO:

Requerimientos de Software: Conceptos y Prácticas para Equipos Ágiles
Fundación para el Desarrollo de las Nuevas Tecnologías
De 21 a 22/05/2009, Hotel Bauen, Buenos Aires, Argentina

Apoio Sociedad Argentina de Informática (SADIO)
Mais informações em
http://www.funtec.org.ar/cursos.html

15 de mai. de 2009

From Vision Statement to Product Backlog

Foi publicada no SlideShare a apresentação que fiz dia 14/05/2009 no Scrum Gathering Brazil. Faça o download dos templates da Project Story e do Product Scope do http://www.scribd.com/parzianello.

7 de mai. de 2009

Deus era agilista?

Antes de iniciar meu texto, gostaria de comunicar que este post é resultado de uma leitura da introdução do livro “A Estratégia da Genialidade - Vol.1”, de Robert Dilts, que faz uma análise da estrutura lingüística utilizada no livro Gênesis da Bíblia Sagrada. O texto não possui nenhuma conotação religiosa e mantém total respeito ao referido texto.

“Quero saber como Deus criou o mundo. Não estou
interessado neste ou naquele fenômeno, ou no espectro
deste ou daquele elemento; quero conhecer os
seus pensamentos; o resto são detalhes.”
Albert Einstein

Na introdução do livro citado acima, Robert Dilts escreve:

As palavras poderosas e emocionantes do Gênesis nos contam a história da criação em vários níveis. Além de descrever o que foi criado, está descrito o processo de como foi criado. Ali vemos a descrição “dos pensamentos de Deus” sob a forma de uma estratégia criativa que possui uma estrutura específica. Trata-se de uma estratégia que inclui um certo número de etapas que se desenvolvem em um ciclo contínuo que se retroalimenta.

Interessante! Segundo as observações de Dilts, a criação do mundo, pelo o que está escrito na Bíblia Sagrada, foi feita por um processo iterativo incremental! E continua:

A criação começa a partir de uma distinção – da criação de uma diferença. Este primeiro ato leva a outro e em seguida a outro e depois a outro – cada idéia estabelecendo o potencial para a próxima. Cada ato de criação inclui a reiteração de um ciclo que compreende três processos fundamentais:

1) Conceitualização: “E disse Deus: Haja ...”
2) Implantação: “E Deus fez ...”
3) Avaliação: “E viu Deus que era bom.”

Ficou muito claro para mim que o processo de criação do mundo, segundo a Bíblia Sagrada, está baseado num processo semelhante ao Scrum, pois contempla: Sprints com prazo fixo de 1 dia de duração (cada ato de criação se passa em um dia), um Product Backlog priorizado no início de cada Sprint (conceitualização), a realização do Sprint Backlog em cada dia (implantação) e a revisão daquilo que foi feito num Sprint Review. Só que considerando a onipotência e a onipresença de Deus, ele atuou em seu projeto como Product Owner, Scrum Master e Team Member, simultaneamente. Outro detalhe é que não há um detalhamento de requisitos no começo do processo, o que implica um projeto de natureza Just-in-Time (estoque zero). Para completar, Dilts expõe sua visão final do processo, que ao meu ver serve para descrever a forma criativa que procuramos adotar nas metodologias ágeis:

Cada ciclo provoca uma sucessão de idéias cada vez mais pessoais e refinadas. Com cada um dos ciclos, a idéia assume cada vez mais vida própria – ela é capaz de criar, multiplicar e sustentar outras idéias. A expressão maior reflete o processo do Criador de tal maneira que é capaz de abastecer todas as outras criações enquanto se multiplica.

Uma bela descrição do desenvolvimento ágil! Não é verdade?
Criar todo o mundo em 6 dias e descansar no 7º realmente foi uma obra divina!

Para aqueles que ficaram curiosos sobre o que está escrito no Gênesis, este é um livro de autoria desconhecida, porém atribuída a Moisés na tradição judaico-cristã. Ele deve ter sido escrito por volta dos anos 1450-1410 a.C., para descrever o princípio de tudo. É o primeiro livro da Bíblia Sagrada. Transcrevo o texto do Gênesis extraído do site http://www.bibliaonline.com.br/, onde fica claro que, no momento da criação do homem à Sua imagem e semelhança, estavam sendo concebidos os verdadeiros Usuários de toda a criação! ;-)

Gênesis 1:1 – 2:3

No princípio criou Deus os céus e a terra. E a terra era sem forma e vazia; e havia trevas sobre a face do abismo; e o Espírito de Deus se movia sobre a face das águas. E disse Deus: Haja luz; e houve luz. E viu Deus que era boa a luz; e fez Deus separação entre a luz e as trevas. E Deus chamou à luz Dia; e às trevas chamou Noite. E foi a tarde e a manhã, o dia primeiro.

E disse Deus: Haja uma expansão no meio das águas, e haja separação entre águas e águas. E fez Deus a expansão, e fez separação entre as águas que estavam debaixo da expansão e as águas que estavam sobre a expansão; e assim foi. E chamou Deus à expansão Céus, e foi a tarde e a manhã, o dia segundo.

E disse Deus: Ajuntem-se as águas debaixo dos céus num lugar; e apareça a porção seca; e assim foi. E chamou Deus à porção seca Terra; e ao ajuntamento das águas chamou Mares; e viu Deus que era bom. E disse Deus: Produza a terra erva verde, erva que dê semente, árvore frutífera que dê fruto segundo a sua espécie, cuja semente está nela sobre a terra; e assim foi. E a terra produziu erva, erva dando semente conforme a sua espécie, e a árvore frutífera, cuja semente está nela conforme a sua espécie; e viu Deus que era bom. E foi a tarde e a manhã, o dia terceiro.

E disse Deus: Haja luminares na expansão dos céus, para haver separação entre o dia e a noite; e sejam eles para sinais e para tempos determinados e para dias e anos. E sejam para luminares na expansão dos céus, para iluminar a terra; e assim foi. E fez Deus os dois grandes luminares: o luminar maior para governar o dia, e o luminar menor para governar a noite; e fez as estrelas. E Deus os pôs na expansão dos céus para iluminar a terra, E para governar o dia e a noite, e para fazer separação entre a luz e as trevas; e viu Deus que era bom. E foi a tarde e a manhã, o dia quarto.

E disse Deus: Produzam as águas abundantemente répteis de alma vivente; e voem as aves sobre a face da expansão dos céus. E Deus criou as grandes baleias, e todo o réptil de alma vivente que as águas abundantemente produziram conforme as suas espécies; e toda a ave de asas conforme a sua espécie; e viu Deus que era bom. E Deus os abençoou, dizendo: Frutificai e multiplicai-vos, e enchei as águas nos mares; e as aves se multipliquem na terra. E foi a tarde e a manhã, o dia quinto.

E disse Deus: Produza a terra alma vivente conforme a sua espécie; gado, e répteis e feras da terra conforme a sua espécie; e assim foi. E fez Deus as feras da terra conforme a sua espécie, e o gado conforme a sua espécie, e todo o réptil da terra conforme a sua espécie; e viu Deus que era bom.

E disse Deus: Façamos o homem à nossa imagem, conforme a nossa semelhança; e domine sobre os peixes do mar, e sobre as aves dos céus, e sobre o gado, e sobre toda a terra, e sobre todo o réptil que se move sobre a terra. E criou Deus o homem à sua imagem: à imagem de Deus o criou; homem e mulher os criou. E Deus os abençoou, e Deus lhes disse: Frutificai e multiplicai-vos, e enchei a terra, e sujeitai-a; e dominai sobre os peixes do mar e sobre as aves dos céus, e sobre todo o animal que se move sobre a terra.

E disse Deus: Eis que vos tenho dado toda a erva que dê semente, que está sobre a face de toda a terra; e toda a árvore, em que há fruto que dê semente, ser-vos-á para mantimento. E a todo o animal da terra, e a toda a ave dos céus, e a todo o réptil da terra, em que há alma vivente, toda a erva verde será para mantimento; e assim foi. E viu Deus tudo quanto tinha feito, e eis que era muito bom; e foi a tarde e a manhã, o dia sexto.

Assim os céus, a terra e todo o seu exército foram acabados. E havendo Deus acabado no dia sétimo a obra que fizera, descansou no sétimo dia de toda a sua obra, que tinha feito. E abençoou Deus o dia sétimo, e o santificou; porque nele descansou de toda a sua obra que Deus criara e fizera.

5 de mai. de 2009

Scrum é um framework?

Segue mais um email para a lista Scrum-Brasil que acredito ter se tornado um post para este blog! Ele inicia com a pergunta do colega Rodrigo Yoshima: Quando dizemos Scrum é um Framework, o quenecessariamente queremos dizer com isso?

Vou tentar dar uma pequena contribuição para esta discussão ... ;-)
  1. Scrum é um método de gerenciamento de projetos;
  2. Tipicamente, de projetos de desenvolvimento de produto (Product Backlog);
  3. Scrum tem como foco principal a entrega de valor para o cliente (Product Owner);
  4. Para tanto, explora a auto-gestão da equipe (Scrum Team);
  5. A equipe deve manter altos níveis de comunicação e colaboração;
  6. Scrum é baseado em muitos princípios e práticas do Lean Thinking;
  7. Por essa razão, exige um fluxo de valor do tipo Just-in-Time (JIT);
  8. Por ser JIT, trabalha com pequenos intervalos de produção (Sprints);
  9. Devido a isso, faz entregas frequentes com estoques reduzidos;
  10. Por ter estoques reduzidos, traz os problemas à tona;
  11. Uma vez que problemas podem surgir, um líder deve procurar contorná-los (Scrum Master);
  12. Os problemas são discutidos diariamente com a equipe (Daily Scrum);
  13. Bem como a evolução do produto (Burndown Chart);
  14. O produto evolui de forma dinâmica, de acordo com os interesses do cliente (Sprint Backlog);
  15. E equipe se compromete com os resultados do projeto (Sprint Planning);
  16. Os resultados obtidos são avaliados durante as entregas parciais do produto (Sprint Review);
  17. E uma análise crítica dos resultados é feita após cada entrega (Restrospective);
  18. E todo o processo reinicia até chegarmos ao produto desejado.

Por que eu escrevi esses 18 pressupostos? Porque muitos deles são diretrizes para o planejamento do meu processo de desenvolvimento. O Scrum não é um método prescritivo ao extremo, como é o RUP, que entrega até os templates de como você deve escrever cada artefato. Tanto um quanto o outro eu posso considerar como frameworks de processo, dado que a instância de cada um será diferente em cada empresa onde eles forem implantados. No entanto, tanto um quanto outro não abrem mão de suas diretrizes "obrigatórias", como no caso do Scrum com: Sprint de prazo fixo (2 a 4 semanas), um único Product Backlog (que muita gente ainda desconhece o poder de uma User Story), Daily Meeting (que muita gente não faz), Sprint Planning e Review (que muita gente não sabe como conduzir), Retrospectives (que muita gente não tem no sangue a melhoria contínua), Burndown Chart (que muita gente ainda tem alergia a métricas e indicadores de desempenho). Nestes itens, não há flexibilidade. A flexibilidade que existe é na exploração do processo criativo para o desenvolvimento do melhor produto, no melhor tempo e no melhor custo, a fim de atender as necessidades de meu cliente.

Ou seja, da mesma forma que um framework MVC tem dentre suas diretrizes obrigatórias a construção das classes GUI na estrutura V do modelo (se você colocar no M vai deturpar o modelo e prejudicar a manutenção e o controle do sistema), o Scrum possui essas características. Se seu sistema foi desenvolvido com base nesse framwork (MVC), mantendo total aderência às suas diretrizes obrigatórias, pode-se dizer que o sistema é uma instância do modelo MVC. Se seu processo de desenvolvimento de software foi planejado com base no framework Scrum, mantendo total aderências às diretrizes obrigatórias, pode-se dizer que o processo é uma instância do modelo Scrum. Conclusão: o Scrum é um framework!

3 de mai. de 2009

Brazil Scrum Gathering 2009

Pessoal! Estarei na próxima semana apresentando um trabalho inédito no Brazil Scrum Gathering 2009, em São Paulo. Nele, vou apresentar, pela primeira vez, um modelo de "Project Story" que estou concebendo para definir de forma rápida e efetiva o escopo de um projeto de software. É uma idéia que tem dado certo de trabalhar com um template de Project Charter com estruturas semelhantes à User Story.

Espero vê-los por lá!!
--------------------------

RESUMO DO TRABALHO
From Vision Statement to Product Backlog:
An Effective Way to Quickly Develop Project and Product Requirements


Wednesday, 13 May 2009 from 11:15 to 12:30

Product Backlog (PB) is a high-level description about what have to be done in a project performed with Scrum. It is well known that PB has to be written (or specified) by the Product Owner (PO), who knows the business rules and what software requirements have to be developed. The problem in this case is that sometimes neither PO nor team members know how to structure a mind process to develop project and product requirements. A systemic view of the business context and the NLP S.C.O.R.E. Model can help a Scrum team to quickly develop a useful PB based on User Stories. In this talk, we will show how to combine these assumptions to develop in PO and team members new communication skills for better working with software requirements.

TOPIC:

Most Neuro-Linguistic Programming (NLP) is oriented around defining a present state and a desired state, and then identifying and applying a technique that will hopefully help someone get to their desired state. The S.C.O.R.E. Model enriches that description by adding a few more simple distinctions. The letters stand for Symptoms, Causes, Outcomes, Resources and Effects. These elements represent the minimum amount of information that needs to be addressed by any process of change. We will show how to think about software as a “resource” that provides desirable “effects” in a business environment, improving process “outcomes” by eliminating the “causes” of undesirable “symptoms”. The User Story framework showed to be powerful when developing a PB based on these assumptions.

OBJECTIVES:
  1. How to use a systemic view (process thinking) to understand the project scope?
  2. How to use the S.C.O.R.E. Model to write a simple and powerful business plan for the project?
  3. How to challenge software requirements with the User Story framework?