Lean: Set-based Development

Lean é sobre comunicação: ampliada, direta, explícita, holística e ativa. Como mais uma ferramenta para ampliar o aprendizado, vou explicar o conceito de Set-Based Development: simples, mas bastante eficiente!

Imagine a situação: você quer fazer um jantar para os seus amigos! Um macarrão ao vôngole! (vulgo berbigão da lagoa para os manezinhos da ilha)

Qual a maneira mais antiga de se fazer isso? Ligando para cada uma das pessoas e avisando que o jantar será no sabado!
Mas uma questão importante para esta sua escolha é que você não está levando em consideração que seus convidados podem não estar disponíveis num sabado à noite para um jantar...

Mas como você é realmente um cara esperto, não vai logo marcando a data do jantar... afinal, você precisa saber se os seus amigos estarão disponíveis! Como você procede?
Escreva a lista de seus convidados:

- Huguinho
- Zezinho
- Pamela Anderson
- Mônica Mattos
- Jenna Jameson

Agora você precisa ligar para todos e saber quando eles estarão disponíveis.
Imaginemos a seguinte disponibilidade:

- Huguinho: Quarta, Sabado
- Zezinho: Quarta, Quinta
- Pamela Anderson: Todos os dias
- Monica Mattos: Segunda, Sexta, Sabado
- Jenna Jameson: Sexta

Bem, Set-Based Development sempre será à respeito de Restrições, não escolhas. Isto significa dizer que, à partir dos dados coletados sobre todos os convidados, pode-se tomar uma decisão mais acertada sobre quando será o jantar: sexta-feira!! Realmente a melhor opção...

E o que isso tem com desenvolvimento de software?

Contratar as moças acima fará com que os desenvolvedores trabalham mais... ou pelo menos que eles cheguem mais cedo... =)

No exemplo acima, para encontrar a solução de um problema, foi necessário coletar informações sobre as restrições que os vários domínios possuem, esperando para que uma decisão seja tomada somente no momento em que se possui o maior conhecimento sobre as várias opções.

Ao desenvolver uma funcionalidade, pode ser necessário decidir sobre um caminho. Esta abordagem supõe que se tenha mais informações sobre as possibilidades antes mesmo de escolher para onde seguir.
Significa dizer que, dados os domínios, a melhor solução pode ser encontrada definindo qual a intersseção entre eles. A figura abaixo exemplifica isso:



Quando existem várias equipes organizando o trabalho a cerca de um mesmo projeto, esta pode ser a forma mais simples de evitar desperdício de comunicação. Durante a produção de um item será possível avaliar a conformidade com as restrições dos grupos envolvidos.

Em produção de carros, é o mesmo que os engenheiros definirem a disposição do chassis do carro, e deixar que os designers façam o trabalho de produzir o carro mais lindo do mundo. Antes de tomarem decisões malucas sobre como será o carro, os designer podem conformar seus modelos com as restrições de chassis...

- Checklists podem ser úteis!

Você consegue identificar quais são as restrições para uma funcionalidade ou requisito de negócio? Restrições de usabilidade que os usuários alvo possuem?
Antes de decidir qual ação tomar, verifique as possibilidades que você possue e escolha a solução que melhor se encaixe no seu objetivo: construir software que satisfaça seu cliente

[]s

Fanf Certification Process

Saudações a todos!!

É com grande prazer que anuncio meu apoio à Fundação FanfAlliance, especializada em fornecer certificados coerentes à forma de trabalho mais comum em desenvolvimento de software: ignorância total!

Diretamente do criado da FanfAlliance:

Fanf Principles

1. Infernizar a vida dos usuário é nossa maior prioridade.
2. Código sem testes é nossa principal ferramenta.
3. POG é nossa filosofia de vida.
4. Quanto mais featues, mais próximos ficamos do Nirvana (especialmente se elas tiverem muitos bugs).

Leia a Definição completa (com a descrição das certificações!)


[]s

Tudo sobre User Stories

Kelly Waters tem escrito há muito tempo sobre User Stories, introduzindo o conceito de INVEST como uma definição clara sobre como trabalhar com esta ferramenta:

INVEST significa:

Indepent: Mesmo sendo impossível para alguns sistemas, tenha em mente que uma User Story deve ser Independente

Negotiable: Uma User Story não é um contrato. Não é uma especificação detalhada. É apenas uma introdução às funcionalidades para que a equipe possa discutir e colaborar para esclarecer os detalhes próximo ao momento de desenvolver a funcionalidade.

Valuable: Uma User Story deve ser valiosa para o cliente da solução. Deve ser escrita em linguagem de negócio. Deve ser uma funcionalidade, não uma tarefa.

