SILVA, Francisco Eronildo da [1]
PINTO, Aurílio Guimarães [2]
FREITAS, Caio Guimarães [3]
ALMEIDA, Cristiany Caliri de [4]
RIBEIRO, Dallas dos Santos [5]
LEITE, Francisco Canindé da Silva [6]
OLIVIERA, Geveson de Souza [7]
MORAIS, Gilvanete Melo de [8]
PERES, Paulo Júnior de Jesus [9]
SILVA, Francisco Eronildo da; et.al. Anwendbarkeit der agilen Methoden in der Softwareentwicklung – Scrum als Referenz. Multidisziplinäre Kern Fachzeitschrift des Wissens. 07-Edition. 02 Jahr, Vol. 03. PP-05-16 Oktober 2017. ISSN: 0959-2448
Zusammenfassung
Ziel dieser Studie ist es, die Geschwindigkeit zu analysieren, die agilen Methoden den Prozess der Softwareentwicklung geben, zeigt, wie die Unternehmen als eine Möglichkeit, Zeit und Mühe in der Softwareentwicklung, reduzieren diese Methoden verwenden als Referenz der SCRUM-Methodik. Agile Methodik die Prämisse, auf der die Ergebnisse schnell erreicht werden sollte, ohne Kompromisse bei der Qualität des Endproduktes (Software), gehört auch entsprechend die SCRUM eine Methodik, die darauf abzielt, die Planung von Software-Projekten, deren Prämisse ist brechen Sie das Produkt in kleinere Stücke und so liefern Sie die Funktionalität ohne Client warten zu lang, um sie anzuzeigen. Unter den Autoren der Verfassung dieser Arbeit gesucht highlights konzeptionelle Aragon Fernandes (2014), Somerville (2007), Roger Pressman (2011), Kim Pries (2010) und Ken Schwaber (2014). Die wichtigsten Schlussfolgerungen sind, dass der Einsatz von agilen Methoden schnelle Softwareentwicklung geben, zeigen mehr Effizienz, Dynamik und bietet Vorteile für Unternehmen, die die Methodik eigen diese Fakten in dieser Arbeit gezeigt.
Schlagworte: Agile, Scrum, Steuerung, Software-Engineering.
1. Einführung
Der agile fing an Betonung auf die 80 zu haben. Die Website DEVMEDIA, sagt: "agile Methoden gibt es schon seit den 80 Jahren aber einige Informationen durchlaufen Verzerrung, die es am Anfang schwierig machte den Einsatz von Methoden. Daher Entwickler sind gekommen, um die agile Methodik als etwas, das zu verstehen, das heißt, können wir ohne Dokumentation, kein Standard entwickeln und nachlässig. Dies gilt nicht, die agilen Methoden zum Projekt Erfolg bringen können, und sind in der Industrie verwendet." Diese Arbeit zeigt, dass die renommierte Autoren-basierte agile töten der Organisation und der nötigen Sorgfalt, dass das Softwareprojekt müssen effizient und effektiv sein, und jeden Tag Sie die Software-Entwicklung erhalten-in der Industrie verwendet wird Markt, und Behörden, die ausgelagerte Fabriken zu entwickeln, ihre Systeme zu mieten.
Diese Studie beschränkt sich um agile Vorteile bringt der Software-Entwicklung zu zeigen. Als Beispiel haben Sie den Modus Operandi der CTIS, Software-Unternehmen, die in den heimischen Markt und die Annahme der gemeinsamen Softwareentwicklungsmethodik betreibt, aber das ist abhängig von des Clients, die Entscheidung für die agile Methodik.
Die Oberaufsicht der Manaus Free Trade Zone-SUFRAMA, die mit ihren Reizen, angeheuert, den Dienst der CTIS und entschied sich für den Umzug nach agilen Methoden.
SUFRAMA ist eine Bundesbehörde, die verantwortlich für die Verwaltung von steuerlichen Anreizen. Die meisten ihrer Systeme sind kritisch und arbeiten mit Einschränkungen, so bieten die Software Werkskundendienst mit agilen Methoden arbeiten. Die Möglichkeit für Agile Methoden in der Vernunft, schnelle Lieferung und Qualität weil die traditionellen Engessava die Prozessmethodologie.
Die agile Methode verzichtet auf einen Stapel Papier, konzentriert sich auf die Qualität des Produkts, denn was für den Kunden zählt die Software richtig funktioniert.
Ist dies nicht in die Details der Änderung der Methodik von SUFRAMA gehen, und ja, zeigen, dass verschiedene Branchen und Behörden, entscheiden sich für Ihre Software Entwicklung Modellwechsel für Agile Methodik.
Trotz des Seins eine Option für die Softwareentwicklung, möglicherweise agile Methodik, bietet verschiedene Vorteile für die Entwicklung sicherlich nicht für alle Projekte geeignet. Zum besseren Verständnis des Themas, sollten Sie etwas über die Geschichte der agilen Entwicklung überprüfen.
Das allgemeine Ziel dieser Arbeit ist eine systematische Überprüfung der agile Methodik zu tun. Der SCRUM-Methode wird das Objekt dieser Studie, wo sie werden aufgeführt, die negative und positive.
Diese Forschung ist durch die Notwendigkeit gerechtfertigt, die die Software-Industrie hat Lieferungen von Produkten mit der geringst möglichen Zeit für ihre Kunden durchführen, ohne die Augen von der Qualität, Wirtschaftlichkeit und Zufriedenheit.
Die Methodik der Studie ist die beschreibende und erklärende Forschung, als Sammlung der bibliographischen Daten.
2. Entwicklung
Diese Studie beginnt mit der Überprüfung des Konzepts der Software, die ursprünglich, im Jahr 1968, auf einer Konferenz organisiert vorgeschlagen wurde, was damals hieß, "Software-Krise" zu diskutieren. Die Software-Krise führte indirekt zur Einführung eines neuen Computer Hardware basierend auf integrierten Schaltungen. Die Anwendung von integrierten Schaltungen von Computeranwendungen, machte als nicht durchführbar, praktikable Vorschläge. Die daraus resultierende Software war größer und komplexer als bisherige Systemsoftware (SOMMERVILLE, 2007).
Software-Engineering ist ein Zweig der Technik, deren Fokus liegt innerhalb der angemessenen Kosten qualitativ hochwertige Software-Systeme zu entwickeln. Software-Engineering ist eine mehrschichtige Technologie mit Werkzeugen, Methoden, Verfahren und Qualitätsorientierung. (SOMERVILLE, 2007). Jeder technischer Ansatz (einschließlich Software) muss in eine organisatorische Engagement für Qualität geerdet sein.
Total Qualitätsmanagements sechs Sigma1 (GYGI; DECARLO; WILLIAMS, 2008) und ähnliche Philosophien sie fördern eine Kultur der kontinuierlichen Verbesserungsprozessen, und es ist diese Kultur, die schließlich zur Entwicklung der zunehmend wirksame Ansätze in der Softwareentwicklung führt. Die Eckpfeiler, der das Software-Engineering unterstützt wird der Fokus auf Qualität (PRESSMAN, 2011).
In Bezug auf die Geschichte der agilen Entwicklung dasselbe begann im Jahr 2001 mit der "Manifesto for Agile Software Development", die von Kent Beck, US-amerikanischer Software-Ingenieur, Schöpfer des Extreme Programming und Test-Driven, unterzeichnet wurde und sechzehn bekannteren Entwickler. Details zu dieser Tatsache können an die Adresse https://www.agilealliance.org/agile101/the-agile-manifesto/ überprüft werden.
Das Manifest betont Individuen und Interaktionen über Prozesse und Werkzeuge; die Software läuft mehr als eine komplette Dokumentation, Zusammenarbeit mit dem Kunden statt Verhandlungen von Verträgen und Antworten im Laufe der folgenden Plan ändern.
Nicht die Bedeutung der Dokumentation oder Prozesse zum mitnehmen, und in keiner Weise beziehen sich die Unwirksamkeit der Werkzeuge, bedeutet jedoch, dass die Lieferung der Software mehr geschätzt, als Pressman zu erklären ist:
"Die agile Softwareentwicklung vereint Philosophie mit einer Reihe von Prinzipien der Entwicklung. Die Philosophie setzt sich für die Zufriedenheit unserer Kunden und die Lieferung der vorherigen inkrementellen; kleines Projekt-teams und hoch motiviert; informelle Verfahren; minimale Software-Engineering-Artefakte und vor allem Einfachheit in der Gesamtentwicklung. Die Prinzipien der Entwicklung priorisieren Lieferung über Analyse und design (obwohl diese Aktivitäten nicht davon abgehalten werden); auch die aktive und kontinuierliche Kommunikation zwischen Entwicklern und Kunden priorisieren ". (Pressman, 2011)
Ein Projekt umfasst Menschen und Veränderungen, vor allem wenn es um Lieferungen. Auf diese Weise beteiligt die agilen Methoden arbeiten mit hoch motivierten Teams, weil sie direkt mit dem Prozess verbunden sind jeden Teil davon, das Gefühl der Verantwortung auf sich den Erfolg der Arbeit und wissen, dass Sie die Möglichkeit haben, die Änderungen während zu unterstützen den gesamten Prozess der Entwicklung.
Agile Entwicklung, können nicht Sie erstellen einen Plan komplett mit alles, die wir durchführen sollte, um dann mit der Entwicklung beginnen, ohne Kontakt mit dem Kunden stattdessen entwickelt inkrementell, d.h. das Produkt erfolgt schrittweise und konsequent auf diese Weise geliefert notwendigen Änderungen vom Client angeforderten oder jederzeit während der Entwicklung von Projektmitgliedern, gesehen nicht vollen Schaden führt und die Änderung ohne größere Schäden durchgeführt werden kann, denn das Projekt in der Entwicklung ist und noch nicht abgeschlossen.
Die ersten Schritten des Systems können eine hohe Priorität-Funktion bieten, so dass Kunden bald für Ihre Systementwicklung bekommen können. Kunden können sehen die Anforderungen in der Praxis und geben Änderungen in späteren Versionen des Systems einbezogen werden.
Auf diese Weise kann der Client machen Verwendung von System-Ressourcen schneller. Was würde Monate dauern, bis in Wochen geliefert werden und kann Fehler zu überprüfen und geben neue Änderungen oder Verbesserungen, nicht brauchen, um bis zum Ende der Entwicklung, die Probleme zu sehen bekommen.
Diese Methode bietet auch eine bessere Kenntnis des Systems an das Team, da es das Geschäft versteht zu entwickeln, so dass es, mit größerer Geschwindigkeit und Genauigkeit, und im Falle von Fehlern, das Team verliert weniger Zeit für die Analyse und den Fehler beheben kann schnell.
Nach Aguinaldo Aragon Fernandes (2014) war zunächst die Scrum mit scharf bei der Bereitstellung von Software-Entwicklungsprojekten in einem komplexen Umfeld konzipiert. Jedoch hat es zunehmend in Produktentwicklungsprojekten von anderen Naturen angewendet wurden ".
Aragon heißt es auch:
"Die Scrum besteht aus iterative und inkrementelle Verfahren zum Management komplexer Projekte, deren Ziel ist es, schnelleren Lieferung zu gewährleisten und Einhaltung der Kundenanforderungen, die Zusammenarbeit zwischen Teammitgliedern und die Produktivität der einzelnen Teilnehmer zu maximieren. Ist eine der Methoden der sogenannten "agile" weiter verbreitet in der It-Markt (Aragon Fernandes 2014).
Agile Methoden können in Auflösungen von komplexen Problemen angewendet werden, wie z. B. Softwareentwicklung Schwaber informiert:
"Komplexes Projekt Situationen auftreten, wenn die Komplexität der Mittelstufen Tätigkeiten ein definiertes Prozesses kontrolliert nicht zulässt, können Sie eine Schleife Produkte in akzeptables Maß an Qualität erzeugen. Die Komplexität eines Projekts ist direkt proportional zur Komplexität der Anforderungen der Kunden und die Technologie beteiligt, Ale, die Merkmale der einzelnen Teammitglieder, unter Berücksichtigung der Vielfalt der Fähigkeiten, Kenntnisse, Einstellungen weitgehend abhängig zu sein etc., die in einer Gruppe von Menschen gefunden werden kann ". Schwaber (2004)
In Situationen wie dieser empfiehlt Schwaber empirischen Prozess Bedienkonzept, das Mechanismen wie Selbstorganisation und Dringlichkeit, mit den folgenden Säulen verwendet:
"Sichtbarkeit: alle Aspekte, die Einfluss auf die gewünschten Ergebnisse für Steuerungsprozesse sichtbar sein sollte.
Inspektion: die verschiedenen Aspekte des Prozesses sollten regelmäßige Kontrollen durchlaufen, um inakzeptable Abweichungen zu erkennen.
Anpassung: der Prozess oder die Zwischenprodukte müssen nach Inspektion, zukünftige Abweichungen schwerere, Case zu minimieren, Eigenschaften und Ergebnisse außerhalb der zulässigen Grenzwerte sind und die Akzeptanz des Endproduktes gefährden, angepasst werden. Schwaber (2004)
Die Scrum gliedert sich in eine Reihe von Praktiken, die unter der Leitung von Teams in bestimmte Rollen, organisiert in einen Strom von Aktivitäten oder fester Dauer jedenfalls völlig kontrolliert mit Artefakten und klar definierten Regeln, die nutzbare Produkte in Abständen erhalten soll kurze Zeit.
Jedes Scrum-Verfahren basieren auf ein "Skelett" von aufeinander folgenden Iterationen der Entwicklungsaktivitäten, vertreten (jeweils eine Steigerung des Produkts), geprüft und angepasst durch seine eigenen Mitarbeiter täglich und orientiert eine Liste der ursprünglichen Anforderungen.
Zu Beginn jeder Iteration, das Team Bewertungen, was geschehen soll, und legt fest, welche brauchbare Funktionalität am Ende der Iteration geliefert werden. Das Team ist frei, Ihre besten Anstrengungen in den Rest der Iteration und am Ende das fertige Produkt gebaut zu verwenden.
Die folgende Abbildung zeigt den Fluss von Scrum:
Auf einem Scrum-Projekt sind die Verantwortlichkeiten zwischen drei Rollen unterteilt:
ProductOwners: Person, die verantwortlich für die Verwaltung der Product Backlog (um sicherzustellen, die für alle sichtbar ist), generieren und verbreiten die Projektanforderungen sowie den Plan für aufeinander folgende Lieferungen, Priorisierung der Ergebnisse, die höheren Mehrwert für das Projekt bringt.
Scrum Master: verantwortlich für die Umsetzung der Scrum-Methode, auch Lehren wie Sie für jedermann in Projekte eingebunden und sicherzustellen, dass alle die Regeln und Praktiken befolgen.
Scrum-Team: Entwicklungsgruppe gemeinsam verantwortlich für den Erfolg jeder Iteration und das Projekt als Ganzes muss bestehend multi-disziplinäre Personen in der Lage, Selbstorganisation und Selbstmanagement.
Der Prozess von Scrum befürworteten umfasst die folgenden Elemente wie unten dargestellt:
Die Vision: von ProductOwners, einschließlich Versionen vorbereitet werden muss und Produkt Lieferung Meilensteine jedem Sprint zu planen, um den Return on Investment des Entwicklungsprojekts Produkt zu maximieren.
Der Rückstand des Produkts: auch durch ProductOwners hergestellt, enthält eine Liste der funktionalen und nicht funktionellen Anforderungen, priorisiert und in Veröffentlichungen (Sprints) unterteilt.
Der Sprint-Planungsbesprechung: das Projekt gliedert sich in Sprints dauert dreißig Kalendertage, einer nach dem anderen ohne Unterbrechung durchgeführt werden. Die Planung erfolgt in einer Sitzung mit der Teilnahme des Scrum-Teams und von ProductOwners, in zwei Perioden von jeweils 4 Stunden:
In die erste Stunde wird der Umfang ("was") von Sprint, durch die Auswahl von den Produktanforderungen Rückstand behandelt werden, die auf den Sprint-Backlog gestellt werden.
In 4 Stunden zu spät, der aktuellen Planung der auszuführenden Aufgaben im Sprint ("wie") und dem offiziellen Beginn des Sprints, bei der Zeit beginnt die Frist von 30 Tagen ausgeführt.
Sprint: die Eigenprodukt Entwicklung Iteration, die eine feste Laufzeit hat. Ein Sprint umfasst Planung Sitzungen, Überprüfung und Retrospektive.
Das Daily Scrum: täglich von 15 Minuten, wo jedes Teammitglied die folgenden Fragen beantwortet:
- Was ich an dem Projekt seit dem letzten Daily Scrum gemacht?
- Was plane ich bis zum nächsten Daily Scrum zu tun?
- Gibt es eine Einschränkung oder Behinderung, dass ich mein Engagement für den aktuellen Sprint und/oder das Projekt zu Ehren?
Darüber hinaus synchronisiert das Team alle Aktivitäten und Programm treffen für die Fortsetzung des Projekts notwendig.
Ein wenig mehr Parteien Ansichten Detaillierung so weit.
Sprint review Meeting: in 4 Stunden das Scrum-Team stellt für die ProductOwners (und andere Interessengruppen) die Arbeit erzielte im Sprint und bestimmt unter ihnen was zu tun ist in den nächsten Sprint.
Die Sprintretrospektive treffen: in 3 Stunden, der Scrum Master fördert die Teammitglieder, die Scrum Entwicklungsprozess Ihrer Geburt Praktiken und Scrum-Prozess-Modell, damit es effektiver und lohnend für den nächsten Sprint zu überprüfen.
Nach Schwaber (2004) sind die Sprint Planungssitzungen, Daily Scrum, Überprüfung und Retrospektive des Sprints, zusammen, die empirische Überprüfung Praktiken und Anpassung von der Scrum.
Es gibt zwei Kategorien von Artefakten im Zusammenhang mit der Scrum: der Rückstand Tabellen und Grafiken, die der Arbeit, die noch fehlt bis zum Ende (benannt BurndownCharts) zeigen.
Die Rückstände sind Tabellen: Product Backlog besteht aus einem "live" Dokument entwickelt und betreut von ProductWoner, die per definitionem nie voll ist (da gibt es immer wieder Verbesserungen in ein Produkt umgesetzt werden, bis sie schließlich von entfernt wird Zirkulation). Enthält eine Liste aller Änderungen, die in das Produkt für zukünftige Versionen (Features, Funktionen, Technologien, Anpassungen, Erweiterungen, Updates, etc.) vorgenommen werden. solche Anforderungen sind nach Priorität sortiert und detailliert in Bezug auf die Beschreibung Attribute, komplexen Faktoren/Anpassungen und Schätzungen (der Aufwand und Begriff) entlang der zukünftige Sprints.
Das Sprint Backlog: definiert die Aufgaben, die das Scrum-Team durchführen müssen, erstellen Sie Produktinkremente (von der Product Backlog) während der Ausführung eines Sprints. Die Ihre Daten sollte ausreichen für Sie an den Sitzungen des Scrum Dario, in Aufgaben begleitet werden, die dauern zwischen vier und 16 Stunden.
Jede Aufgabe sollte dokumentiert werden, zumindest in Bezug auf Ihre Verantwortung, den Status (nicht begonnen, in Bearbeitung, abgeschlossen) und die Anzahl der Stunden der verbleibenden Arbeit jeden Tag des Sprints.
Die BurndownCharts zeigen grafisch die Höhe der Gesamtarbeit (andere Bemühungen) im Laufe der Zeit reflektieren Ihre Korrelation mit dem Fortschritt der Projektteams bei der Reduzierung Ihrer Arbeit. Kann im Rahmen des Product Backlog (einschließlich alle Sprints) oder innerhalb der einzelnen Sprints (Sprint Burndow) verwendet werden.
Scrum, wie bereits erwähnt, wurde ursprünglich für den Einsatz in Software-Projekten in komplexen Umgebungen, d.h. wo die Anforderungen verändern sich mit einiger Regelmäßigkeit, die Ihren Handlungsspielraum haben können oder Ihren Projektstrukturplan oder PSP EAP Projekt organisiert und gliedert sich in Paketen von inkrementellen, konsistente und nutzbare Artefakte, aufeinanderfolgende Perioden von jeweils 15 bis 30 Tag an den Kunden ausgeliefert werden.
Zunächst ist dieses Konzept perfekt für ein Projekt oder Programm dessen Ziel ist die Entwicklung von Produkten oder Dienstleistungen anderer Art, oder sogar, dass Initiativen zur Verbesserung der durch den Einsatz von Methoden mit Six Sigma, Lean, etc. beinhaltet. Kurz gesagt, ist der Scrum eine empfohlene Vorgehensweise, die starke Anwendbarkeit für Projekte gezeigt hat, die die Kombination von Fähigkeiten und Kenntnissen konzentriert, um ein Team und die gemeinsame Anstrengungen erfordern.
Zweite Pries & Quigley (2010) Es gibt Möglichkeiten, die Scrum für den Einsatz in verschiedenen Arten von Programmen und komplexe Projekte, wie z. B. anzupassen:
Kombiniert mit traditionellen Methoden des Projektmanagements: Konzepte und Artefakte, wie WBS (Projektstrukturplan) und Product Backlog, verdient Wertanalyse, die BurndowsCharts und Kommunikationsplan, Kontrolle der Sitzungen verbinden können Sprints (Planung, täglich, Review, Retrospektiven) etc..
Verwaltung von komplexen Programmen: Einführung von Scrum, Scrum, wo der Rückstand des Produkts kann unterteilt werden in Sub-Rückstände, jeweils durch Ihre jeweiligen Team Scrum verbraucht zu werden.
Kompetenz in Funktionsbereichen dienen verschiedene Projekte (z.B. Teams von Tests oder Qualitätssicherung): im Produkt Baclog in verschiedenen Ausführungen und Aufgaben in den Rückstand in einen Spint jene Aufgaben, die innerhalb von dreißig Tagen kommen kann.
Kombiniert mit der Technik in Form von "Cascade": Sie können den Zeitplan in feste Dauer Modell unterteilt, um beispielsweise eine Sequenz von Sprint mit einem Meilenstein (Meilenstein) im Projekt vorgesehen synchronisieren, sowie hatte die Aktivitäten der Verifizierung und Validierung des Formulars Entwicklung in jedem Sprint.
Kombiniert mit dem Six-Sigma-Ansatz: können wickeln Sie jede der Phasen des DMAIC-Methode (Define, Measure, Analyze, Improve, Control) in einem Sprint laufen nacheinander ab.
Schwaber (2004) erwähnt die Möglichkeit der Verwendung der Scrum in einem Kontext von Preis- und Dauer vorangestellt. In diesen Fällen kann der Rückstand des Produkts verwendet werden, nicht nur zu zeigen Sie den Kunden, die die Anforderungen verstanden wurden, sondern auch die Priorität der einzelnen Wert Generation verstanden wurde. Die wichtigsten Anforderungen können sein zuverlässig jeden Folgetreffen in Funktionalität für die ersten paar Sprints und den Schritten ausgewählt.
Es ist wichtig zu betonen, dass die Annahme von Scrum für eine Organisation sorgfältig getan werden sollte, gibt es viele Herausforderungen zu bewältigen.
Wir verbinden die Punkte, die, wenn nicht gut gelungen, die Wirksamkeit der Scrum-Methodik gefährden können:
Es ist wichtig, ein gut funktionierendes Team, Arbeitsgruppe, da der Erfolg der Arbeit hängt intensiver Anstrengung auf die Fähigkeiten, die jeder als ein Differential hat;
Es ist wichtig, dass jedes Mitglied der Scrum einen ausgeprägten Sinn für Selbstmanagement hat.
Stellen Sie sicher, dass nur ein Projekt Teammitglieder zugewiesen werden.
Sie müssen sicherstellen, dass das Engagement aller Beteiligten (vor allem von denen, die den Mandanten zu vertreten).
Sie müssen sicherstellen, dass die Rückstände gut dokumentiert sind, so gibt es keine Missverständnisse zwischen den Beteiligten.
Möglicherweise gibt es einige Schwierigkeiten, "atomisiert" die Aufgaben in jeder Zeile die Rückstände platziert werden, sowie die Abhängigkeiten zwischen ihnen, die die Planung beeinflussen können und die guten Fortschritte bei der Umsetzung der Sprints zu etablieren.
Sie müssen sicherstellen, dass alle Sitzungen (Planung, tägliche, Review, Retrospektive) der Sprints durchgeführt werden heraus und, die der festen Zeiten effektiv erfüllt sind, auf die Gefahr von Beschädigung der Sinn für Disziplin, die entscheidend für den Erfolg der Methode ist.
Fazit
Bevor Sie die Angebote von verschiedenen Autoren ist berüchtigt für Agilität und Schnelligkeit, dass agilen Methoden, insbesondere die SCRUM gewählt, um den anderen in dieser Arbeit veranschaulichen Unternehmen geben, die Software Fabriken mieten.
Zu den Vorteilen, können wir hervorheben: die größere Flexibilität bei der Kontrolle und Verwaltung der laufenden Arbeit, Wert auf Teamarbeit und konzentrieren sich auf schnelle Ergebnisse, gemeinsame Verantwortung mit der Gruppe verursacht ein größeres Gefühl der Verpflichtung, schnellere Lieferungen und Effizienz, Feedback betonend, Kommunikation und Kundenzufriedenheit zu steigern, indem er die Software Lieferzeit reduziert, ohne die Qualität zu verkürzen und stieg der Gewinn des Unternehmens.
Referenzen
FERNANDES, A. A.; ABREU, V.F.: Bereitstellung von Governance, 4. Aufl., São Paulo, SP: Brasport Bücher und Multimedia-Publishing company Ltd., 2014.
PRESSMAN, r. 2011 Software Engineering A professionelle Herangehensweise. Übersetzung Ariovaldo Griesi, Mario Moro Fecchio. 7. Auflage-São Paulo, SP: MGH Editora Ltda, 2011.
PRIES, Kim H., QUIGLEI, Jon M. Scrum Projektmanagement. CRC Press, 2010
SOMMERVILLE, i. Software-Engineering. 8. Ed. São Paulo, Pearson Addison Wesley, 2007.
SCHWABER, Ken. Agile Project Management mit Scrum. Microsoft Press, 2014.
Das agile Manifest. Verfügbar in: <https: www.agilealliance.org/agile101/the-agile-manifesto/="">. Abgerufen am 21. Oktober 2016.</https:>
Manifest für Agile Softwareentwicklung. Verfügbar in: <http: www.manifestoagil.com.br/="">.</http:> Abgerufen am 21. Oktober 2016.
Einen Überblick über agile Methodik. Verfügbar in: <http: www.devmedia.com.br/uma="" visao-geral-sobre-metodologia-agil/27944/="">.</http:> Abgerufen am 21. Oktober 2016.
[1] Abschluss in Informatik, es fungiert als einen öffentlichen Server auf SUFRAMA, als Administrative Analyst-Sie.
[2] Abschluss in Informatik, es fungiert als einen öffentlichen Server auf SUFRAMA, als Administrative Analyst-Sie.
[3] Abschluss in Informatik, es fungiert als einen öffentlichen Server auf SUFRAMA, als Administrative Analyst-Sie.
[4] Abschluss in Business Administration, fungiert als Beamter auf SUFRAMA, als Administrator.
[5] Abschluss in Informatik, es fungiert als einen öffentlichen Server auf SUFRAMA, als Administrative Analyst-Sie.
[6] Abschluss in Informatik, es fungiert als einen öffentlichen Server auf SUFRAMA, als Administrative Analyst-Sie.
[7] Abschluss in Informatik, fungiert als Server SUFRAMA, als Administrative Analyst-Sie.
[8] Studierte Wirtschaftswissenschaften, fungiert als Beamter auf SUFRAMA, als Ökonom.
[9] Abschluss in Informatik, es fungiert als einen öffentlichen Server auf SUFRAMA, als Administrative Analyst-Sie.
