EL064X - Aula 07

Engenharia de Software é uma ciência?

• Wikipedia:
  • "Engenharia de software é uma área do conhecimento da computação voltada para a especificação, desenvolvimento e manutenção de sistemas de software aplicando tecnologias e práticas de gerência de projetos e outras disciplinas, objetivando organização, produtividade e qualidade"
  • Os fundamentos científicos para a engenharia de software envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e garantindo suas qualidades. Além disso, a engenharia de software deve oferecer mecanismos para se planejar e gerenciar o processo de desenvolvimento de um sistema de informação Sistema computacional, pois ambos se confundem!
  • Atualmente, essas tecnologias e práticas englobam linguagens de programação, banco de dados, ferramentas, plataformas, bibliotecas, padrões, processos e a questão da Qualidade de Software.

• Pode ser considerada como pesquisa onde o papel do pesquisador é compreender a natureza dos processos, produtos e o relacionamento entre os dois no contexto do sistema

• O papel do profissional da prática (engenheiro de software) é construir sistemas cada vez melhores, utilizando o conhecimento disponível

• Mais que em outras disciplinas, estes papéis são simbióticos

• O pesquisador precisa dos laboratórios para observar e manipular as variáveis

• Elas somente existem quando os engenheiros de software constróem sistemas de software
  • O engenheiro de software precisa compreender melhor como construir sistemas melhores
  • O pesquisador pode produzir modelos para ajudar

Engenharia de Software é desenvolvimento

• As tecnologias da disciplina são baseadas no elemento humano

• O Software não é o mesmo o tempo todo
  • Existe um enorme número de variáveis que provocam diferenças
  • Seus efeitos precisam ser entendidos

• Atualmente,
  • o Conjunto de modelos insuficientes que nos permita pensar sobre a disciplina
  • Falta de conhecimento dos limites das tecnologias para certos contextos
  • Análise e experimentação insuficientes (empirismo x experimentação)

Processo de Software

Modelos ciclo de vida

• Sequencial ou Cascata (Waterfall)

• Desenvolvimento iterativo e incremental

• Evolucional ou Prototipação

• V-Model

• Espiral

• Componentizado

• Formal

• Ágil

• RAD

• Quarta geração

Modelos de Maturidade

• Capability Maturity Model Integration (CMMi)
• MPS-BR

Metodologias e Métodos

• Metodologia Estruturada
  • Análise Estruturada
  • Projeto Estruturado
  • Programação Estruturada
  • Análise Essencial
  • SADT - Structured Analysis and Design Techniques
  • DFD - Diagrama de Fluxo de Dados
  • MER - Modelo de Entidades e Relacionamentos

• Metodologia Orientada a Objetos
  • Orientação a Objetos
  • Rational Unified Process ( RUP )

• Desenvolvimento ágil de software
  • Feature Driven Development ( FDD )
  • Enterprise Unified Process (EUP)
  • Scrum (Scrum)
  • Crystal (Crystal Clear, Crystal Orange, Crystal Orange Web)
  • Programação extrema ( XP )

• Outras Metodologias
  • Microsoft Solution Framework ( MSF )

Modelagem

• Análise estruturada [Gane & Searson]
• Análise Essencial [Palmer & McMenamin e Ed. Yourdon]
• UML [Grady Booch, Ivar Jacobson & Jaimes Rumbaugh]

Maré da Agilidade

O Maré de Agilidade é um evento itinerante que viaja pelas cidades do Brasil, apresentando assuntos como:

• Extreme Programming(XP)
• Scrum
• Domain Driven Design (DDD)
• Model Driven Design (MDD)
• Test-driven Development (TDD)
• Feature-driven Development (FDD)
• Gerenciamento Ágil de Projetos (GAP)
• Lean
• e tantos outros.

• Esses assuntos começaram a fazer parte do vocabulário do desenvolvedor de software, no entanto muitas vezes sem a devida capacitação para entendimento e aplicação de tantos conceitos.
• Evento: Belém-PA
• Período: 26 a 28/11/2009.