Estimatable: User stories devem ser passíveis de serem estimadas. Devem prover informação suficiente para serem estimadas, sem serem muito detalhadas.

Small: Nem pequena demais, nem grande demais. User Stories devem ser do tamanho suficiente

Testable: User Stories devem ser claras o suficiente para serem testáveis.


Aproveitem a leitura...

FISL: Números

Saudações!

Nesta edição do Fisl estiveram presentes 7 mil pessoas entre expositores, palestrantes, participantes inscritos e convidados... um recorde!! Haja nerds nesse mundo....

Mais alguns recordes que conseguimos:

• 45 mil litros de café expresso


• 30 mil latas de coca-cola vendidas


• O kernel do slackware foi recompilado 635 vezes


• 25 milhões de spans, emails com putaria e correntes com piadinhas enfadonhas enviados


• 10 mil vezes a frase "que merda de wireless" foi repetida


• 35 usuários descontentes com a idéia do Debian vender os cds da distro


• Nenhum CD do debian vendido


• 780 fotos tiradas junto com o Orkut


• 1980 fotos tiradas junto com o Maddog (que mal podia se locomover)

[]s

FISL: Terceiro dia

Terceiro e último dia de evento! O cansaço eh visível na cara da maioria das pessoas, tanto que o evento custou a embalar neste sábado... com a maior parte das pessoas chegando mais tarde...

=)

Muito mais palestras hoje! e muita gente perguntando sobre Agile...

Vamos lah:

Guilherme da Globo.com apresentou uma palestra sobre Desenvolvimento Ágil em sua empresa... Bem, minhas impressões não são das melhores, mas valeu assistir.
Deve ser muito complicado apresentar durante uma sessão lotada (com inúmeras pessoas sentadas no corredor da sala), e acredito que a situação deve ter deixado o Guilherme um tanto nervoso. Nem tanto agile, nem tanto globo.com... nao deu pra saber muito bem como se trabalha na empresa do Tio Marinho (deu pra saber que, que nem nós na Audaces, eles tb separam uma parte do sprint para trabalhar em bugs ou tarefas não planejadas)... e também não deu pra saber muito sobre Agile em si... achei um pouco confusa...





Foi um momento tb para que eles divulgassem uma necessidade imensa de desenvolvedores - os tempos são de vacas gordas meu amigos! todos desejam desenvolvedores ágeis...


Dai veio a apresentação da moça do Mozilla... que bacana... os valores, a questão do apoio à comunidade...


Finalizamos o dia com uma "mesa" redonda improvisada para falar de desenvolvimento Ágil, abaixo seguem algumas fotos... Tanto eu quanto o Manuel tentamos explicar e trocar experiências sobre a utilização de práticas de Scrum e XP...






Infelizmente perdi a palestra do Papai Noel Maddog... sessão extremamente lotada, mas deu para assistir alguns trechos transmitidos via internet - me pareceu interessante.... uma pena...


Para finalizar nossa experiência em terras gaúchas: churrasco!!!!
Tinha até apresentação de dança no lugar... voltei uns 5 kilos mais experiente da churrascaria...


[escrito no onibus seguindo para Floripa]

FISL: Open FISL de Poker

O povo mandando ver no poker... jogando sem dinheiro... fracos... =)

FISL: Mozilla

Acaboo de voltar da palestra dessa senhora ai do lado, Mitchell Baker - "A" Mulher por trás da Mozilla Foundation e Mozilla Corporation. A palestra apresentou o que é isso tudo que a mozilla se tornou, e de que maneira os principais valores OpenSource são incorporados à forma de trabalho da Mozilla...

ANIMAL, a mulher praticamente me converteu a ser um colaborador da mozilla... =)
O que me chamou mais a atenção foi realmente tentar manter os projetos de desenvolvimento com decisões distribuídas completamente. A principal motivação é: Manter a internet do jeito que está hoje: livre
Segundo ela, apesar de possuirem funcionarios e receita, a maior parte das atividades e produção é feito sempre pela comunidade.


Muito bom... vou ver depois se consgo o video da palestra.

FISL: Segundo dia

Tá bom, tá bom... eu sei que estamos no terceiro dia... mas ontem nao consegui escrever nada... então tai vai o condensadão do segundo dia de evento...

Felizmente, ou não, consegui assistir algumas palestras! Cara, não gostei de muitas não...

Algumas fotos dos grupos de usuários aglomerados tentando sugar toda a energia disponível no evento... malditos notebooks sem bateria!

Lá está o grupo de usuários Slack que passou o evento formatando e configurando seus sistemas... =)






Além disso, foi interessante ver a versão paulistada do Coding Dojo... a casa estava extremamente cheia, e o desafio da vez foi o dos números romanos: dado um número romano, o método retorna a representação inteira do número: "I" = 1

