Ao trabalhar num projeto onde os usuários eram extremamente exigentes quanto aos detalhes de como a interface gráfica funcionaria, passei a pensar sobre como aquelas exigencias poderiam ser documentadas. Após um tempo vi que seria impossível coletar cada exigência que o usuário faz sobre aquelas dezenas de interfaces, principalmente porque o usuário pedia a alteração, a mesma era implementada e a partir daquela mudança o usuário notava que havia um outro detalhe que poderia ser alterado e como tinhamos 3 usuários chaves cada um fazia suas exigências ao sabor de seu humor. Vendo aquele grande número de requisitos de interface e usabilidade, um processo iterativo poderia sim ajudar, mas ainda sim esse vai e vem de alterações tinha grandes chances de ocorrer. Abstraindo essas exigências e olhando de outra perspectiva notamos certas similaridades que podem nos ajudar a definir um padrão, como por exemplo processo para cadastro de informações:  - usuário informa os dados; - sistema valida informações; - Usuário desenha geometria no mapa; - Sistema valida as regras topológicas; - Sistema apresenta mensagens de resultado;Ou como proceder numa alteração por exemplo. Esses procedimentos sempre nos conduzem a um padrão que é replicado às demais telas. Lembrando que me atenho ao aspecto funcional, como a mensagem é trocada entre usuário e sistema. Com relação à aparência de um site, deixo isso na mão de um designer que tem o conhecimento para definir estrutura de exibição das informações, cores, logos e etc.Unindo-se a esta idéia acredito que a maior parte da responsabilidade em definir como os aspectos funcionais devem ser elaborados é nosso(desenvolvedores), afinal somos nós que trabalhamos o ano todo com centenas de usuários, diversos de projetos e mais do que ninguém temos o conhecimento necessário para definir como a tela se comportará e qual é a melhor forma para definir uma interface que torne a experiência do usuário algo prático, rápido e que controle bem as exceções, evitando que cadastros sejam perdidos, que informações erradas sejam inseridas, retrabalhos e etc.
Os operadores do sistemas convivem com um conjunto de informações em seu dia-a-dia. Estas informações mais relevantes deve sem apresentadas em um plano principal, pois são elas que fornecerão insumo para que seu trabalho seja exercido da melhor forma.
Todo o restante das informações deve aparecer com menor importancia na tela sem que esta importancia reduza este nova informação a um pequeno painel flutuante sobre o restante das informações, afinal por mais que existam outras informações de maior importancia em segundo plano a informação atual deve ser mostrada de forma que a atenção atual fique somente nela e assim que ela perder esta importancia ela é recolhida e não mais está sobre o mapa ou uma tabela dinamica com um resumo das informações.As vezes imagino pq mostrar mais que 5 paginas… eu não teria tempo no meu trabalho para olhar cada uma delas, acho que as interfaces podiam ser mais dinamicas e um padrão sobre validações, formatos, e coisas que facilitem a vida do usuário seriam melhores tanto para a agilidade da execução do trabalho qto para redução de erros.
Afinal desenvolvemos sistemas para facilitar a vida do usuário, ele não sabe sozinho como isto pode ser feito da melhor forma, fico indignado quando fazemos coisas inferiores pq o usuário não sabe o que quer isto vai de encontro com a ética de um desenvolvedor.
Aí que fico indignado com essa definição extremamente unilateral de papeis, ou seja, definimos que um programador só faz codificar, um analista de requistos os coleta, prioriza e mantém os requisitos e se o usuário não definir o que ele quer podemos usar este documento contra ele, mas veja bem… ele nos contratou para que fizessemos o melhor e é claro que ele vai pagar com felicidade por ele, basta que ele esteja feliz com o software.
Enfim, concluindo sobre os padrões, acredito que definir uma a uma cada tela seja um trabalho muito árduo que exije grande esforço, mas se soubermos que informação exibir e os padrões que definam em que ordem devemos mostrar os dados se devemos priorizar campos requeridos, se devemos ocultar alguns dados não requeridos em grupos, como vamos formata-los. Como exibir as informações mais relevantes ao usuário e como mostrar novas janelas que contribuam para estas informações mais relevantes.Vejamos um ciclo completo:Um usuário que é responsável por coordenar a recepção de produtos deve ter um painel que mostre os produtos que necessitam de reposição nas próximas semanas e destes produtos o que já foi solicitado e se há algo chegando dentre os próximos dias. para ele selecionar algo que estava prestes a acabar avisando que é necessário solicitar estoque de reposição. para o vendedor apareceria outro painel com as informações relevantes ao trabalho dele. Contendo uma pesquisa sobre preços dos produtos frequentemente comprados, quais são os produtos que estão a ponto de chegar a reserva de estoque.Talvez estes painéis representem grande tráfego na rede e alto consumo de processamento, mas tornar o sistema algo que traga valor aos usuários é o melhor caminho.Talvez as telas que forneçam informações, tornem desnecessários preencher tantas informações para um cadastro.
Outro grande problema são as telas de cadastro, por exemplo… se eu for cadastrar uma rua, certamente eu já estarei no local em que desejo desenha-la neste ponto algumas informações não precisarão ser preenchidas pois o desenho já estará posicionado sobre algum pais, estado, cidade e bairro então pra que digitar tudo isso novamente? bom pra poupar processamento? se seu sistema não puder fazer uma busca em tabelas com no maximo 500 registros seu problema é mais grave, resolva sua infra antes de implementar o software.
Tenho quase certeza que o usuário não pedirá isso, pois isso vai onerar um custo e o pobre do usuário não vai pedir, mas se vc fizer um sistema meia boca, sinto lhe informar mas fará só um.
Enfim, para definir essas caracteristicas não acredito que seja necessário criar um protótipo de tela, uma prova conceitual com certeza, mas criar um protótipo para cada tela em algumas hora eu não vejo necessidade, talvez para determinar os padrões e facilitar a visualização pelo usuário, mas para cada tela eu não acho necessário.

