Contratos e Scrum: The Good, The Bad and The Ugly

4,171 views

Published on

- The Good: Contratos de Escopo Variável

- The Bad: Contratos de Preço Fixo

- The Ugly: Aquisição Progressiva e Aquisição por Métricas de Tamanho ( Pontos de Função )

- Como escolher uma forma de contratação

Published in: Technology

Contratos e Scrum: The Good, The Bad and The Ugly

  1. 1. <ul><li>José Paulo Levandovski Papo </li></ul><ul><li>E-mail: [email_address] </li></ul><ul><li>Site: http://josepaulopapo.blogspot.com </li></ul>Contratos e Scrum: “The Good, The Bad And The Ugly”
  2. 2. Agenda <ul><li>The Good: Contratos de Escopo Variável </li></ul><ul><li>The Bad: Contratos de Preço Fixo </li></ul><ul><li>The Ugly: Aquisição Progressiva e Aquisição por Pontos de Função </li></ul><ul><li>Como escolher uma forma de contratação </li></ul><ul><li>Considerações Finais e Bibliografia </li></ul>
  3. 3. “ The Good” - Contratos de Escopo Variável <ul><li>“ Pagaremos $75.000,00 por mês nos próximos dois meses. Todo o software entregue até este ponto deve atender aos requisitos de qualidade conforme apêndice X. Há algumas estimativas iniciais, mas estas são pouco confiáveis.” </li></ul><ul><li>De acordo com o Standish Group, 64% das funcionalidades de sistemas nunca ou raramente são usadas. Se o escopo se torna a variável do projeto, então pode-se ter um sistema de maior qualidade exatamente nas funcionalidades de maior valor para os clientes. </li></ul><ul><li>Segundo Poppendieck, apesar de ser contra-intuitivo, organizações que fazem outsourcing gastarão menos e terão mais benefícios se colaborarem com os fornecedores ao usar alguma forma de contrato de escopo variável. </li></ul>
  4. 4. The Bad – Contrato de preço fixo <ul><li>É complexo definir todas as suas necessidades e requisitos no início de um projeto. </li></ul><ul><li>O processo de desenvolvimento de sistemas é inerentemente carregado de incertezas. </li></ul><ul><li>Fornecedor parece ter o maior risco, pois o cliente possui pouco incentivo para aceitar o trabalho como completo. </li></ul>
  5. 5. The Bad – Contrato de preço fixo <ul><li>Geralmente não gera o menor custo </li></ul><ul><ul><li>Fornecedores competentes incluirão uma boa margem de risco </li></ul></ul><ul><ul><li>Cria um jogo comum de um preço baixo com requisições de mudança caras, ainda que para alterações simples. </li></ul></ul><ul><li>]Geralmente não fornece o menor risco ao comprador </li></ul><ul><ul><li>Quando o custo, o cronograma e o escopo são fixos o que variará para baixo? A qualidade... é claro !!! </li></ul></ul><ul><li>E por fim, mas não menos importante: o cliente geralmente não recebe o que ele gostaria ao final do projeto! </li></ul>
  6. 6. The Ugly - Aquisição Progressiva © Max Wideman
  7. 7. The Ugly - Aquisição Progressiva <ul><li>Contrato Mestre – Define os termos e condições gerais para um relacionamento de longo prazo </li></ul><ul><li>Anexos de requisições – Entregáveis específicos associados com uma iteração. </li></ul><ul><li>As primeiras iterações podem utilizar o contrato de Custos Reembolsáveis, no caso de não haver limite de tempo para a fase de Elaboração. Ou então de preço fixo para realizar um número determinado de iterações( timeboxed ). Essas primeiras iterações não produzirão apenas documentação. O baseline arquitetural (ou esqueleto arquitetural) também será definido, implementado e testado. </li></ul><ul><li>As iterações subseqüentes obterão estimativas mais refinadas e poderão utilizar anexos baseados em preço fixo. </li></ul>
  8. 8. The Ugly - Aquisição por métricas de tamanho <ul><li>Cliente compra uma quantidade específica de tamanho de software. </li></ul><ul><li>Exemplos </li></ul><ul><ul><li>Aquisição de 2.000 pontos de função + ou – 20% </li></ul></ul><ul><ul><li>Aquisição de 1.000 pontos de caso de uso + ou – 20% </li></ul></ul><ul><li>Não é necessário especificar o escopo e os requisitos de forma detalhada. </li></ul><ul><li>Diversos projetos em órgãos privados e públicos já utilizaram essa modalidade de contrato. Obtiveram melhores resultados que aqueles em projetos com contratos de preço fixo. </li></ul>
  9. 9. Benefícios da Aquisição Progressiva ou por métricas de tamanho <ul><li>Se casa perfeitamente com o processo iterativo do Scrum. </li></ul><ul><li>Permite uma relação de maior parceria e confiança entre as partes. </li></ul><ul><li>Facilita respostas flexíveis às mudanças inevitáveis nos requisitos, condições de mercado e tecnologias. </li></ul><ul><li>Atende à necessidade de controles financeiros e preços competitivos. </li></ul>
  10. 10. Benefícios da Aquisição Progressiva ou por métricas de tamanho <ul><li>Encoraja um ciclo de desenvolvimento dirigido ao produto ao invés de dirigido pela documentação. </li></ul><ul><li>Liga revisões contratuais à performance do fornecedor. Movimento para o próximo incremento ocorre quando o produto da iteração é satisfatório de acordo com certas regras definidas no contrato master. </li></ul><ul><li>Dá ao fornecedor pagamentos baseados em performance. </li></ul><ul><li>Diminui a necessidade de colocar grandes margens de risco. Permite oferecer preços mais competitivos e garantir qualidade do produto. </li></ul>
  11. 11. Escolhendo uma forma de contratação <ul><li>Algumas das variáveis a se avaliar: </li></ul><ul><ul><li>Volatilidade e dificuldade dos requisitos </li></ul></ul><ul><ul><li>Urgência de entrega dos requisitos </li></ul></ul><ul><ul><li>Grau de riscos envolvidos em atingir os objetivos </li></ul></ul><ul><ul><li>Tecnologia utilizada (se nova para a organização) </li></ul></ul><ul><ul><li>Grau de inovação da solução </li></ul></ul><ul><ul><li>Tamanho da subcontratação </li></ul></ul><ul><ul><li>Grau de Experiência e maturidade no planejamento de ambos os lados </li></ul></ul>
  12. 12. Mas e se não houver saída e eu tiver que tratar de um projeto com preço fixo? <ul><li>Executar o projeto iterativamente ainda te dá vantagens mesmo em um projeto com contrato de preço fixo: </li></ul><ul><ul><li>Ele ataca os principais riscos e os elementos mais difíceis no início. Isso fornece um feedback adiantado se o projeto terá ou não problemas em uma de suas variáveis! </li></ul></ul><ul><ul><li>É possível descobrir mais rapidamente se as estimativas de custo foram baixas. </li></ul></ul><ul><ul><li>É possível tomar ações de mitigação no princípio e no meio do projeto(como contratar especialistas, verificar a existência de componentes prontos, gerenciar as expectativas no início, etc), para não deixar os riscos se tornarem problemas na fase final do projeto. </li></ul></ul><ul><ul><li>Ele fornece resultados visíveis de valor para os clientes. Se for o caso, isso gera confiança com os clientes e possibilita voltar para negociações racionais. </li></ul></ul>
  13. 13. <ul><li>Crie buffers de cronograma e orçamento para refletir as incertezas nas estimativas do projeto. Estes buffers não são “gordura” (padding)! </li></ul><ul><li>Se o projeto for extremamente arriscado e não for possível alterar a forma de contrato então aumente ainda mais suas contingências! </li></ul><ul><li>Este buffer provavelmente se converterá em iterações extras no plano de projeto. Considere essas iterações como parte de sua reserva de risco! </li></ul>Mas e se não houver saída e eu tiver que tratar de um projeto com preço fixo?
  14. 14. Considerações Finais <ul><li>Existem diversas formas possíveis para se contratar projetos de software. </li></ul><ul><li>Utilize a forma de contratação mais adequada para a realidade de seu projeto. </li></ul><ul><li>Escolha entre as opções Good, Bad ou Ugly. </li></ul><ul><li>Palavra-chave: Negociação!!! </li></ul>
  15. 15. Bibliografia <ul><li>BITTNER, K; SPENCE, I. Managing Iterative Software Development Projects, Boston: Addison-Wesley, 2007 </li></ul><ul><li>BECK, K.; CLEAL, D. Optional Scope Contracts . Disponível: http:// www.xprogramming.com/ftp/Optional+scope+contracts.pdf </li></ul><ul><li>BERCZUK, S.; APPLETON, B. Software Configuration Management Patterns . Boston: Addison-Wesley, 2002 </li></ul><ul><li>BROOKS, Frederick. The Mythical Man-Month : Essays on Software Engineering Anniversary Edition. 2nd Edition. Boston:Addison-Wesley, 1995. </li></ul><ul><li>COHN, Mike. Agile Estimating and Planning . Boston: Addison-Wesley, 2006 </li></ul><ul><li>DEMARCO, T.; LISTER, T. Waltzing with Bears : Managing Risk on Software Projects. New York: Dorset House Publishing, 2003 </li></ul><ul><li>LARMAN, Craig. Agile and Iterative Development : A Manager’s Guide. Boston: Addison-Wesley, 2004 </li></ul>
  16. 16. Bibliografia <ul><li>MARCINIAK, J; REIFER, D. Software Acquisition Management . New York: John Wiley & Sons, 1990 </li></ul><ul><li>McCONNELL, Steve. Rapid Development : Taming Wild Software Schedules. Redmond: Microsoft Press, 1996 </li></ul><ul><li>POPPENDIECK, M. Agile Contracts . Disponível: http:// www.poppendieck.com/pdfs/AgileContracts.pdf </li></ul><ul><li>SCHWABER, Ken. Agile Project Management with SCRUM . Redmond: Microsoft Press, 2004 </li></ul><ul><li>SMITH, P. G.; REINERTSEN, D. G. Developing Products in Half the Time . 2 nd Edition. New York: John Wiley & Sons, 1998 </li></ul><ul><li>WIDEMAN, M. Progressive Acquisition and the RUP . Partes I até V. Rational Edge.Disponível: http://www.maxwideman.com/papers/acquisition/intro.htm </li></ul><ul><li>YOURDON, E. Death March , 2nd Edition. New Jersey: Pearson, 2004. </li></ul>
  17. 17. Dúvidas <ul><li>“ In many ways, managing a large computer programming project is like </li></ul><ul><li>managing any other large undertaking - in more ways than most </li></ul><ul><li>programmers believe. But in many other ways it is different - in more ways </li></ul><ul><li>than most professional managers expect.” – Frederick Brooks </li></ul>

×