Minha impressão da sessão: complicada... e isso é o problema mais comum neste tipo de dojo... Com um desafio simples, ou simples demais, facilmente as pessoas ficam cansadas com o ritmo de baby steps, o que acaba por desmotivar os demais... (experiência própria)

Talvez o coding dojo para inciantes não devesse ser tão óbvio, para não tornar a sessão maçante, já que nós, nerds, somos seres que buscam resolução de problemas... eu gosto muito do desafio do Poker, que permite ao menos uma dscussão mais focada no design da solução, nem tanto no algoritmo... será?? Foi engraçado ver o povo aplaudindo sarcásticamente cada vez que os testes passaram...
Espero poder participar de uma sessão deles quando for pra São Paulo da próxima vez...

Ao térmno do dojo, conversei com o Hugo e a Mariana a respeito disso, e a impressão deles acredito ter sido a mesma... mas ponto positivo para o mundo Agile! E vem coisa boa por aí...

Gringos e OLPC

Momento de rivalidade do evento: uma competição para criar um jogo em python para o OLPC... em um dia...

Equipes brasileiras e gringas passaram o dia programando para a plataforma... e próximo ao término do dia foi o maior alvoroço quando os argentino do grupo grupo de usuários Lanus realmente conseguiu o feito... com uma joguinho simples estilo come-come, eles apresentarão a solucao...
olha soh o tumulto que isso gerou:





O Treco funcionando






os cara são realmente bons...

Apresentacao Revista Ágil

Abaixo segue um vídeo que nós fizemos para apresentar a Revista Visão Ágil... o pessoal de Belém que fez o vídeo, da TaSafo (altos nome esse grupo!) - o Luiz e Carlos...

(eu falando sem parar estriquinado.... hahaha)

FISL: Como saber se um pinguin é macho??

Só ver se ele mija em pé!!



Chego no banheiro e encontro o Tux desse jeito... o que eu posso fazer? Bater uma foto e mandar pra internet!!

[]s

FISL: "Free" my ass!!

Nota capiciosa: Estamos num evento sobre software livre, e com alguns problemas com a rede wireless... principalmente devido à quantidade imensa de notebooks aqui...
Alguns levam mais sorte... e muitos grupos de usuáros e stands estão com Access Points para distribuição do sinal (da feira) para mais pessoas... detalhe: quase todos estão protegidos...

Meu questionamento: onde está o espírito colaborativo que permitiu que este evento acontecesse? Grupos de usuários não permitem que outras pessoas utilizem pontos de acesso a rede que eles possuem... obviamente, a rede disponível apenas para os membros dos grupos... ao invés de darmos uma ajudinha à organização do evento que estamos participando... onde está a colaboração?

lamentável...

FISL: Capitão Vinícius "nascimento" Teles

Salve salve!!

Ontem fomos eu e o Manoel assistir a duas palestrar: o Daniel Wildt e do Vinícius Teles... o que posso dizer a respeito: ANIMAL!! Os dois "dinossauros agéis" (no ótimo sentido da palavra) ainda tem muuuito que mostrar...

O Daniel tem um estilo mais informal, e completamente absorto nas práticas e valores de XP - não há como deixar de pensar que é uma pessoa que respira agilidade. A naturalidade com que ele transita entre os valores, exemplos pessoais e práticas é bastante motivador!... muito boa a apresentação.

O Manoel aproveitou para falar sobre a Revista Visão Ágil, apresentando o conceito e divulgando seu projeto... e estávamos lá para fotografar e apoiar!

Conheci então o Vinícius, da ImproveIt - pioneira no brasil em mentoring de XP... e o livro do Vinícius, infelizmente para alguns, é o único exemplar em português a falar sobre Desenvolvimento Ágil (vou começar a escrever o meu...).

A apresentação do vinícius: cara, o bicho é bom.... hahahaha
A intenção dele não foi apresentar sua idéia de forma convencional, mas instigar a ira e a reflexão através de piadas e ofensas leves (algumas nem tanto)...
Me lembrou muito o Tropa de Elite, ao informar ao presentes que "mesmo que eles assistam milhares de coisas sobre Agile, seria quase impossível que eles trabalhassem dessa forma em qualquer empresa - porque hoje a maior parte das empresa não sabe o que é desenvolvimento de software!"

Concordo plenamente com ele... apesar da abordagem que ele seguiu, a mensagem foi clara: nem nas universidades ouvimos sequer mencionar palavras como : Teste Automatizado, Código Legado, Cliente... e nos trancamos numa bolha de que acredita em um Big Design UpFront para resolver qualquer problema de software... e que trás uma triste notícias: Projetos de Software Não dão certo! (Quantos de vcs já trabalharam num projeto entregue no prazo, com um código mantível e no custo planejado????? Quantos de vocês já tiveram que trabalhar até tarde? finais de semanas?)

