Agile software development Agile software development is a set of principles for software development in which requirements and solutions evolve through collaboration between self-organizing,[1] cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change.[2] Agile itself has never defined any specific methods to achieve this, but many have grown up as a result and have been recognized as being 'Agile'. The Manifesto for Agile Software Development,[3] also known as the Agile Manifesto, was first proclaimed in 2001, after "agile methodology" was originally introduced in the late 1980s and early 1990s. The manifesto came out of the DSDM Consortium in 1994, although its roots go back to the mid 1980s at DuPont and texts by James Martin[4] and James Kerr et al.[5] History[edit] Incremental software development methods trace back to 1957.[6] In 1974, E. The Agile Manifesto[edit] Agile principles[edit]
Lean forklaret for sjuskehoveder - Kommunikationsforum Lean er et begreb du lige så godt kan forholde dig til. For det komme rogså til dig på et tidspunkt. Her er en stribe artikler og links om lean (klik på fx artikler i feltet for at få listen): Lean på kforum.dk & her er en tidligere artikel, der giver dig overblik over emnet på 10 minutter: Begrebet lean er opfundet af forskerne Jim Womack og Daniel Jones. Forbedringer på 50 % Det er 40 år siden, Toyota begyndte at arbejde med at trimme virksomheden. De fem principper i lean Lean blev i første omgang udviklet i Toyotas industriproduktion som fem grundlæggende principper. Forstå, hvad der skaber værdi for kunderne og se den værdikæde, hvormed råvaren tilføres værdi frem til, at kunden får dækket sit behov. Husmetaforen De fem principper er generelle for lean. De ni trin i leanhuset Når man skal indføre lean i sin organisation, skal man ifølge forfatterne følge de ni trin. Trin 1: Organiser opgaverne For det første er det vigtigt, at man organiserer opgaverne. Trin 2: Overtag styringen 7. 8.
Kanban This article is about the process management and improvement method. For the lean manufacturing process, see Kanban. Kanban in the context of software development can mean a visual process management system that tells what to produce, when to produce it, and how much to produce inspired by the Toyota Production System[1] and Lean manufacturing.[2] The name 'Kanban' originates from Japanese[看板], and translates roughly as "signboard" or "billboard". It was formulated by David J. Start with existing process The Kanban method does not prescribe a specific set of roles or process steps. Agree to pursue incremental, evolutionary change The organization (or team) must agree that continuous, incremental and evolutionary change is the way to make system improvements and make them stick. Respect the current process, roles, responsibilities and titles It is likely that the organization currently has some elements that work acceptably and are worth preserving. Leadership at all levels 1. 2. 3. 4.
Unified Process The Unified Software Development Process or Unified Process is a popular iterative and incremental software development process framework. The best-known and extensively documented refinement of the Unified Process is the Rational Unified Process (RUP). Other examples are OpenUP and Agile Unified Process. Profile of a typical project showing the relative sizes of the four phases of the Unified Process. Overview[edit] The Unified Process is not simply a process, but rather an extensible framework which should be customized for specific organizations or projects. The name Unified Process as opposed to Rational Unified Process is generally used to describe the generic process, including those elements which are common to most refinements. In 2012 the Disciplined Agile Delivery framework was released, a hybrid framework that adopts and extends strategies from Unified Process, Scrum, XP, and other methods. Unified Process Characteristics[edit] Iterative and Incremental[edit] Risk Focused[edit]
An ideal case (part 1 in the series including 1, 2, 3, 4) Let’s imagine an ideal scenario for software development. In this scenario, there are some users who have real needs that you can identify. Further, some of these users are paying customers who will gladly give you money if you can deliver value to them. You can express their needs as a set of criteria to be satisfied, and these criteria can be measured. Your customers bring you their business because: not only do you promise to identify what they want and build them a solution, you also promise to deliver a solution quickly. The flow of information is something like: latent demand -> characterized demand -> value-adding design -> production -> deployed solution …and your goal is to have smooth and continuous flow through this process, gently accelerating for all eternity. That is only a very high level description. As information flows through the system, we must have some representation of it: …or… what does the user want?
Scrum (development) Scrum is an iterative and incremental agile software development framework for managing product development. It defines "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal", challenges assumptions of the "traditional, sequential approach" to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines in the project. A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called "requirements churn"), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. Later, Schwaber with others founded the Scrum Alliance and created the Certified Scrum Master programs and its derivatives. Each sprint is started by a planning meeting.
Capability Maturity Model Integration Un article de Wikipédia, l'encyclopédie libre. CMMI, sigle de Capability Maturity Model + Integration, est un modèle de référence, un ensemble structuré de bonnes pratiques, destiné à appréhender, évaluer et améliorer les activités des entreprises d'ingénierie. CMMI a été développé par le Software Engineering Institute de l'université Carnegie-Mellon, initialement pour appréhender et mesurer la qualité des services rendus par les fournisseurs de logiciels informatiques du département de la Défense des États-Unis(DoD). Il est maintenant largement employé par les entreprises d'ingénierie informatique, les directeurs des systèmes informatiques et les industriels pour évaluer et améliorer leurs propres développements de produits[1]. Le modèle CMMI[modifier | modifier le code] CMMI est un cadre générique de processus qui se décline en trois modèles (appelés constellations) : Maturité[modifier | modifier le code] Historique[modifier | modifier le code] « Initial » (niveau de maturité 1)
Extreme programming Planning and feedback loops in extreme programming. Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development,[1][2][3] it advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted. Critics have noted several potential drawbacks,[5] including problems with unstable requirements, no documented compromises of user conflicts, and a lack of an overall design specification or document. History[edit] Although extreme programming itself is relatively new, many of its practices have been around for some time; the methodology, after all, takes "best practices" to extreme levels. Origins[edit] The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews.
Architecture orientée services Un article de Wikipédia, l'encyclopédie libre. Pour les articles homonymes, voir SOA. Ce terme est apparu au cours de la période 2000-2001[1] et concernait à l'origine essentiellement les problématiques d'interopérabilité syntaxique en relation avec les technologies d'informatique utilisées en entreprise. Cette conception a évolué pour désigner maintenant le sous-ensemble particulier d'architecture de médiation en fonction de la technologie disponible. Historique[modifier | modifier le code] Au cours de la décennie 1980-1990, la problématique de l'interopérabilité des systèmes d'information, particulièrement complexe lors de fusion ou de l'acquisition d'entreprises, a donné naissance au domaine de recherche de l'interopérabilité des données ; c'est à cette époque que l'on distingua l'interopérabilité syntaxique de l'interopérabilité sémantique des données. Les deux principales exigences fonctionnelles qui se sont dégagées au cours de cette période sont : La définition des WebServices
Agile Architecture: Strategies for Scaling 1. Towards Agile Architecture Architecture provides the foundation from which systems are built and an architectural model defines the vision on which your architecture is based. The scope of architecture can be that of a single application, of a family of applications, for an organization, or for an infrastructure such as the Internet that is shared by many organizations.Regardless of the scope, my experience is that you can take an agile approach to the modeling, development, and evolution of an architecture. Here are a few ideas to get you thinking: There is nothing special about architecture. 2. Figure 1. Figure 2 depicts the agile/basic lifecycle described by the Disciplined Agile Delivery (DAD) framework. Figure 2. An alternative to this light-weight approach to initial architecture modeling, is to attempt to define your architecture completely before implementation begins. 3. This question is more complex than you think. Sometimes people don't agree. 4. 5. Figure 3. Figure 4. 6.