Tenho visto tantas ondas de mercado e tantos xiitas que auto-explodem quando você diz algo contra a linguagem que ele acredita, que me questiono sobre o que é correto. Pra explicar o que penso, imaginemos um cenário que corriqueiramente encontramos:

– O cliente contrata uma solução em que ele necessita ter em mãos um resumo de suas finanças;

– Noutro momento ele quer planejar com mais tempo seus pagamentos e recebimentos;

– Devido a tanta informação ele precisa que um processo noturno seja executado para conciliar todos pagamentos recebidos com a contabilidade e o estoque;

Ufa… Agora gostaria de convocar um xiita para mostrar uma solução completa com o framework de sua religião… alguns em java usariam tudo, mas já vi resultados de testes que dizem que ruby e python são bem mais rápidas que java, então, esta seria a melhor solução realmente? Da mesma forma o pessoal de .net descreverá toda gama de soluções que .net dispõem, mas e se os dispositivos móveis não tiverem windows como sistema operacional? Ou se então o cliente deseja utilizar ferramentas livres.

Acho que muitas vezes esquecemos que o sucesso só virá se as necessidades do cliente forem completamente solucionadas, ficar nesta guerra nos bastidores ao meu ver nada contribuí, pois muitas vezes encaramos o cliente como um ignorante que não sabe o que quer.

É simples: O sucesso virá se o cliente estiver satisfeito, pouco me importa se isto será feito com fortran, com c, delphi ou ruby and rails. A pergunta é? Você solucionou os problemas do cliente?

]]> http://simplologia.wordpress.com/2009/08/16/com-tantas-linguagens-de-programacao-qual-escolher/feed/ 1 cldsantos http://simplologia.wordpress.com/2009/08/12/pensamentos-sobre-desenvolvimento/ http://simplologia.wordpress.com/2009/08/12/pensamentos-sobre-desenvolvimento/#comments Wed, 12 Aug 2009 03:08:09 +0000 cldsantos http://simplologia.wordpress.com/?p=5 ]]>

Frequentemente entrei no meio de projetos mal conduzidos. O que nos torna cúmplices e altamente envolvidos, ou alguma vez vc já pisou numa m**** e seu amigo do lado não sentiu o cheiro, o pior é ver que tudo foi resultado de abandono de praticas que a anos são garantia de sucesso.

