cheap dedicated servers

Newton Wagner se desenvolvendo na web

3Oct/111

Colaboração entre Cliente e TI ajuda no Desenvolvimento de Software

Espírito Colaborativo

Houve o tempo em que os desenvolvedores de Software recebiam suas demandas diretamente dos clientes/usuários, e compilavam as regras do negócio para dentro de suas aplicações, sem documentação ou muita possibilidade de transferência de conhecimento.

Anos mais tarde, a falta de documentação destes softwares tornaram as empresas dependentes de seus desenvolvedores, que, caso saíssem, deixariam provavelmente um estado de caos. Assim nasceram as metodologias de software com bases na Engenharia, onde documentações, processos e muito planejamento tomou conta da "indústria", e passamos à denominação de "Fábrica de Software", em uma clara alusão ao processo produtivo de uma indústria comum (linhas de produção de software, no caso).

Isso resolveu alguns problemas, mas trouxe muitos outros, dentre eles: o fato do desenvolvimento ser uma atividade intelectual, e não pode ser medida dentro de um conceito de "Fábrica", de montagem de um veículo, por exemplo; O excesso de planejamento e burocracia, tornou o processo de desenvolvimento muito mais lento, e com o aumento da competitividade o tempo passou a ser fator crítico de sucesso para os projetos, inclusive de Software.

Foi aí que um grupo de grandes profissionais do desenvolvimento de software, como Martin Fowler (pra citar só o mais conhecido), elaborou um Manifesto para o desenvolvimento ágil de Software, em busca do equilíbrio entre estes dois mundos vividos anteriormente.

O que é bastante curioso, a primeira vista, é que o manifesto não trata apenas do desenvolvimento de software da área de TI pra dentro, mas sim de uma mudança cultural que deve atingir todos os envolvidos nestes projetos, valorizando:

Indivíduos e interação entre eles mais que processos e ferramentas;
Colaboração com o cliente mais que negociação de contratos;

Interação entre indivíduos, significa a proximidade (encontros "cara-a-cara" sempre que possíveis), disponibilidade e clareza nas informações. No desenvolvimento do Software, a área Cliente sabe quais são as suas dificuldades e necessidades, e a área de TI sabe como melhor consolidar estas necessidades e transformá-las em Software. A efetiva comunicação entre as duas áreas aumentará a qualidade do produto final.

A colaboração com o cliente é a transparência e confiança na comunicação entre ele e a área de TI, em uma via de duas mãos, comunicando sempre o progresso, informando aquilo que ainda não está claro, trocando experiências e trilhando sempre o caminho da qualidade.

Do manifesto, surgiram também alguns princípios, que também indicam como o comportamento colaborativo favorece o bom trabalho dos projetos:

  • Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.
  • Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
  • O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
  • Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

Com tudo isso, podemos concluir que de fato um Time de Desenvolvimento de Software, não é composto somente por Gerentes de Projetos, Analistas de Sistemas e Desenvolvedores. É feito também pelos Clientes, Patrocinadores e Usuários. Cada um contribuindo com as informações que possuem para o objetivo final e bem comum: Software de qualidade e Ambiente sustentável.

PS.: Não deixe de ver o Manifesto completo, e todos os 12 princípios do software ágil.

Artigos Relacionados:

23Sep/110

O papel da Análise de Requisitos e a Taquigrafia/Digitação

Taquigrafo

O termo Análise, está associado à investigação, descoberta, estudo. Em se tratando de Análise de Sistemas ou Negócio/Requisitos para a construção de sistemas, temos de nos lembrar muito bem destes significados da palavra Análise, e nos aproximar profundamente deles.

Profissionais de Análise de Requisitos, por exemplo, que vão até o cliente prontos apenas para ouvir e anotar todas as necessidades e especificações do cliente, e depois simplesmente transcrevê-las dentro de modelos de documentos, estão se distanciando do termo "Análise".

Não precisamos de Analistas pra transformar anotações em documentos. Podemos substituir o analista na fase de anotação por taquigraficos, e na fase de transcrição para os modelos, um veloz digitador vai me poupar outro caminhão de tempo.

Mas peraí! Quem garante que o cliente está no caminho certo? Vamos deixar o processo correr desta forma, pra sofrer no tempo de implementação com regras conflitantes, com alterações constantes no escopo e estrutura do projeto a cada validação do cliente/usuário?

Isso é papel do Analista. Mas ele precisa efetivamente fazer isso, é um processo de investigação, descoberta, estudo, lembra? Investigar se aquilo está fazendo sentido para o negócio; estudar as legislações envolvidas; pesquisar outros sistemas ou consultar outros analistas com experiência na área de conhecimento; questionar e validar o negócio com o cliente.

Agindo assim, realmente podemos dizer que temos (somos) um Analista, e conseguimos evitar dores de cabeças nas etapas seguintes até a entrega da solução. Ou você prefere agilizar logo um curso de taquigrafia? #troll

Artigos Relacionados:

31Jul/081

Estendendo Helpers no Kohana Framework

Os helpers no Kohana Framework não passam de classes estáticas (que não precisam ser instanciadas), e você pode precisar adicionar funcionalidades à um método ou criar suas próprias funcionalidades. Para isso, você vai precisar criar uma extensão do Helper.

