De Brooks a Berkun
Contents
1. Infelizmente quando olhamos algumas particularidades do mercado brasileiro de presta o de servi os de desenvolvimento percebemos que muitas empresas d o pouqu ssimo valor para esse aprendizado lan ando m o de v nculos empregaticios muitos fr geis PJ s e afins o que resulta em uma alta rotatividade de seus colaboradores H quem acredite que este tipo de conhecimento pode ser capturado e aprisionado em documentos e coisas do tipo N o o meu caso A explicita o de conhecimentos sua compila o em artefatos que podem ser recuperados a qualquer momento ben fica para todas as organiza es Mas n o consegue representar nem um pequeno peda o de toda a experi ncia adquirida por um time durante a execu o de um projeto Trata se de outra ilus o high tech para usar um termo do DeMarco finito What needs to he done Voltando ao Berkun Logo no in cio de The Art of Project Management ele ensina tr s li es chave que guiam boa parte de seus m todos guias e sugest es S o elas v Gerenciamento de Projetos e Desenvolvimento de Software n o s o artes sagradas apesar do ar de novidade que impera em nossa rea crucial lembrar que existem ensinamentos que podem vir de outros lugares Quanto mais simples for a sua vis o do que voc faz mais poder e foco voc ter em sua execu o estar sempre curioso e aberto novas id ias o que torna o crescimento poss vel Uma vis o si2. finito What needs to be done A sugest o de Brooks baseada em uma proposta de Harlan Mills 3 d t tulo para o terceiro capitulo do seu livro O Time Cir rgico Segundo ele o time ideal formado por Programador Chefe Cirurgi o v Co Piloto v Administrador v Editor v Secret rias duas Bibliotec rio Almoxarife v Testador v Advogado da Linguagem Reparem bem N s temos praticamente 9 pessoas trabalhando para o programador Dando lhe todo suporte que far aumentar sua efic cia e produtividade Lembram se que o Brooks tamb m sugeria que aloc ssemos apenas 1 6 de nosso cronograma para tarefas de codifica o Outro mundo n o mesmo Pode e deve ser fact vel em um time cir rgico de verdade mas aplica se a equipes montadas para o desenvolvimento de sistemas finito What needs to he done O cirurgi o seria respons vel pela execu o de todas as tarefas principais daquela parte do projeto sua especifica o design codifica o testes e documenta o N o difere muito de alguns j ob descriptions e an ncios de vagas que ainda vemos por a Seria um analista programador que segundo Brooks deveria ter 10 anos de experi ncia O mundo da programa o mudou muito desde os tempos do COBOL e da PL A complexidade e abrang ncia de nossas linguagens e arquiteturas de aplica es aumentaram para os lados e para baixo E cada vez mais comum que cada
3. Um estudo informal dos livros The Mythical Man Month e The Art of Project Management e uma homenagem aos seus autores Fred Brooks e Scott Berkun Paulo Vasconcellos Abril 2006 finito What needs to be done 1 Em 2005 comemorou se 30 anos do lan amento da primeira edi o de The Mythical Man Month de Frederick P Brooks Jr O livro pode ser considerado o primeiro cl ssico das reas de Engenharia de Software e Gerenciamento de Projetos Fred Brooks trabalhou por 8 anos na IBM entre 1956 e 1964 Seu ltimo ano foi dedicado ao desenvolvimento do OS 360 um empreendimento que envolveu mais de 5 mil homens ano Surge ent o a provoca o que o levaria ao livro uma pergunta b sica de Thomas Watson CEO da IBM Por que programa o t o dif cil de ser gerenciada Tr s d cadas de avan os tecnol gicos e de consolida o das ci ncias Engenharia de Software e Gerenciamento de Projetos n o foram suficientes para tornar o texto obsoleto Muito pelo contr rio at hoje o livro considerado uma refer ncia obrigat ria Em 2004 quando questionado sobre a raz o da longevidade de sua obra prima Fred Brooks respondeu Eles falam que o livro a B blia da Engenharia de Software por isso que todo mundo o l mas ningu m o usa No ano em que comemorou seu trig simo anivers rio The Mythical Man Month ganhou um tipo de upgrade de complemento Trata se de The Art of Project
4. Management de Scott Berkun N o s uma coincid ncia de temas afinal existem milhares de t tulos sobre Gest o de Proj etos e Engenharia de Software Mas v rios outros aspectos aproximam as duas obras Scott Berkun trabalhou por dez anos na Microsoft em proj etos como Windows MSN e Internet Explorer Ou seja Berkun reviveu experi ncias parecidas com aquelas de Brooks em uma corpora o de porte e relev ncia quase id nticas finito What needs to be done N o por acaso que os dois livros possuem linguagem e estrutura muito parecidos Podem ser classificados como hist rias de guerras Ambos s o muito f ceis de ler e seguem uma ordem pr pria em detrimento de padr es nomenclaturas e sequ ncias que caracterizam 9 em 10 t tulos sobre gerenciamento de projetos lan ados nos ltimos tempos Este artigo foi concebido originalmente para comemorar os 30 anos de The Mythical Man Month Compar lo ao rec m lan ado The Art of Proj ect Management s uma maneira de tornar a homenagem e por que n o dizer as provoca es um pouco mais ricas Por incr vel que pare a nem The Mythical Man Month nem The Art of Project Management mereceram uma edi o em portugu s do Brasil Um lapso que ainda pode ser corrigido E deveria Como s o best sellers mesmo por aqui raz o comercial n o h Como Gest o de Projetos est na moda resta nos torcer para que no meio daquele tanto de livro lan ado para a
5. m uma coloca o de Tom DeMarco em um de seus principais trabalhos Peopleware 6 A fun o do gerente n o fazer as pessoas trabalharem e sim tornar poss vel que elas trabalhem finito What needs to he done Podemos perceber o mesmo tipo de separa o de fun es e responsabilidades na ind stria cinematogr fica O diretor do filme arquiteto tem a palavra final sobre todos os aspectos da cria o E os produtores coordenadores tratam do dia a dia do projeto Antes de encerrar o tema uma observa o Fred Brooks assim como Scott Berkun trabalhou na ind stria desenvolvendo produtos Falta em seus job descriptions do Arquiteto e do Produtor Coordenador a preocupa o com um Cliente Parece bvio que o chefe seja ele o Arquiteto ou o Coodenador seja a principal interface da equipe do proj eto com o cliente Eu prefiro deixar que o Coordenador seja sempre o canal de contato principal com o cliente independente de ter ou n o a palavra final no projeto As quest es t cnicas e funcionais na maior parte das vezes deveriam ser solucionadas ou melhor direcionadas pelo Analista de Neg cio apresentado no sub cap tulo anterior finito What needs to be done A Outra funcao da Organizacao Quando falamos em Organiza o Estrutura a primeira imagem que aparece a de um organograma Preocupamo nos quase que exclusivamente em saber quem que manda no peda o e quem deve ter o ju
6. serem insinceras perguntadas sem a inten o de se obter uma resposta Por exemplo A cai a ficha e o cliente de repente descobre que tem que ir para outra tela certo finito What needs to be done Mas independente da qualidade e da intelig ncia de nossas perguntas devemos esperar diversas id ias ruins comicamente est pidas hilariantes etc Triste o ambiente pouco tolerante a elas porque al m de sisudo e mon tono inibe a participa o de todos os membros da equipe mina o esp rito de colabora o que deveria existir durante todo o projeto Al m de desperdi ar boas piadas n Seguindo com Berkun melhor que a gente suje as m os e cometa v rios erros nesta fase Quanto antes isso acontecer mais r pido a gente chega s boas id ias As duas mais importantes ferramentas de um arquiteto s o a borracha na sala de desenhos e a marreta na constru o Frank Lloyd Wright A mais importante ferramenta do f sico sua cesta de lixo Albert Einstein Berkun tamb m detona outro mantra comum em certos c rculos por a o tal think outside the box N o a elimina o das caixas a parte mais dif cil exatamente saber quais caixas utilizar e quando Restri es estar o sempre presentes E completa fa a o que voc quiser com a caixa Pense dentro da caixa fora da caixa debaixo da caixa corte a e fa a fogo com ela qualquer coisa desde que voc gerencie para resolve
7. time assuma como verdadeiras solicita es que podem nem mesmo ter partido do cliente ou dos verdadeiros usu rios v Busque as Informa es que Faltam Os mais not veis erros em requisitos s o erros de omiss o A coleta e an lise bem realizadas devem tornar bem vis veis todas as pe as que faltam no tabuleiro do projeto v Defina Prioridades Relativas para todos os Requisitos Costumo solicitar ainda na coleta que o cliente usu rio defina se aquela solicita o Fundamental Importante ou Acess ria Uma classifica o clara e simples assim aj uda muito em diversas tomadas de decis o v Refina ou Elimine a Linguagem Amb gua n o Intencional Palavras como r pido grande pequeno bonito e us vel requerem m tricas relativas para serem entendidas Em alguns casos pode ser do interesse de todos que elas permane am em aberto at momentos posteriores do proj eto Mas a princ pio devemos eliminar toda reda o que n o permita um entendimento nico de um requisito finito What needs to be done Cabe aqui outra intromiss o minha Ainda h muito trabalho a ser realizado antes do Analista de Neg cios Sistemas repassar os requisitos para o time de Arquitetura da Solu o As dicas do Berkun listadas acima s o teis mas n o suficientes No meu ponto de vista todos os requisitos coletados devem ser estruturados formando uma Base de Conhecimentos do projeto Existem algumas ferramentas desenhadas especifica
8. tudo E tem bom gosto J onas Fagundes J Werther Roberto R gis J os Papo Ivo Michalick e outros amigos ocultos deixaram sua contribui o na forma de coment rios neste blog ou no grupo de discuss o CMM Brasil Muito obrigado a todos Guz Vasconcellos colaborou na revis o com palpites de diagrama o e nos momentos de descontra o levando consider veis goleadas no Winning Eleven 8 That s all Folks Claro que n o O finito seguir com um artigo por semana sempre girando em torno dos temas Engenharia de Software Gerenciamento de Projetos Arquitetura de Solu es e tudo o mais que caiba neste torto tri ngulo Sugest es de temas Quer trocar id ias Levar palestras e workshops para sua escola ou empresa Demorou finito What needs to be done Ops err Vc fez uma busca por bolo de fub e caiu aqui por engano Ou ent o ficou morrendo de curiosidade o seguinte Ingredientes 4 ovos 4 copos de leite 1 x cara e meia de a car 1 x cara e meia de fub 2 colheres de sopa de manteiga 2 colheres de sopa de farinha de trigo 1 colher de sopa de fermento em p 1 x cara de queijo canastra ou parmes o ralado 1 pitadinha de sal Preparo Em uma vasilha misture os ovos acrescente o leite e aos poucos coloque o fub misturando bem Coloque o a car o sal a manteiga e misture novamente J unte a farinha de trigo e por ltimo o fermento em p Leve ao liquidificador baten
9. um chute v 70 uma boa estimativa v 90 estudamos e detalhamos quase tudo Uma boa estimativa dependeria principalmente de dois fatores bons requisitos e um bom design temas que ser o tratados posteriormente E Berkun ainda pede confie em seus programadores como voc confiaria em um neuro cirurgi o Se este falar que aquela opera o no c rebro demorar 12 horas voc tem coragem de pedir para que ele reduza para digamos 4 horas Voc seria o louco o suficiente finito What needs to be done Quest o de Confian a Berkun diz que o problema com nossos projetos n o est nos cronogramas mas sim na forma como eles s o elaborados e usados O coordenador deve confiar nas estimativas apresentadas pelos programadores e demais membros do time Se cada estimativa apresentada for bem justificada n o h porque desconfiar delas Uma quest o de valida o qu o prov veis s o os prazos fixados Se nenhuma probabilidade oferecida e nenhuma pr condi o colocada ent o a realiza o do cronograma pode at ser poss vel mas n o prov vel Que base de compara o quais refer ncias n s possu mos para avaliar corretamente as estimativas apresentadas Tanto Brooks em 75 quanto Berkun insistem s o dom nio do nosso hist rico tanto de equipes quanto dos indiv duos permitir um j ulgamento j usto Qual a nossa produtividade nossa performance hist rica Qual o ndice de incid ncia de b
10. zo de obedecer Fred Brooks diz que precisamos aprender a desenhar estruturas e processos que incentivem e n o que inibam a criatividade e a iniciativa E lembra a Criatividade vem dos indiv duos e n o das estruturas e processos Scott Berkun segue linha parecida dizendo que os proj etos dependem muito da habilidade do time em fazer uso do conhecimento de seus membros de compartilhar id ias e trabalhar em sincronicidade ao inv s de seguir restritivas linhas de autoridade uma rigorosa disciplina e uma compuls o a seguir ordens sem nenhum tipo de questionamento Esse embate muit ssimo bem documentado por Domenico de Masi no livro Criatividade e Grupos Criativos 7 Domenico afirma que atravessamos uma fase caracterizada por um Cultural Gap um fen meno que constrangeu os atuais knowledge workers os trabalhadores do conhecimento a se organizarem segundo os velhos princ pios industriais Que sej a s uma fase Mas ainda n o h muitos ind cios de que esteja para terminar Por exemplo o termo f brica de software de uma infelicidade incr vel Um ox moro no meu ponto de vista Por outro lado temos a consolida o de produtos como Linux Apache Eclipse e Firefox que s o criados em ambientes onde parece imperar o caos Deve haver um meio termo n o finito What needs to he done Em 1986 Fred Brooks publicou o artigo No Silver Bullet que aparece como o cap tulo 16 da edi o que comemorou o
11. Berkun lembra bem que nossa tradi o jogar gente l para ver no que que d Se bem pensada a adi o ou troca de pessoas em um time pode ser ben fica Depende da raz o do atraso do projeto para come o de conversa claro Se o s motivo s n o for em bem identificado s de que adianta j ogar mais pessoas na frigideira v A adi o de pessoas pode ser combinada com outras a es do coordenador pode n o deve No m nimo a es que otimizem minimizem o n mero de intera es e facilitem a r pida absor o do projeto pelo s novo s integrante s finito What needs to be done Cronogramas sao so um Tipo de Previsao Mas ha quem os trate como se fossem documentos sagrados Para Scott Berkun os cronogramas nao sao rem dio para um proj eto design ou pr ticas de engenharia ruins e tamb m n o podem proteger um proj eto de uma lideran a fraca obj etivos obscuros e comunica o pobre Independentemente do tempo gasto e do capricho com que um cronograma foi elaborado no final das contas eles s o apenas uma lista de palavras e n meros Uma lista que segundo Berkun deve ter tr s obj etivos bem claros Descrever quais tarefas devem ser executadas quando e quais produtos ser o gerados v Funcionar como um integrador da equipe indicando depend ncias e amplificando os compromissos m tuos e Fornecer para o time uma ferramenta que possibilite o acompanhamento da evolu o do p
12. a Nova Organiza o Drucker Peter Harvard Business Review 1991 Republicado em HBR Gest o do Conhecimento Editora Campus 2001 5 The New New Product Development Game Takeuchi H e I Nonaka Harvard Business Review 1986 6 Peopleware Productive Projects and Teams DeMarco Tom e Timothy Lister Dorset House 1999 e 1987 7 Criatividade e Grupos Criativos De Masi Domenico Sextante 2003 8 Requirements Led Project Management Robertson Suzanne e J ames Robertson Addison Wesley 2003 9 Programming System Dynamics Lehman M e L Belady ACM SIGOPS 1971 finito What needs to be done Cr ditos e Considera es Finais As imagens utilizadas neste artigo s o de Chema Madoz fot grafo espanhol que n o faz nenhuma quest o de esconder sua maior influ ncia o louco mestre Salvador Dali Os puristas podem reclamar dos indevidos mashups que fiz nas imagens Entendam como sendo uma forma de for los a visitar o belo site de Chema onde as imagens podem ser vistas em seu formato original As demais imagens diagramas rabiscados foram surrupiados digitalmente de The Art of Project Management Ali s boa parte das fotos presentes no livro s o do pr prio Scott Berkun Que faz uma coisa que nunca vi em livros t cnicos lista os sons que mantiveram sua sanidade durante as longas horas em frente ao micro De Charles Mingus a Aimee Mann passando por Beatles Clash Radiohead e Audioslave O cara escuta de
13. an e Belady 9 que mostra que em cada nova vers o o n mero de novos m dulos cresce linearmente mas o n mero de m dulos afetados pelas mudan as aumenta exponencialmente Todas as corre es e altera es de rumo em rela o arquitetura original tendem a destruir a estrutura a aumentar a entropia e desordenar o sistema O divisor de guas a separa o entre mar s mudan as ben ficas e tsunamis detonantes deveria ser mais n tido Mas a pr tica prova que n o Est no discurso de todos os processos modernos que devemos aceitar as mudan as Afinal elas s o inevit veis Mas sabemos que alguns change requests podem simplesmente inundar o projeto com efeitos colaterais mortais O que permite sua distin o Como avaliar corretamente o impacto e os riscos de uma mudan a Creio que imposs vel sem uma clara vis o da arquitetura do sistema Um modelo detalhado que exponha todas as interfaces entre todos os m dulos parece ser a melhor vacina contra mudan as mal ficas Mas um modelo s mede o impacto das mudan as na arquitetura do sistema E os planos cronogramas agendas e finais de semana prolongados Como ficam finito What needs to be done Planejar ou nao Planejar E uma questao Apesar de demonstrar uma certa simpatia por XP eXtreme Programming e suas breves itera es Berkun refor a a utilidade dos planos de longo prazo mesmo quando eles s o grosseiros eles tornam as mudan as de curt
14. camente sobre ele e sua conviv ncia com o arquiteto Agora seguindo com o time cir rgico proposto por Fred Brooks O co piloto que ele sugere o alter ego do cirurgi o capaz de executar qualquer tarefa atribu da a este A nica diferen a que o co piloto seria menos experiente Mas ainda assim funcionaria como um backup do cirurgi o inclusive representando o em reuni es com outras equipes Por m sua principal fun o avaliar e discutir as id ias do programador chefe Lembra vagamente uma das pr ticas sugeridas pelo m todo conhecido como eXtreme Programming XisP para os ntimos a Pair Programming O Administrador sugerido por Brooks um tipo de Coordenador do Projeto Apesar do cirurgi o ter a palavra final em todas as quest es o administrador que cuida do dia a dia da gest o financeira de pessoal suprimentos etc Mais sobre o assunto no sub cap tulo seguinte O Editor o respons vel pela documenta o O cirurgi o segundo a proposta de Brooks gera os documentos principais tanto os t cnicos quanto aqueles para os usu rios finais Mas seria o editor o respons vel pela compila o final anexa o de refer ncias bibliografia etc um luxo Por m ainda hoje brigamos para obter bons documentos de bons programadores inutilmente O Bibliotec rio escritur rio ou program clerk como sugerido por Brooks parece n o fazer muito sentido nos dias de hoj e Mas pa
15. como as coisas devem ser feitas v Cliente A mais importante das tr s perspectivas Mas infelizmente a mais fraca em muitas organiza es Segundo Berkun as tr s perpectivas sempre se sobrep em Cada considera o de neg cio tem implica es T cnicas e para o Cliente e assim por diante E cada decis o pode favorecer determinado ponto de vista em detrimento de outro Ao investir tempo explorando cada uma das perspectivas diz Berkun poss vel ver oportunidades para melhores decis es estrat gicas Para Berkun a fase de planej amento de um projeto s se encerra quando os 4 documentos propostos por ele est o prontos Ou em suas palavras quando as decis es que eles cont m est o tomadas Os documentos s o finito What needs to be done v Marketing Requirements Document MRD Trata se da Vis o do Mundo apresentada pelo neg cio ou sua MRD equipe de marketing Apresenta os obj etivos do neg cio e aj uda a definir o que o proj eto deve contruir visando sua satisfa o Vision v Documento de Vis o Escopo i ira i i s po ak Specifications Define os obj etivos do proj eto explica sua l gica e apresenta L caracter sticas em alto n vel requisitos e datas Defi nem diretamente o que o projeto deve realizar WBS v Especifica es Define o como de um proj eto com uma perspectiva de design e engenharia Work Breakdown Structure WBS Mostra com
16. d processes found here amplifica o seu valor E seria o resultado da combina o de duas coisas i o que torna projetos e times bem sucedidos de uma maneira geral e ii o que torna o projeto e o time atuais diferentes dos outros finito What needs to he done Eu gosto de acrescentar uma terceira vari vel t o importante quanto o projeto emsi e o time no momento da sele o customiza o de um processo o Cliente Quando se trabalha na ind stria como o caso de Berkun raramente se dispara um projeto para um cliente espec fico Da sua omiss o Mas no mercado de presta o de servi os de desenvolvimento altamente recomendado que o perfil valores e a cultura do cliente seja levado em considera o no momento da customiza o do processo Em alguns casos o pr prio cliente solicita a incorpora o de alguns m todos e artefatos quando n o a ado o de um ciclo de vida espec fico Mas o importante aqui entender que n o existe e nem nunca existir uma metodologia m gica aplic vel em v rios projetos Cada projeto exigir um processo espec fico Mas isso n o significa que a organiza o sempre partir do zero Muito pelo contr rio A primeira vari vel colocada por Berkun acima o que torna nossos proj etos e times bem sucedidos de uma maneira geral Trata se de um corpo de conhecimentos nico exclusivo E org nico j que o natural que ele cres a e fique mais rico a cada projeto
17. dan as desde o trabalho de estimativas E mesmo que n o n o custa nada perguntar ao time se o cronograma segue verdadeiro e exequivel v Quais ajustes s o necess rios para aumentar tal probabilidade Berkun diz que raro obter 100 de confian a na pr xima data de qualquer um que seja honesto e s o Portanto esta pergunta quase sempre ser colocada v Como executar tais ajustes com cuidado e de forma isolada Um telefonema Um email Despedindo algu m Berkun alerta que devemos pensar de forma cir rgica mas n o devemos temer as a es e decis es que precisam ser executadas tomadas v Quais s o os maiores ou mais prov veis riscos que enfrentamos hoje na pr xima semana ou no pr ximo m s E quais s o as conting ncias A simples identifica o dos maiores ou mais prov veis riscos j de acordo com Berkun um grande passo no sentido de preven los O mundo mudou e eu n o estou sabendo Os patrocinadores ainda s o os mesmos E seus objetivos mudaram O time se preocupa com algo que eu n o conhe o Nossas antenas e sentimentos devem estar atentos para mudan as que ocorram tanto no micro universo quanto no macro universo do projeto Na sequ ncia do mesmo cap tulo de The Art of Proj ect Management Scott Berkun apresenta v rias outras ferramentas para o micro gerenciamento di rio do projeto Brinquei com os par nteses para destacar a mensagem gerenciar um projeto significa tentar cuidar de u
18. do por alguns minutos Volte com a massa para a vasilha e acrescente o queijo ralado Despej e numa f rma untada e leve ao forno quente por mais ou menos trinta minutos Se vai ficar bom como o da minha V eu n o posso garantir N o existe receita m gica certo finito What needs to be done Trabalho liberado sob uma mine Licen a Creative Commons Attribution NonCommercial ShareAlike 2 0 Brazil Voc pode copi lo e compartilh lo vontade Desde que n o seja para fins comerciais o que depende de uma libera o pr via do autor Voc tamb m pode alter lo ou criar outros artigos ou documentos a partir dele Mas lembre se de compartilh lo sob uma licen a id ntica Ah e de citar o s autor es tamb m finito What needs to be done O que 0 finito O finito um conj unto de servi os desenhado para atender organiza es que executam projetos particularmente aqueles voltados para o desenvolvimento de software Os servi os foram estruturados na seguinte sequ ncia lt In cio bem o proj eto como p direito e o correto entendimento da dor que devo sanar v Me comunico de maneira adequada com todos e o tempo todo v Sou flex vel e me adapto entendo que cada proj eto demanda um processo espec fico e lt Vivo aprendendo fa o de cada projeto uma escola Os servi os podem ser contratados individualmente ou em grupos configurados pelo pr prio cliente Dentre os fo
19. ds to be done v Arquiteto e Produtor s o a mesma pessoa poss vel em pequenos projetos para Brooks de 3a 6 programadores Mas uma combina o arriscada em projetos maiores Brooks justifica Pensadores s o raros executores s o raros pensadores executores s o rar ssimos v O Produtor o chefe e o Arquiteto o seu bra o direito a dificuldade aqui segundo Brooks o estabelecimento da autoridade do Produtor em quest es t cnicas Ele diz que o entrosamento entre o Produtor e o Arquiteto fundamental E que o primeiro deve respeitar muito o valor do arquiteto v O Arquiteto o chefe e o Produtor o seu bra o direito segundo Brooks este seria o arranjo ideal para equipes pequenas enquanto o anterior Produtor o chefe funcionaria melhor em proj etos maiores imposs vel evitar o paralelo das sugest es de Fred Brooks com aquelas apresentadas por eff Sutherland depois de Takeuchi e Nonaka 5 em seu m todo chamado Scrum J eff Sutherland ao contr rio de Brooks n o deixa d vida sobre quem fala mais alto em um projeto O Arquiteto que no Scrum chamado de Product Owner tem a palavra final Enquanto o Coordenador Produtor ou Scrum Master trata de eliminar riscos e obst culos que estej am impedindo o time de obter sua melhor performance S o respectivamente o Navegador e o Piloto em uma equipe de rally uma analogia criada pelo pr prio Sutherland Este desenho faz lembrar tamb
20. e Usabilidade e Designers de Produtos Mas Berkun observa Mesmo que na ltima d cada muito progresso tenha sido feito no refinamento de m todos de pesquisa e compreens o de clientes grande parte dele n o foi assimilado pelo corpo gerencial ou em organiza es centradas na engenharia Ainda incomum que times de projetos tenham um expert em pesquisa de cliente design de interfaces e usabilidade disponibilizado para os tomadores de decis o Na sugest o que apresentei na 22 parte desta s rie o Desenvolvedor de Interfaces realiza tais fun es Trabalhando bem pr ximo do Analista de Neg cios finito What needs to be done Muito se fala e eu n o tenho d vidas de que o tema requisitos responde por mais de 50 dos problemas em nossos projetos Berkun nos apresenta 5 dicas para a obten o do que ele chama de Requisitos de Alta Qualidade Planeje as negocia es de requisitos e as itera es Identificados nossos clientes e demais atores do projeto torna se fact vel a elabora o de uma Agenda para a Coleta de Requisitos No pior cen rio uma RFP deve dar pistas suficientes para o rascunho de um plano inicial Elimine as Suposi es Erradas Como identific las S perguntando Como diz o Berkun se voc o coordenador do projeto religiosamente fa a perguntas esclarecedoras como por que precisamos disso que problema isso resolve e assim por diante S n o permita que seu
21. egridade arquitet nica da solu o l f Data Ele diretamente apoiado por cinco especialistas A Gee v Analista de Neg cios biz cuida da coleta e organiza o dos requisitos e ap ia seu desenvolvimento fazendo a ponte entre os usu rios e a equipe de desenvolvimento v Desenvolvedor de Interfaces front especialista em usabilidade e manda bem em conceitos de arquitetura de informa es Hoje deve brincar com AJ AX J avascript Flash HTML CSS ASP J SP JSF e afins v Desenvolvedor de Servi os srv domina orienta o a obj etos componentiza o e mais recentemente servi os E um programador cl ssico que como tal n o leva o menor jeito com as frescuras da camada de apresenta o v Arquiteto de Informa es data uma vers o remo ada dos DBA s administradores de bancos de dados Domina o desenho e desenvolvimento de bases tradicionais transacionais mas tamb m sabe quando lan ar m o de sistemas gerenciadores de conte do e bases anal ticas v Nosso antigo inimigo infraestrutura s o os respons veis por nossos servidores redes firewalls e outros brinquedinhos T los como parte da equipe de projeto desde os primeiros dias uma pr tica que com certeza minimiza aquele jogo de empurra que costuma acontecer um pouco antes ou um pouco depois do delivery da solu o finito What needs to be done Mas e o coordenador No pr ximo sub capitulo falo especifi
22. eita e o Bolo de FUIG oo ecnncecccsens ceeencceeeeeeeeesseeeeesceenes 47 Receitas Metodologias Processos zzzzzzzzuzunanununeasas 50 QOD sais pai e esa Pp Tarada a 53 SERVICO as isa da DOE ORA DAM DE DS E OR NES 55 Outras Obras Citadas 2 2 02 e cece cence ee cee eee eee eee eee a 56 Cr ditos e Considera es Finals 000eeesesessnssesenennennens 57 Seres humanos que s o quase nicos em sua capacidade de aprender com as experi ncias dos outros tamb m se caracterizam por sua resist ncia em faz lo Douglas Adams finito What needs to be done No segundo capitulo de The Mythical Man Month hom nimo Fred Brooks mostra um fac s mile do card pio do Restaurant Antoine de New Orleans Destaca um Avis au Public que aparece logo no cabe alho do menu Good cooking takes time If you era made to wait it is to serve you better and to please you Brooks apresenta cinco raz es para nossos constantes e intermin veis atrasos O primeiro o incur vel otimismo de programadores e afins Ele diz que nossas t cnicas de estimativas s o pobres e refletem uma situa o irreal de que tudo vai dar certo Esse mesmo otimismo nos faria negligenciar particularmente a fase de testes de um projeto O segundo motivo seria a confus o entre Esfor o e Progresso Tal confus o nasceria da falsa cren a de que Homens e Meses Horas s o intercambi veis Brooks refor a que s conseguimos trocar algu
23. ficador v Apresenta de 3 a 5 objetivos de alto n vel v Consolidada v Inspiradora e v Memoravel O fato do autor no caso Scott Berkun manter um blog faz com que seu livro sej a constantemente atualizado Recentemente Berkun publicou um pequeno artigo chamado Why vision documents stink Isso mesmo cheiram mal Ele comenta que em levantamentos informais em suas palestras por exemplo constatou que a grande maioria dos Documentos de Vis o s o muito ruins Ele tem tr s teorias para o problema v Afalta de um autor l der que no meu ponto de vista deveria ser o pr prio Arquiteto Os documentos n o seriam escritos para servir ao leitor denotando falta de compreens o e de intera o com o cliente e v A confus o entre hype e realidade que geraria documentos meio marketeiros e pouco obj etivos finito What needs to be done Scott Berkun dedica varias paginas de seu livro para tratar da tal Engenharia de Requisitos termo que ele n o utiliza e do Design termo que ele usa insistentemente de uma solu o Cap tulos como How to figure out what to do Where Ideas come from e What to do with ideas once you have them d o o merecido tratamento aos temas Para Berkun a Perspectiva do Cliente pode ser obtida de duas formas Requisitos e Pesquisas E sugere que para cuidar das fun es relacionadas esses tipos de levantamentos dever amos alocar dois tipos de experts Engenheiros d
24. idade de meses de um proj eto dependeria de suas restri es sequenciais O n mero m ximo de pessoas dependeria do n mero de sub tarefas independentes Podemos elaborar um cronograma mais demorado utilizando menos pessoas Mas n o podemos encurtar seu prazo natural adicionando m os finito What needs to be done Recentemente Scott Berkun publicou uma s rie de exce es a Lei de Brooks Alertando que n o queria de ya maneira alguma sugerir o abandono da lei O pr prio Brooks ja reconheceu que sua lei ultraj antemente super simplificada Abaixo as exce es apontadas por Berkun v Depende da pessoa l gico O acr scimo de uma ou mais pessoas mais experientes que aquelas da equipe atual pode eu disse Pode gerar um efeito positivo no projeto v Alguns times podem assumir mudan as mais facilmente acho que depende inclusive de um entrosamento pr vio dos novos integrantes com os antigos Um entrosamento proveniente de proj etos anteriores Mas depende principalmente das outras a es do coordenador ltimo t pico abaixo v H coisas piores que estar atrasado com certeza como entregar algo totalmente diferente daquilo que o cliente espera Berkun lembra bem a nica coisa que a lei fala que o projeto atrasar mais com a adi o de mais pessoas Mas tal acr scimo pode ser ben fico ou crucial para o resultado final do projeto v H diferentes maneiras de adicionar pessoas a um projeto mas
25. istemas os quais suas interfaces devem conformar Isso muda de interface para interface de tempos em tempos n o apenas porque h uma necessidade mas porque as interfaces s o desenhadas por pessoas diferentes v Instabilidade de changeability A entidade software est constantemente sujeita a press es por mudan as Software pode ser alterado facilmente ele infinitamente male vel v Invisibilidade abstra es geom tricas s o muito teis mas n o conseguem representar toda a complexidade de um software Brooks lista ent o uma s rie de avan os que podem aj udar a melhorar a qualidade de nossos projetos Mas frisa que nenhum deles uma bala de prata Linguagens de alto n vel ele cita Ada lembrem se o artigo finito What needs to be done de 1986 Orienta o a Objetos Programa o Autom tica Programa o Gr fica etc Na sequ ncia ele lista alguns princ pios que podem atacar diretamente a ess ncia dos problemas com software Comprar ao inv s de Construir a solu o mais radical para os problemas com a constru o de software n o constru los De certa forma as ondas ERP e CRM livraram v rias empresas de grande parte do peso da constru o e manuten o de sistemas Mas todas as organiza es ainda demandam solu es espec ficas Se n o as constroem internamente contratam servi os de desenvolvimento N o acredito que um dia ser poss vel comprar pacotes ou co
26. jeto que o cronograma deveria ser negociado com o cliente Choque de realidade muitas equipes s o estruturadas ap s o fechamento do neg cio triste mas temo que n o seja uma exce o finito What needs to be done N o dif cil entender o outro lado Normalmente quando um proj eto sai da rea de neg cios para aquisi o via departamento de TI ele ja est atrasado J para ontem Normal O problema come a quando a aquisi o fechada o cronograma apresentado desprovido da menor evid ncia de que poder ser cumprido Aos poucos estamos aprendendo que a Aquisi o Progressiva uma alternativa muito superior para contrata es de projetos de software Em linhas gerais um projeto fatiado em fases normalmente todos j s o e as partes negociam apenas a fase imediatamente seguinte aquela que apresenta o menor grau de incerteza As partes come am com um grande n mero e um cronograma gen rico e concordam em refin lo no decorrer do projeto O contratante pode optar por abrir uma nova concorr ncia a cada itera o fase mostrando independ ncia e principalmente muita maturidade em seus processos de desenvolvimento e aquisi o de sistemas finito What needs to be done No texto original de The Mythical Man Month Fred Brooks apresenta um meta modelo que deveria guiar a constru o de todos os cronogramas As regrinhas v 1 3 Planeja
27. judar a gente a passar na prova apare am mais t tulos como os de Brooks e Berkun Este artigo n o deve ser visto de forma alguma como uma alternativa aos textos originais Ele deve servir como um incentivo para a leitura de ambos Ou releitura por que n o Em 1995 foi publicada uma edi o de The Mysthical Man Month comemorando os 20 anos da obra Ela traz uma s rie de artigos e cap tulos complementares Mas o texto original como era de se esperar foi mantido Que a experi ncia seja agrad vel e til LA Indice Pr logo aipin a aa ee aaa aE 2 Entre o Rel gio e a Bola de Cristal 2552555525555 5 2 5 22 5 Cronogramas s o s um Tipo de Previs o uu e 8 Quest o de Confian a iccciscscanacecenascecenmencecenames 10 Cronogramas Um Meta Modelo i izuuunaasenansesesaesos 13 R gua Esquadro e Bom Senso s iszianeanenaneamenao 15 Como montar Times e influenciar Projetos izuzunasasmas 16 Os Dois Donos do Projeto i icuuisiesananacanananes 22 A Outra fun o da Organiza o ccusunenesesanenescenanes 25 Castelos de Areia izicacuanananansanananansanananaananananaanananaanas 26 Vai Entender o que o Cliente Quer iziissuananaaseneos 32 E a inevitabilidade das Mar s cuccscccanasncaneanenaseamenao 40 Planejar ou n o Planejar uma quest o uueee 44 A Rec
28. m minha compara o Scott me presenteou com uma c pia autografada de seu livro Ah se ele soubesse como tor o para que seu livro n o permane a atual daqui 25 anos A longevidade do livro de Brooks indica de certa forma que n o aprendemos muito Ou que n o aprendemos direito Eu sinceramente gostaria que ambos se transformassem em rel quias documentos de um tempo em que a gente estava brincando de aprender a desenvolver software e a gerenciar projetos O pr ximo passo ensinou Brooks aceitar que software um dos mais complexos trabalhos manuais do homem Tal complexidade demanda nosso cont nuo aprendizado a melhor utiliza o das novas ferramentas uma melhor adapta o a m todos gerenciais a aplica o do bom senso e acima de tudo humildade para reconhecer nossas falhas e limita es finito What needs to be done The Mythical Man Month Frederick P Brooks Jr Addison Wesley R 89 20 Na Cultura em 09 mar 06 The Art of Project Management Scott Berkun O Reilly R 124 24 Na Cultura em 09 mar 06 finito What needs to be done 1 Software Engineering Economics Boehm Barry Prentice Hall 1981 2 Exploratory experimental studies comparing online and offline programming performance Sackman H W J Erikson e E E Grant CACM 1968 3 Chief programmer teams principles and procedures Mills H IBM Federal Systems Division Report FSC 71 5108 1971 4 O Advento d
29. m n mero imenso de var aveis a maioria delas muito pequena e vol vel durante todo o dia Todos os dias finito What needs to be done A Receita e o Bolo de Fuba Quando pensei no titulo deste Ultimo capitulo busquei algo que fosse extremamente simples uma receita culin ria de um prato bem default Mas que ao mesmo tempo parecesse nico em cada fornada O bolo de fub foi uma lembran a imediata Nunca vi dois iguais Mais seco mais molhado dois ou quatro ovos com queijo ou n o com vinagre Pois achei mais de 30 mil ocorr ncias para bolo de fub no Google Minha fam lia mineira obviamente compartilha uma mesma receita Mas o resultado sempre diferente Para algo que deveria ser incrivelmente simples s o s nove ingredientes Um mesmo processo Um mesmo cronograma Mas surpreendente mesmo a ilus o que todos n s que lidamos com desenvolvimento de sistemas j alimentamos pelo menos uma vez na vida a ilus o de que existiria uma receita m gica uma bala de prata que nos aj udaria a entregar nossos projetos no prazo dentro do or amento e excedendo todas as expectativas de nossos clientes e usu rios Se quase imposs vel reproduzir com exatid o a simplicidade de um bolo de fub o que dizer de software Em 1986 Fred Brooks publicou o artigo No Silver Bullet que aparece como o cap tulo 16 na edi o de 20 anivers rio de The Mythical Man Month No texto ele p
30. mente para isso Mas o mais importante o modelo da base Nesta palestra j meio velhinha apresentada em 2003 em evento da SUCESU PMI apresento uma sugest o de um modelo minimo Em Requirements Led Project Management 8 de Suzanne Robertson e J ames Robertson h um modelo um pouco diferente que eles chamam de Requirements Knowledge Model Uma base persistida em um gerenciador de bancos de dados ao inv s de documentos textuais ou planilhas eletr nicas mais gerenci vel Fica mais f cil manter a tal rastreabilidade bi direcional dos requisitos e tamb m seu relacionamento com todos os demais artefatos produzidos no projeto Uma vez gravado um requisito nunca mais pode ser deletado Parece boba mas se trata de uma regra fundamental Cada m nima altera o na reda o do requisito ou em algum de seus atributos significa a inser o de um novo requisito que substitui o anterior mas mant m um v nculo Assim conseguimos rastrear todas as mudan as que ocorreram desde os instantes iniciais de um projeto Portanto a base de conhecimentos acaba se tornando um dos sen o o principal subs dio para o Gerenciamento de Mudan as tema do pr ximo cap tulo finito What needs to be done Perdidos no Espa o entre os Requisitos e a Solu o Constata o inquietante de Berkun Por raz es que n o consigo explicar totalmente muitas pessoas t m dificuldade com o planej amento do trabalho criativo Na maioria d
31. mento v 1 6 Codifica o v 1 4 Testes individuais v 1 4 Testes de integra o No cap tulo 19 da edi o especial do livro after 20 years Brooks admite que seu modelo muito waterfall cascata mas tamb m pode ser adaptado para modelos de ciclo de vida mais modernos iterativos c clicos e incrementais Mas que luxo Gastar 33 do tempo do proj eto s em em planej amento E 50 do tempo do projeto em testes Scott Berkun n o deixa por menos e nos apresenta a regra dos ter os v 30 Design v 30 Programa o v 30 Testes Provavelmente gastamos os 10 que restam tentando justificar o cronograma Brincadeirinha A simplicidade e obj etividade das duas sugest es acima assustam Mas pense um pouco Elas s o v lidas finito What needs to he done Ambos come am concordando que devemos consumir cerca de 30 de todo o tempo do proj eto apenas em seu planej amento e arquitetura Isso n o significa que em um projeto de 9 meses os tr s primeiros ser o consumidos exclusivamente em atividades de planej amento e design Em um processo de desenvolvimento mais moderno voc planeja cada itera o Mas se trata de um n mero justo Eu diria generoso se considerarmos diversos de nossos projetos Berkun tamb m um desenvolvedor Brooks nunca foi Talvez isso explique o fato de Berkun dar o dobro de tempo para as atividades de codifica o Um pouco mais de 15 como sugerido por Brooks
32. mpara o de seus produtos com aquele que o projeto deve gerar v Explicitar o que est fora do escopo do projeto Mostrar quais os riscos do projeto v Suas depend ncias externas sub contratados e afins v Emalto n vel como o trabalho ser organizado e v Apresentar todas as suposi es e depend ncias Ou sej a o Documento de Vis o como proposto por Berkun compila todas as informa es e decis es elaboradas no planej amento inicial de um projeto Esta compila o escrita de forma a ser acess vel leg vel para todos os atores de um projeto se torna um dos principais meios de comunica o negocia o com os clientes N o entendo porque Berkun n o sugere a inser o de um cronograma Outra altera o que eu faria a cria o de uma prioridade 3 com a lista de todas as caracter sticas cen rios classificados como perfumaria ou sup rfluos Eles sempre est o l s uma quest o de classific los finito What needs to be done Berkun sugere que 5 itera es seriam suficientes at a gera o de uma vers o final do Documento de Vis o Acho arriscado fixar assim o n mero de vers es Cada projeto pode determinar um ritmo ciclo bastante particular Mas creio que um m nimo de 3 itera es sej am necess rias O trabalho nas Especifica es e na WBS gerar sem d vidas altera es na Vis o Por fim Berkun destaca as 5 qualidades de uma Boa Vis o Efeito Simpli
33. mples de nosso trabalho pode facilitar sua compara o com outras coisas que existem ao nosso redor Aumentamos assim a possibilidade de aprendizagem Simples n o sin nimo de f cil correr uma maratona simples certo Basta come ar a correr e n o parar at alcan ar o quadrag simo kil metro Voc diria que f cil Lideran a e gerenciamento tamb m s o dif ceis mas sua natureza realizar coisas de determinada maneira atr s de um objetivo espec fico simples Bolos de fub e p es de queijo tamb m s o extremamente simples N o consigo entender porque s aqui em Minas eles s o realmente gostosos finito What needs to be done E l Encerro assim o artigo que elaborei com a inten o de homenagear Fred Brooks e sua obra prima The Mythical Man Month e tamb m para apresentar o ca ula dos gurus ele detestaria o r tulo Scott Berkun Como eu disse l no in cio da viagem estes artigos n o substituem de forma alguma o prazer de ler os dois livros E posso garantir n o cobrem nem 10 de seu conte do O retorno que eu recebi infelizmente a maioria foi off blog compensou com sobras o trabalho O pr prio Scott Berkun deu uma olhada no trabalho E comentou did read the tribute you wrote and was flattered by it wouldn t compare myself to Brooks maybe if in 25 years the art of project management is even still in print can a few modest comparisons begin Apesar de n o concordar co
34. mponentes ou servi os para todo e qualquer tipo de problema de neg cio v Refinamento dos Requisitos e Prototipa o R pida a parte mais dif cil da constru o de software definir precisamente o que construir Creio que imposs vel para os clientes mesmo aqueles que trabalham ao lado dos engenheiros especificar completamente precisamente e corretamente todos os requisitos do software antes de experimentar algumas vers es Portanto segue Brooks um dos mais promissores avan os o desenvolvimento de m todos e ferramentas para a prototipa o r pida de sistemas como parte do processo iterativo de especifica o dos requisitos v Desenvolvimento Incremental aumente cres a um software n o construa no texto original grow not build software Para Brooks a met fora da constru o ja deu o que tinha que dar Vamor olhar para a natureza e estudar a complexidade dos seres vivos ao inv s dos trabalhos mortos do homem Este princ pio pode ser aplicado tanto no ciclo de vida do projeto quanto no ciclo de vida do pr prio produto Processos iterativos e incrementais ja s o comuns Quase carne de vaca O que novo a forma como o Google por exemplo cresce e evolui seus servi os N o se trata meramente de uma manuten o e eu acredito que muitos de nossos produtos podem ganhar com esse novo enfoque Independente do p blico e da tecnologia diga se de passagem v Grandes Designers Grandes projetos de
35. nito What needs to be done Por que ent o a fase de design Arquitetura da Solu o seria t o negligenciada Para Berkun talvez seja porque as pessoas temem a explora o de id ias especialmente quando est o sendo observadas Berkun diz ter evid ncias irrefut veis de que h um n mero infinito de id ias prejudiciais horr veis in teis comicamente est pidas e embara osamente ruins Ele solta essa p rola ao questionar a m xima segundo ele oriunda de comerciais de TV e de sess es de brainstorming ou de comerciais de TV vendendo sess es de brainstorming que diz que n o existem m s id ias L gico que elas existem Aos borbot es Dentre outras coisas ele sugere algo muito simples Boas perguntas atraem boas id ias Para Berkun existem dois tipos de perguntas Boas e um tipo de pergunta Ruim quando estamos envolvidos em um trabalho criativo Perguntas Direcionadoras Boas Chamam a aten o do time para algo importante til ou mesmo central para o trabalho em execu o Tipo Como o usu rio saber que deve clicar neste bot o para ir para a pr xima tela Perguntas Criativas Boas Ao contr rio das quest es direcionadoras estas devem levar o time para territ rios ainda n o explorados do problema em quest o Algo como Haver o outros meios para o cliente chegar na pr xima tela Perguntas Ret ricas Ruins G meas das quest es criativas diferenciam se pelo fato de
36. ns meses por um monte de gente em um conj unto de atividades que n o exij am nenhum tipo de intera o entre as pessoas Acho que nem em panha de caf existe tal isolamento finito What needs to be done A terceira raz o relacionada por Brooks para os atrasos em nossos proj etos chata e provocativa n s n o somos sinceros como o chef do Antoine A facilidade com que damos chutes e apresentamos cronogramas sem um m nimo de embasamento realmente assustadora Pior apresentando os como s rios E a responsabilidade tanto de quem pede quanto de quem da J vi empresa muito grande solicitar uma proposta para um projeto de milh es apresentando um documento de 7 sete p ginas e fazendo uma reuni ozinha com os poss veis contratados Tamanha neglig ncia em qualquer outra rea deve ser caso de pol cia Na nossa parece normal A forma como acompanhamos e monitoramos a evolu o de nossos cronogramas seria a quarta raz o A impress o que grande parte dos proj etos nos transmite que assim que eles ganham ritmo perde se o controle Adicionar pessoas a um projeto de software atrasado s adiar a sua entrega A Lei de Brooks Por ltimo Brooks cita sua lei como outra grande raz o para nossos atrasos Segundo ele adicionar pessoas a um proj eto atrasado como tentar apagar um inc ndio com gasolina Cada novo membro pode significar uma nova cadeia de intera es e restri es A quant
37. o o time trabalhar para realizar o proj eto Berkun tamb m parece cair na armadilha waterfall quando prop e que a fase de planej amento de um proj eto s se encerra com a entrega definitiva destes 4 documentos Apesar de indicar os aspectos iterativos e incrementais de sua elabora o N o deveriam ser apenas os acidentes tamb m conhecidos como mudan as que nos for am a voltar a tais documentos tal fase Se o MRD que pode ser um RFP Request for Proposal por que n o ou pelo menos deveria ser elaborado pelo Cliente temos que o primeiro documento confeccionado pelo time do projeto o Documento de Vis o Segundo Berkun al m de apresentar e explicar todas as caracter sticas features do produto a ser gerado como no Manual sugerido por Brooks o documento deve finito What needs to be done v Explicar o proj eto em apenas uma senten a uma declara o de vis o v Mostrar como o projeto contribuir para a satisfa o dos obj etivos do neg cio v Apresentar as caracter sticas cen rios essenciais para os Clientes prioridade 1 v Mostrar as caracter sticas cen rios considerados desej veis mas n o essenciais prioridade 2 Apresentar os clientes e os problemas que o proj eto deve solucionar para eles Bem como apresentar os atores stakeholders Explicar por que os clientes comprariam ou alugariam o produto do projeto Apresentar os concorrentes e uma co
38. o ou m dio prazos mais f ceis E justifica quando uma mudan a nos objetivos requisitos ou no design ocorre raramente o plano original vai parar na lixeira O plano original talvez sej a nossa melhor sen o nica base de compara o para uma correta avalia o das mudan as propostas Berkun cita Dwight D Eisenhower Nenhuma batalha vencida de acordo com um plano mas nenhuma batalha vencida sem um Berkun e mais um monte de gente gosta de comparar Projeto com partidas de xadrez Tanto que o cap tulo de seu livro que trata de forma mais espec fica o tema mudan as chama se Middle Game Strategy Cada decis o do gerente do projeto assim como cada movimento de um enxadrista s pode assumir uma de duas caracter sticas poss veis v Conservadora deixa o com o maior n mero poss vel de movimentos futuros de op es Em um proj eto pode significar uma desacelera o do ritmo Mas escreve Berkun este o pre o do seguro que voc est comprando v Agressiva mostra total dom nio e comprometimento com uma estrat gia O gerente confia em seu plano e em sua for a finito What needs to be done A aus ncia de um plano n o permite nem mesmo avaliar o perfil das decis es do gerente do projeto Ea maneira como elas s o apresentadas pode ser um p ssimo indicador Lembra aquela piada do marido que diz sempre ter a ltima palavra em casa Sim senhora Para Scott Berkun o Gerente que tem t
39. odem ou devem ser incorporadas ao desenho da solu o Um delimitador deve ser estabelecido e ele deve ficar mais restritivo na medida em que o desenvolvimento avan a ou o projeto nunca terminar O delimitador parece bvio na teoria mas pe a rara na pr tica Se a mudan a solicitada for crucial para o pleno atendimento das necessidades de neg cio o que fazer Ignor la Dizer que ela ser implementada na 22 vers o Toda solicita o de mudan a deve ser analisada com carinho independente do que estej am indicando o term metro e o tax metro do projeto Independente da fase do projeto e da fase da lua finito What needs to be done Para Scott Berkun toda solicita o de mudan a deveria seguir o mesmo processo de negocia o que guiou a fase inicial de coleta de requisitos Creio que a assimila o do processo se torna mais simples se entendermos que toda solicita o de mudan a nada mais que um novo requisito Ou em muitos casos uma nova vers o de um requisito Quando executamos corretamente a Engenharia de Requisitos avaliamos os impactos que cada nova solicita o pode causar naquelas previamente coletadas Agora recebendo um change request executar amos o mesmo tipo de an lise Dependendo do porte do projeto e do n mero de depend ncias grau de acoplamento dos requisitos tal avalia o pode ser penosa e demorada inevit vel Berkun sugere um breve check list para uma avalia o pr
40. oraj osos colegas b Agrupamentos de Id ias Depois de um certo tempo j ogando conversa fora digo id ias para fora conveniente que elas sej am agrupadas e analisadas c Tr s Alternativas Naquele que deve ser identificado como meio do caminho desta etapa do projeto indicado que a lista de alternativas seja filtrada gerando de 3 a 5 alternativas mais vi veis d Duas Alternativas Pouco tempo depois dever amos ser capazes de escolher apenas 2 alternativas de implementa o e Um Design E ent o apenas um design ou Arquitetura da Solu o f Especifica es Ent o com a Arquitetura definida geramos a especifica o t cnica da solu o finito What needs to be done O primeiro passo aceitar as mudan as como um estilo de vida e n o como um desvio uma exce o Assim de forma simples e direta Fred Brooks come a a tratar o tema Mudan as Mudan as ocorrer o em um projeto n o s porque o trabalho inicial coleta e an lise de requisitos e arquitetura da solu o n o foi bem feito Segundo Brooks a entidade Software est sempre sujeita a press es por mudan as Claro como pr dios carros e computadores Mas coisas manufaturadas raramente mudam ap s sua produ o o software sim dada sua infinita maleabilidade N o carecemos nem mesmo das borrachas e marretas de Frank Lloyd Wright Longe de mim diz Brooks sugerir que todas as mudan as de obj etivos do cliente p
41. os livros que li sobre gest o de projetos e desenvolvimento de software h pouca cobertura sobre como sair de uma lista de requisitos do que deve ser implementado para um bom design Cronogramas apresentam uma data para quando os requisitos supostamente estar o finalizados e outra data para quando as especifica es supostamente estar o prontas mas poucas instru es s o fornecidades para a execu o daquilo que est entre essas duas datas Para Berkun t o logo estej amos com os requisitos no lugar os designers podem explorar o territ rio desenhado pelos requisitos H um largo espa o chamado Espa o do Problema de maneiras potenciais para resolver o problema colocado Dependendo dos requisitos este espa o pode ser bem grande por exemplo h um infinito n mero de possibilidades para se desenhar uma casa um sistema de contabilidade um web site ou seja l o que for que esteja lhe pagando Portanto at que voc tenha alguma no o das possibilidades que existem n o muito esperto se comprometer com qualquer coisa descoberta nos momentos iniciais a fase em que temos s uma folha ou um quadro branco Brancos e vazios a fase das Id ias apaixonante para alguns e apavorante para outros As id ias v m das pessoas lembra Berkun nenhuma id ia na hist ria da humanidade brotou de uma pilha de pedras de livros de auto ajuda de semin rios de criatividade ou de sess es de brainstorming fi
42. otal controle do projeto est sempre um passo frente Para tanto ele sugere a realiza o de dois check lists para a verifica o de nossa sanidade digo da sanidade do projeto O primeiro t tico di rio e apresenta as seguintes quest es v Quais s o nossos objetivos e compromissos Eles ainda s o v lidos No meio de tanto trabalho diz Berkun muito f cil perder os objetivos de vista Olhar para eles diariamente uma forma de manter o foco e avaliar corretamente as prioridades v O que estamos realizando hoje contribui para a realiza o dos objetivos claro como os trabalhos em execu o contribuir o para a satisfa o dos obj etivos e dos requisitos Se n o diz Berkun o barco t come ando a ficar deriva v Os trabalhos est o sendo conclu dos de forma a satisfazer os requisitos e cen rios H mil maneiras de completar uma unidade de trabalho que n o satisfaz o esp rito e a inten o do design lembra Berkun Sabemos que a dist ncia entre o ta pronto do programador e o ta pronto do usu rio pode ser quilom trica O outro check list estrat gico e segundo Berkun deveria ser executado semanalmente ou mensalmente seja em reuni es de discuss o do status do proj eto ou mesmo individualmente As quest es s o finito What needs to be done Qual a probabilidade de atingirmos o pr ximo milestone com o apropriado nivel de qualidade Com certeza aconteceram mu
43. quisitos s o muito vol teis Por que n o sugerir um contrato de Aquisi o Progressiva Voc n o tem uma m nima equipe apoiando o na elabora o das estimativas Cobre o chefe Ou contrate a m e Dinah sei l finito What needs to be done Como montar Times e influenciar Projetos A experi ncia pr tica de Fred Brooks como citado anteriormente foi com projetos mastod nticos 1000 pessoas envolvidas ou mais Mas ele lembra que desde aquela poca os gerentes de programa o preferiam pequenos e agudos times formados por pessoas de primeira classe Brooks cita um estudo de Sackman Erikson e Grant 2 que mostra que um programador de primeira classe que recebia US 20 000 ano podia ser at 10 vezes mais produtivo que um programador de US 10 000 ano Mas um pequeno grupo de estrelas seria capaz de desenvolver um OS 360 Talvez em 10 ou 25 anos segundo c lculos do autor Por outro lado Brooks lembra que times grandes orientados para a execu o de um trabalho na base da for a bruta s o lentos caros ineficientes e produzem sistemas que n o possuem integridade arquitet nica OS 360 Exec 8 Scope 6600 Multics TSS SAGE etc A lista longa E o dilema cruel escreve Brooks Haveria solu o Curiosidade em 30 anos o sal rio anual de um bom engenheiro saltou de US 20 mil para US 80 mil nos EUA O cafezinho do Antoine custava US 0 20 Hoje vendido por US 2 75
44. r os problemas identificados como cr ticos para o projeto finito What needs to be done O Problema do Tamanho do Espaco do Problema id ias fogem do controle diz o t tulo de um sub cap tulo do livro de Berkun Por isso se dificil encontrar boas id ias muito mais complicado gerenci las Berkun diz que um erro muito comum tratar o processo de design como se fosse um grande interruptor Para ilustrar melhor a quest o Berkun apresenta o gr fico abaixo Problem space Cexplorins alternatives Problems Writings specifications defined ora snse desisn Em 4 e Time goes this way A partir de uma s lida base de bons requisitos come amos a explorar alternativas de solu o Com o passar do tempo a tend ncia que o n mero de alternativas cen rios aumente Aumentamos assim o tamanho do Espa o do Problema Um dos riscos segundo Berkun n o saber o momento de parar com a gera o de id ias e come ar a filtr las Para tal Berkun sugere a fixa o de alguns pontos de checagem finito What needs to he done Como ilustra o gr fico abaixo s o 6 os grandes check points que deveriam nos guiar no processo de arquitetura da solu o Ki ms T a a efined groupings ST a Vis o e Prova de Conceito Nosso ponto de partida deveria ser um documento de vis o e uma prova de conceito Traduzindo para Pindorama ser a tal proposta t cnica para muitos c
45. realmente muito pouco Mesmo com todos os frameworks e geradores de c digo da vida Por fim temos as atividades t o ignoradas em tantos cronogramas os famigerados Testes Brooks pesa a m o e destina 50 de um cronograma exclusivamente para eles Berkun se contenta com 30 Por favor tentem esquecer por alguns instantes que ele trabalhou na MS no projeto Windows ok finito What needs to he done R gua Esquadro e Bom Senso S o os tr s elementos que devem existir entre o rel gio cronograma e a bola de cristal que ap ia nossas estimativas A R gua nosso hist rico de m tricas nossos ndices de produtividade e coisas do tipo Concordo que a m xima n o se gerencia o que n o se mede n o se aplica totalmente em nossa rea Mas ignorar nossos n meros definitivamente n o aj udar em nada O Esquadro deve representar nossas ferramentas de apoio e ajuste Se estamos em uma fase inicial do projeto talvez os Use Case Points sej am teis J temos informa es suficientes para municiar estimativas baseadas em An lise por Pontos de Fun o Lancemos m o dela Desde que n o ignoremos o que a R gua nos ensinou Por fim o mais importante o tal Bom Senso Na boca de muitos e em t o poucos projetos O cliente n o forneceu informa es suficientes para uma boa estimativa Ent o sej a sincero e diga para ele que a estimativa apresentada de baixa qualidade Voc suspeita que os re
46. recia ser crucial nos tempos dos cart es perfurados e das intermin veis listas impressas em formul rios cont nuos No entanto eu acredito que toda organiza o que esteja finito What needs to he done buscando o reuso de seus ativos de software ou implantando uma SOA Arquitetura Orientada a Servi os demandar a presen a de um bibliotec rio um especialista que em outro artigo eu chamei de GBA Gestor da Biblioteca de Ativos Se prestarmos aten o na complexidade dos atuais ambientes integrados de desenvolvimento IDE s Integrated Development Environment com seus frameworks testes autom ticos integra o com ferramentas de modelagem etc veremos que pode fazer sentido o papel do Almoxarife ou toolsmith na nomenclatura original utilizada por Brooks Um profissional especializado nas ferramentas e na sua adequa o para cada tipo de projeto e fun o Em equipes grandes ou em f bricas parece ser uma fun o de grande utilidade O Testador o nosso Engenheiro de Testes uma fun o que aos poucos vai se tornando mais comum Pena que muitos ainda o confundam com um programador que n o deu certo ou com programadores iniciantes Teste coisa s ria tanto que Brooks como mostramos na 12 parte do artigo dedicaria 50 do esfor o de um projeto exclusivamente para ele Por fim Brooks sugere a aloca o de um Advogado da Linguagem Creio que nossos espert ssimos e modernos IDE s nosso
47. revia que em um horizonte de 10 anos n o apareceria nenhuma evolu o nem tecnol gica nem gerencial que promoveria ganhos consider veis de finito What needs to be done produtividade e confiabilidade Ceticismo n o pessimismo Brooks frisava Nove anos depois para a edi o comemorativa ele escreveu No Silver Bullet Refired seu 17 cap tulo Responde algumas cr ticas e conclui que estava certo em sua avalia o Uma avalia o que pode ser resumida em uma frase apenas Construir software ser sempre dif cil Brooks fundamenta sua tese apresentando quatro propriedades irredut veis da entidade software v Complexidade uma propriedade essencial n o acidental Ou seja software uma entidade complexa por natureza talvez a mais complexa de todas as constru es humanas De tal complexidade vem a dificuldade de comunica o entre os membros do time dela deriva a impossibilidade de enumerar ou mesmo compreender todos os estados de um programa e da vem a falta de confian a da complexidade da estrutura que vem a dificuldade de se criar novas funcionalidades que n o resultem em efeitos colaterais indesejados Em suma e para usar um termo bem nosso tupiniquim Software um bicho de sete cabe as Ponto v Conformidade grande parte da complexidade que deve ser dominada pelo engenheiro de software arbitr ria for ada sem rima ou raz o pelas diversas institui es humanas e outros s
48. rmatos de contrata o dispon veis al m de consultoria est o palestras workshops e treinamentos Para maiores informa es consulte este prospecto pdf ou entre em contato finito pfvasconcellos eti br Zz What needs to be done uma quest o formulada por Peter Drucker em uma entrevista para a revista Business 2 0 a Grande Pergunta que segundo Drucker todo executivo ou gerente deveria fazer todo dia
49. rojeto e que permita estrutur lo em etapas mais gerenci veis E n o que tem cliente que inconscientemente quero acreditar prefere ver um cronograma atualizado do que software rodando Querendo ou n o os cronogramas viraram o grande documento de um projeto de software Responsabilidade demais para algo que deveria ser s mais uma ferramenta Pior para algo que deveria evoluir j unto com o projeto A elabora o do melhor cronograma usando as mais capacitadas pessoas e as melhores ferramentas tamb m ser uma tentativa de prever o futuro Algo que nossa esp cie raramente faz bem Scott Berkun finito What needs to be done E impossivel gerar um cronograma com um minimo de voo acuracidade no momento inicial de um projeto Berkun pos afirma e milhares de projetos confirmam esta lei Mas so continuamos insistindo Berkun gerou o gr fico ao lado a e o partir de Software Engineering Economics 1 de Barry pa Boehm Nos momentos iniciais de um proj eto nosso 2 chute pode ter uma varia o de 400 H quem Project Reguirements Desi n Implementation arrisque 4 d gitos inidiaion analyse Berkun afirma que a volatilidade dos requisitos dentre outros fatores pode gerar estimativas de baixa qualidade E que n o h nada de errado com elas desde que sej am apresentadas como tal Estimativas de Baixa Qualidade E sugere a ado o de N veis de Confiabilidade para nossas estimativas v 40 s
50. s testadores e l gico o arquiteto eliminam a necessidade de um language awyer Advogado n o n finito What needs to be done Fred Brooks encerra O Time Cir rgico terceiro capitulo de The Mythical Man Month falando que um sistema deve ter total Integridade Conceitual e que isso s seria poss vel atrav s da dedica o integral de um Arquiteto System Architect no texto original Logo depois em Por que a Torre de Babel falhou ele fala de dois l deres em um projeto o Arquiteto ou Diretor T cnico e o Produtor Mas o dito popular n o ensina que Tot com dois donos morre de fome Como um proj eto pode ter dois l deres e n o parecer uma organiza o confusa Segundo Brooks o Produtor o cara que monta o time divide as tarefas e elabora o cronograma Tamb m ele quem cuida da aquisi o de recursos durante todo o projeto Portanto na maior parte do tempo o Produtor estaria interagindo com entidades externas ao projeto Ainda assim ele quem estabelece padr es de comunica o e relat rios com o time J o Arquiteto ou Diretor T cnico respons vel pelo desenho do sistema a ser constru do seus m dulos e tamb m seu aspecto exterior Interage principalmente com o time resolvendo quest es t cnicas Considerando que os dois perfis s o necess rios em projetos de qualquer porte Brooks aponta tr s relacionamentos poss veis entre eles finito What nee
51. s 20 anos de The Mythical Man Month Para Brooks ainda cometemos erros de sintaxe com certeza mas eles n o s o nada quando comparados aos erros conceituais da maioria dos sistemas Scott Berkun cita Brooks na abertura do cap tulo How to figure out what to do o terceiro de The Art of Proj ect Management A parte mais dif cil da constru o de software decidir o que construir Nenhuma outra etapa do trabalho conceitual t o dif cil quanto a fixa o dos requisitos t cnicos detalhados incluindo todas as interfaces com usu rios finais com m quinas e outros sistemas Nenhuma outra etapa compromete tanto o projeto se executada erroneamente Portanto a fun o mais importante que o construtor de software executa para seu cliente a extra o iterativa e o refinamento dos requisitos do produto Para Brooks trata se de uma fun o que deveria ser executada por uma pessoa ou um grupo pequeno de pessoas Seria para ele uma forma de garantir a Integridade Conceitual de uma solu o A separa o desta etapa quando decidimos o que deve ser constru do da etapa de implementa o quando decidimos como construir seria outra forma poderosa de buscar tal integridade finito What needs to be done Berkun chama de insanamente simples a forma como ele v a etapa de planejamento de um projeto Ela representada no gr fico abaixo Requirement Desisn Specification Implementation What do we need
52. signs v m de grandes arquitetos designers A constru o de software um processo criativo Uma boa metodologia pode fortalecer e liberar uma mente criativa mas n o pode inflam la ou inspir la Brooks conclui a principal quest o para a evolu o da arte do software est centrada como sempre esteve nas Pessoas N o por acaso que Brooks encerra seu livro recomendando a leitura de Peopleware de Tom DeMarco finito What needs to be done Receitas Metodologias Processos E n o parece ser uma mera coincid ncia que Scott Berkun inicie seu livro citando Peopleware de Tom DeMarco A obsessao com metodologias outra instancia da ilusao high tech Deriva da crenca de que o que realmente importa a tecnologia Independente de qual seja o avan o tecnol gico ele cobrar seu pre o com a deteriora o da sociologia do time Para Berkun a pior coisa seguir cegamente um conjunto de regras e procedimentos s porque eles apareceram em um livro famoso ou porque s o promovidos por um respeitado guru Berkun coloca que processos e metodologias s o muito importantes mas nunca ser o balas de prata entregadores de proj etos bem sucedidos E alerta para o perigo dos gerentes em determinado momento de um projeto come arem a acreditar que o Processo o Projeto Pode parecer absurdo mas este desvio mais comum do que se imagina Um bom processo segundo Berkun ap ia as pessoas e Goo
53. to do Aow will we do it Do if E seguindo em sua insanidade Berkun justifica a necessidade de Planos Segundo ele os planos funcionam como um rem dio contra todo tipo de estupidez porque for am que quest es importantes sej am resolvidas enquanto h tempo para considerar outras op es Apesar de uma sutil diferen a ambos os autores concordam com a separa o das fases de Arquitetura ou o que coleta de Requisitos Defini o etc e de Especifica o ou como design especifica o etc Uma distin o bvia simples mas deveras negligenciada Quantas e quantas vezes testemunhamos arquitetos assim entre aspas mesmo discutindo comos em dias iniciais de um proj eto Brooks radicaliza ao propor que o principal artefato gerado pelo Arquiteto de uma solu o o Manual uma especifica o de toda a parte externa de um sistema o manual do usu rio mesmo nas fases iniciais de um proj eto Um documento que n o deveria se preocupar em explicar os comos finito What needs to he done Berkun um pouco mais met dico e indica a necessidade de 4 documentos principais Antes por m ele alerta para a criticidade do balanceamento de tr s perpectivas v Neg cio quando equipes de engenharia ignoram como seu neg cio funciona muitas decis es da ger ncia parecer o il gicas ou est pidas v Tecnologia o mindset de constru o e materiais Tem o foco em
54. ugs Existem estimativas para m dulos proj etos semelhantes Como elas foram elaboradas e quais fatores elas consideraram N o h m gica Por outro lado os programadores devem confiar no plano no cronograma apresentado Como Entendendo a l gica que o criou O tema me faz lembrar duas provoca es daquelas feitas por Watts Humphrey finito What needs to be done Por que profissionais competentes concordam com cronogramas quando nao t m a menor id ia sobre como ir o cumpri los Por que executivos racionais aceitam tais cronogramas quando os engenheiros n o oferecem a menor evid ncia de que poder o respeita los Berkun fecha o tema apresentando uma s rie de pequenas dicas muito teis v A dura o de uma itera o deve ser coerente com a volatilidade do projeto Quanto mais vol til menor deve ser a dura o da itera o v Devemos ser otimistas na elabora o do Documento de Vis o que ser apresentado posteriormente e pessimistas no cronograma v Devemos apostar no Design E planejar pontos em que as altera es de escopo ser o permitidas v Tornar p blica a filosofia do Plano Cronograma v Considerar a experi ncia da equipe no tipo de projeto que estamos tratando v Assim como seu entrosamento E antecipar os riscos Sempre o Sempre foi meu S ent o estabelecido um compromisso entre todos aqueles que se envolver o diretamente no desenvolvimento do pro
55. uma das tarefas listadas acima seja atribu da a um especialista Uma divis o que n tida em f bricas de software por exemplo Em caminho oposto alguns advogados de m todos geis enaltecem a import ncia de um time formado por generalistas A analogia com equipes m dicas reaparece em um artigo de Peter Drucker publicado pela Harvard Business Review em 1988 O Advento da Nova Organiza o 4 Segundo Drucker informa o dado investido de relev ncia e prop sito Por conseguinte a convers o de dados em informa o requer conhecimento E conhecimento por defini o especializado Com efeito as pessoas realmente detentoras de conhecimentos tendem ao excesso de especializa o qualquer que seja seu campo de atua o exatamente porque sempre se deparam com muito mais a aprender Apesar de ser simp tico aos chamados m todos geis n o acredito na possibilidade ou efic cia de um time composto por generalistas Prefiro apostar em uma forma o que valorize o perfil e a experi ncia de cada um de seus membros No diagrama abaixo apresento um exemplo de um time estruturado por especializa es finito What needs to be done O arquiteto o novo cirurgi o o dono e principal respons vel por aquele projeto ou Arquiteto m dulo Mas s coloca a m o na massa E Coordenador codificando para transferir conhecimentos mem amet Ocupa se com a concep o e manuten o da i l int
56. undo ideal o para so mesmo Scott Berkun apresenta ent o uma forma muito simples de gest o de mudan as que ele chama de vers o super lean do processo de especifica o Consiste do seguinte 1 O Coordenador do Projeto ou o Analista de Neg cios interfer ncia minha escreve um sum rio da mudan a solicitada incluindo sua rela o com os obj etivos do proj eto e com os requisitos previamente apresentados justifica a necessidade da mudan a e apresenta o desenho da mudan a a ser implementada Berkun sugere que este documento tenha no m ximo duas p ginas 2 O programador o testador e todos significativamente impactados pela solicita o devem analisar o documento gerado e dar suas contribui es As mais not veis e ansiosamente aguardadas por todos s o as estimativas de desenvolvimento e testes 3 O documento finalmente apresentado aos l deres do projeto e como sugeri anteriormente ao cliente usu rios zezinhos etc Nessa breve reuni o a mudan a aceita ou n o Se recusado diz Berkun o documento deve rastejar at o canto mais pr ximo e solu ando incontrolavelmente desaparecer do universo do projeto Insisto que a reuni o citada no item 3 acima deveria ser programada e tratar de um conjunto de solicita es de mudan as Se executada ad hoc e a granel se transformar rapidamente no inferninho do projeto finito What needs to be done Fred Brooks cita um estudo de Lehm
57. via dos requisitos que apareceram fora de hora v Qual problema estamos tentando resolver Precisamos resolv lo para obtermos sucesso Precisamos resol v lo na itera o atual Podemos viver com o problema v Trata se de um sintoma ou uma causa aceit vel que tratemos apenas o sintoma v Temos no o do impacto desta mudan a v O custo da mudan a ser compensado pelo benef cio gerado v E os riscos de novos problemas s o compensados pelo benef cio da mudan a A menos que a solicita o de mudan a seja absurdamente rid cula a execu o do check list acima n o ser r pida e muito menos trivial Por isso cabem aqui dois alertas i O cliente ou usu rio ou o stakeholder Zezinho que solicitou a mudan a deve participar do processo acima Ele precisa ter no o do estrago que est prestes a causar E ser co respons vel por ele e ii O processo de desenvolvimento em uso a metodologia deve tentar programar o momento certo para a avalia o das mudan as solicitadas finito What needs to he done Como foi apresentado na 12 parte desta s rie quanto maior a incerteza a volatilidade dos requisitos menor deve ser a dura o de uma itera o No mundo ideal todas as solicita es de mudan as s o analisadas no momento em que a equipe planeja a pr xima itera o Se uma triagem foi executada anteriormente pelo coordenador ou analista de neg cios em conj unto com o Zezinho ent o n o o m
Download Pdf Manuals
Related Search