Arquivo da categoria: Software engineering

Live Twitter Analysis and Visualization

Kanban: Do início ao fim!

quadro-kanban-710x434

Excertos (Ver link abaixo):

No final de 1940, a Toyota encontrou um novo processo de engenharia que poderia ser empregado em seus negócios. Sabe onde? Por incrível e mais improvável que possa parecer, dentro de um supermercado.

Minha mãe sempre diz: Uma imagem vale mais que mil palavras. Não é que ela está certa! Estudos científicos comprovam que o cérebro processa uma informação visual 60 mil vezes mais rápido do que em texto. Sem falar que à retina está ligada a 40% de todas as nossas fibras nervosas. Fantástico!

Um ótimo exemplo de WIP pode ser encontrado no palácio imperial do centro de Tóquio, no Japão. Lá o Kanban é utilizado como uma forma de sinalizar a necessidade de puxar mais trabalho.

Como assim? Usando Kanban em um parque? Sim, é necessário controlar o número de pessoas que estão dentro do parque, pois muitas o visitam e é preciso o mínimo de organização para que todos possam aproveitar da melhor maneira o passeio. Ao entrar no parque você recebe um cartão (kanban) e ao sair deve devolver o mesmo cartão, dessa forma se consegue saber a quantidade de pessoas que estão dentro do parque.

Kanban: Do início ao fim!

Conteúdo do artigo:

Intro

Voltando à história do Kanban (breve história)…

Kanban e desenvolvimento de software

Mas, como o Kanban funciona hoje?

– Um quadro Kanban simples

Princípios fundamentais

– Visualizar o fluxo de trabalho (workflow)

– Limitar a quantidade de trabalho em andamento (WIP)

– Gerenciar e medir o fluxo

– Tornar as políticas do processo explícitas

– Usar modelos para reconhecer oportunidades de melhoria

Classificação de itens e hierarquia

– Épicos (Epics)

– Estória de usuário (User Story)

– Tarefas (Tasks)

Evidenciando um quadro Kanban

– Buffer

– Priorização de itens

– Limite WIP

– Raias

Benefícios do Kanban

SmallBDD announcement

cucumber

SmallBDD.png

SmallBDD é um nascente framework implementado em Smalltalk inspirado no Cucumber.

Smalltalk é uma linguagem onde a expressividade de uma DSL interna dispensa a complicação associada ao desenvolvimento de DSL externas envolvendo o uso de parsers.

Para executar os cenários descritos acima o desenvolvedor implementa as definições (step definitions no jargão do Cucumber) como abaixo:

SmallBDD2SmallBDD3

O projeto está publicado no Smalltalkhub.

Nota: Estou me baseando principalmente na edição de 2012 do The Cucumber Book.

hwcuc_xlargecover

Meu retorno ao BDD (Veja outros posts meus sobre o BDD), cujo valor para equipes interagindo com usuários do negócio me parece inegável, vem também de ver algum valor para organizar o trabalho mesmo quando temos que simular os interesses de usuários abstratos, na Internet por exemplo.

O Akita escreveu um artigo interessante e crítico sobre BDD. Na época fiquei um pouco influenciado em uma espécie de  Cargo Cult. Afinal era o Akita e o DHH! Mas acho que o artigo do Akita está datado e um tanto equivocado. Para criticar ele mostra códigos da step definitions, que são ilegíveis para o negócio realmente. Mas no livro citado acima a parte em que o negócio deve participar da redação é bem mais legível e este é um dos objetivos principais: legibilidade, clareza e simplicidade.

Dentro deste meu novo convencimento resolvi implementar BDD na minha linguagem preferida.

Links relacionados:

  • Writing Maintainable Automated Acceptance Tests, Dale H. Emery
    • Test automation is software development . This principle implies that much of what we know about writing software also applies to test automation. And some of the things we know may not be apparent to people with little or no experience writing software.
    • Much of the cost of software development is maintenance—changing the software after it is written. This single fact accounts for much of the difference between successful and unsuccessful test automation efforts. I’ve talked to people in many organizations that attempted test automation only to abandon the effort within a few months. When I ask what led them to abandon test automation, the most common answer is that the tests quickly became brittle and too costly to maintain. The slightest change in the implementation of the system—for example, renaming a button—breaks swarms of tests, and fixing the tests is too time consuming.
    • But some organizations succeed with test automation. Don’t they experience maintenance costs, too? Of course they do. An important difference is that where unsuccessful organizations are surprised by the maintenance costs, successful organizations expect them. The difference between success and failure is not the maintenance costs per se, but whether the organization expects them. Successful organizations understand that test automation is software development, that it involves significant maintenance costs, and that they can and must make deliberate, vigilant effort to keep maintenance costs low.

O que fazer com monopólios e algoritmos

monopolio

Com a chegada da maturidade da Internet mundial e suas empresas, temos visto uma crescente onda de manipulações de mercado. Empresas que antes estavam sujeitas a competição no mundo real, encontraram um paraíso virtual na grande rede mundial. O que mais encontramos nesse paraíso das empresas são mercados em situação de monopólio absoluto ou mercados em situação de quase monopólio, quando apenas duas ou no máximo três empresas reinam com o mundo a seus pés. E agora, pra “piorar”, entrou no jogo do capitalismo global um atacante de peso no time das empresas: o algoritmo. E agora? O que devemos fazer?

http://meupinguim.com/que-fazer-monopolios-algoritmos/

Link relacionado:

RenoirSt – A DSL enabling programmatic cascading style sheet generation

renoirst-a-dsl-enabling-programmatic-cascading-style-sheet-generation-1-638

Related:

 

Elegant Pharo Code

1mc27f4wegs4vzkezbw-tug

Beautiful & Powerful One-liners, Expressions and Snippets

Writing computer software remains difficult and hard. Most computer code is hard to read and quite intimidating. This does not have to be the case.

Simple things should be simple, complex things should be possible — Alan Kay

Our software development environments should be designed in such a way that they make it easy to read and to write code for day to day tasks, for those problems that are solved.

Studying a list of example tasks — one-liners, expressions and snippets — is an excellent way to check out candidate programming languages. Here is a list with solutions implemented in Pharo — an immersive, live environment including a pure, object-oriented programming language focused on simplicity and immediate feedback.

Elegant Pharo Code

FUN MOOC – Programmation objet immersive en Pharo

s70kf

Programmation objet immersive en Pharo

Estamos na reta final. Na sétima semana. Quem puder corra para obter o material e não perca uma possível próxima edição.

[UPDATE]

No Pharo MOOC foi desenvolvida uma aplicação Web.

O deploy foi feito em Pharo Cloud, um web hosting dedicado a Smalltalk web-applications.

TinyBlog é bem simples, usa Seaside e Bootstrap. A persistência é feita usando MongoDB. Como o deploy foi feito numa conta free a versão que foi enviada não usa o MongoDB.

Baixe o tutorial para criar a aplicação TinyBlog se quiser conhecer os detalhes. Está em francês mas tenho a versão em inglês nos arquivos do curso (que eu guardei) se estiver interessado.

O login para a área de administração do blog é admin/password.

[UPDATE]

Os arquivos do curso podem ser vistos em Archived Course.

Attestation

PharoMOOCAtestation