Na minha experiência o projeto que teve a melhor condução, foi audacioso a ponto de retomar praticas iniciais ao projeto para que pudéssemos nos firmar em requisitos que nos serviram construir fortes alicerces, mas pecamos no contato com o cliente, ultrapassamos o prazo de entrega e não cumprimos alguns pouquíssimos requisitos, o que ao meu ver foi um sucesso.

Enfim, mais conhecimento para a carreira…

Participar de um projeto de desenvolvimento de software exige doação, envolvimento, temos o luxo de não ver este belo trabalho com os olhares monetários vendo custos, lucros e prejus como nossos superiores, ficamos com a parte apaixonante. Este envolvimento deve nos levar a tomar certas atitudes ao vê-lo saindo do caminho, que tomaríamos se víssemos um parceiro indo para o lado negro da força. É fato que muitas empresas trabalham com vários projetos em paralelo e leiloam recursos entre eles, e isto deve ser evitado ou conduzido de forma que a pessoa consiga ter o este envolvimento e trabalhe sem uma identificação com o que faz. Isto nos remete às questões de planejamento de iterações (sprints ocorrem em projetos com pessoas dedicadas a somente um projeto) e cada iteração tem seu objetivo no decorrer do desenvolvimento, seja ele uma prova de conceito arquitetural, sua implementação ou a construção efetiva. A equipe deve estar comprometida com ele, ou isso não é a sua vida (querido desenvolvedor, programador, tester, analista e etc.)?

De tudo que vi até aqui acho que a combinação de requisitos bem definidos, comprometimento com o projeto, bom planejamento faz com que as coisas funcionem bem, pois sempre vejo problemas sérios sendo justificados com os tais requisitos falhos. E pra poupar essas justificativas empacantes. O jeito é fazer as coisas do jeito certo.

Um grande problema é que por mais que as empresas façam requisitos e planejem iterações, acabam tornando iterações sinonimo de fase, achando que requisitos e casos de uso são escritos em pedra com as ordens de um ser superior (chamado cliente), ou que é impossível construir casos de uso e desenvolve-los na mesma iteração.

Ao chegarmos ao ponto em que estamos levando a sério os requisitos, entendemos o que o cliente precisa, dividimos os casos de uso entre os desenvolvedores e como num passe de mágica esperamos ver um software rápido, seguro, escalável e qualquer outro nome legal que a IBM coloca em suas propagandas saindo do outro lado. Infelizmente mágica é só entretenimento e frequentemente somos iludidos por elas. Se não elencarmos um responsável que seja um ponto de referência na equipe para bolar e tomar conta da arquitetura, ninguém o fará. Logo acreditamos que ao elencarmos esta atividade isso será algo trivial que será feito rapidinho logo após que tivermos colhidos os requisitos e elaborado os casos de uso, NÃO!!! A arquitetura deve ser bolada no principio e deve ser evoluída e mantida, enfim teremos trabalho até o fim da construção com ela. Afinal é com ela que cumpriremos muitas vezes os requisitos não-funcionais.

Testes… Trabalho Eterno Sempre feito por Todos da Equipe, Sempre!!!

É realmente assim que funciona, verifique os requisitos, os casos de uso a arquitetura candidata, os diagramas, teste o código, a funcionalidade e o software.

Logicamente tudo muito bem organizado em um cronograma que também pode ser verificado, não há problemas nisso eu garanto.

Alguns podem ser rígidos quanto ao esforço exigido nesta árdua tarefa, você poderá justificar com os conceitos que tem, mas sem dinheiro no bolso o projeto não vai pra frente, então automatize tudo que puder, e infelizmente eu não vi até hoje nenhuma ferramenta que faça isso sozinha e você terá que custumizar a sua para o seu projeto, ou seja, terá que implementar as classes para os junits, nunits, runits, a, b,  c units afora. Mas isto felizmente lhe dará o impacto de uma mudança em seu projeto, fará com que esta mesma mudança não dispare um retrabalho braçal e fará com que vc consiga justificar a implementação de algo que distingue do objetivo de implementar o que o caso de uso pede, pois os ganhos são enormes.

Pois bem das atividades principais acho que vimos todas que são realmente importantes de uma forma genérica, haverão problemas de integração, de retrabalho de testes funcionais, mas lhe garanto que se sua equipe faz tudo que foi citado os problemas serão muito menores, muito mesmo…