Uma outra teoria foi bastante bastante trabalhada: DESENVOLVIMENTO DE SOFTWARE NÃO É IGUAL ENGENHARIA!!!!

Não vou me estender muito, até porque na próxima edição da revista Visão Ágil vai haver uma matéria mais completa.... mas uma coisa boa aconteceu! Ganhei o livro do Vinícius num sorteio com os presentes!! Agora vou ter que pedir para ele autografar!! hahahaha

Abaixo seguem algumas fotos:

Daniel


Manoel Pimentel


Vinícius Teles

FISL: Comunidade

Saudações Senhores!
Bem, este primeiro dia, apesar de cansativo, foi muito proveitoso!! Conheci inúmeras pessoas bacanas, entre elas obviamente Manoel Pimentel, gente boníssima e pioneiro na Visão Ágil.
Somo eu e ele aqui, falando sobre Desenvolvimento Ágil e divulgando a revista...

Entre os destaques:

Orkut Büyükkökten



É o cara ali, com sua cara de nerd inverterado....

A arena de programação é muito show! Os ner... desenvolvedores que ficaram todo o evento resolvendo problemas de programação são o destaque da feira, enclausuádos num aquário no meio do salão da PUC

O Shopping.. quer dizer, a faculdade PUC me impressionou... cheio de lojas e restaurantes, a estrutura não está deixando nada a desejar...
=)


Como não podia faltar... em um lugar cheio de homens não podem faltar: as modelos contratadas! (tudo bem... tudo bem... elas são "quase" todas as mulheres que existem por aqui)
Abaixo a Intel mostrando qualidade "inside":



E pra finalizar por enquanto, ai está a cúpula do Netbeans neste evento: Manoel Pimentel e Greg Sporar (pessoal da cetil deve ser morrido de inveja agora.... hahahahah) - mas eles ainda não me convenceram a usar o netbeans



É isso senhores... agora a noite ainda vamos a uma apresentação do Daniel Wildt... e depois: cana!!

[]s

FISL: A Chegada

Saudações! postando diretamente do evento... depois de uma viagem extremamente cansativa, chegamo!
Impressões iniciais: extremamente organizado o evento. Super tranquilo de pegar as credenciais de expositor, e já arrumar um canto pra conversar com as pessoas.

Criei um album no PicasaWeb para armazenar : FISL Álbum

Logo postarei mais fotos... ta foda a conexão desse lugar!!! Eita internet fraca... será que eu encontro alguém que saiba mexer em linux pra consertar os servidores??


[]s

Lean: Como maximizar o feedback?

Adaptado do livro: Lean Software Development: An Agile toolkit.

Passo a passo para ampliar o feedback

1) Escolha o seu problema mais difícil e encontre uma maneira de ampliar o feedback

a. Amplie o feedback das equipes de desenvolvimento à gerencia perguntando a cada equipe ao término de uma interação as seguintes perguntas:

• A equipe possuiu todos os conhecimentos necessários para esta iteração?


• Algum recurso necessário faltou?


• Como podemos modificar nosso trabalho de forma a tornar o desenvolvimento mais rápido e melhor?


• O que está atrapalhando o caminho?

b. Aumente o feedback dos clientes e usuários para a equipe de desenvolvimento mantendo um grupo com foco no usuário final. Encontre as respostas para as perguntas:

• O quão bem esta sessão do software resolverá o problema para o qual ela foi criada?


• Como pode ser melhorado?


• Como esta última iteração afetou a sua percepção sobre as suas necessidades?


• O que você precisa para colocar este último incremento de software em produção?

c. Ampliar o feedback do produto para a equipe de desenvolvimento pode ser feito através de:

• Ter os desenvolvedores escrevendo e executando testes de código à medida que o código de produção é escrito


• Ter analistas, clientes ou testadores executando e criando testes de aceitação à medida que os desenvolvedores trabalham no código. Permita que os desenvolvedores auxiliem nestes testes com o intúito de automatizar tudo.


• Permita que desenvolvedores tenham acesso aos testes de usabilidade de cada uma das funcionalidades próximas de serem finalizadas, para que eles possam verificar como os usuários reagem à implementação

d. Amplie o feedback dentro da própria equipe através de:

• Torne os testadores em parte integrante da equipe


• Incorpore todos os envolvidos no projeto desde as primeiras fases


• Estabeleça a política de que a equipe de desenvolvimento deverá manter o produto