Grade

• Gestão Ágil de Requisitos (Manoel Pimentel)
• eXtreme Programming (XP) na Prática (Renato Willi e Paulo Igor)
• Manifesto 2.0 (Alexandre Gomes)
• As Armadilhas do Scrum (Alexandre Magno)
• CASE: A Agilidade Está no Ar (Renato Willi)
• Gestão Lean para Desenvolvimento de Software (Manoel Pimentel)
• O Que Todo Agilista Deveria Saber Sobre Arquitetura (Felipe Rodrigues)
• No Boteco com Agilistas (Open Space)
• Imersão em Retrospectiva (Participe de uma Retrospectiva Real!)

Gestão Ágil de Requisitos

• Antes de iniciar o mini curso houve uma atividade interessante de colocar 2 pessoas que não se conheciam uma do lado da outra e pediu para que se entrevistassem durante 5 min para se conhecerem. Após isso, o parceiro era quem tinha que apresentar o colega.

• Nessa atividade foi constatada que as perguntas tiveram um maior direcionamente nos interesses do entrevistador do que de conhecer de fato o colega, ou seja, que fazemos perguntas direcionadas ao nosso interesse.

• Na análise de requisitos, por dependermos muito do modo como abordamos e somos abordados pelo cliente, devemos fazer reuniões e entrevistas que tenham foco no negócio que o sistema tratará.

• Houve também outra atividade, onde algumas pessoas faziam mímicas sobre um determinado evento e os demais deveriam adivinhar do que se tratava. Isso foi um exercício para perceber quanto as pessoas são diferentes ao se expressarem. Alguns tiveram dificuldade de fazer a encenação e por isso tiveram dificuldade em ser compreendidos, havendo assim, um problema de comunicação.

• Ao se falar de Agile, muitos ligam com rapidez, entregas antes do prazo, desenvolvimento sem documentação, etc. Mas o Agile não tem a proposta de ser rápido, mas sim, ser eficiente. E sim, tem documentação, a mínima (e necessária) possível. Para escolher um mascote para o Agile entre o Coelho e a Tartaruga, seria mais óbvio escolhermos o Coelho. No entanto, se lembrarmos da estorinha da corrida, a Tartaruga foi quem venceu. Por quê? Por que ela teve foco e não se distraiu com o que não era importante.

• Outra dinâmica durante o curso, foi um exercício baseado no livro do 6 Chapéus do Pensamento. O exercício colocou em ação uma forma de como controlarmos e organizarmos todos os pensamentos que nos vêm a cabeça durante uma reunião. Sessões:

1. Identificação de riscos (chapéu preto) => Cautela
2. Geração de idéias (chapéu verde) => Criatividade
3. Apuração de informações (chapéu branco) => Conhecimento
4. Exposição de emoções (chapéu vermelho) => Emotividade
5. Busca de uma visão positiva (chapéu amarelo) => Otimismo
6. Organização da própria reunião (chapéu azul) => Visão global

• Vale a pena conferir http://myfiles-express.com/search.php?search=os%20seis%20chapeus%20do%20pensamento%20edward%20de%20bono.

• Ainda falando da técnica do 6 Chapéus do Pensamento, houve um outro exercício onde se usavam os pensamentos do exercício anterior para montar um mapa mental. Essa técnica permite deixar clara as idéias anteriormente levantadas e onde elas se ligam. A sugestão é montar esse mapa mental (foi utilizado X-mind) junto com o cliente para que assim ele lembre ao máximo dos detalhes do que ele precisa do sistema. Se não for possível, valide o mapa mental após de concluído com o cliente.

• Falando em estabelecer um escopo, é sugerido que seja feito de modo Iterativo e Incremental (ver figura sobre construção de cadeira no slide 12). É como a estória de se abater uma vaca. Não abatemos para comer ela inteira, comemos ela por partes. Devemos tentar partir nossa entrega em entregas menores, para no final compor o todo. Devemos andar em baby step's.

