É possível observar muitas mudanças, nas últimas décadas, quando se
fala em segurança no desenvolvimento de software. Assistimos à explosão
de aplicações web. Seguiu-se um aumento sem precedentes de falhas de
segurança. Depois disso, ficou claro para todos que havia necessidade de
controle de segurança sobre o processo de desenvolvimento de sistemas.
As primeiras análises de segurança de aplicações que fiz, de 1998 até o
início da década passada, revelavam falhas básicas, problemas de fácil
exploração, e, muitas vezes, o desconhecimento total de segurança pela
equipe de desenvolvimento.
O panorama hoje é outro. De uma forma geral, as equipes de
desenvolvimento têm já uma visão de segurança um pouco melhor. Os
esforços de treinamento em segurança, quase unânimes nas empresas, tem
dado resultado. O controle de segurança, seja pelo escritório de
segurança, seja no próprio processo de desenvolvimento, tem tornado as
aplicações mais resistentes.
Ao mesmo tempo em que vejo essa evolução em cada análise que faço,
observo também alguns problemas que não mudam, apesar da preocupação com
a segurança da informação no desenvolvimento de software ser cada vez
maior; apesar dos sistemas desenvolvidos ainda possuírem um número
excessivo de falhas de segurança. Mesmo assim, as especificidades do
processo de desenvolvimento, muitas vezes alijam o pessoal de segurança
de controles mais efetivos sobre este. Não só falta conhecimento de
segurança nas equipes de desenvolvimento: falta conhecimento sobre
desenvolvimento nas equipes de segurança.
Este não é um artigo acadêmico ou científico. No meu trabalho ao
longo destes anos, tive oportunidade de estar em contato com dezenas
equipes de desenvolvimento e inúmeros gestores de segurança. Quero
compartilhar com vocês alguns erros e recomendações que parecem
constantes nesses casos.
1. Estamos no mesmo time
É muito comum ver a equipe de segurança e a equipe de desenvolvimento
jogando em times separados. O desenvolvimento se ressente, porque vê o
trabalho da equipe de segurança como mera crítica sobre o seu trabalho. A
equipe de segurança se ressente porque quando chega o deadline do
projeto, a direção acaba privilegiando a operação, ignorando as
recomendações de segurança dadas. Só lembram-se da equipe de segurança
quando acontece o ataque. E muitas vezes apenas para levar a culpa.
Seria uma ilusão simplista achar que existe uma saída fácil para
isso. Não existe. Sempre haverá algum atrito entre essas áreas, como em
diversas outras áreas na organização. Mas é importante haver o esforço
consciente para não deixar o relacionamento degradar.
A equipe de segurança deve se esforçar para se colocar na posição de
provedora de consultoria para o time de desenvolvimento. Deve se colocar
como apoio para quando precisam de informações e dicas sobre segurança.
Uma falha fatal é aparecer no processo de desenvolvimento só no final,
pra dizer que tem problema. Isso realmente faz o papel da área de
segurança se parecer com uma mera crítica.
2. Ensine o desenvolvedor a pensar no erro
Treinamento em segurança da informação é muito importante. Trata-se
do melhor custo x benefício para aumento de segurança de sistemas. Um
desenvolvedor que conheça os principais ataques e os principais
mecanismos de falha, vai naturalmente levar isso em conta no
desenvolvimento.
Mas existe um aspecto mais funcional: o desenvolvedor sempre vai
pensar no sistema funcionando. Isso também é muito comum com engenheiros
e projetistas. Quando se está criando algo, sempre pensamos na coisa
funcionando. Mas para garantir a segurança temos que pensar na falha.
Tudo funciona bem se estiver tudo certo. Mas e se algo der errado, como
aquela função vai reagir? Mesmo que a equipe conheça os principais
ataques, se não pensar no erro, vai acabar comprometendo a segurança.
3. Lembre-se que não depende só da equipe de segurança
Vamos colocar a coisa da forma mais simples possível: controlar a
segurança no desenvolvimento de software é difícil porque controlar
qualquer coisa no processo de desenvolvimento de software é difícil.
Pode procurar: controlar custo, controlar prazo, controlar qualidade,
pode escolher. Por que é assim? Porque a grande maioria das empresas no
Brasil, mesmo as de grande porte, ainda não tem um processo de
desenvolvimento de sistemas efetivo. Muitas tem metodologias lindamente
redigidas. Quase todas não usam a metodologia.
O que o CSO deve fazer é cobrar a implantação de uma metodologia de
desenvolvimento de sistemas. Qual metodologia? Qualquer uma. A que puder
ser efetivamente implementada. Qualquer método é melhor que nenhum
método. Num primeiro momento, não precisa nem ter requisitos de
segurança por si, o mero fato de haver um método irá facilitar o
controle sobre a qualidade do código produzido.
4. Quanto mais cedo, melhor
Incluir segurança depois do sistema pronto é muito mais caro. Algumas
vezes é impossível. Como já falamos antes, fica com cara de mera
crítica. Porém é fato que muitos dos testes de segurança só podem ser
feitos sobre o sistema final. É recomendável fazer testes de segurança
desde muito cedo no processo de desenvolvimento. Tão logo exista uma
parte do sistema pronta, já se pode fazer um pen teste. Antes disso, já
se pode fazer uma inspeção de código de segurança. Antes disso, ainda na
fase de projeto é possível fazer uma análise funcional de segurança
sobre a especificação do sistema.
Problemas identificados nas etapas iniciais não só são mais baratos
de corrigir como acabam por agregar um fator de conhecimento. Uma vez
que o desenvolvedor saiba que tal código não deve ser feito de tal
maneira, por ser inseguro, irá evitar tal construção no restante do
código.
5. Aponte os problemas específicos e as soluções
Dizer que o sistema apresenta segurança precária é mera crítica.
Dizer que o código é confuso, que não há proteção contra o tal ataque,
ainda não é específico o suficiente. Dizer que na linha 25 tem um
problema e que situações similares devem ser corrigidas em todo o código
ainda não é o ideal. Para corrigir todas essas observações indicadas
será necessário algum julgamento por parte do desenvolvedor. Essa
situação é similar àquela ou não? Esse mecanismo protege mesmo daquele
ataque? Isso vai levar o desenvolvedor para uma área onde ele não se
sente confortável. Ele não é o especialista em segurança: você é.
Correto é dizer que, nas linhas 32, 144 e 398, do arquivo xpto.java, e
nas linhas 244 e 532 do arquivo foobar.java o desenvolvedor usou o
componente X, da forma Y, enquanto deveria ter usado o componente Z, da
forma W. De posse desta informação, é muito simples para o desenvolvedor
encaixar o ajuste em sua rotina de manutenção corretiva.
Conclusão
O panorama é positivo hoje para a segurança no desenvolvimento de
sistemas. Nunca tivemos plataformas de desenvolvimento tão seguras
quanto as atuais. Nunca tantos desenvolvedores foram treinados em
segurança. Nunca tivemos tantas ferramentas para apoiar o
desenvolvimento seguro de aplicações. O desenvolvedor e a equipe de
segurança, contam hoje com sistemas de análise funcional, tais como o
GRC Manager da Módulo. Contam com ferramentas de inspeção de código de
segurança como o AppScan, Fortify e, mais recentemente, a iniciativa
brasileira Safeval. Contam com dezenas de ferramentas de invasão, como
as ferramentas gratuitas do Owasp, o Acunetix e tantas outras.
O que falta mesmo para que a segurança no desenvolvimento deixe de
ser um problema para ser uma solução é a união da equipe de
desenvolvimento com a equipe de segurança. É o desenvolvimento aprender
mais sobre segurança, mas a área de segurança aprender mais sobre
desenvolvimento também.
Tem havido muita discussão sobre como as práticas de desenvolvimento
Agile estão prejudicando mais do que ajudando. As pessoas se queixam de
coisas como testes unitários, TDD, CI, programação em par, e falam que
revisões de código limitam a criatividade do desenvolvedor e criam um
trabalho desnecessário.
Isso é naturalmente irônico, já que os processos Agile surgiram
precisamente porque as pessoas sentiram que os processos não-Agile que
os precederam estavam prejudicando mais do que ajudando. Então, o que
está acontecendo aqui?
Por que os processos existem?
Os processos existem para garantir os resultados. Se você não se
preocupava com a rapidez com que podia fazer algo, ou com quão bem ele
funcionará, você não precisa de processos. Mas você se importa. Então
descobre maneiras para garantir que possa entregar a tempo, com
qualidade, e com qualquer outra característica com que se importe.
Processos também existem para obter resultados previsivelmente bons
de grupos de trabalhadores qualificados de formas diferentes. Se eu
tiver um exército de pessoas que fazem widgets, quero alguma garantia de
que vão continuar a fazer widgets bons, não importa quem esteja
envolvido (desde que tenham algum nível base de habilidades).
Mas e o desenvolvimento de software?
Isso não deveria surpreender ninguém, mas o desenvolvimento de
software também precisa de processos. Por que não precisaria? Afinal,
você se preocupa com fornecimento de bons softwares e deseja resultados
bons das pessoas que o constroem.
E o que faz um bom software? Além do óbvio (que funciona bem e faz o
que você quer que ele faça), um bom software é fácil de conviver. É
fácil de corrigi-lo se for necessário, é fácil mudá-lo se quiser.
Por que os processos tendem a ser ruins?
É quase inevitável que os processos limitarão os impulsos individuais
(ou seja, criatividade). Levados ao extremo, eles sufocarão a paixão,
transformarão todos em ociosos estúpidos, e geralmente tirarão a
diversão do trabalho. Ninguém quer isso. Mas ainda precisamos fazer as
coisas.
O truque é não levar as coisas longe demais. Parte disso está no
reconhecimento de que quanto mais capazes são os desenvolvedores, de
menos processos você precisa para orientá-los. E vice-versa.
Imagine por um segundo que a sua equipe de desenvolvimento seja
composta por ninjas que podem fazer rapidamente um código como se não
estivesse estlizado. Eles podem construir o que você quiser, com rapidez
e eficiência, sem bugs, e levar aos clientes finais com o mínimo de
perturbação quantas vezes você quiser. Será que você ainda precisaria de
processos elaborados para ajudar a guiá-los? Provavelmente não.
Mas aqui está a realidade: a maioria das empresas não tem equipes de
ninjas escrevendo código. Isso vai soar duro, mas a maioria dos
desenvolvedores não é ótima. Na verdade, a maioria nem sequer é
especialmente boa. E pensam que são melhores do que realmente são
(incluindo eu mesmo).
E isso fica ainda pior. A maioria das equipes também tem que lidar
com bases de código hostis, o que torna muito mais difícil fazer um bom
trabalho. Mesmo desenvolvedores bons podem se complicar com isso.
No entanto, apesar dessa realidade, você ainda precisa fazer as
coisas. Então, você encontra maneiras de obter desenvolvedores
(excelentes e não tão excelentes) para fazer um bom trabalho. É disso
que trata a maioria das práticas de Agile.
Você faz uma unidade de teste ou TDD ou par, porque ajuda a reduzir
erros e a escrever um código mais sustentável. Você configura a CI, pois
ela ajuda você a encontrar bugs rapidamente e lhe ensina como fazer o
deploy do seu aplicativo de forma eficiente. E assim sucessivamente.
Pensamento final
Se você acha que as práticas de engenharia Agile são dolorosas ou
desnecessárias, você pode muito bem estar certo. Mas, seja como for,
essas práticas são as melhores ferramentas que temos hoje para conseguir
que os desenvolvedores façam um bom trabalho. Então, se você realmente
quer uma mudança, há dois caminhos a percorrer: ou obter desenvolvedores
muito melhores ou inventar melhores práticas.
A programação em par
é uma prática um tanto quanto controversa, e altamente ágil
contra-intuitiva. Em poucas palavras, são duas pessoas que trabalham na
mesma coisa, usando apenas um computador, ao mesmo tempo. Parece loucura
que isso funcionaria de fato, muito menos ser melhor do que dois
programadores trabalhando separadamente. Mas de alguma forma ela
funciona.
Estamos usando essa técnica há algum tempo, e tenho notado alguns benefícios interessantes que gostaria de compartilhar.
Eliminando dialetos
Se você pedir a 10 pessoas para escrever um pequeno parágrafo sobre
uma ideia específica, provavelmente receberá 10 resultados muito
diferentes. De fato, isso provavelmente seria verdade mesmo se você
tivesse especificado exatamente o que queria que a pessoa escrevesse
(tudo – desde quantas frases deveriam ser utilizadas até as estruturas
gramaticais permitidas).
O mesmo vale para os programadores. Os devs possuem seus próprios
estilos de escrita de código, não importa a linguagem. Eles diferem em
nomes de variáveis e nomes, preferências para construções específicas de
fluxo de controle, comentários de estilos etc. Resumindo, os devs
possuem seus próprios dialetos.
Esses dialetos são especialmente perceptíveis quando um único dev
trabalha exclusivamente em uma parte específica de uma grande base de
código. Ler módulos diferentes em um código fonte é como ir a uma
excursão no campo e ouvir tudo com sotaques diferentes.
Claro, existem coisas que você pode fazer para tentar minimizar essas
diferenças (coisas como padrões de codificação e convenções de
nomenclatura). No entanto, acho que a maioria dos devs tem dificuldade
em seguir as convenções de nomenclatura quando são deixados à sua
própria sorte. É muito fácil recorrer ao seu dialeto quando ninguém está
olhando.
Comece a trabalhar em par (pairing). O pairing é quase
surpreendentemente eficaz em eliminar dialetos de dev e em obter um
código inteiro para ler a base como se fosse escrito por um único
programador. Aparentemente, é muito mais difícil injetar seu próprio
estilo no código quando alguém assume o teclado a cada poucos minutos.
Reduzindo a complexidade
Muitos devs amam a complexidade. Mais perturbador, muitos se sentem
obrigados a, desnecessariamente, introduzi-la no código que escrevem. O
mais preocupante de tudo é que poucos têm a autoconsciência para
perceber o que estão fazendo antes que seja tarde demais. Então, os
códigos fontes em todos os lugares estão repletos de versões diferentes
de uma máquina de Goldberg.
O fato é que, quando o código está apenas na sua cabeça, ele
normalmente parece muito simples. As condições de limites e os casos
extremos são examinados rapidamente, saltos esquisitos de lógica não
parecem tão estranhos, as construções complexas parecem simples, e assim
por diante.
A programação em par te obriga a explicar suas
ideias de design aparentemente racionais para outro ser humano. Na
maioria das vezes, o próprio ato de explicar para alguém o ajuda a
perceber que algo está errado. E, se isso não o faz, um olhar intrigado
ou um cético “OK…” do seu par provavelmente o fará.
Pensamento final
As duas razões mais comumente aceitas para programação em par são
promover propriedade compartilhada e forçar revisões de código
contínuas. São benefícios importantes com certeza, mas a programação em
par também ajuda de outras maneiras. Você já notou algum que você
gostaria de compartilhar?
Não tem jeito: a melhor forma de ganhar dinheiro com projetos de
inovação ainda é vender manuais ensinando como ganhar dinheiro com
projetos de inovação.
Muita gente tem idéias todos os dias, o tempo todo. Algumas são boas, a grossa maioria é ruim. Não poderia ser diferente. Ainda bem. Pois se já está difícil de acompanhar o ritmo das mudanças dos tempos digitais e conectados, imagine se fôssemos invadidos por boas idéias? O Japão sofreu um ataque desses em 1853 e os impactos em sua cultura duram até hoje.
Uma
boa idéia é um processo de maturação, que envolve foco, dedicação,
informação, estudo, experiência e muita, muita, muuuuuuuuita paciência.
Você conhece alguém que teve uma idéia mágica e ficou rico da noite para
o dia em uma área que desconhecia? Não? Pois é, esses caras
simplesmente não existem. Quem se vende dessa forma é mentiroso ou
iludido. E vai quebrar. É a lei de Murphy na prática. Mas você é diferente, né?
Sim, eu sei. Você é diferente. É mais esperto do que a galera. Sabe
identificar uma boa oportunidade. É um empreendedor nato. Sabe de tudo.
Tem um montão de idéias. É capaz de tocar quatro startups ao mesmo tempo
enquanto ainda trabalha de bancário, perde tem acompanha as mídias
sociais e não perde um episódio desta série, desta série, desta série ou desta série, na falta desta série, já que esta série e esta série
perderam sua pegada. Resolve os problemas do planeta no verso de um
guardanapo, depois assoa o nariz nele e o joga fora. Se morasse nos EUA
já estaria milionário etc etc etc... ACORDA, ZÉ MANÉ.
Não
é fácil. Nunca foi fácil. Nem mesmo se seu pai comprar os direitos de
mineração de muitos terrenos e os registrar em seu nome. Quando se trata
da economia de serviços, o único segredo para a sobrevivência é a velha
máxima da padaria: encostar a barriga no balcão e trabalhar feito um
burro de carga.
Em outras palavras, Papai Noel não existe. Ou se
existe, não dá a mínima para você. Nem para mim. Para os que sobem
rápido porque deram sorte, a Carmina Burana já dizia faz tempo: fortune rota volvitur, descendo minoratus. Esse balde de água fria é a primeira parte de meu presente de Natal para você.
É
disso que trata a segunda metade do meu presente de Natal: uma lista de
20 tópicos que devem ser analisados antes de se lançar no escuro,
torrar as economias da família e comprar um Fiat Uno metido a besta
por conta de seus futuros lucros. Vale a pena desenvolvê-la como um
pré-planejamento de negócios, para ter uma boa noção de seu produto ou
serviço. Acima de tudo, para saber se ela é adequado ao mercado.
Abusando de minhas metáforas abusadas, é como um procedimento-padrão de
checagem de sua corda de bungee-jumping para ver se ela pelo menos está
no lugar. No começo cabia tudo em um post, agora vou ter que parcelar em
três vezes sem juros no cartão.
Quanto
desperdício. A história está cheia de "gênios incompreendidos" e de
mentes-brilhantes-avançadas-demais-para-sua-época que não conseguiram o
devido reconhecimento em vida. Ora, faça-nos o enorme favor de não ser
mais uma delas. Inovadores não correspondidos costumam ser mais chatos e
sem-noção do que aqueles carinhas que são perfeitos para os pais da menina, mas que se esqueceram de perguntar se a moça está interessada.
Chega de enrolação, vamos à lista:
1. SINOPSE:
um pequeno resumo do projeto. Em duas frases. Nada de slogans ou frases
de efeito. Algo que explique, de forma sucinta e breve, o que faz o
produto/serviço. A explicação deve ser o mais abrangente possível e ao
mesmo tempo extremamente simples. Sabe visão/missão de empresa? Exatamente o contrário dessa bullshitagem. É a pegada que importa. Para dar um exemplo, sabe como Alien foi vendido a um produtor de cinema (aquele cara que gasta uma fortuna adiantada, bancando o filme)? Foi assim: "Tubarão.
Em uma espaçonave". Só? Só. Cabem três dessas em um tweet. Como Tubarão
foi vendido? Não faço a menor idéia. Não é relevante para este post.
E o caçador de tubarões Roy Schneider com essa gola cacharrel de Steve Jobs, hem? Dá pra fazer um doutorado em semiótica com isso.
2. ATIVIDADES: quais são as características e
vantagens do produto ou serviço? Como ele funciona e o que oferece? Qual
é o nível de expertise necessário para operá-lo e quais são os
pré-requisitos para seu uso eficiente? Pode dividir os usuários e seus
pré-requisitos em três níveis: a interação de nível iniciante,
intermediário e avançado. Usuários iniciantes costumam correr para se
tornar intermediários. Usuários avançados costumam ficar com preguiça de
se manter na frente e a barriga os empurra para o nível intermediário.
Desenhar a interação para o Intermediário Perpétuo pode ser uma boa.
3. USO: qual será o uso pretendido para o
produto/serviço? Que situações ele melhora ou simplifica? Que problemas
elimina? Que novas condições demanda? O que, afinal, ele faz? Como era o
mundo antes dele? Como e por que ele melhora o ambiente? Como transmite
informação, produz conteúdo ou auxilia na vida pessoal, social ou
profissional? É no uso que se percebe como era tosco o mundo de
antigamente. Dá até para conceber uma vida sem, sei lá, pen drives. Mas
para quê?
Daí
seu tio, AQUELE QUE TUÍTA EM CAPS LOCK, te pergunta para que serve o
Twitter e por que você passa tanto tempo nele. Isso é fácil. Quero ver
você responder em uma tuitada. Não conte comigo.
4. MAPA MENTAL: faça um diagrama procurando
relacionar todos os conceitos e ações ligados ao produto, tente definir
seu ecossistema. O mapa mental é uma ferramenta fundamental para se
conhecer melhor o produto/serviço, suas capacidades e limitações e
possibilidades de expansão. Mapas mentais são muito bacanas, ainda
escrevo mais detalhando o tema. Confesso que não sei muito a respeito e
que acho os mapas feios de dar dó. Mas parece que funciona, uma parada
assim meio tipo hipnose. Vou ler mais e conto depois, pode cobrar.
Enquanto isso leia o genial Change By Design.
É bem bom, recomendo. Se estiver sem grana para o frete, leia a versão
em Kindle, direto do computador. É um saco de interface que brilha
demais e dá dor de cabeça, mas o conteúdo vale a pena.
5. CATEGORIAS DE SERVIÇOS(com descritivo de conteúdo de cada categoria):
quais serão as principais categorias oferecidas e qual será o conteúdo
exposto em cada uma delas. Esse é básico. No entanto, é fundamental.
Acredite se quiser, quase ninguém o faz.
Definição de categorias para o SOA da IBM. Continua complicado? Pois imagine sem a divisão como seria fácil de explicar.
6. AMBIENTE: como seu produto ou serviço se enquadra
no ambiente social, de trabalho, de lazer de seus potenciais usuários?
Como ele se integra a outros produtos e serviços com quem divide o
ecossistema? O que é eliminado por ele? O que é amplificado ou reduzido
por ele? O que faz dele fundamental e indispensável?
Quem
imaginaria que haveria um negócio bem lucrativo na venda de tapetinhos
de esfriamento de notebooks? Ou em SEO? Em Links patrocinados? Pegou? É
por aí.
Por enquanto, é isso. Daqui a pouco eu volto com mais alguns tópicos para o seu check-list.
Não me leve a mal, mas... quem é seu usuário? Você ainda pensa nele como um grupo demográfico? Pode não.
Com quem você pensa que está falando?
Seu usuário está cada vez mais mimado, tem produtos e serviços cada vez
mais personalizados. Não vai querer, de jeito nenhum, algo genérico.
Produtos e serviços, não custa nada lembrar, foram feitos para ajudar
pessoas a satisfazer suas necessidades. A lógica arcaica de se fazer as
funcionalidades o mais amplas possível para que acomodem o maior número
de pessoas é furada. Talvez ela valha para produtos genéricos feito os
da Microsoft. Daí não espanta o fato de todo mundo odiá-los.
A
melhor forma de acomodar uma boa variedade de usuários é projetar seu
produto ou serviço para tipos específicos de indivíduos - cada um com
suas necessidades específicas. Públicos-alvo é uma coisa do século
passado. Hoje se fala em personas e cenários. Por mais que tenha quem defenda que isso é tarefa de profissionais de Arquitetura de Informação ou de Experiência do Usuário,
acredito que isso seja tarefa de todos, principalmente de quem define a
estratégia do produto. Vamos, então, aos quesitos que quebram a cara de
muitos que não prestar atenção neles:
13. USUÁRIOS-CHAVE (PERSONAS): seu usuário, a nível
de pessoa, enquanto gente, sacou? Pois é. Brincadeiras à parte, é seu
usuário na forma de uma pessoa, não de um demográfico. Demográficos são
generalizantes, sintéticos, simplificados, paupérrimos. Gente é mais do
que isso. Bem mais. Quando se define um produto ou serviço baseado em personas
fica mais fácil determinar o que ele deve fazer e como deve se
comportar; comunicar-se com todos os interessados, gerar consenso,
mensurar a efetividade e contribuir para uma melhor compreensão do
porquê as coisas dão certo (ou do porquê não dão). Personas são
representadas como gente comum. Elas representam grupos de usuários,
motivações e comportamentos. Elas devem o cotidiano, os hábitos e os
anseios do usuário. E, naturalmente, como o produto ou serviço interfere
neles.
14. CENÁRIOS E AÇÕES: cenários são situações
enfrentadas e decisões tomadas pelas personas quando entram em contato
com o produto ou serviço. Elas podem ser descritas na forma de diagramas
de blocos, storyboards ou listas de bullets, tanto faz. O importante é
que descrevam cada etapa das possíveis interações com cada um dos
potenciais usuários com o produto ou serviço.
15. NARRATIVA: é a tal da storytelling, tão falada hoje em dia, seja transmídia ou não. Existem empresas
especializadas em extrair a narrativa de corporações, o que pode ser
bastante útil para que redescubram como vieram parar ali e pra quê,
afinal, servem. Mas você pode se perguntar: "pra que que eu preciso de
narrativa em e-commerce"? É aí que você se engana: qualquer serviço
transacional PRECISA de narrativa para conduzir o usuário através de
suas diferentes fases para que a experiência seja a melhor possível.
O serviço Reinvigorate praticamente pega seus usuários pela mão e os encaminha pelo processo. A narrativa é clara "mensure, analise, evolua". Mais bons exemplos de design para a conversão aqui.
16. SUPORTE: não o atlético, o técnico. Muita gente
se esquece desse "detalhe" que não tem nada de pequeno e costuma
sacrificar a experiência do usuário. Se você fez uma boa pesquisa de
personas, já sabe que ninguém é igual a você e que todos precisam ou
demandam informações complementares. Como você irá fornecê-las? Através
de uma página de FAQ? De um chat? Por telefone? Terá um manual? Páginas
de ajuda? Uma Wiki? Se a ajuda for terceirizada ou colaborativa, como
moderá-la? Como garantir sua qualidade?
O aplicativo Gallery,
que permite a criação de álbuns de fotos dentro de sites, tem uma wiki
para ajuda. E também tem um fórum, para matar dúvidas mais específicas.
17. MÉTRICAS E RESPOSTAS: hoje, que tudo é
mensurável, não medir chega a ser um pecado. Dá pra medir transações,
scrolls, clicks, tempos de decisão e ociosidade. Dá até pra simular um eye tracking,
se você quiser. Mas medir o quê? Que tipo de informação é relevante?
Que dados são fundamentais? Por quê? Existem vários especialistas
capazes de medir praticamente tudo. Mas se você não sabe o que quer ou
para onde pretende ir, de que adianta medir? Pro isso é importante
hierarquizar a estratégia para avaliar a qualidade das interações e
melhorar a qualidade do produto ou serviço que você oferece.
Poderia falar aqui do Google Analytics.
Sim, mas até aí qualquer zé mané poderia falar do aplicativo mais usado
- e o mais eficiente pelo preço que cobra - para mensuração de
websites. Prefiro falar do CrazyEgg,
um serviço complementar e bastante eficiente para medir o que está
sendo clicado, onde e por quanta gente. Use o aplicativo que quiser, só
não ponha a culpa de maus resultados no desconhecimento de seu usuário.
Hoje ninguém mais pode se dar a esse luxo.
18. FEEDBACK: uma vez recolhidas as métricas, como
analisar seus resultados e o que fazer para que o produto ou serviço que
você imaginou se aproxime dos anseios e necessidades de seus usuários?
Se você acha que suas métricas não são suficientes, pode assinar um serviço como o Notable,
que abre espaço para que a comunidade deixe seu feedback. É um pouco
salgado, mas se a comunidade for suficientemente ativa e colaborativa,
pode ser uma boa.
19. FATURAMENTO: de onde, afinal, vem o dinheiro?
Essa história de "ganhei experiência" é legal pra quem tem dinheiro no
bolso. Como fazer com que necessidades financeiras não prejudiquem a
qualidade ou os ideais que proporcionaram o surgimento do produto ou
serviço?
O
comércio eletrônico pode parecer um negócio da China, mas precisa ser
muito bem planejado. O comércio é sazonal, em Novembro e Dezembro cai o
13º, por isso se gasta mais. Em Janeiro as contas começam a chegar e em
Fevereiro e Março vêm IPTU, IPVA, Imposto de Renda e matrículas
escolares. Resultado: quem não ganhou dinheiro até Novembro não ganhará
nada até Abril, na melhor das hipóteses. E precisará continuar a
investir em estoques, servidores, segurança e logística para conquistar
um público fiel. Não tem conversa: quando a esmola é muita, o santo
desconfia. Uma boa ideia talvez seja fazer um site de reclamações. Pena que essa alguém já teve.
20. PROJEÇÃO: quais são os cenários de projeção caso
o produto ou serviço não tenha sucesso? Tenha sucesso demais? Que
desdobramentos ou cenários alternativos poderão ser desenvolvidos?
Antes se rezava para que os anjos ajudassem, hoje as preces vão em busca de um Angel Investor.
Mas não se iluda: dinheiro é dinheiro e com investimento não se brinca.
Quem põe dinheiro em uma empreitada sem perguntar muito pode retirá-lo
da mesma maneira. Mesmo que você acha seu negócio faça todo o sentido e é
o mercado que não o compreende. Se você mediu direito o mercado,
seguindo esses tópicos e os dos dois posts anteriores, talvez perceba
que sua ideia, que parecia genial a princípio, não é tão boa assim. Nem
tão inovadora.
Para encerrar, recomendo uma leitura: Rework, dos carinhas da 37Signals. Dá pra ler em Kindle (nos eReaders e notebooks) ou ouvir em audiobook.
Dá até pra ler o primeiro parágrafo degrátis no site da Amazon. Só não
dá pra usar a desculpa da demora do frete para deixar de ler. Eu não
ganho NADA com comissão alguma (nunca ganhei, pode examinar os links).
Só recomendo o que realmente acho genial. Como esse livro do meu amigo Julius Wiedemann, de que falarei em outro post.
É um baita livro. Vai fazer você repensar seus processos, fontes de rendimento e ideais com sua empresa. Vale mesmo a pena.
Bom,
é isso aí. Esses 20 requisitos não são a garantia de sucesso de seu
projeto de inovação. Mas se não o matarem, certamente o tornarão mais
forte.
Eu não sei exatamente quando foi que comecei a me ressentir com
pessoas para quem eu estava escrevendo código, mas foi um sinal claro de
que eu estava me sentindo esgotado. Durante dez anos, trabalhei como um
desenvolvedor em agências de design e marketing, em seguida, no Yahoo!,
e, finalmente, dentro da minha própria empresa de serviços ao cliente.
Em algum ponto ao longo do caminho, eu tinha perdido contato com as
pessoas que utilizam o software que eu estava criando. E isso foi um
saco!
Uma das grandes alegrias de criar software é resolver problemas. Não
apenas resolver problemas academicamente, mas realmente consertar as
coisas para as pessoas. Tornar a vida de outras pessoas melhores,
permitindo-lhes realizar mais com menos. A satisfação obtida por ter
outro ser humano satisfeito usando o que você criou é o que faz tudo
valer a pena. Se esse ciclo de feedback é quebrado, você acaba liberando
código para o vazio como uma máquina produzindo funcionalidade para a
especificação.
Uma coisa que você encontra rapidamente quando você reduz seu papel para simplesmente uma das codificações para a especificação
é que a sua posição padrão para qualquer pedido é “não”. Para manter o
projeto no prazo, no orçamento, e para evitar que a equipe boie, você
tem que se manter firme contra o que poderia ser visto como mudanças
desnecessárias e pedidos estúpidos de usuários que realmente não sabem o
que estão falando. É cansativo dizer “não”, e acaba acumulando
rapidamente ressentimento para com aqueles que fazem as perguntas.
Antes que você perceba, o trabalho não é divertido como ele costumava ser.
A solução é fácil. Pare de codar para especificação, e comece a programar novamente para os usuários.
Funcionalidade não é o bastante
Acho que todos nós, provavelmente, estivemos em uma situação na qual
os usuários pedem algo que já existe. Com o nosso pequeno CMS, Perch, os usuários muitas vezes pediram a capacidade de reordenar itens de conteúdo.
É claro, já era perfeitamente possível reordenar os itens – havia
opções para definir o conteúdo para ordenar em qualquer campo, e em
qualquer direção. Se o usuário precisava de uma ordem arbitrária, eles
poderiam adicionar um novo campo, adicionar um número aos seus itens, e
ordenar com isso. No papel, era um sistema bastante poderoso e flexível.
No entanto, os usuários ainda estavam pedindo uma maneira de ordenar o
conteúdo. A funcionalidade estava lá, mas os usuários não estavam
encontrando, entendendo, ou ambos. A especificação foi atingida, mas a funcionalidade estava fracassando com os usuários.
Lembre-se, a especificação é um requisito mínimo. Para realmente fazer um bom trabalho, às vezes é necessário ir além do que a especificação diz e fazer algo que realmente funciona para as pessoas que têm de usá-la.
Aceite quando os usuários estão tendo problemas
Uma grande parte disso é aprender a aceitar quando o código em que
está trabalhando está quebrado. Às vezes os problemas internos são os
mais difíceis de resolver e, como com todos eles, o primeiro passo para
resolvê-los é admitir que você tem um problema. Como um desenvolvedor, é
uma lição muito difícil aprender que, uma característica que funciona
perfeitamente, livre de erros, está quebrada se os usuários não a
entendem.
O que você desenvolveu pode atender aos requisitos da especificação o suficiente para obter o aval, mas não estamos trabalhando para a especificação mais. Como é que vamos começar utilizar e aval?
Às vezes, o problema pode ser resolvido com uma melhor mensagem de
usuário, ou por repensar a interface, mas outras vezes você só tem que
aceitar que os usuários estão tendo problemas, e que você precisa voltar
à prancheta – e que isso é ok. Se o que está aí não funciona para os
usuários, então não funciona.
Minha primeira recomendação nessa situação é simplesmente ouvir seus
usuários. Pergunte a eles o que estão tentando conseguir. Muito parecido
com a debatida citação “cavalos mais rápidos” de Henry Ford, seus
usuários podem aparecer com as soluções erradas, mas o seu requisito
fundamental pode muitas vezes ser destilado a partir dessas soluções.
Então, pergunte a eles, e depois ouça atentamente a resposta.
Os verdadeiros grandes desenvolvedores resolvem problemas
Voltei para a prancheta com a minha ordenação de conteúdo e
implementei uma interface JavaScript de reordenação usando drag e drop. O
core que meus usuários estavam pedindo era uma forma rápida de definir
uma ordem arbitrária de conteúdo. Eu não sou de lançar enormes
quantidade de JavaScript em todos os problemas, mas, nesse caso, parecia
que drag and drop era uma boa maneira de atingir esse objetivo.
Agora os usuários podem pegar um pouco de conteúdo e largá-lo
facilmente onde quiserem. O resultado final é diferente da
funcionalidade que fornecemos antes? Não, mas o processo de chegar lá é
mais alinhado com a maneira como os usuários querem utilizar o software.
Isso não só significa que eles não estão me incomodando com pedidos
de recursos que existem, mas também que são capazes de conseguir mais
com o software.
FAQs são erros que você não corrigiu ainda
Temos uma política de não ter FAQs. Se os usuários estão perguntando
sobre algo com regularidade, então isso significa que não estamos
explicando as coisas claramente, ou que o produto pode ser melhorado.
Com o Perch, os usuários precisam adicionar o domínio do seu site e a
chave de licença correspondente antes de poderem logar em uma nova
instalação. Se eles perderam todas as instruções e não conseguiram fazer
isso, então foram presenteados com a seguinte mensagem:
“Desculpe, sua chave de licença não é válida para este domínio.”
Apesar de precisa, essa mensagem muito raramente resultou em o
usuário tomar o rumo correto de ação para resolver o problema. O que
elas realmente fazem é pedir ajuda dizendo que eles não conseguiram
logar.
Uma maneira de resolver isso seria adicionar FAQ ao nosso site que
explica o que fazer quando se deparar com a mensagem. Isso seria um
curativo na ferida – seria estancar a hemorragia, mas não aliviar a dor.
A solução real era muito mais simples. Nós modificamos a mensagem de
erro:
“Desculpe, sua chave de licença não é válida para este domínio. Log
em sua conta Perch e adicione o seguinte como o seu domínio de produção
ou de teste: example.com”
Com example.com sendo o domínio onde a instalação está sendo
executada. Após essa alteração simples, ninguém nos faz essa pergunta
mais. Tenho certeza de que muita gente ainda sente falta das instruções
de instalação e vê o erro, mas não é mais um problema para eles – eles
só precisam fazer a alteração e continuam sem incidente.
A pior coisa que você pode fazer com FAQs é uma lista delas em seu
site. FAQs são bugs, e a única resposta satisfatória para eles é
corrigir o problema; assim, as perguntas não serão feitas novamente.
Ser um desenvolvedor não é fornecer ferramentas, é resolver
problemas. Se queremos curtir o que fazemos, fazer coisas
impressionantes, e não nos sentirmos esgotados, então precisamos
encontrar maneiras de resolver problemas que funcionam muito bem para os
usuários. Se você fizer um grande software, os usuários apreciarão seu
trabalho e você vai se sentir orgulhoso com o que você conseguiu. Pra
mim, isso soa como uma boa receita para ser feliz no seu trabalho.
Mais um artigo da série Agile! Veremos como escrever boas user
stories. Este é um ponto importante, pois uma boa user story deve ser
entendida tanto pelo team técnico quanto pelo cliente/PO.
Lets…
Sabemos que escrever as user stories é “trabalho” do PO, mas na
teoria, porque na prática quem vai escrever ou é o Scrum Master ou o
time. Nem sempre a realidade do mercado consegue seguir o que temos na
literatura. Mas o objetivo deste artigo não é esse e sim tentar
responder: “as user stories do seu projeto são boas?”. Ou seja, para seu
cliente, ela é valiosa? Ele olha para ela e sabe de fato o que
significa que será feito?
Estou lendo o livro The Samurai Agile,
de Jonathan Rasmusson (em breve vou publicar um review sobre ele); em
um dos seus capítulos ele aborda sobre o assunto e vi que já cometi
alguns erros quando precisei escrever user stories há um tempo, em um
projeto pessoal. Um dos problemas foi não ter percebido o quanto alguns
pontos na user story estavam técnicos. O autor faz uma pergunta
interessante: “Se seu cliente estivesse com fome e ele tivesse que
escolher apenas entre as duas opções abaixo, o que seria mais claro para
ele?”
1. História: Ernie’s Tech Diner
C++ 3 days
Connection pooling 2 days
Model-View_presenter pattern 5 days
2. História: Sam’s Business Pancake House
Create user account 3 days
Notify subscribers of new listings 2 days
Cancel subscription 1 day
Com certeza a história dois faz mais sentido para o negócio do
cliente. Os termos são simples e fáceis de serem entendidos. E o mais
comum: quando somos muito técnicos e escrevemos como na primeira
história, o SM deve ficar atento com isso caso todo o time esteja
participando da escrita das US. E em outro exemplo o autor trouxe que
podemos ser técnicos e o cliente entender. A história abaixo não perde
seu valor:
Add database connection pooling: é dificil para o cliente entender
Mas…
Reduce page load time from 10 secs to 2 secs.
Parece que faz mais sentido para o cliente e você já sabe o que
acontece nos bastidores para atingir o objetivo da user story (US).
Enfim, qualquer US deve ser do tipo INVEST, ou seja, independente, negociável, valiosa, estimável, small (pequena) e testável.
Independente: sua história não pode depender de outras histórias, caso isso aconteça é preciso quebrá-la.
Negociável: é que ela pode ser alterada e adaptada e não fechada.
Testável: que seja possível criar testes que valide aquela história. Algo como:
Login with expired:
Testable:
– redireciona logins expirados
– mostra mensagens de erros apropriadas
Small & Estimatable: não tem que ser grande e sim pequena para que possa ser estimável, quanto maior, mais difícil é estimar.
Este artigo evidencia aspectos importantes do processo de codificação, traçando um paralelo entre eficácia e eficiência no trabalho do desenvolvedor. Também destaca como a adoção das práticas ágeis proporciona uma melhoria na qualidade do código fonte em projetos de software.
Influência do Mercado no processo de desenvolvimento.
Motivos da baixa qualidade no processo de codificação
O mercado é regido por constantes mudanças que impactam no dia a dia das empresas. Sabe-se que tais mudanças se revertem em alterações, às vezes diárias, nos softwares e consequentemente afetam o ritmo de trabalho do time de desenvolvimento. Diante disso, é necessário, que os desenvolvedores possam corresponder proporcionalmente a essa demanda, fazendo com que as organizações se mantenham, ou se tornem, mais competitivas perante o mercado. É comum que uma pressão recaia sobre o time, uma vez que todo o processo está associado à utilização de sistemas.
Neste cenário, a eficácia passa a ser um caminho natural para responder à demanda do mercado. A eficácia é o menor caminho para alcançar um objetivo. Neste contexto, o objetivo pode ser a correção de um erro que impede o andamento de um determinado processo ou a entrega de uma nova funcionalidade que irá gerar algum diferencial para a empresa.
Porém, nem sempre eficácia e qualidade andam juntas. A grande incidência de código mal escrito é resultado da eficácia buscada pelo time. Geralmente, isso ocorre quando uma demanda classificada como urgente é solicitada pelos gestores. O código de baixa qualidade geralmente tem características como inflexibilidade, fragilidade, alto nível de dependência e baixo grau de entendimento.
Há outros fatores que podem contribuir para a produção de código de baixa qualidade. Considere uma provável necessidade de autoafirmação de um desenvolvedor que deseja mostrar que pode atender com rapidez o que lhe é solicitado. Em situações como essa, é evidente a influência de fatores psicológicos, como, por exemplo, o ambiente de competitividade no time de desenvolvimento.
Consequências da má qualidade de código
Priorizar somente a eficácia no processo de codificação é prejudicial e insuficiente, se tornando uma prática válida apenas para gestores que buscam soluções imediatistas. Conforme mencionado anteriormente, a eficácia resulta em um aumento na incidência de código mal escrito, o que é bastante prejudicial a todos os envolvidos. Para exemplificar este prejuízo, podemos destacar:
Improdutividade resultante da manutenção de códigos de complexos;
Compromete psicologicamente a equipe, devido à sensação de não corresponder às expectativas dos envolvidos;
Proliferação de código de má qualidade;
Expõe a reputação profissional do desenvolvedor, pois deixará uma má evidência do seu trabalho;
Aumento do custo do projeto.
Devido a pouca evolução do projeto, é comum que os gestores exerçam uma cobrança mais efetiva visando alcançar os resultados, o que resulta em maior pressão ao time de desenvolvimento. Além disso, os gestores passam a adotar as seguintes práticas:
Contratação de novos desenvolvedores objetivando maior produtividade da equipe;
Maior fiscalização sobre as atividades de cada desenvolvedor;
Propostas de hora extra, buscando reduzir o prazo de entrega;
Desligamento de membros do time.
Tais ações geralmente não implicam na melhoria da produtividade. Pelo contrário, resultam na insegurança, desmotivação, inchaço da equipe e ainda menor evolução no andamento do projeto.
Utilização das práticas ágeis neste contexto
Adotando o SCRUM como framework, o desenvolvimento de um grupo de funcionalidades (Sprint Backlog) sempre estará associado a um tempo predefinido. Isto garante que a equipe possa realizar o seu trabalho com boa qualidade, em um período que pode variar de duas a quatro semanas.
Neste modelo, há um espaço de tempo definido para a entrega de uma funcionalidade, sendo que a complexidade do trabalho é diretamente proporcional a esse tempo. O conceito de Time Box faz com que o tempo, que antes era um fator crítico, passe a ser aliado do desenvolvedor ao realizar o seu trabalho. O fator tempo passou a ser controlável uma vez que o time pode mensurar a relação entre trabalho desenvolvido e o tempo gasto ou tempo restante.
A adoção das Time Boxes favorece a produção de código de qualidade, obedecendo a boas práticas e convenções específicas do projeto ou da empresa. Quando adotamos o SCRUM, favorecemos ao desenvolvimento de um ritmo de trabalho uniforme, ao aumento da produtividade além de contribuirmos para uma melhora considerável no ambiente de trabalho.
Além do uso de Time Boxes, outro pilar do SCRUM que favorece a qualidade de código é a inspeção. O fato de haver inspeção constante faz com que ocorra diminuição de inadequações no código já que o mesmo será previamente detectado e corrigido. Nesse contexto, devemos salientar que a interdisciplinaridade e autogerenciamento do time de desenvolvimento permitirá que todos possam inspecionar o código, contribuindo para o aprendizado constante e para a prevenção de erros do release.
A programação pareada proposta pelo XP Extreme Programming, permite a refatoração de código quase que de maneira automática. A análise do código de um segundo desenvolvedor é importante e permite que a utilização de determinados métodos ou variáveis seja questionada, repensada e otimizada.
Como atender as constantes demandas do mercado
Entregar releases de forma contínua significa manter o projeto em conformidade com as características do mercado que está em constante mudança. Definir as features que irão compor o próximo Sprint Backlog e saber alinhá-las aos interesses da gerência ou de outros stakeholders é um artifício que permite atendê-los de maneira convincente. O dimensionamento do tempo para desenvolvimento e entrega de releases deve estar associado aos anseios do mercado. Isso está intimamente relacionado à criação de um elo confortável entre a forma de trabalho do time e as expectativas da gerência. Ter um código legível e fácil de manter é um dos requisitos necessários para que o time possa entregar software de forma contínua e em curtos espaços de tempo, estabelecendo um ciclo harmônico entre a empresa e o mercado.
Com o lançamento do Team Foundation Server 2012,
nós ganhamos uma funcionalidade muito interessante, denominada
“Asynchronous Checkout”. Desde as primeiras versões do TFS, toda
comunicação com o servidor já era baseada em http, permitindo que
desenvolvedores trabalhassem em todos os cantos usando a Internet como
meio de integração.
O Team Foundation Server 2012 utiliza basicamente duas maneiras de
trabalho com o código fonte: uma chamada de “local workspace” e outra
chamada de “server workspace”. A opção mais comum e recomendada de uso é
o modelo local, que traz os arquivos com os quais você vai trabalhar
para uma pasta local e depois fica gerenciando apenas as alterações;
necessitando sincronizar apenas os arquivos alterados, reduzindo grande
parte da comunicação com o servidor e permitindo o uso do TFS Offline - o
que garante as operações básicas (add, edit, rename, delete, undo,
diff).
Já no modo server, os arquivos ficam centralizados no servidor,
eliminando a necessidade de baixar o projeto completo. Porém, ele não
funciona em caso de queda de conexão, o que trava o projeto e não
permite fazer alterações. Esse modelo é recomendado para projetos
grandes, com muitos arquivos e onde o cliente local não tem muito espaço
em disco.
Quando falamos de WorkSpace, ou seja, “espaço de trabalho”, não
estamos falando sobre o modelo de compartilhamento dos arquivos. Para o
compartilhamento, temos duas opções: modo exclusivo (fica preso com você
durante a edição) ou modo compartilhado (é recomendado porque todos
podem alterar qualquer arquivo). Por padrão, no template de processo
ágil, chamado de Visual Studio Scrum, o modelo de trabalho é múltiplo
check-out, permitindo uma maior colaboração e fazendo com que você não
fique parado enquanto uma outra pessoa está com algum arquivo preso.
Para configurar o modelo de compartilhamento dos arquivos vá em Team
Explorer > Settings > Team Project > Source Control conforme a
Figura 01:
Figura 01 – Configurando Multiple Check-out
Mas a grande novidade da vez no Team Foundation Server 2012 é a
funcionalidade Asynchronous Checkout, que amplia o conceito “local
workspace”, realizando um checkout em segundo plano, proporcionando para
nós, desenvolvedores, uma melhor experiência, sem “travar” o Visual
Studio enquanto ele se comunica com os serviços do Team Foundation
Server 2012.
O ‘local workspace’ é o primeiro passo para termos suporte para uma
tendência, que é o conceito de DCVS (Distributed Concurrent Versions
System). Na prática, você agora pode trabalhar tranquilamente em modo
off-line (descontado do TFS), realizando suas alterações com todos os
arquivos liberados. Quando voltar a se conectar, ele fará o sincronismo
dos arquivos. Trabalhar desconectado se tornou muito fácil com o Team
Foundation Server 2012.
Para ativar o Asynchronous Checkout vá no Team Explorer > Team
Project Collection > Source Control > Workspace Settings conforme a
Figura 02.
Figura 02 – Worspace Settings
Como você pode observar no caminho utilizado durante a configuração
do Asynchronous Checkout, fizemos diretamente no Team Project Collection
essa alteração, afetando qualquer Team Project criado nessa estrutura.
Agora, para praticar, faremos uma pequena simulação. Conforme
demonstrado na Figura 03, o arquivo HomeController.cs está disponível,
ou seja, ninguém o está manipulando nesse momento.
Figura 03 – Arquivo disponível
O próximo passo é interromper a conexão com Team Foundation Server
2012, desligando o seu cabo de rede ou qualquer outro recurso. Assim o
Visual Studio pode detectar que o TFS não está mais disponível, conforme
mostra a Figura 04.
Figura 04 – Team Explorer off-line do TFS
Com o Team Foundation Server off-line, continue trabalhando
normalmente no Visual Studio. Então, pelo Solution Explorer, abra o
arquivo HomeController.cs e inicie a edição mesmo. Você ai perceber que
naturalmente ele, mesmo descontado, está disponível para edição.
Figura 05 – Editando um código
E se você retornar ao Solution Explorer, conforme a Figura 06, verá
que o arquivo está marcado em modo de edição. Na prática, o Visual
Studio está gerenciando essas alterações que você está realizando em
modo desconectado do serviço do Team Foundation Server.
Figura 06 - Arquivo em edição
E para conferir os itens pendentes vá ao Team Explorer > Pending
Changes, conforme a Figura 07, e verá o referido arquivo na lista de
pendência local. Fantástico!!!
Figura 07 – Arquivo editado na lista de pendência.
Como você observou, ao se conectar novamente no Team Foundation
Server, basta fazer o Check-In e sincronizar as alterações com o
servidor. Para tornar essas alterações mais divertidas, enquanto
estávamos off-line eu aproveitei para me conectar ao Team Foundation
Server de outro computador e fazer uma modificação nesse mesmo arquivo.
Com isso, ao tentar sincronizar, ele vai identificar um possível
conflito. A ferramenta tenta resolver sozinha e quando não consegue
alerta você, conforme pode observar na Figura 08, caindo na rotina
padrão de gestão de merge no TFS.
Figura 08 – Resolve conflicts
Você pode escolher a sua alteração, escolher a versão do servidor ou
entrar na ferramenta de Merge, conforme a Figura 09, e fazer manualmente
os ajustes. Depois de resolvido, é só efetuar um novo Check-in.
Figura 09 – Ferramenta de merge
O Team Foundation Server 2012 ganhou mais agilidade no gerenciamento
de código mesmo estando off-line, o que nos dá mais liberdade para fazer
as alterações e, depois, quando possível, realizar o sincronismo
integrando o seu código com a sua versão principal no servidor.
Outro ponto importante em destaque e que vai fazer a diferença é
justamente o suporte ao modo assíncrono, permitindo uma maior agilidade
nas operações com o controle de versão, deixando o Visual Studio 2012
liberado para você continuar trabalhando. E, de brinde, outra novidade é
que agora o Visual Studio detecta alterações externas nos arquivos e
inclui automaticamente essas alterações na sua lista de pendência.
Neste artigo vou trazer o que ganhamos ao escrever User Stories
ao invés de ter que gastar mais tempo escrevendo documentações de
requisitos. Não estou dizendo que não devemos documentar, pelo
contrário. Porém, a ideia é saber o que e como documentar.
O User Stories promove os seguintes pontos:
Aprendizado;
Precisão;
Encoraja a comunicação face-to-face com o cliente;
Possibilita feedback em tempo real;
Evita a falsa sensação de que temos tudo documentado de forma correta e só falta implementar;
Permite uma colaboração e inovação com o time.
Já os documentos de requisitos:
São grandes e cansativos;
Encoraja o trabalho por imaginação com falsos ‘achismos’;
É difícil de planejar;
Feedback em tempo real é inexistente;
Desencoraja abertura de colaboração e invocação com o time.
Isso quer dizer que não vou documentar? Não. Em um projeto Agile há
documentação sim, porém ela não é o meio primário de obter as coisas e
nossa última fonte de obter o entendimento, conversar com o cliente, é
mais importante. A diferença é que aqui evitamos o desperdício do tempo
documentando, pois ao terminar toda documentação, o que foi escrito no
início talvez não tenha mais valor para o cliente.
Vou ficando por aqui. Espero que tenham curtido o artigo e possam colocá-lo em prática na realidade de vocês.
Hoje eu gostaria de falar das dificuldades da homologação de entregas
de software. É, isso mesmo, você ouviu direito: HOMOLOGAÇÃO. “Uai, mas
do que esse cara esta falando? Quem precisa de homologação quando se tem
entregas constantes e refatoração??? Que cara antiquado…”.
A questão é, por mais inconveniente que seja falar isso, por mais que
seja chato, nem todos os clientes aprovam/querem/curtem a ideia de
entregas constantes de pequenos conjuntos de funcionalidades. Muito
menos entregas que, isoladas de um todo, não representam (pelo menos aos
olhos do cliente) valor para o negócio.
[Cena 1]
“Ding dong”, toca a campainha. O cliente abre a porta. Surge desenvolvedor com quatro rodas empilhadas e um notebook.
Desenvolvedor: - Caro cliente tenho uma entrega para você. As rodas do carro estão prontas.
Cliente: - Uai, mas o que eu vou fazer com quatro rodas, sem um carro para elas estarem?
- Ahh, mas eu tenho este teste aqui – fala o desenvolvedor,
mostrando o notebook – que mostra que as rodas funcionam perfeitamente. E
caso algo não esteja funcionando posso ir fazendo correções até que
elas estejam perfeitas!
- Amigo, eu quero um carro, não rodas e testes. Nem vou
ficar testando até ficar perfeito. Sou um cara ocupado pacas, só volte
aqui com esse carro completo…
O foco é entregar software, certo?
Certo, mas software que funcione. E o processo de refatorar até
acertar, esperando chegar ao ponto certo, pode nem sempre ser o ideal.
Obviamente tudo depende do cenário em que você esta atuando.
Às vezes desenvolvemos aplicações voltadas para novas necessidades.
Ou para nichos. Cheias de incertezas e de possibilidades, se baseiam em
um feeling de que as pessoas precisam daquilo, só que ainda não sabem.
Um microblog, uma rede social voltada para um publico especifico, um
jogo para smartphone. De início acreditamos em algumas premissas, em
algumas funcionalidades básicas, e a partir delas desenvolvemos e
entregamos algo. Medimos os resultados, via reação e consumo do
público-alvo (o cliente) e à medida que estas necessidades vão se
esclarecendo, vamos refatorando o que existe, retirando o que se mostrou
desnecessário, melhorando o que fez sucesso e entregando mais
novidades.
Domínio emergindo, entrega constante, refatoração. Tudo como a teoria
atualmente vigente prega. Esse é o lado sexy do desenvolvimento de
software, que deu origem a produtos milionários como Facebook, Twitter,
Instagram e muitos outros.
Porém muitas vezes construímos sistemas de informação para domínios
complexos. Complexos (eu friso) e já estabelecidos. Com o objetivo de
atender dezenas de tipos de cliente diferentes, esses domínios são
erguidos sobre regras pré existentes, mas nem sempre claras, regidos por
normas governamentais e internacionais. Sistemas que lidam com
negócios, com a circulação de bens de consumo e que dão vida as
corporações.
É nesse cenário que muitas vezes o “domínio emergindo, entrega constante, refatoração” não funciona tão bem. Porque?
Problema 01 – Nem sempre é possível isolar uma funcionalidade
Processos de negócio são formados por grandes blocos de ações,
checagens e validações. Determinar onde as funcionalidade começam e
terminam, onde fica cada coisa, qual é o significado de cada conceito é
um trabalho árduo e que aos poucos vai dando forma a um domínio que
mapeia e dá vida as necessidades do cliente.
A questão é que muitas vezes ter uma pequena parte dessa necessidade
já realizada não representa nada para o cliente. Precisaríamos de
recortes maiores. Mas estes recortes maiores têm um custo muito mais
alto para que sejam apresentados.
Numa metáfora de construir um corpo humano, entregar uma válvula do
coração não representaria um progresso real para o cliente. Porém,
entregar um coração inteiro iria demandar um simulador de corpo humano
complexo o suficiente para que fosse feita a validação real. E os custos
deste simulador provavelmente seriam tão altos que inviabilizaria o
projeto.
Problema 02 – O tempo do P.O. vale ouro
O papel de P.O. é uma criação da TI. Podemos falar para o cliente que irá nos guiar durante o processo de desenvolvimento “você
será o product owner. Sua responsabiliade é nos guiar durante o
processo de desenvolvimento indicando o que agrega mais valor ao
projeto, aprovando as entregas e estando a nossa disposição full time”.
Por mais que o cliente fale “Ok, ok”, ele tem outras atividades e
responsabilidades, que tornam seu tempo muito muito precioso. Dessa
forma nem sempre teremos a oportunidade de acertar por “tentativa e
erro”, refatorando até chegar ao ponto ideal. Até porque várias entregas
que não chegarem ao ponto (o famoso “é quase isso”) podem minar a
credibilidade do projeto.
Problema 03 – Nem sempre é o P.O. que aprova as entregas
“Uai, mas não devia ser assim.”. Nem sempre :/ .Às vezes outros
clientes têm que aprovar, afinal o P.O. representa os stakeholders que
serão, em última instância, os usuários (diretos e indiretos) do
sistema.
Solução? Como sempre, a velha história de que não existe bala de prata.
Se o negócio for complexo, o foco na sua organização e posterior
formação de um domínio consistente ajuda muito. É muito mais fácil (e
aceitável aos olhos do cliente) refatorar uma interface gráfica do que
alterar todo um sistema de cálculo ou de validação. No final das contas é
o domínio que dá a segurança para o usuário de que suas necessidades
vão ser atendidas.
Daí, gastar um tempo maior construindo o conhecimento (a famosa
“análise”) do negócio, pode ajudar bastante. Conhecendo o negócio do
cliente como um todo fica muito mais fácil determinar como efetuar
recortes mais efetivos e com isso determinar pontos de entrega de
pacotes maiores mas que facilitam a homologação com o usuário final.
Desse modo o P.O. até poderia receber as entregas com mais
constância, no final de cada sprint. Porém, os usuários
finais/stakeholders as validariam a partir de “pacotes maiores”.
Resumindo, o P.O. até olha as rodas, mas ele as testa com o usuário
final quando existe uma carroceria e um eixo. Carroceria + eixo + rodas =
volta de carro e com isso sensação real de progresso.
“Domínio emergindo, entrega constante, refatoração” é perfeito no
mundo das intenções, mas nem sempre viável no mundo real. Se você
conseguir estabelecer esta dinâmica, lindo, ótimo, maravilhoso. Mas se
prepare para a frustração, porque nem sempre é isso que o cliente quer. E
é ele que paga nossos salários.
Recentemente, em uma prova de Psicologia do
Trabalho, respondi uma pergunta sobre a missão dos psicólogos que
trabalham na área de Recursos Humanos. Cheguei a conclusão de que o
psicólogo organizacional, de certa forma, é um ‘gerenciador de
conflitos’. Confesso que no momento em que escrevo este artigo, pergunto
a mim mesmo se a mesma relação poderia ser ampliada e considerar outros
profissionais, como os da área da administração, departamento de
pessoal, e tecnologia de informação, como os gerentes e líderes de
projeto.
De acordo com Sigmund Freud - e me perdoem porque irei reduzir o gap
semântico e não ser tão formal quanto ao rigor da ciência psicanalítica
-, no processo de constituição do indivíduo há o momento da castração,
que normalmente é feita pelo cuidador que assume o papel do pai, cuja
relação é explicada através do Complexo de Édipo. Este período nada mais
é do que aquele em que se faz a internalização das leis pelo indivíduo,
e ocorre pelo fato desse indivíduo que está em formação não poder
realizar plenamente todos os seus desejos. O ID não pode se manifestar e
dar vazão aos desejos pulsantes dentro deste indivíduo por causa do
SUPEREGO, que surge devido ao processo de castração.
Em uma análise relacional, quando o indivíduo inicia o trabalho em
uma empresa, invariavelmente ele deverá se adequar, caso queira
realmente trabalhar nela. Não falo apenas das características dessa
empresa, mas também os seus valores, que nem sempre são os mesmos do
indivíduo. Em outras palavras, o indivíduo quer se manifestar de uma
forma, entretanto, ele deve adequar-se a um padrão de conduta que não
necessariamente é o dele. Fácil observar que existe posto aí um processo
de ‘castração’ do desejo desse indivíduo.
É verdade que parte desse desejo pode ser sublimado (outro termo
psicanalítico) e assim diminuir essa tensão psíquica do indivíduo de
querer realizar o desejo em plenitude e mantê-lo assim, mas não poder.
Todavia, também de acordo com Freud, essa tensão não é 100% sublimada,
havendo, portanto, resquícios do desejo inicial.
Do outro lado, existe a empresa que, via de regra, está focada para a
inovação, pertencimento ao mercado, reconhecimento, e, obviamente, o
lucro. Todas essas coisas juntas podem, não necessariamente, estar em
conformidade com os desejos dos colaboradores. Vamos concordar que
pouquíssimas empresas, permitem aos empregados trabalharem, por exemplo,
vestindo o que quiserem e estando presentes fisicamente na empresa
quando quiserem, por um motivo simples: em tudo é exigido certa
disciplina e portanto, processos castradores do desejo do ID e
certamente, disciplinadores. Como a disciplina é imposta, se torna
motivo de muita consideração e ponderação.
No meio desses dois interesses, no qual um é fato conhecido por todos
(que é o caso da empresa), e o outro, pouco conhecido, por se tratar de
eventos internos do indivíduo e por isso mesmo, subjetivo, está o
psicólogo organizacional. Uma das funções desse profissional cosiste em
fazer com que as pessoas se sintam bem em trabalhar no ambiente em que
estão, tendo uma certa perspectiva de futuro e melhora, mesmo que esses
dois fatores estejam associados diretamente à empresa no qual fazem
parte; e o outro é sobre a empresa, que precisa que os funcionários
estejam sempre bem, felizes e alegres, trabalhando para terem uma vida
com certa dignidade e com isso fazer a empresa ter lucro. Caso não seja
feito isso, a tendência é que as coisas não sejam mais tão harmoniosas.
Então, não seria de responsabilidades do psicólogo organizacional a
gerência de conflito? Não sei quanto a vocês, mas penso que sim. E
também não estariam incluídos nesse grupo, o líder de equipe e do
projeto, o gerente de projeto, o coordenador, o analista de sistemas,
entre outros?
Um tema recorrente nos diversos blogs e sites que abordam metodologias
ágeis é "por que o PMBoK inviabiliza as práticas ágeis?". Volta e meia,
nas minhas andanças pela web, esbarro com algum texto listando uma série
de trechos de (bons) livros, usando isso para justificar que a
Gerência de Projetos PMI Style seria óleo e a Agilidade seria água, ou
seja, coisas que não se misturam.
E dá-lhe: "tal trecho que fala 'blá blá blá', no capítulo tal, mostra
que é impossível usar o PMBoK em um projeto ágil" ou: o "tal trecho que
diz 'blé blé blé', o que torna as duas coisas incompatíveis".
Diante do exposto, queria contar uma história. A da minha avó e seu
caderno de receitas. Dona Heloiza era uma grande cozinheira. Não estou dizendo isso por
nepotismo. Era mesmo. Podem perguntar a quem não era da família, mas que
teve oportunidade de degustar sua comida. Galinha ao molho pardo
clássica. Lasanha sensacional. Daria para fazer aqui uma lista enorme de
tudo de bom que ela cozinhava.
A vida inteira minha avó colecionou receitas em um caderno. Cada vez
que lia uma receita em uma revista, ou via em um programa de televisão,
experimentava a mesma. Cozinhava, submetia o resultado à aprovação da
família e, se todo mundo gostasse do prato, ele era registrado no
caderno.
E, assim, o caderno (e a gente) ia engordando. Não importava qual era
a fonte, revista, jornal, dica de amiga, o ciclo era sempre o mesmo.
Aprender, testar, aprovar e registrar.
Mas vovó tinha um segredo. Ela nunca preparava o prato igualzinho ao
que estava registrado. Ela sempre mudava algo, adaptava o preparo à
situação. Se alguém não gostava de cebola, ela ralava a dita cuja e
falava que tal ingrediente não tinha sido usado. Se não tinha massa pra
lasanha, usava massa de macarrão (e ficava sensacional). Se não tinha
camarão pra empadinha, fazia com frango a mesma receita. E ficava bom
demais.
As receitas sempre davam certo e faziam sucesso. Isso
porque eram adaptadas para cada ocasião e necessidade. Não havia ortodoxia nem leitura "ao pé da letra". Havia, sempre, a
vontade de fazer funcionar de acordo com a ocasião.
Assim é o PMBok. Um livro de referências. Um conjunto de melhores
práticas que foram listadas por milhares de especialistas como
interessantes para a execução e o gerenciamento de um projeto. Esses especialistas passaram por experiências, testaram técnicas,
checaram se funcionavam e registraram, para que outras pessoas pudessem
utilizar o conhecimento.
Mas, como um bom livro de receitas, não foi feito para ser seguido à
risca, mas sim para ser adaptado a cada situação. Checando a definição na Wikipédia, encontramos:
"O Guia PMBOK é o guia que identifica um subconjunto do conjunto de
conhecimentos em gerenciamento de projetos que seria amplamente
reconhecido como boa prática na maioria dos projetos na maior parte do
tempo, sendo em razão disso utilizado como base pelo Project Management
Institute (PMI). Uma boa prática não significa que o
conhecimento e as práticas devem ser aplicadas uniformemente a todos os
projetos sem considerar se são ou não apropriados."
Condenar uma obra de referência a uma leitura literal é, no mínimo,
ingênuo. E virar as costas para a opinião de milhares de especialistas
pode soar de forma bem presunçosa. Acredito que o segredo vai ser sempre se munir do maior número de
informações, técnicas e opiniões possíveis. Ter sempre um vasto
ferramental. E, na hora da ação, do fazer acontecer, escolher o que
melhor se encaixa a cada situação.
"Ah, mas meu problema é inédito. Nunca ninguém fez isso". Bom amigo,
aí, nesse caso, cabe a você ser o herói e abrir o caminho na mata
virgem. Mas, se alguém já passou pelo caminho, não custa muito pelo menos
ouvir, nem que seja para fazer diferente.
Daí vejo que minha avó sempre esteve certa. Testou tudo o que achou
de bom no seu caminho. Registrou o que se mostrou melhor. Mas nunca
deixou de adaptar, de se moldar ao momento, de buscar a melhor maneira
de fazer funcionar. Sempre analisando o momento e a situação. Pensem nisso.
O padrão Command é um bicho estranho no contexto da programação
orientada a objeto. Diferentemente da maioria dos objetos, um objeto
command representa um verbo, em vez de um substantivo. Isso é um pouco
menos estranho em uma linguagem como JavaScript, na qual as funções são
realmente um tipo de objeto, mas o sentido clássico do padrão Command é
ainda diferente de uma função.
Outro padrão de projeto
Este artigo segue uma série sobre padrões de projeto em JavaScript.
Para ver os outros que já foram destacados e os esperados no futuros,
confira a lista logo abaixo.
Como eu disse, um objeto command é de fato representativo de um
verbo, em vez de um substantivo como a maioria dos objetos é. Outra
maneira de dizer é que o padrão Command é uma maneira de encapsular a
invocação de um método. É simplesmente uma camada de abstração entre o
objeto que implementa um método e o objeto que deseja invocar esse
método. Isso é muito poderoso no mundo da interface do usuário. Como de
costume, isso irá provavelmente fazer um pouco mais de sentido com um
exemplo de código.
Vamos supor que estamos fazendo um aplicativo de despertador,
provavelmente muito semelhante ao do seu celular. Ele lista vários
alarmes que você pode ter, e, no caso desse aplicativo, esse número pode
estar em qualquer lugar entre zero e infinito, ao contrário dos meros 4
alarmes que meu pequeno telefone me oferece. Para esse aplicativo, nós
iremos precisar de um objeto [code]Alarm que contém o status e as
configurações do alarme. Neste momento, estamos apenas preocupados com
alguns métodos específicos que ele implementa: [code]enable,
[code]disable, [code]reset, e [code]set.
Para cada um desses métodos, vamos criar um objeto command para encapsulá-lo:
Observe que cada objeto Command acompanha uma interface. Neste
exemplo, a interface define apenas um método e cada um desses métodos
chama apenas uma função. Se esse for o caso, você provavelmente pode
ignorar fazer coisas como essas e usar apenas funções de callback, o que
é, essencialmente, utilizar as funções como os objetos Command
próprios, no caso de você ainda estar usando o padrão Command, mas você
não percebe porque ela sempre tem sido chamada de função callback.
Agora vamos precisar usar os objetos Command. Estaremos os entregando
para um objeto de interface do usuário que adiciona um botão na tela e,
quando o botão é clicado, ele executa o método [code]execute no objeto
Command que foi passado para ele. Claro que ele sabe quais métodos
invocar, pois todos os comandos usam a mesma interface.
var alarms = [/* array of alarms */],
i = 0, len = alarms.length;
for (; i < len; i++) {
var enable_alarm = new EnableAlarm(alarms[i]),
disable_alarm = new DisableAlarm(alarms[i]),
reset_alarm = new ResetAlarm(alarms[i]),
set_alarm = new SetAlarm;
new Button('enable', enable_alarm);
new Button('disable', disable_alarm);
new Button('reset', reset_alarm);
new Button('set', set_alarm);
}
As quatro partes do padrão Command
O padrão Command tem quatro partes principais que o compõem. A
primeira e mais óbvia é o objeto Command. Agora você sabe o que é isso.
As outras três partes são o client, invoker, e receiver. O client é o
código que cria o objeto Command e passa para o Invoker. Isso
significaria que no trecho de código anterior, o código dentro do
[code]for loop é o client. O invoker é o objeto que utiliza o objeto
Command e chama seu(s) método(s). Finalmente, o receptor é o objeto no
qual o comando está fazendo chamadas, que nesse caso são os
[code]Alarme.
Sem todos essas quatro partes, não é o padrão Command. Sabendo disso,
você pode pensar que o que eu disse sobre uma função de callback sendo
considerada para o padrão Command está errado, certo? Bem, eu discordo
um pouco. Acredito que o JavaScript seja simplesmente fantástico o
suficiente para ter feito funções serem capazes de operar como seus
próprios objetos Command. Todas as quatro partes estão lá, acontece que o
objeto Command está contido dentro do receptor. O único argumento que
eu poderia ver como válido é que não há mais outro nível de abstração.
Veja só, o cliente agora tem que saber o que é o nome da função no
receptor, ao passo que, anteriormente, o cliente não precisava saber
disso, no entanto, eles precisavam conhecer os objetos Command. Você
perde a abstração e, portanto, um pouco de modularidade, mas ganha mais
simplicidade de entender e código mais rápido.
Se você gostaria de ver um exemplo de algo que é um acordo entre o
exemplo acima do objeto Command e apenas usando callbacks, então dê uma
olhada abaixo:
var makeEnableCommand = function(alarm) {returnfunction() {
alarm.enable();
}
}
var makeDisableCommand = function(alarm) {returnfunction() {
alarm.disable();
}
}
var makeResetCommand = function(alarm) {returnfunction() {
alarm.reset();
}
}
var makeSetCommand = function(alarm) {returnfunction() {
alarm.set();
}
}
Em vez de criar um objeto que tem um método a ser chamado, só crie
uma função que seja usada como um callback. É, acima de tudo, inútil, a
menos que ele vá realmente fazer mais do que apenas chamar uma função
específica. Também pode ser utilizada como um meio para tornar o seu
código um pouco mais seguro. Assumindo que o invoker seja um código de
terceiro, poderia, eventualmente, fazer alterações ao método do receptor
por adicionar, alterar ou anular as suas propriedades. Isso é, no
entanto, extremamente improvável.
Eu te ordeno terminar isto
Isso é tudo que eu tenho. Eu não mencionei que o padrão Command
também pode ser usado como um meio para criar a capacidade de desfazer
as ações, mas eu não quero prolongar muito isso aqui, por isso não vou
mostrar te mostrar como fazer isso. Além de usar callbacks simples, o
padrão Command tem uso bastante limitado. Há momentos em que ele pode
vir a ser muito útil, e você vai se sentir muito especial por ter
utilizado um padrão de projeto de software.
Em seu último artigo publicado, Fabricio Vargas Matos,
CEO da Qualidata, onde trabalho, falou da utilização de casos de uso em
nossos projetos. E em um trecho ele fala dos ARCs (ARCs???)
“Além das descrições de casos de uso trabalhamos com
outros tipos de artefatos que chamamos generalizadamente de ARCs –
Artefatos de Representação do Conhecimento (evitamos propositalmente a
palavra documentação) que utilizamos para construir e representar esse
conhecimento que depois será mapeado em software pelos programadores,
que obviamente precisarão tomar muitas decisões de construção, mas
partirão de um problema discutido e mapeado previamente, consistente o
suficiente para dar fluidez no planejamento da construção.”
Quero fechar o foco na parte entre parênteses “evitamos propositalmente a palavra documentação”.
Cheguei ao ponto: Sim amigos, aqui na Qualidata evitamos a palavra
documentação. Eu particularmente corro dela como o diabo evita a cruz.
“Mas por quê?”, você, caro leitor, pode estar pensando. E por que isso é importante/relevante?
Porque esta palavra (documentação) foi corrompida pelo mau uso.
Geralmente, em um projeto de TI, todos os entregáveis (ou pelo menos
a maioria deles) que não são código/software são geralmente chamados
de documentação.
No passado, imaginava-se que um projeto de software começava com o
mapeamento de tudo que o usuário iria necessitar. Tudo então era
descrito em documentos, um monte de formulários que teoricamente
captariam a essência do projeto. Estes deveriam ser analisados pelo
usuário, aprovados e então construídos. Sim, sim, estou falando do
Waterfall, velho de guerra, aquele que todo mundo adora jogar pedra.
Pode jogar a sua agora.
A partir daí o software seria testado. Se algo não tivesse de acordo,
isto é, se algo não funcionasse como deveria (um cálculo de impostos
que não batesse, uma busca que não traz os resultados esperados, etc.) a
documentação era checada. Se a necessidade não estivesse mapeada,
tratava-se de uma falha de análise/desenvolvimento que não percebeu o
requisito. Se estivesse lá, isto é, se tivesse sido aprovada pelo
usuário o erro então era dele, afinal ele tinha (conferido e) autorizado
que a funcionalidade fosse construída daquele jeito.
Estando pronto o projeto, o usuário (agora proprietário do software)
poderia levar o mesmo para ser mantido em qualquer lugar, afinal ele
possuía “documentação” descrevendo tudo.
Aparentemente todo mundo seria feliz no mundo da TI. O usuário se
sentia mais seguro com essa proposta (afinal, vai estar tudo
documentado), bem como o desenvolvedor ("O usuário confirmou que é desse
jeito. Olha só a assinatura dele no documento").
O problema é que além de todos os furos que essa metodologia tem (e
que são comentados por aí faz anos), a documentação era tratada
meramente como uma ordem de serviço. E isso quando o usuário se dignava
em analisar e aprovar a mesma. No pior dos casos, burocracia pura e
simples. O único momento em que ela era usada era na hora de determinar
a culpa, dizer se quem errou foi o desenvolvedor ou o cliente.
Assim, a palavra documentação foi se transformando em sinônimo de inutilidade, como algo que não agregava valor ao projeto.
O agilismo foi a pá de cal. Agora todos eram livres para desenvolver
sem escrever nada, sem preencher um formulário, sem elaborar um
documento. Um PO (product owner) do seu lado o tempo inteiro para
responder tudo o que você precisasse saber. E todos seriam felizes.
Só que não é bem assim que a coisa funciona.
Em tempo, citando mais um trecho do artigo do Fabricio, a realidade da qual estou partindo/da qual faço parte diz respeito a quem “desenvolve sistemas com complexidade de negócio e de cliente que exijam grande esforço para elicitação de requisitos”.
Tendo isso em vista, eu afirmo: representações do conhecimento são necessárias.
Não só para comunicação, mas para sua própria elicitação/compreensão.
Na Qualidata acreditamos que estas representações (daqui pra frente
vou chamar de ARCs, ok?) servem não só para transmitir o que descobrimos
sobre o domínio do cliente, mas servem também como ferramenta para
entendermos MELHOR nosso objeto de estudo.
Quanto mais complexo um domínio, mais regras, mais cenários. E nada
melhor do que tentar estabelecer uma narrativa para ver se a história
faz sentido, se levamos todos os cenários em conta, se o que esta sendo
feito é o que REALMENTE deve ser feito.
Ao elaborar um ARC colocamos em teste a compreensão que temos do
negócio sobre o qual atuamos. Se algo não fecha, sinal de que deve ser
mais pesquisado, mais investigado. E quando outra pessoa for
ler/ver/ouvir seu ARC, mais uma vez esse conhecimento vai ser colocado
em xeque, afinal se o conhecimento ali apresentado é coerente ele deve
ser entendível por outros que não sejam seus elaboradores. Dessa forma, o
conhecimento não só é validado como transmitido.
Notem que quando eu falei ler/ver/ouvir o ARC eu não estava
brincando. Na Qualidata acreditamos que um ARC pode ser qualquer coisa.
Um diagrama, um desenho, um vídeo, uma gravação. O importante é que
toda essa informação esteja organizada de uma forma que ela flua
naturalmente, como uma história transmitida através de várias formas de
expressão.
Os benefícios: mais reflexão na elaboração, mais validação, mais
facilidade de transmissão da informação, mais visibilidade para
clientes.
Se a antiga documentação era somente uma forma de determinar quem
errou, os ARCs são uma maneira de contar uma história, ou melhor, são
mapas em constante melhoria. Um mapa do século XVI era incompleto se
compararmos com os mapas do século XX, mas eles viabilizaram inúmeras
viagens pelo mundo. E os mapas de hoje em dia (pense no Google Maps, e
mais ainda, no Google Street View) são incrivelmente melhores e mais
acessíveis do que os mapas do século XX.
Ainda usando a metáfora do mapa, acreditamos que um ARC deve ser uma
ferramenta, um meio e não um fim, porque esta sempre sendo melhorado.
Enquanto documento tem um ar de coisa morta, uma foto estática de um
passado congelado, um ARC esta vivo e em constante evolução. Ou pelo
menos deve estar, senão não se trata de um ARC.
25
Figura 01 – Configurando Multiple Check-out
Figura 02 – Worspace Settings
Figura 03 – Arquivo disponível
Figura 04 – Team Explorer off-line do TFS
Figura 05 – Editando um código
Figura 06 - Arquivo em edição
Figura 07 – Arquivo editado na lista de pendência.
Figura 08 – Resolve conflicts
Figura 09 – Ferramenta de merge