2) Inicie iterações com sessões de negociação entre clientes e desenvolvedores. Clientes devem indicar quais funcionalidades possuem a prioridade máxima, e os desenvolvedores devem selecionar e comprometerem-se somente com aquelas que eles acreditam realmente serem capazes de completar no período fechado da iteração

3) Insira os gráficos de progresso para seu projeto em uma área comum para que a equipe(s) possa visualizar sem problemas o que precisa ser feito e que todos possam ver para onde o projeto está convergindo

4) Se você dividir um projeto através de múltiplas equipes, faça um esforço a mais para dividir a arquitetura de maneira a permitir que elas possam trabalhar o mais independentemente possível. Encontre maneira dos times sincronizarem o próprio trabalho o maior número de vezes possível (build contínuo do sistema todo)

5) Equipes independentes devem considerar também a interface do usuário de forma independente

6) Encontre o seu problema mais complexo e faça sua equipe conseguir três soluções viáveis para resolvê-lo. Ao invés de escolher apenas uma das soluções, permita à equipe experimentar todas as três opções ao mesmo tempo.

[]s

FISL 9.0: Eu Vou!

Saudações senhores!
Bem, o título diz tudo!

Esta semana, diretamente de Porto Alegre, estarei no maior encontro sobre software de nosso país (quiçá do mundo)... correspondente direto da Revista Visão Ágil (sabia que escrever de graça ia me dar bons frutos!!! obrigado Manoel!)...

Entenda o Evento (Fórum Internacional de Software Livre):

Lean: Maximize o Feedback

Temos a tendência a categorizar e determinar comportamentos(procedimentos?) para todas as atividades que executamos. É comum que numa empresa busquemos padronizar o trabalho e criar regras para orientar o trabalho de todos.

No post anterior (e num dos posts mais lido do blog), apresentei a idéia de que, seguindo o modelo científico, para o desenvolvimento de software, o ciclo de aprendizado deve facilitar a experimentação ampliando o acúmulo de conhecimento. Feedback, nesta ótica, é o resultado de seus experimentos e será a forma mais efetiva de lidar com problemas em nossa área.

Como?

• Ao invés de permitir que erros acumulem, rode os testes no momento em que o código for produzido


• Ao invés de adicionar mais documentação ou mais detalhes ao planejamento, tente validar idéias escrevendo código


• Ao invés de garimpar mais requisitos com os usuários, mostre a eles um grupo de potenciais telas e receba sua impressões


• Ao invés de estudar mais cuidadosamente qual ferramenta utilizar, leve as três principais para sua empresa e teste!


• Ao invés de tentar descobrir como converter um sistema inteiro em um único esforço massiço, crie uma interface web para o sistema legado e evolua esta idéia

Feedback para Equipes

Talvez a principal apresentação sobre o tema. Direto do Google Chanel no youtube

Série de Posts sobre Lean:

1. Elmine o Desperdício
2. Amplifique o Aprendizado

Lean: Amplie o Aprendizado

As origens do Lean estão diretamente ligadas à indústria. Entretanto, os princípios Lean podem ser aplicados diretamente ao desenvolvimento de software.
É preciso deixar claro: Criar software não é um processo produtivo; a atividade é melhor comparada a um processo de desenvolvimento.

Mas qual a diferença?

Entenda o processo de desenvolvimento de software como uma atividade semelhante à do Chef de cozinha, preparando um novo prato. Um processo produtivo seria eu, após ver a receita no programa da Ana Maria Braga, reproduzí-la. Para um, a variação de experiências é extremamente importante para atingir os melhores resultados... para o outro (eu e a Ana Maria), a situação é diferente, variações não são toleradas, sob pena de não ter o prato criado.

O método científico

Software está inserido no grupo de atividades chamadas problem-solving. Isto quer dizer que, de antemão, toda a intenção em criar um software está ligada à resolução de um problema.

Para problemas complexos, é necessário ter o máximo de informação possível para que se possam propor uma solução apropriada. A aborgadem coerente para tal é utilizar o método científico: observe, crie uma hipótese, execute um experimento e verifique se os resultados são condizentes com sua hipótese. O ponto interessante de tal abordagem é que, caso suas hipóteses estejam sempre corretas, você não conseguirá aprender muito. Caso exista uma possibilidade de falha em suas hipóteses, a quantidade de informação adquirida em experimentar será imensamente mais rica.

Existem duas escolas bastante distintas em na área de software:

A primeira motiva um desenvolvedor a ter certeza que todas as suas soluções - design, código, testes- estejam perfeitas à primeira execução. Neste ambiente existe pouco espaço para a geração de conhecimento através da experimentação. Esta abordagem funciona melhor em problemas bem estruturados - normalmente possuem uma única solução já bem conhecida e um caminho preferido para alcançar tal solução. Por exemplo, os principais problemas apresentados em colégios.