• Outras técnicas
  • Story-writing workshops (Orientada pelos papéis)
    • Como um ___ (papel) eu posso/gostaria/devo ____ (funcao) para __________(realizar negocio).
  • Invest (Mike Crown) Independent, Negotiable, Valuable, Estimable, Small, Testable
  • Test First Visao do client (negocio)
  • TDD - Test Driven Development
  • BDD - Behavior Driven Development (comportamento)
    • Given <um valor>, when <situacao> then <acao>
  • FDD Feature(característica) Driven Development
  • Modelo A.R.O. <Ação> <Resultado> <Objeto>
  • FBS Feature BreakDown Structure
  • Scrum

• Ferramentas sugeridas

AgileDraw UML em Cores X-Mind FitNesse Junit RSPEC

Livros User Stories Applied for agile software Feature Driven Development Agile Modeling - Scott A Meta - Nobel PPT \\10.32.8.163\cresult\CDS\ItensComuns\Treinamentos\MaterialTreinamentos

eXtreme Programming (XP) na Prática

• Quando falamos em XP, Programação Extrema temos as impressões de que ele é:
  • POG melhorado
  • Não funciona com sistema grande
  • Não documenta
• Creio o que o nome 'extrema' não tenha sido muito bem escolhido, causando essa má impressão.

• O XP prega:

-Valores

  Comunicação
  Simplicidade
  FeedBack
  Respeito
  Coragem

- Princípios

  Humanidade
  Fatores econômicos
  Melhoria

- Prática

  Prog em par
  Build em 10'
  Sentar juntos

• No XP o constante acompanhamento e realização de pequenos ajustes durante o desenvolvimento faz com que ele esteja uma boa ferramenta para requisitos vagos e sistemas com mudança constante.

Uma premissa do XP é codificar testando. O TDD (Desenvolvimento dirigido por testes) é muito utilizado. Deve-se programar a passos de bebê. Avaliação de como trabalhar em equipe no XP Houve um exercício durante o mini curso, onde uma pessoa era o cliente e todos os demais da turma era a equipe. Um sistema de reserva de quartos de uma pousada foi montado. A forma de trabalho apresentada consistia em ter 2 programadores juntos codificando e reversavam a cada hr com outra dupla. Assim muitos puderam participar como desenvolvedores do projeto. O cliente fala para toda equipe o que deseja e todos ajudam a definir o BD, validações e testes em conjunto.

As dúvidas sobre o modo de apresentação do produto final é feita de forma aberta para o cliente, deixando ele falar o que quer. O objetivo é deixar a pergunta aberta sem sugerir uma solução. Depois, durante a conversa, podemos dar sugestão, no entanto, o cliente deve ser o responsável por essa decisão, pois se houver alteração de tempo, ele vai avaliar o que é melhor pra ele.

• Links
  • http://slideshare.net/seatecnologia
  • http://blog.seatecnologia.com.br
  • http://improveit.com.br
  • http://visaoagil.wordpress.com
  • http://www.visaoagil.com.br
  • dojo-pa@googlegroups.com (dojo -> movimento oriental)

• Livro
  • InfoQueue/BR - Scrum e XP direto das trincheiras

PPT \\10.32.8.163\cresult\CDS\ItensComuns\Treinamentos\MaterialTreinamentos

Palestras

Manifesto 2.0

