Mostrar mensagens com a etiqueta Projecto. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Projecto. Mostrar todas as mensagens

24 outubro 2008

Visual Assembly (2)

Apenas um "Mockup" da janela principal de edição do Projecto PIC Visual Assembly:


Confesso que não tem sido dos projectos mais activos mas, não tem estado parado! :)

08 setembro 2008

Programação visual em Assembly?

Quem tem como hobbie programar microcontroladores gosta com certeza de passar algum tempo a "brincar" com os poucos bytes de memoria disponíveis e programar em Assembly.

Um dia deste enquanto me divertia com um PIC16F628 pensei: "e se fizer um ambiente realmente visual para programar em Assembly?"

Fiz alguns desenhos e estudos e algum tempo depois obtive o primeiro prototipo funcional do "Visual Pic Algorithm Builder":

Depois com tempo faço um resumo do projecto e dos objectivos mas para já fica um primeiro screenshot da janela de edição:

15 janeiro 2008

Runft - Migração de Dados (outra vez)

Depois de algumas correções e vou deixar isto a correr durante a noite outra vez...
Acho que se deve aguentar bem... Amanhã tenho de sair cedo e não estou numa de fazer outra noitada...

Já processou boa parte dos dados (para ai 1/3)... runft

Entretanto, enquanto servia de ama do script, voltei a preparar uma versão compilável do FGalaxy (um dos meus projetos pessoais)...

Screenshot:

08 dezembro 2007

Scrum – em poucas palavras.

Segundo a wikipédia Scrum é o nome de um método de gestão de projecto para desenvolvimento de software “agile”.

O método scrum é baseado em “Sprints”. Uma Sprint é uma tarefa ou conjunto de tarefas com um foco e objectivos claros.

Um responsável de Produto (Product Owner) compila todas as alterações planeadas para um determinado produto e estabelece prioridades para as funcionalidades a desenvolver.

Ao output do trabalho do Product Owner dá-se o nome de Product Backlog. O Product Backlog não é mais do que uma lista de “to-do” constantemente actualizada ao nível dos seus itens e respectivas prioridades.

Antes de cada Sprint é criado um Sprint Backlog com os itens de prioridade mais elevada.

Uma Scrum Team é composta por 1 utilizador e de 5 a 9 elementos responsáveis pelo desenvolvimento de software.

Durante uma primeira sessão de discussão entre a Scrum Team e o Project Owner o objectivo da Sprint é estabelecido e as funcionalidades do Backlog são subdivididas em tarefas detalhadas.

A equipa (Scrum Team) deverá ser autónoma e todos os elementos partilham da mesma responsabilidade nos resultados.

Nesta fase o papel do Scrum Master é o de ser o mentor e “coach” (treinador e professor) da equipa. Tem a responsabilidade de lidar com qualquer possível impedimento ao processo de desenvolvimento e a de trabalhar para garantir à equipa as melhores condições possíveis para a concretização do objectivo.

Cada Sprint medra o valor do produto e adiciona novas funcionalidades e melhoramentos.

Todos os dias existe obrigatoriamente uma breve reunião entre o Scrum Master e equipa. Cada elemento deverá responder (de alguma forma) a 3 perguntas:

  • o que foi feito desde a ultima reunião;
  • o que se vai fazer até à próxima reunião;
  • existe alguma coisa que esteja a impedir que o trabalho continue de acordo com o planeado;

Links:

Scrum in 5 min (pdf)
Scrum at Wikipedia

Gestão de equipas de desenvolvimento.

Um projecto poderá falhar ou derrapar devido a n circunstancias, em cada uma das suas fases existem riscos e, quanto mais complexo um projecto se torna maiores são os riscos.

A gestão de projecto tem diversas facetas e em projectos complexos estas facetas são idealmente responsabilidade de várias pessoas. Escrevo acima de tudo sobre uma das partes da gestão de um projecto.

Poder-se-á dizer que um projecto é essencialmente a sua fase de desenvolvimento. De facto, todas as outras fases servem somente (1) para garantir que o output criado pelo desenvolvimento preencha os requisitos da solução. Isto surge-nos de forma intuitiva, ao ponto de, na maior parte dos projetos que por ai anda, as fases de analise, desenho e testes sejam praticamente inexistentes.

Tendo em conta que os requisitos se encontram determinados e que o desenho da solução a desenvolver se encontre realizado, a principal preocupação durante a fase de desenvolvimento é o cumprimento dos prazos estabelecidos (2). Qualquer desvio da base line de um projecto deverá ser identificado e corrigido o mais rapidamente possível.

Todos nós sabemos que: projetos mais pequenos têm menos problemas e são mais fáceis de prever; equipas mais pequenas são mais fáceis de gerir e como tal consegue-se obter uma maior produtividade de cada elemento; projetos com uma duração grande tendem a “derrapar” muito mais do que projetos de duração mais curta.

Escrito isto e partindo destas premissas poderíamos rapidamente dizer: - subdividam-se os projetos e as equipas! - Bom, parte do problema estaria resolvido. mas... (existe sempre um “mas”)

Ao serem desenvolvidos e geridos por seres humanos os projetos têm uma tendência natural para “criarem” uma curvatura entre tenção e relaxamento (3) e em projetos mais longos, mesmo que subdivididos, existem períodos de relaxamento muito maiores e, períodos de tensão muito mais acentuados.

Para controlar o desenvolvimento e evitar que este “derrape” atrasando-se, é necessário mais do que controlo! É necessário gestão! A gestão durante a fase de desenvolvimento poder-se-á "resumir" em 6 pontos principais:

  1. minimizar gap entre tenção de relaxamento;
  2. manter o enfoque de cada elemento da equipa;
  3. garantir, aproveitar, validar e integrar a criatividade da equipa;
  4. obter dados fidignos sobre o avanço de cada tarefa;
  5. garantir a conformidade com os requisitos;
  6. depreender e actuar rapidamente sobre problemas e dificuldades encontrados no desenvolvimento;
  7. proteger a equipa de desenvolvimento de ruído, impedimentos e problemas externos;
Links: Scrum at wikipedia

(1) a palavra “somente” pode ser considerada perigosa quando utilizada neste contexto, de facto, as outras fases garantem: o âmbito; os requisitos; a conformidade dos entregáveis; do projecto e como tal, devem ser consideradas tão importantes quanto a fase de desenvolvimento

(2) Não é inteiramente verdade. Para além do controlo dos prazos é necessário, durante a fase de desenvolvimento, um controlo de conformidade.

(3) Escreverei mais sobre este assunto num outro post.