Nada como fazer do jeito certo para simplificar as coisas…

Uma ferramenta que efetua testes em sua aplicação web como se um usuário a estivesse usando.

Permite que vc bole um script descrevendo os passos que o teste deve seguir e descubra se o teste foi bem sucedido.
Fantástico, não precisamos mais ficar fazendo aquele trabalho de macaco adestrado, testando manualmente uma interface de cadastro… Será???
Bom, para a ferramenta funcionar vc terá que bolar um script, poutz… só mudamos a forma de trabalho de nosso bichinho. Mas e se algo pudesse gravar as minhas ações perante a interface web que estou utilizando… clique aqui, digite a usuário e senha, clique em confirmar, clique lá, clique cá, verifique se foi escrita a mensagem informando que o usuário está logado? hummm Genial!!!
Seu pedido é uma ordem… o Selenium IDE faz isso pra vc… como um gravador de macros do M$ Office. Vc instala um complemento no FireFox e pode gravar seus passos ao usar seu site…

Agora pense naquela idéia maluca que seu professor sempre dizia sobre os testes regressivos onde a qualquer mudança em seu sistema o correto seria testá-lo completamente para certificar-se que está tudo nos conformes… bom conseguiram resolver este probleminha massante…

Mas eu ainda terei que efetuar ao menos uma vez aquele trabalhinho de macaco… e se eu mudar a interface, opa… faça o teste novamente para alterar o antigo script…

Então tá… temos o Selenium Remote Control…

Pronto… agora está completo e não podemos reclamar de nada. Com o Selenium RC, podemos contruir uma aplicação que efetue os testes, ou seja, imagine que um programador muito bão (um mineirinho esperto) desenvolveu uma interface que é montada dinamicamente através de reflection, onde os ids dos campos tem o nome dos atributos das classes, utilizando reflection também é possível montar os testes dinamicamente… Vc consulta esta classe, obtém o tipo, tamanho do campo e etc. com isso podemos efetuar testes aleatórios inserindo textos e caractéres especiais em campos numéricos e ver como o site se comporta… apareceu aquela bunita telinha do tomcat… tchanammm um erro…

O Selenium Core lhe fornece toda a biblioteca para efetuar a interação com a pagina via programação…

Exemplo:

import com.thoughtworks.selenium.*;
import junit.framework.*;
public class GoogleTest extends TestCase {
    private Selenium browser;
    public void setUp() {
        browser = new DefaultSelenium("localhost", 4444, "*firefox", "http://www.google.com");
        browser.start();
    }

    public void testGoogle() {
        browser.open("http://www.google.com/webhp?hl=en");
        browser.type("q", "hello world");
        browser.click("btnG");
        browser.waitForPageToLoad("5000");
        assertEquals("hello world - Google Search", browser.getTitle());
    }

    public void tearDown() {
        browser.stop();
    }
}

O pessoal do OpenQA está de parabéns…

http://www.openqa.org/selenium/

Navegando pela net a procura de ferramentas que facilitem meu dia-a-dia como programador me deparei com uma série de blogs, sites de fabricantes e geniais inventores focados cada um em vender seu belo peixe ou demosntrar que em sua lista existem as mais novas bugigangas lançadas no mercado… ooohhh isso é muito divertido… descobrir este monte de inovações as quais exigiram boa parte de seu tempo. Mas qual o verdadeiro ganho? demonstrar para os seus que é um profissional atualizado e está na crista da onda? Resolver velhos problemas com uma nova perspectiva de uma solução?

Bom, acabei descobrindo que saber do ultimo modelo do pen drive que vem pintadinho com um personagem engraçadinho ou ver que exite uma ferramenta que tira de vc aquele suspiro de “poutz… pq não pensei nisso antes” mas na hora H deixa a desejar… não evoluem meu ambiente de trabalho, não melhoram minha produtividade, não aumentam o tempo que dedico a minha família e as tantas coisas saudáveis que por desperdício deste deixamos de lado…

Então inicio este projeto com o intuito de refletir sobre uso destas inovações relacionando aos ganhos que realmente contribuem para o enrigecimento dos pilares que dão significado as nossas vidas.

Bom…… boa viagem a todos nós…