• Constatação: na história, a cada novo modo de fazer uma escultura, houveram vários estilos e cada um contradiz o anterior. E isso tbm vai acontecer no desenvolvimento de software.
• É mais barato para empresa gerenciar a oscilação de humor do funcionário do que a rotatividade.
• Aptitude 2.0 -> temos que desinstalar pacotes internos nossos, de cada integrante da equipe e instalar um pacote mais atualizado. Assim teremos mais atitude para mudar no projeto. Isso pq a mudança sempre será constante.
• Não se querem mais especialistas, querem especialistas generalistas. Se vc só tem um martelo como ferramenta, todos os parafusos são vistos como pregos!
• A inflação dos títulos estão denegrindo os nossos CVs. A cada ano temos que ter mais títulos e cada vez valem menos. Não q não tenham o seu valor, mas a cada ano teremos mais títulos, onde o mínimo exigido pelo mercado vai ficar cada vez maior.
• Como o título não mede o papel de desempenho do funcionário, o q vai ser valorizar no CV daqui pra frente, vão ser os blogs, os fóruns, os projetos anteriores que o profissional participou. O qto a opinião e a interação com a comunidade vai ser cada vez mais valorizado.
• Profissionais 2.0 se preocupa com a solução do projeto e não com a satisfaçao pessoal. Ex de profissional 1.0: qdo um proj acaba tendo frameworks não solicitados e q não agregam valor no resultado da solução, só por prazer do profissional utilizar os frameworks que quer, isso não é atitude com foco na solução.
• O foco no desenvolvimento de software 2.0
• Em time que ganha se mexe SIM! Se vc não tirar a equipe da rotina, não mudar a sala, não mudar de linguagem, enfim, não fazer mudanças, vc não ajuda no amadurecendo na equipe, que é o que gera a satisfação e logo a motivação da equipe.
• Devemos abolir a Síndrome de Nostradamus
• Mas vale um cliente 100% satisfeito com uma entrega parcial do que um cliente parcialmente satisfeito com uma entrega 100%
• Convenção -> Rail e struts 2 -> atendem as necessidades da maioria e as exceções não são tão importantes
• Discussão -> participar de todos e não ditar regras

• Links
  • http://www.slideshare.net/seatecnologia/manifesto-20
  • http://www.slideshare.net/alegomes/
  • http://s3.amazonaws.com/ppt-download/computacaoinvisivel-090623132044-phpapp02.key?

As Armadilhas do Scrum

• Scrum é como sogra, vive jogando na sua cara o que fez ou não fez de errado.

Documentar é preciso, mas somente o essencial. No momento do proj que se decide deixar a documentação para o final, neste momento vc está desvalorizando a documentação. Devemos criar novos hábitos. Cuidado com receitas de sucesso.

• Papéis ->
  • Ex Scrum master não é só um título, mas uma mudança de comportamento. O ScrumMaster é responsável pelo funcionamento do Scrum. Não é o gerente do projeto. O PO deve ser bem escolhido, pois ele vai dar direção do que foco da solução a cada sprint.
• Devemos continuar sendo -> multi-tarefa, multi-projeto, multi-tudo... mas tbm temos ser multi-disciplinar
• Elaboração do Product Backlog -> o scrum master não é um gerente de projeto. Os backlogs devem ser definidos por todos.
• Pocker -> serve não para medir o valor de uma atividade, mas o qto a pontuação de cada integrante influencia na pontuação do outro. Para cruzar as opiniões e avaliar as diferenças
• Low-tech -> post-it, papéis de padeiro, etc. Utilize de uma forma útil, mas não seja refém dos post-it. É preciso ter organização, claro, mas não é necessário perder muito tempo com isso. Não interfere na solução final.
• Engenharia de softw -> vc precisa, mas não é no Scrum que vc vai tê-las.
• Reuniões diárias -> não é cofee break, não é bate-papo, não é 'conversa sobre relação', não é julgamento. Deve ser encarado como um micro gerenciamento.
• Potencialmente entregável -> visualizar o que pode ser entregável
• Perda de ritmo -> 1o. sprint 1 semana. 2o. sprint 3 semanas. 3o. sprint 4 semanas... isso não faz a equipe saber o seu ritmo
• Cancelamento de sprints? q nada -> cancelar sprint é não ver isso como aprendizado.

O valor da 1a. sprint -> comece com um sprint bem elaborado para servir de exemplo para os outros sprints

• Escopo fechado? -> é lenda! Não devemos pensar em escopo imutáveis, devemos pensar q sempre haverá alterações, pq tudo evolui.
• Gordurinha-> security buffer

Os problemas continuam mesmo usando o Scrum. A intenção do Scrum, antecipar os problemas para que assim possam ser resolvidos a tempo. Por isso, não se anula a idéia de trabalhar no fds, a noite, etc. Ou seja, gera stress.