A segunda escola afirma ser melhor possuir ciclos rápidos de experimente - teste - corrija do que garantir à primeira vista que um código está perfeito. Citando Edward Yordon:

Um pedaço de lógica em código normalmente precisa ser reescrito três ou quatro vezes para ser considerado um trabalho elegante e profissional. Então por que existe tanta resistência em refatorar código quando estamos sempre felizes em poder revisar documentos várias vezes até chegar a um resultado satisfatório?

A sugestão Ágil

Transforme a experimentação e o feedback numa constante. Permita que os desenvolvedores possam, de forma rápida e barata, tentar formas novas de aumentar sua qualidade e produtividade. Utize os resultados para aprender o máximo que puder e não tenha medo de tomar decisões erradas.

Iterações curtas permitem um feedback instantâneo dos clientes e usuários sobre a satisfação e a utilidade que seu sistema apresenta.

Retrospectivas são um momento importantíssimo do processo de desenvolvimento de software, já que é possível encontrar problemas que afetam a todos numa equipe, que dificilmente seriam percebidos.

"Learning is everything"

[]s

South Park e as Celebridades da internet

Quem são as celebridades??? Hilário!!! (vale a pena buscar no youtbute)

Celebridades da web assassinadas em South Park

[producao alta hoje]

[]s

Ação Global? Wikinomics?

Senhores... acredito que o vídeo abaixo traduz muito do que eu posso descrever sobre minha percepção do quê é este mundo colaborativo que vivemos hoje...

Imagine um número imenso de pessoas que está descontente com o ritmo apressado que nossas vidas tem tomado. Pessoas que gostariam de despertar em você, a percepção de que o tempo passa e que devemos aproveitá-lo da melhor forma possível...

Agora imagine uma ambiente em que essas pessoas pudessem trocar experiências e se auto-organizar para realizar uma manifestação de suas idéias...
Imagine que este local o suficiente preparado para que, juntos, eles pudessem propor uma mudança em seu estilo de vida...

Bem, é isso que o "grupo" do Improve Everywhere está fazendo nos EUA... e com reflexos no mundo todo!!

Desacelere





Senhores, se estas pessoas conseguem se reunir para uma ação dessas, por que nossas empresas(talvez a minha) ainda não perceberam a força das comunidades?????

Quer saber como criar e transformar sua empresa numa comunidade? Pergunte-me como!


[]s

Por que Scrum funciona?

• A natureza iterativa de desenvolvimento do Scrum(incluindo a reestruturação de prioridades entre as iterações)


• Celulas de desenvolvimento completas do Scrum (juntos todas as pessoas necessárias para realizar um trabalho)


• Pelo fato de muitas equipes utilizando Scrum tiveram a change trabalharem no mesmo ambiente físico


• Muitas equipes Scrum trabalham em um projeto por vez


• A maior parte dos relatorios chatos e pesados, além de formulários burocráticos estão sendo deixados de lado porque as equipes estão produzindo algo novo


• O Foco em definir testes de aceitação juntamente com os requisitos


• A disponibilidade de campeões(Donos do produto e entusiastas de Scrum)

Entenda a história Completa

[]s

Lean: Elimine o Desperdício

O que é Desperdício?

Desperdício(Waste) é tudo aquilo que não adiciona valor a um produto, valor este que deve ser percebido pelo usuário.

Se um componente de software não utilizado usuário é mantido no sistema, isto é disperdício. Se um ciclo de desenvolvimento de software se esforça para levantar um livro de requisitos que não é lido, isto é desperdício. Se os desenvolvedores produzem mais funcionalidades que o imediatamente necessário, isto é disperdício. Em desenvolvimento de software, transpor o trabalho entre equipes é disperdício.
Para o modelo Lean, o ideal é encontrar o que o cliente deseja, e então criar ou entregar exatamente o que ele necessita, virtualmente no exato momento da solicitação.
Qualquer coisa que entre no caminho de rapidamente satisfazer uma necessidade do cliente é considerado desperdício!

Encontrando desperdício

Por Mary Poppendieck: Eliminate Waste

Os sete desperdícios do Desenvolvimento de Software

Trabalho Particialmente Finalizado
Você deve possuir uma vaga idéia de como o sistema funcionará. Pode até ter uma noção de requisitos de negócio e condições de sucesso para uma funcionalidade. Quem sabe até mesmo algum código produzido.
Entretando, equanto este código não estiver integrado a sua base de código, tiver sido validado e aceito por seu usuário, não há como prever o seu comportamento. Funcionalidades pela metade apenas atravancam o caminho para trabalhos que poderiam ser feitos. Tornando-se facilmente obsoleto, trabalho parcionalmente concluído é pior do que trabalho nenhum... Funcionalidades e códigos parcialmente finalizados ampliam a complexidade de seu sistema, e amplificam os custos de manutenção de sua aplicação.

