{"id":2679,"date":"2014-04-07T15:41:05","date_gmt":"2014-04-07T15:41:05","guid":{"rendered":"http:\/\/kasperskydaily.com\/brazil\/?p=2679"},"modified":"2020-02-26T13:15:54","modified_gmt":"2020-02-26T16:15:54","slug":"a-regra-de-seis-parte-iii","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.br\/blog\/a-regra-de-seis-parte-iii\/2679\/","title":{"rendered":"A regra de “Seis” – Parte III"},"content":{"rendered":"

Esse texto \u00e9 continua\u00e7\u00e3o, veja a parte anterior aqui<\/a>
\n<\/span><\/p>\n

O princ\u00edpio de \u201cSeis\u201d<\/strong><\/p>\n

Considerando que a fase de julgamento e desenvolvimento inicial foi realizada por um grupo\u00a0pequeno, ficou claro que as abordagens de gerenciamento de projetos n\u00e3o seria fun\u00e7\u00e3o de uma equipe t\u00e3o reduzida. Como resultado, uma abordagem semelhante \u00e0 SCRUM foi implementada: os desenvolvedores trabalhariam em um espa\u00e7o aberto, interagindo continuamente, assim eles prontamente poderiam abarcar todos os aspectos do processo de desenvolvimento. Essa foi a forma como trabalhou a equipe de desenvolvimento do \u201cSeis\u201d.<\/p>\n

Defini\u00e7\u00e3o: SCRUM<\/span><\/strong><\/p>\n

SCRUM \u00e9 uma abordagem de gest\u00e3o de projetos para o desenvolvimento de software \u00e1gil e din\u00e2mico. Est\u00e1 baseada no princ\u00edpio de que o cliente (usu\u00e1rio) n\u00e3o sabe exatamente o que precisa e poderia alterar a exig\u00eancia no decorrer do processo. Isso significa que o processo de desenvolvimento \u00e9 caracterizado pela presen\u00e7a de ciclos consequentes e numerosos: constru\u00e7\u00e3o, demonstra\u00e7\u00e3o, an\u00e1lises de respostas e, finalmente, atualiza\u00e7\u00e3o da vers\u00e3o.<\/p>\n

Mas a distribui\u00e7\u00e3o de pap\u00e9is SCRUM mudou de maneira significativa. Eugene Kaspersky definiu seis fun\u00e7\u00f5es principais:<\/p>\n

arquiteto<\/span><\/strong><\/p>\n

\u00c9 a pessoa (ativamente envolvida no processo de codifica\u00e7\u00e3o) que sabe o que construir e como constru\u00ed-lo.<\/p>\n

designer t\u00e9cnico<\/strong><\/p>\n

N\u00e3o existe uma defini\u00e7\u00e3o simples para este papel, mas \u00e9 a pessoa \u00e9 respons\u00e1vel por \u00a0tornar realidade algumas ideias e solu\u00e7\u00f5es. Talvez o mais importante \u00e9 que o designer t\u00e9cnico deve saber como n\u00e3o fazer as coisas.<\/p>\n

inventor<\/strong><\/p>\n

O inventor aplica solu\u00e7\u00f5es n\u00e3o convencionais para resolver problemas. No caso de \u201cSeis\u201d, os problemas eram incont\u00e1veis. A solu\u00e7\u00e3o tinha que, finalmente, fornecer o mais alto n\u00edvel de prote\u00e7\u00e3o ao usu\u00e1rio e ainda consumir a menor quantidade de recursos do sistema.<\/p>\n

gerente de projetos<\/strong><\/p>\n

O papel do gerente de projetos em SCRUM n\u00e3o pressup\u00f5e estritamente seguir regras estabelecidas. Ele controla o conjunto de recursos e prazos, mas ele n\u00e3o \u00e9 um chefe. Ele n\u00e3o comanda os programadores sobre o que fazer, mas motiva-os a tomar decis\u00f5es e fazer bem o trabalho.<\/p>\n

\u201cA equipe era pequena, n\u00e3o t\u00ednhamos um chefe\u201d, diz Doukhvalov. \u201cO gerente de projetos estava planejando, relatando, mas as decis\u00f5es eram tomadas conjuntamente\u201d.<\/p>\n

gerente de marketing<\/strong><\/p>\n

O produto \u00e9 criado para os clientes e n\u00e3o para a pr\u00f3pria equipe de desenvolvimento. \u00c9 vital ter uma compreens\u00e3o das expectativas dos usu\u00e1rios com o novo produto e como eles v\u00e3o utiliz\u00e1-lo. Se os especilistas se ocupam de todos os aspectos t\u00e9cnicos do produto antiv\u00edrus, \u00e9 necess\u00e1rio tamb\u00e9m pensar em outros detalhes como definir as op\u00e7\u00f5es de configura\u00e7\u00e3o, as mensagens e criar uma interface de usu\u00e1rios intuitiva. Todas as caracter\u00edsticas levam em considera\u00e7\u00e3o as necessidades dos usu\u00e1rios e o gerente de marketing se ocupa de entender estas necessidades.<\/p>\n

psic\u00f3logo<\/strong><\/p>\n

Trabalhar sob press\u00e3o, dormir pouco, conflitos no grupo, a instabilidade \u2026 \u00c9 necess\u00e1rio algui\u00e9m que crie um ambiente amig\u00e1vel e produtivo. Esta fun\u00e7\u00e3o foi atribu\u00edda ao pr\u00f3prio Eugee Kaspersky, que proporcionava \u00e0 sua equipe apoio e recursos e tamb\u00e9m os protegia de influ\u00eancias externas.<\/p>\n

Francamente, nos projetos SCRUM, existe outro papel fundamental: o de quem se ocupa em anotar tudo o que ocorre durante o processo de desenvolvimento. Mas esta posi\u00e7\u00e3o n\u00e3o foi ocupada por ningu\u00e9m e isso gerou problemas.<\/p>\n

\u201cN\u00f3s n\u00e3o sabemos o por qu\u00ea, mas introduzimos este papel apenas um ano atr\u00e1s\u201d, afirma Kaspersky.<\/span><\/p>\n

De acordo com o princ\u00edpio, o n\u00famero de pap\u00e9is n\u00e3o corresponde necessariamente ao n\u00famero de membros da equipe. Um papel pode ser distribu\u00eddo entre v\u00e1rias pessoas, enquanto que um \u00fanico integrante pode executar v\u00e1rias fun\u00e7\u00f5es.<\/p>\n

\u201cEnquanto t\u00ednhamos uma organiza\u00e7\u00e3o formal, agimos como uma \u00fanica equipe, por isso n\u00e3o havia distin\u00e7\u00e3o exata entre os pap\u00e9is: em particular, tudo se misturava durante as sess\u00f5es de brainstorming\u201d, confessa Nikolay Grebennikov. \u201cPor exemplo, uma pessoa que se ocupava de criar os c\u00f3digos poderia expressar sua opini\u00e3o sobre o desenho do aplicativo e esta opini\u00e3o era levada em considera\u00e7\u00e3o. Eu era o gerente de projetos, mas participava ativamente dos debates. O sucesso do projeto se deve a esta flexibilidade, porque todos juntos nos preocupav\u00e1mos com cada detalhe\u201d.<\/p>\n

De acordo com De-Monderik, os pap\u00e9is eram altamente intercambi\u00e1veis\u200b\u200b: \u201cCada membro da equipe foi o melhor em seu dom\u00ednio, mas o 50% de suas habilidades coincidiam com outra pessoa da equipe. Mike poderia se ocupar dos c\u00f3digos de Sobko se ele n\u00e3o estivesse presente, os especialistas que se ocupavam da interface poderiam se ocupar de algumas tarefas de engenharia e vice-versa. Eu poderia fazer desenhos em vez de Max Yudanov e \u00e0s veces Kolya Grebennikov poderia se ocupar do desenho tamb\u00e9m\u201d.<\/span><\/p>\n

\u00c9 fundamental compreender que cada fun\u00e7\u00e3o \u00e9 um est\u00e1gio espec\u00edfico da execu\u00e7\u00e3o do projeto. Durante a fase inicial, o arquiteto \u00e9 a figura central. Logo, o inventor entra em a\u00e7\u00e3o durante o est\u00e1gio intermedi\u00e1rio do processo de desenvolvimento, quando os recursos s\u00e3o criados e desenvolvidos. E durante a \u00faltima fase, a figura-chave \u00e9 o gerente de projetos que tem o papel mais importane porque gerencia diferentes recursos para que toda a equipe respeite os prazos.<\/p>\n

Em busca da perfei\u00e7\u00e3o<\/span><\/strong><\/p>\n

Com a abordagem SCRUM e um projeto t\u00e3o ambicioso, para \u201cSeis\u201d n\u00e3o havia sido estabelecido uma lista fixa de requisitos, mas existiam especifica\u00e7\u00f5es b\u00e1sicas. O \u00a0produto tinha que:<\/p>\n