Com o advento da internet, com os serviços web, o barateamento do hardware, os sistemas tornaram-se altamente conectados, modularizados, aumentou muito a velocidade em que surgem necessidades, mudou a necessidade na eficiência de responder ao mercado, os sistemas mudaram tornando-se web, modularizados.
Algo que começou a ocorrer nos projetos é que na prática os modelos, diagramas dificilmente conferem com o que está implementado, documentação desatualizada.
As metodologias antigas foram concebidas num mundo sem internet, sem globalização.
Hoje o escopo do sistema muda rapidamente, até o prazo da entrega, o sistema já não é mais bem aquilo o que o cliente quer.
As mudanças de negócio são mais intensas, há a necessidade de maior proximidade com o cliente, respostas rápidas, e uma maior mabeabilidade, negociar entregas e não um sistema como um todo, isso tudo Scrum aborda, ele foi elaborado para mitigar ou aliviar esses e outros empecilhos ou lacunas que foram sendo encontrados nos modelos antigos.
O manifesto ágil é uma declaração de ideais utópicas a se aspirar. Quaisquer práticas prescritivas que resultem dele, como Scrum e Kanban são simplesmente tentativas práticas de se progredir em direção a esse ideal. Entretanto, devido à natureza do princípio, nenhuma dessas práticas poderão realmente alcançar o ideal. Algumas aproximam-se mais que outras, mas a agilidade absoluta não poderá nunca ser alcançada na prática.
Manifesto Ágil pode ser resumido em três questões mais amplas: Transparência, Verificação e Adaptação.
https://www.thoughtworks.com/pt/insights/blog/agile-theory-vs-practice
An agile process creates plans as needed and allows teams to self organize directly around a problem. We must trust our process to keep our project on track, but there is a paradox associated with any process: If you don't use your process it can't help you; if your process doesn't help, you won't use it.
Origins
Software development in the 1990s was shaped by two major influences: internally, object-oriented programming replaced procedural programming as the programming paradigm favored by some in the industry; externally, the rise of the Internet and the dot-com boom emphasized speed-to-market and company growth as competitive business factors. Rapidly changing requirements demanded shorter product life-cycles, and were often incompatible with traditional methods of software development.
The turning point in current software development came in the mid 1990s. Many people were re-examining the idea that software must be built like hardware. Jeff Sutherland and Ken Schwaber were formalizing a new process called SCRUM. Alistair Cockburn was working on Crystal Clear.
http://www.agile-process.org/don.html
https://www.blueprintsys.com/blog/non-functional-requirements-need-your-love-too/
Modeling
The best modeling tools are an old fashioned fountain pen and an artist's blank sketch book with pages that pull out. These simple tools let each model be unique with a language of its own. Some things will be exaggerated, others omitted. A model should express the modeler's thoughts and subjective point of view. So be creative, use a drop shadow to indicate more important objects, put a shinning star on newly created objects, try drawing little stacks to show collections. UML was created to document complexity, not expose it. Instead of the typical class hierarchy diagram try an instance diagram to find complexity. Don't let conventions stop you from communicating your thoughts rather than details.
Don't spend time getting everything just right. You certainly don't want to spend time getting all the lines straight. When modeling ask yourself a simple question: How much effort should I put into this model if it will be thrown away tomorrow? That is how you know when you are done modeling.
Sometimes the activity of modeling can be more important than the model. Agile CRC cards are an expression of that. You model together as a team. At the end the model disappears but the understanding, insight, and team collaboration remains. Designing this way is more dynamic and object oriented than static versions.
Create a model to answer specific questions, keep the answer short and concise. If you think others could learn from your model you can keep the document, but make it Agile. Saving a document is an implicit agreement to keep it up to date or destroy it.
http://www.agile-process.org/proverbs.html
http://www.agile-process.org/model.html
eXtreming Programming is an agile framework.
it is some important topics:
TDD (test driven development) - test first, develop, refatory, test again ... baby steps ...
Couple (Programming in pairs, Developing in pairs, Analysing in pairs, Testing in pairs)
Documents (It doesnt use ET, EF, but uses User Histories)
Liberacao Frequente de Pequenas Entregas
Planejamento de Releases e Planejamento de Iteracao
(As histórias de usuários são estimadas antes de serem desenvolvidas. Na iteração, o programador pega a tarefa e depois a estima).
Spikes - é um programa muito simples para explorar soluções potenciais.
Refatoração - Código Limpo.
Reunião diária em pé - (o que fiz ontem, farei hoje o que há de problemas?)
Todos são donos (Compartilhamento)
Padrão de Codificação
Com exceção do XP, que possui várias definições técnicas, Scrum e RUP são abstratos demais do desenvolvimento de software para impor uma diferença muito grande.
Extreme Programming emphasizes teamwork. Managers, customers, and developers are all equal partners in a collaborative team. Extreme Programming implements a simple, yet effective environment enabling teams to become highly productive. The team self-organizes around the problem to solve it as efficiently as possible. Extreme Programming improves a software project in five essential ways; communication, simplicity, feedback, respect, and courage. Extreme Programmers constantly communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested.
http://www.extremeprogramming.org/
Activities
XP describes 4 basic activities: coding, testing, listening, and designing.
Values
XP recognizes 5 values: communication, simplicity, feedback, courage, and respect.
Rules
XP has 5 rules: Planning, Managing, Designing, Coding, Testing.
http://www.extremeprogramming.org/values.html
http://www.extremeprogramming.org/rules.html
User stories.
frequent small releases.
Iteration planning.
iterations.
daily stand up meeting.
Simplicity.
metaphor.
CRC cards.
spike solutions.
No functionality is added early.
Refactor whenever and wherever possible.
The customer is always available.
Code the unit test first.
All production code is pair programmed.
Only one pair integrates code at a time.
Integrate often.
Set up a dedicated integration computer.
Use collective ownership.
All code must have unit tests.
When a bug is found tests are created.
Acceptance tests are run often and the score is published.
XP is set up for small groups of programmers. Between 2 and 12.
Scrum is an agile framework.
Sprints
Iterations
Scrum Master
Na minha opinião, o grande lance do SCRUM é ser iterativo e incremental, e limitar suas entregas em Sprints que variam entre uma semana (no mínimo) e quatro semanas (no máximo), focando em entregar algo de valor para o negócio num curto prazo, obter feedback do usuário e seguir assim até acabar.
The practices of Lean are quite different from the hands-on, practical tasks that programming-centric XP asks you to do in your project ("Automate everything", "Have tests", "Meet daily"). Value-stream analysis could give you some new insights and conceptual tools with which to reason about business and tasks to do.
And, using horizontal swimlanes, you can effectively segment the board into sections for planned work in the iteration and the (sadly inevitable) operations support work that interrupts even the most disciplined teams. This make it very clear what work was committed and what snuck into the sprint.
Another well-known process to have come out of the object-oriented community is the Rational Unified Process (sometimes just referred to as the Unified Process).
The original idea was that like the UML unified modeling languages the UP could unify software processes.
RUP is a very large collection of practices and is really a process framework rather than a process.
The key common aspects of RUP is that it is Use Case Driven (development is driven through user-visible features), iterative, and architecture centric (there's a priority to building a architecture early on that will last the project through).
My experience with RUP is that its problem is its infinite variability.
No RUP há uma ênfase em se elaborar um projeto detalhado do sistema como uma fase distinta do processo.
E embora se prevejam entregas parciais (chamadas "liberações") elas em geral não estão destinadas a entrar em produção (são mais para colher feedback).
É sabido que nas metodologias ágeis o escopo não é definido previamente ou por completo em uma fase qualquer. No RUP há um grande enfoque na definição do escopo na primeira fase da metodologia, que é a fase de Concepção. Apesar do RUP pregar a realimentação de informações ao longo do processo para refinar os requisitos ao longo do processo, a fase de Concepção traz um foco maior a definição do prévio do escopo, que foge das características de uma metodologia ágil.
Existem 4 fases, Concepção, Elaboração, Construção e Transição. Cada fase é composta por objetivos e por várias iterações que farão com que esse objetivo seja alcançado através de aplicações de disciplinas que correspondem a Análise, Planejamento, Modelagem, Desenvolvimento e Teste.
As metodologias ágeis tem em suas iterações todas as etapas (Análise, Planejamento, Modelagem, Desenvolvimento e Teste)
Mas, também na minha opinião, o grande lance do RUP é ser iterativo e incremental, entregar em pedaços pequenos (Iterações), focando em entregar algo de valor para o negócio num curto prazo, obter feedback do usuário e seguir assim até acabar.
BDD
ET
EF
UML
Menos documento, mais código, Product Owner falando direto para desenvolvedores. É legal? Sim, muito. Equipes auto-organizadas, com desenvolvedores que se auto-supervisionam, são maduros emocionalmente, responsáveis, conhecem muito bem de engenharia, arquitetura, construção, testes, deploy, infra etc. Seria ótimo se fosse possível. Infelizmente, em 95% das organizações, não é. Equipe auto-organizada, em escala, ainda não existiu, e ainda não existe. É pedir demais do ser humano, em seu perfil padrão, mas não é impossível que assim seja, mas não por agora.
Agile methods are focused on an adaptive nature and people-first orientation.
The Self-Adaptive Process
The Difficulty of Measurement
Managing a People Oriented Process
Programmers are Responsible Professionals
Putting People First
The Adaptive Customer
Controlling an Unpredictable Process - Iterations
The Unpredictability of Requirements
Projeto Interativo: Desenvolva seu projeto em interações, com releases freqüentes podemos colher feed-back e aplicar melhorias continuas ao nosso trabalho.
Riscos: Fazer com que o projeto seja orientado a riscos é fundamental, mitigar riscos não é uma tarefa apenas do gerente de projetos e sim da equipe toda. Apenas levantar riscos no documento de visão(Rup) não é o suficiente, é necessário criar planos de ação para os riscos e estar sempre de olho neles.
Priorização de Tarefas: 45% das funcionalidades entregues nunca são utilizadas e 19% raramente são utilizadas, logo entregar funcionalidades com valor para o cliente é fundamental. A priorização não pode partir do cliente( ou no Scrum do Product Owner) mas deve partir de todas a equipe, arquiteto, QA, desenvolvedor, gerente e cliente.
Ajuste o processo: Se você está usando: Rup, Xp, Scrum, FDD, Open Up ou algo do gênero, não esqueça de adaptar o processo a sua realidade. Não utilize cegamente as metodologias como se fosse leis, você deve adapta-las a sua realidade. Qualquer extremo é sempre ruim, sempre devemos buscar o ponto de equilíbrio.
Para que serve uma metodologia? SCRUM e RUP - Metodologias são guias, não coleiras. A que serve para um, não necessariamente servirá para outro. A versão que atende hoje, não atenderá amanhã (melhoria contínua). A customização que serviu para um, não necessariamente servirá para outro.
Quando o RUP começou a ganhar mercado fora da Rational/IBM, um erro primário de implantação de processo aconteceu em larga escala: empacotar o processo inteiro, inseri-lo na organização, trabalhar totalmente orientado a ele, e esperar o milagre.
Visão do Gerente
Frameworks de processos geralmente são iniciativa da gerência.
Isso porque gerentes em geral não conseguem ter uma visibilidade dos projetos do ponto de vista técnico e precisam de mecanismos "abstratos" de planejamento e acompanhamento.
A formalização e a burocracia são a forma de trazer visibilidade sobre o projeto para quem não está efetivamente participando do mesmo.
Processos e a hierarquia
Se imaginarmos uma hierarquia, com o presidente da empresa no topo e os desenvolvedores na base, podemos dizer que os processos ágeis funcionam de baixo para cima (bottom-up), fluindo da equipe, enquanto os processos "tradicionais" vêm de cima para baixo (top-down), partindo da gerência.
Não é raro a empresa adotar formalmente um processo como o RUP ou CMMI enquanto a equipe adota um processo scrum-like com um gerente fazendo a interface entre um mundo e outro.
Customização dos processos
Um ponto de vista interessante é que os processos ágeis começam com uma burocracia mínima e pode-se acrescentar ao processo o que mais for necessário. Por outro lado, frameworks com o RUP trazem um arsenal de papéis, atividades, artefatos e você precisa retirar os que você não vai usar.
No fim das contas, após passar por um processo de adaptação, o RUP pode tornar-se praticamente a mesma coisa que o Scrum, apenas com um ponto de partida diferente.
Entregas
Na entrega para o usuário final, é inevitável um choque proporcional à quantidade de funcionalidades entregues, pois sempre haverá um gap entre o que foi entendido e o que realmente é necessário.
Enfim, se o cliente quer optar por uma entrega total, ele deve ser consciente de que o tempo necessário para ajustes não será pequeno.
Desde a fase de Elaboração, o RUP já prevê atividades de teste e entrega. Aliás a ideia toda dessa fase é ter uma arquitetura executável para mitigar os maiores riscos do projeto cedo.
Considerações gerais
Frameworks de processos como o RUP foram concebidos como ferramentas aos gerentes. Metodologias ágeis focam na auto-organização da equipe. Em empresas, ambos acabam sendo de alguma forma necessários.
Links:
https://pt.stackoverflow.com/questions/25498/quando-usar-rup-e-quando-usar-agile