Processos Extras
Você já se perguntou se todo o papel utilizado é realmente necessário? Algum procedimentos para desenvolvimento de software requerem papeis para serem assinados por usuários, fornecendo rastreamento e permitindo a aprovação para uma mudança. Já verificou se o cliente realmente acha estes procedimentos valiosos? O fato de um documento ser um artefato de software não o torna valioso. Se você tem que esperar que um documento seja produzido para que você inicie o seu trabalho, reavalie a real necessidade de tal documento, e porque não, proponha mudanças. Lembre-se: procedimentos podem e devem ser questionados!

Funcionalidades a mais
Pode parecer ótimo entregar ao cliente mais funcionalidades do que ele está esperando... pegá-lo de supresa, e supreendê-lo... este é o desperdício mais śerio. Mais funcionalidades significa: Mais código para ser mantido. Mais testes para serem realizados. Mais documentos de especificação para serem criados. Mais conteúdo para gerar documentação. Mais bugs para aparecerem no sistema... enfim: jogar dinheiro no lixo... ainda mais se você pensar que 80% do total de funcionalidades de um sistema simplesmente não são utilizadas.

Troca de tarefas
Organizar pessoas em múltiplos projetos é outra forma de desperdício. Por ser uma atividade essencialmente intelectual, é necessário, toda vez que ocorrer a troca entre tarefas de projetos diferentes, que o desenvolvedores foque-se em algo completamente novo. Contexto de projeto diferentes, realidades diferentes, procedimentos muitas vezes diferentes...
O tempo que ele levará para estar realmente produtivo em cada projeto reduzirá muito! Sem contar que, normalmente, ocorrerá uma guerra de interesses entre os projetos pela atenção do desenvolvedor...
Minha vó já dizia: fazer muitas coisas ao mesmo tempo é um pretexto para não finalizar nenhuma

Espera
O maior ponto de desperdício em desenvolvimento de softwar é esperar para que algo seja produzido. Esperas em iniciar projetos, realizar testes, aguardar o levantamento de requisitos detalhistas, desenvolver uma funcionalidade são consideradas desperdício.
Atrasos distanciam seu usuário de receber um produto que satisfaça suas necessidades. Em muitos casos, atrasos são apenas a ponta do iceberg para problemas muito maiores. Em ambientes e mercados muito competitivos, atrasos e esperas podem significar milhões de investimento perdidos.
Poucos consideram custos realicionados a participação do mercado como sendo influenciada por atrasos... mas os principais líderes do mercado atualmente foram os pioneiros em seus nichos...

Movimento
Desenvolvimento de software é uma atividade que demanda muita concentração, e interrupções podem ser desastrosas no trabalho realizado. Quanto tempo um desenvolvedor leva para encontrar uma informação? Questões sobre requisitos de negócio ou informações técnicas levam quanto tempo para serem respondidas?
Documentos que transitam entre setores também são disperdícios. Quanto mais pontos um documento passar para iniciar sua implementação, maior será o ruído causado pela interpretação de informações (efeito telefone sem fio)

Defeitos
Você sabe o quanto custo a correção de um problema em fase desenvolvimento? e na integração? UM ABSURDO!!
Defeitos no sistema não agregam valor, não satisfazem o cliente, e definitivamente não são baratos. Qualquer tipo de retrabalho causado por problemas de implementação de requisitos, interpretação de necessidades e correção de documentação devem ser severamente combatidos. Neste ponto os métodos ágeis diferem muito dos modelos mais tradicionais: Construa com qualidade, não tente aferir qualidade após o produto pronto. Crie uma sistema que evite que os erros ocorram, e não que verifique se eles estão presentes em seu sistema para depois corrigí-los.



Tentar eliminar alguns dos desperdícios existentes no desenvolvimento de software é o primeiro passo para melhorar a qualidade de seu sistema... Tente!

"O" Melhor em OpenSource

A notícia de hoje foi enviada pelo amigo "anarquista" Ederson (boi):

2007 The World Bossies Awards

Traduzindo: "O" Melhor do OpenSource

Encontre respostas para estas perguntas:

• É possível que uma empresa progredir com software livre?


• Soluções em CRM, ERP, SAS, VoIP, Gestão de Conteúdo? Mesmo?


• E o que ganhamos com isso?

As categorias:

As melhores aplicações OpenSource
O principal em CRP, ERP, Portais, Gestão de Conteúdo e plataformas de colaboração