• 3 práticas:
  • pergunte ao time
  • entregue
  • inspect/adapt

• Links
  • http://amagno.blogspot.com/
  • http://blog.adaptworks.com.br/
  • http://www.adaptwork.com.br

CASE - A Agilidade está no ar

Mostragem de projetos na aeronáutica fazendo uma retrospectiva falando de:

• choque de cultura
• q nao se poderia colocar post-it na parede
• forma de trabalho
• respeito a hierarquia
• foi feito o uso de 'mantras'. Ex: no quadro KANBAN era escrito algumas frases como "Eu vou documentar o código"

• Links
  • http://www.slideshare.net/seatecnologia/agilidade-no-ar-mar-de-agilidade-salvador-bahia

Gestão Lean

• Lean -> Realizar mais o q importa eliminando o q não importa. Simplicidade
• The 5 whys -> perguntar sempre
• heijunka -> nivelamento da producao. Evitar multitarefa (figura de um cirurgiao para varios pacientes)
• hansei -> busca da melhoria continua. Retrospectiva
• Kaizen -> Mudançao de atitude

pdca (plan do check action) ???

• Poka-yoke -> Automação de testes (Dentro da TPS (Toyota Production System), Poka-Yoke é um dispositivo físico de controle que é acionado automaticamente quando há algum erro ou defeito no processo de produção, sendo que esse acionamento é feito normalmente por duas motivações: para controle e para advertencia)
• Andon -> Impedimentos
• KanBan -> comunicação, ritmo, entregas. O KanBan trabalha com a information irradiada e não refrigerada. Por isso o quadro, por isso os post-it coloridos. Para a inf estar aos olhos, irradiada na sala onde a equipe 'mexe o doce'. Já existem KanBan eletrônicos.
• Fábula dos porcos cansados -> aaantigamente os porcos moravam na floresta e para comer os porcos, incediavam a floresta para comer os porcos e para isso se movimentava uma grande equipe para executar a atividade. Qdo alguém deu a idéia de caçar os porcos e depois

• Links
  • http://www.visaoagil.com.br

=== O que todo agilista deveria saber sobre arquitetura === Para aprofundar:

• DDD
• TDD (não é só jUnit)
• Dependency Injection
• REST
• Domain Specific Language
• eXtreme Programming

Links twitter.com/felipero felipero@gmail.com http://www.slideshare.net/rponte/entendendo-domaindriven-design

Boteco

• Focar nos princípios e não nas metodologias. Adaptar as ferramentas a realidade da sua empresa.

Não devemos usar Agile, devemos entender seus princípios e adotar o que for bom e o que funciona para a nossa empresa. Agile X RUP:

• A falha do RUP pode ter sido pela forma como foi vendido. Como uma ferramenta que ia resolver todos os problemas. E outra possível falha é que o entendimento geral seria de executar todos os processos do RUP.
• O Agile está nascendo como um modo de trabalhar sem anular as atividades que já existem do cliente, mas na maneira como a equipe se comporta, se comunica. Para adotar o Agile veja onde 'tá doendo mais'. Dessa forma vc começa a adotar aos poucos a nova forma de trabalho e utilizando como uma solução de verdade.

Material e outros links

• \\10.32.8.163\cresult\CDS\ItensComuns\Treinamentos\MaterialTreinamentos
• http://www.infoq.com/br
• http://www.visaoagil.com/
• http://www.maredeagilidade.com.br/
• http://manoelpimentel.blogspot.com/
• http://www.slideshare.net/alegomes/
• http://www.slideshare.net/seatecnologia/
• http://www.slideshare.net/rponte/
• http://maredeagilidade.com.br/eventos_passados/bahia/03-2009/
• http://tasafo.wordpress.com/2009/12/13/aconteceu-o-mare/
• Movimento de reformulação da eng de software: http://www.semat.org/bin/view

Vídeo

• [www.youtube.com/watch?v=1lqxORnQARw Hug a developer today]