O primeiro passo é ir até o diretório da sua aplicação (por padrão ele é chamado application) e criar um diretório chamado helpers, caso ele ainda não exista, claro, e criar um arquivo chamado MY_form.php. É importante ressaltar que o prefixo MY_ pode ser configurado.

No primeiro exemplo, vamos estender o form helper do framework para criar o input date. Neste caso, utilizamos o plugin datePicker para jQuery (biblioteca javascript) onde, para colocar o seletor de data (calendário) ao lado do combo, basta definir uma classe "date-pick" para o elemento HTML. Vamos ao código:

<?php defined('SYSPATH') or die('No direct script access.');
class form extends form_Core
{
	/**
	 * Creates an HTML form input date tag.
	 *
	 * @param string|array input name or an array of HTML attributes
	 * @param string       input value, when using a name
	 * @param string       a string to be attached to the end of the attributes
	 * @return string
	 */
	public static function date($data, $value = '', $extra = '')
	{
		if ( ! is_array($data))
		{
			$data = array('name' => $data);
		}
		// Insere atributo class com valor date-pick
		$data['class'] = (isset($data['class'])) ? $data['class'].' date-pick' : 'date-pick';
		return form::input($data, $value, $extra);
	}
} // End form class

Dessa forma, ao usar o código abaixo, será gerado um input text com a classe "date-pick", e o jQuery faria todo o serviço:

<?php echo form::date('dt_aniversario'); ?>

Você também não terá problemas caso passe outros atributos:

<?php echo form::date( array('name'=>'dt_aniversario', 'title'=>'Data de Aniversário') ); ?>

Na imagem abaixo segue um exemplo do funcionamento do campo data:

Artigos Relacionados:

3Apr/084

Trabalhando com Triggers no MySQL

Não ouço comentários a respeito do uso de Triggers e Stored Procedures no banco de dados MySQL. Talvez por que, quem conheça e utilize estas ferramentas, prefira trabalhar com outros bancos mais robustos como Oracle, SQL Server e há espaço até para o PostgreSQL.

Esses dias, enquanto migrava uma aplicação que uso no trabalho do framework Code Igniter para o Kohana, percebi que poderia poupar código se fizesse a implementação de algumas atividades direto no banco, com o uso de Triggers, que estão disponíveis no MySQL 5.

Minha aplicação possui a entidade Tarefa, com 4 campos de data descritos, de forma que eu consigo controlar quando eu deveria ter iniciado a atividade, e comparar com quando, realmente, isso foi realizado. Os campos são: data prevista de início; data de início realizada; data prevista de término; e data de término realizada.

O problema que eu tinha é que muitas vezes eu precisava replanejar as datas previstas, por um motivo qualquer, como um atraso em uma atividade anterior, que era de responsabilidade do cliente. Então eu simplesmente entrava no sistema e alterava as datas previstas, mas precisava guardar um histórico, armazenando as datas anteriores e o motivo deste replanejamento.

Para resolver isto via código na aplicação, teria que implementar um método "after_save" em tarefas, verificar se houve replanejamento das datas, carregar um objeto entidade Replanejamento, preenche-lo com os dados e salvá-lo. A outra opção foi criar esta trigger no banco de dados:

CREATE TRIGGER log_replanejamento AFTER UPDATE ON tarefas
  FOR EACH ROW
    BEGIN
      IF OLD.dt_inicio_previsto <> NEW.dt_inicio_previsto OR OLD.dt_fim_previsto <> NEW.dt_fim_previsto THEN
        INSERT INTO replanejamentos SET
          tarefa_id = OLD.id,
          dt_inicio_previsto = OLD.dt_inicio_previsto,
          dt_inicio_realizado = OLD.dt_inicio_realizado,
          dt_fim_previsto = OLD.dt_fim_previsto,
          dt_fim_realizado = OLD.dt_fim_realizado,
          dt_replanejamento = NOW(),
          observacao = OLD.observacao;
      END IF;
    END;

Pra quem não está acostumado com a sintaxe das Triggers, uma "tradução" do comando seria: Crie a trigger LOG_REPLANEJAMENTO após atualizações em TAREFAS. Para cada linha, se a data de inicio prevista for diferente da nova data de inicio prevista, OU se a data de fim prevista for diferente da nova data fim prevista, insira na tabela REPLANEJAMENTOS.

Está lá o meu histórico: simples, rápido e indolor. :)

Mais informações no próprio manual do MySQL.

Artigos Relacionados:

Tagged as: 4 Comments
7May/076

Tutorial do Zend Framework em Português

Uma das melhores referências do Zend Framework era o tutorial Getting Started With Zend Framework, disponibilizado no Akra's DevNotes.

O Adler percebeu a dificuldade de muitos desenvolvedores em entender o tutorial, e resolveu traduzí-lo para nossa língua. Você pode baixar a versão traduzida, em PDF, na própria página do tutorial. Ainda não tive tempo de ler, mas parabéns pelo trabalho e iniciativa do Adler.

Artigos Relacionados:

Tagged as: , 6 Comments
Lomadee, uma nova espécie na web. A maior plataforma de afiliados da América Latina.