"The general idea behind Agile is that instead of arguing about the wording of a requirements document written three months earlier with little perspective into the current situation, it's often healthier to acknowledge that the project is going to be flexible and evolving, and put processes in place that allow it to be that way.
Barely over 200 words, that manifesto become the foundation for a movement that has changed the world of software development forever. Endless writing and speaking has explored the various ways the manifesto could be interpreted, and many specific frameworks and methodologies (such as Extreme Programming, Kanban, Lean, and Scrum) have been developed to formalize its principles. A whole 'Agile industry' has emerged, with successful companies offering tools, training, consulting, certification, and other products and services. The economic engine behind the Agile movement as a whole is massive. ...
On the surface, it seems like design and Agile should magically work together, but there are some underlying philosophical issues you have to wrestle with before figuring it out. Design is all about big–picture thinking: planning, strategy, working out all the details, thinking everything through, making it perfect, etc. (Eric Karjaluoto called it the 'masterpiece mentality.') Agile, on the other hand, is more often about doing the basics and saving details for later: iteration, minimum viable products, 'perfect is the enemy of done,' etc. Those two worlds don't blend smoothly together, at least at first. Agile developers can get frustrated with designers for over–thinking things ('Why can't they just let it go? We can get to that later.'), while the designers get discouraged by the perceived low standards of Agile developers ('Don't you want it to be good? Don't you want the user to be happy?').
In both cases, though, the problem comes from a misunderstanding of each other's perspectives (as problems often do). The designer isn't being obsessive, they're just trying to do right by the user. And the developer isn't being lazy, they're just following a process that actually gets things done with minimal navel–gazing. Both sides could learn some important lessons from each other."
(James Archer, Forty)
"Scrum is a management framework for incremental product development using one or more cross–functional, self–organizing teams of about seven people each. It provides a structure of roles, meetings, rules, and artifacts. Teams are responsible for creating and adapting their processes within this framework. Scrum uses fixed–length iterations, called Sprints, which are typically two weeks or 30 days long. Scrum teams attempt to build a potentially shippable (properly tested) product increment every iteration."
"Trello is a collaboration tool that organizes your projects into boards. In one glance, Trello tells you what's being worked on, who's working on what, and where something is in a process."
"2.1 Abstraction Levels: An abstraction for a software artifact is a succinct description that suppresses the details that are unimportant to software developer and emphasizes the information that is important. For example, the abstraction provided by high level programming language allows a programmer to construct the algorithms without having to worry about the details of hardware register allocation. Software typically consists of several layers of abstraction built on top of raw hardware; the lowest–level software abstraction is object code, or machine code. Implementation is a common terminology for the lowest level of detail in an abstraction. When abstraction is applied to computer programming, program behavior is emphasized and implementation details are suppressed. The knowledge of a software product at various levels of abstraction undoubtedly underlies operations regarding the maintenance and reuses the existing software components. It is, therefore natural that there is a steadying growing interest in reverse engineering, as a capable of extracting information and documents from a software product to present in higher levels of abstraction than that of code. The abstraction as the process of ignoring certain details in order to simplify the problem and so facilitates the specification, design and implementation of a system to proceed in step–wise fashion. In the context of software maintenance , four levels of reverse engineering abstraction are defined: implementation abstraction, structural abstraction, functional abstraction and domain abstraction.
Implementation abstraction is a lowest level of abstraction and at this level the abstraction of the knowledge of the language in which the system is written, the syntax and semantics of language and the hierarchy of system components (program or module tree) rather then data structures and algorithms is abstracted. Structural abstraction level is a further abstraction of system components (program or modules) to extract the program structures, how the components are related and control to each other. Functional abstraction level is a higher abstraction level, it usually achieve by further abstraction of components or sub–components (programs or modules or class) to reveal the relations and logic, which perform certain tasks. Domain Abstraction further abstracts the functions by replacing its algorithmic nature with concepts and specific to the application domain."
(Nadim Asif, 2003)
Nadim Asif (2003). "Reverse Engineering Methodology to Recover the Design Artifacts: A Case Study". International Conference on Software Engineering Research and Practice, SERP '03 Las Vegas, Nevada, USA. Volume 2.