O Melhor em redes
Os ganhadores em VoIP, serviço de diretórios, streaming de mídia, analizadores de protocolo e sniffers wireless

O Melhor em middleware
Os selecionados entre sistemas operacionais, servidores de aplicação, servidores web e plataforma de virtualização


O Melhor em segurança
Principais projetos em avaliação de vunerabilidades, prevensão de intrusão, anti-virus, anti-spam, firewalls, VPNs e testes de segurança

O melhor em desenvolvimento de software
As escolhas entre IDEs corporativas, rich Internet app platforms, AJAX toolkits, sistemas de gerenciamente de regras de negócio e servidores de integração contínua.

O melhor em storage
Sistemas de arquivos, servidores de arquivos, sistemas de storage via rede e ferramentas de benchmark




Leitura de cabeceira obrigatória nos dias de hoje...

[]s

Velocity? que tal Capacity?

Desabafo muito interessante de Tim Ottinger da Object Mentor, falando sobre um dos termos mais utilizados em scrum: Velocity

Complementando o post do Tim, vou aproveitar e tecer alguns comentários...

Trocando em miúdos: velocidade é a CAPACIDADE da equipe em produzir uma parte do sistema... simples?? Nem tanto.
Notou a ênfase no termo capacidade?

Isto quer dizer que, tendo em mente o conceito de funcionalidade finalizada:

Uma equipe deve medir a velocidade desde que este valor não seja tomado como um indicador de pressão. Vou explicar melhor: imagine-se numa equipe Scrum. Até ai, tudo lindo e maravilhoso... a quantidade de trabalho que a equipe consegue suportar com saúde é 35 pontos(ou horas ideais). Qualquer mudança neste número pode significar duas coisas: um desastre para seu gerente ou uma aparente evolução da equipe.

Quando for um desastre

Somos seres humanos, e qualquer gestor não identificará com bons olhos a menor variação para menos no valor da Velocidade da equipe. Por quê??? Oras, é muito mais fácil criticar e dzer que a equipe deixou de cumprir as "metas" e está fazendo corpo mole.
Entenda, nesta situação a Velocidade está sendo encarada como uma medida de produtividade, sem que explicitamente isto seja dito. Assim, a primeira atitude seria forçar o retorno ao estado anterior, mesmo que para isso seja necessário cortar qualidade. Isto fere completamente as Regras de Ouro do Desenvolvento Ágil e removerá muitos dos benefícios da abordagem.

Aparente evolução da equipe

É bom finalizar uma Sprint com o Burndown zerado... certo? Orgulha a equipe, dá direito a pizzas, talvez uma ida mais cedo pra casa... e assim, no próximo Sprint o melhor a fazer é conseguir "aquele pouquinho a mais", pra incentivar a equipe a se esforçar mais... para no proximo sprint, se tudo correr bem, forçar um pouquinho a mais as "metas"...


Moral das duas histórias: Onde está a preocupação com o quê foi produzido?? É muito fácil se perder em números e na tentativa de controlar a produtividade da equipe através de gráficos burndown que finalizam "na mosca" e pré determinando a velocidade dos sprint.
Velocidade é uma medida de estado/capacidade e não predição. Ela apenas determina o quanto, na situação da sprint, a equipe é capaz de fazer.

Meça produtividade de outras formas: label: Métricas

Uma sugestão interessante: você consegue analizar a relação:

Funcionalidades Finalizada X Valor de Negócio X Sprint

Não??? Antes de pensar em quantos pontos uma equipe faz ou deixa de fazer, meça o quanto a produção deles está lhe trazendo de retorno... vai se surpreender...
Metas, no desenvolvimento Ágil, são as funcionalidades que a equipe conseguiu alcançar, e não a estimativa que tais atividades possuem... Meça o que realmente importa, deixa a equipe cuidar do resto




Pra finalizar:

Treinamento Scrum SC - Teamware

12 e 13 de Maio - Florianópolis

Objetivos:

Cada individuo será treinado para ser capaz de assumir as seguintes responsabilidades:

• Utilizar Scrum para gerir o trabalho como membro de uma equipe de desenvolvimento de produtos.
• Remover as barreiras entre o desenvolvimento e o cliente, para que o cliente dirija o desenvolvimento.
• Ensinar o cliente como maximizar o ROI e alcançar os seus objetivos através de Scrum.
• Melhorar continuamente a vida da equipe de desenvolvimento através da liberação da criatividade e o fortalecimento.
• Melhorar continuamente a produtividade da equipe de desenvolvimento de todas as formas possíveis.
• Melhorar continuamente as práticas de engenharia e suas ferramentas, para que todo incremento de funcionalidades seja potencialmente entregável.

Mais informações: Gestão Ágil de Projetos com Scrum SC


[]s