|
|
| Linha 1: |
Linha 1: |
| = Engenharia de Software é uma ciência? = | | = Projetos = |
| <br> | | <br> |
|
| |
|
| * Wikipedia:
| | == Grupo 1 == |
| ** "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.
| |
| <br> | | <br> |
| | | * Projeto GPS |
| * 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
| | ** Luciene |
| | | ** Renato |
| * O papel do profissional da prática (engenheiro de software) é construir sistemas cada vez melhores, utilizando o conhecimento disponível
| | ** Leonardo |
| | |
| * 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 | |
| <br> | | <br> |
|
| |
|
| = Engenharia de Software é desenvolvimento = | | == Grupo 2 == |
| <br> | | <br> |
|
| |
|
| * As tecnologias da disciplina são baseadas no elemento humano | | * Sistema de Academia |
| | | ** Gessmar |
| * O Software não é o mesmo o tempo todo
| | ** Telas |
| ** Existe um enorme número de variáveis que provocam diferenças
| | ** Casos de Uso |
| ** Seus efeitos precisam ser entendidos | | ** Aplicação que facilita a interação com o cliente |
| | |
| * 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) | |
| <br> | | <br> |
|
| |
|
| = Processo de Software = | | == Grupo 3 == |
| <br> | | <br> |
|
| |
|
| * Modelos ciclo de vida | | * Sistema de Lanchonete |
| * Sequencial ou Cascata (Waterfall) | | ** Júlio e Júlio |
| * Desenvolvimento iterativo e incremental | | ** Casos de Uso |
| * Evolucional ou Prototipação | | ** Prototipação |
| * V-Model | |
| * Espiral | |
| * Componentizado | |
| * Formal
| |
| * Ágil
| |
| * RAD
| |
| * Quarta geração
| |
| <br>
| |
|
| |
|
| = Modelos de Maturidade = | | == Grupo 4 == |
| <br> | | <br> |
|
| |
|
| * Capability Maturity Model Integration (CMMi) | | * Racheiros |
| * MPS-BR | | ** Thiago, João Paulo e Matheus |
| | ** Casos de Uso |
| | ** Telas |
| <br> | | <br> |
|
| |
|
| = Metodologias e Métodos = | | == Grupo 5 == |
| <br> | | <br> |
| | | * Easy RV |
| * Metodologia Estruturada
| | ** Alexandre |
| ** Análise Estruturada
| | ** Descrição 5W2H |
| ** Projeto Estruturado
| | ** Apresentação protótipo |
| ** Programação Estruturada
| |
| ** Análise Essencial
| |
| ** SADT | |
| ** DFD - Diagrama de Fluxo de Dados | |
| ** MER - Modelo de Entidades e Relacionamentos | |
| <br> | | <br> |
|
| |
|
| * Metodologia Orientada a Objetos
| | == Grupo 6 == |
| ** Orientação a Objetos
| |
| ** Rational Unified Process ( RUP )
| |
| <br> | | <br> |
| | | * Projeto |
| * Desenvolvimento ágil de software
| | ** Will |
| ** Feature Driven Development ( FDD )
| | ** Wilson |
| ** Enterprise Unified Process (EUP)
| | ** Não apresentaram |
| ** Scrum (Scrum)
| |
| ** Crystal (Crystal Clear, Crystal Orange, Crystal Orange Web)
| |
| ** Programação extrema ( XP )
| |
| <br>
| |
| | |
| * Outras Metodologias
| |
| ** Microsoft Solution Framework ( MSF )
| |
| | |
| = Modelagem =
| |
| <br>
| |
| | |
| * Análise estruturada [Gane & Searson]
| |
| * Análise Essencial [Palmer & McMenamin e Ed. Yourdon]
| |
| * UML [Grady Booch, Ivar Jacobson & Jaimes Rumbaugh]
| |
| <br>
| |
| | |
| == O que é ==
| |
| | |
| O Maré de Agilidade é um evento itinernte 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çam 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. O evento abaixo descrito, foi o realizado em Belém-PA nos dias 26,27 e 28 de novembro de 2009. | |
| | |
| == Objetivos ==
| |
| Divulgar o material coletado durante o evento para disseminar esse conhecimento.
| |
| | |
| == Características ==
| |
| O evento aborda muitos assuntos com foco em Agile. Há minicursos e palestras. A grade escolhida de minicurso e palestras foi:
| |
| 26/11 -> Gestão Ágil de Requisitos (Manoel Pimentel)
| |
| 27/11 -> eXtreme Programming (XP) na Prática (Renato Willi e Paulo Igor)
| |
| 28/11 -> 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 qto 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 se 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. 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.
| |
| == Benefícios para a Algar Telecom == A minha opinião pessoal sobre os temas acima abordados é que na prática poderemos adotar conceitos sobre todos os temas, mas em especial sobre a [[Gestão Ágil de Conhecimento]] e as [[Armadilhas do Scrum]] que tiveram um conteúdo hoje já necessário na nossa gestão de Software. Quero também frizar a importância da palestra [[Manifesto 2.0]] que tem opiniões sobre o comportamento das pessoas e do modo como cada geração se comporta diante da criação das coisas, sejam elas, pinturas, esculturas ou software.
| |
| == 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 == Pesquisadores == *Cecília Margarete Heinen
| |
| | |
| = Vídeo =
| |
| <br> | | <br> |
| * [www.youtube.com/watch?v=1lqxORnQARw Hug a developer today]
| |