Forskningen grundar sig på att det finns en kunskapslucka i utvärderingar av företag som praktiskt implementerar arbetsmetoden Scrum. Det finns tydliga samband mellan kulturen i en organisation och hur denna kan effektivt och framgångsfullt implementera ett agilt arbetssätt (Ilvari, Ilvari, 2011). Forskaren gjorde en semistrukturerad intervjuform med 7 medarbetare. Syftet utvärderar implementering av Scrum som metod samt hur organisationen jobbar med kundinsikter. Resultatet visar att en majoritet av medarbetarna upplever ett högre engagemang och större motivation tack vare det nya arbetssättet. Att sätta kunden i centrum är ett arbete som kräver stort fokus och då inte minst från organisationens ledare. Här har organisationens ledare varit engagerade. Några förbättringspunkter identifierats i forskningen, som till exempel att organisationen behöver bli bättre på att systematiskt mäta och sprida kundinsikter, att utveckla arbetet med att bli en lärande organisation samt att ledningen behöver hitta ett sätt att strategiskt jobba med organisationens kultur. / The research is based on the fact that there is a knowledge gap in evaluations of companies that implement the working method Scrum. There is a connection between the culture of an organization and how it can effectively and successfully implement an agile approach (Ilvari, Ilvari, 2011). The researcher did a semi-structured interview with employees. The purpose of the study was to evaluate the implementation of Scrum as a method and how the organization works with customer insights. The result shows that a majority of employees experience a higher commitment and greater motivation thanks to the new way of working. Putting the customer at the centre is something that requires a lot of focus. And much from the organisation's leaders. Here the organisation's leaders have been highly involved. Some improvement points were also identified in the research, such as systematically measuring and disseminating customer insights, developing the work of becoming a learning organization, and That the management does not work strategically with the organisation's culture. / <p>2019-08-23</p>

When it comes to using agile methods in safety critical application development, there is a limited amount of empirical findings. To learn more about how people in this field perceives the use of working with these methods, it is of interest to take part of their experiences and opinions. The purpose of this thesis is to discover advantages, disadvantages and improvement factors of working with the agile method Scrum in combination with safety critical application development. The study was limited to the roles of developers and verifiers working in two anonymized companies in the defence and railway industry. A qualitative approach was used which included a multiple case study where each of the involved company were considered a case. Empirical data was collected through semi structured interviews with the employees from the two companies. The collected data was categorized, coded and analyzed using comparative analysis. The data was coded based on one of the seven areas documentation, organization, communication, education, development, verification and planning. The interviewed developers and verifiers pointed out various advantages, disadvantages and improvement factors within the areas mentioned above. The majority of the opinions among the interviewees varied. However, some common aspects were pointed out. The most frequently mentioned factor to improve for the developers was in the communication area, while the verifiers raised educational aspects as the most common factor to improve. The findings from this study can be used to point out sections that the investigated companies should consider when using the agile method Scrum in combination with safety critical application development. The thesis also provides empirical evidence of how people in the in-spected companies consider difficulties and opportunities in their work. / När det kommer till användadet av agila metoder vid säkerhetskritisk applikationsutveckling finns det begränsat med empiriska fynd. För att få veta mer om hur personer som arbetar inom detta område uppfattar användandet av dessa metoder, är det av intresse att ta del av deras erfarenheter och åsikter. Syftet med denna uppsats är att identifiera fördelar, nackdelar och förbättringsmöjligheter när det kommer till att arbeta agilt med Scrum vid säkerhetskritisk applikationsutveckling. Studien inkluderade rollerna utvecklare och verifierare som arbetade i två anonymiserade företag inom försvarsrespektive järnvägsindustrin. En kvalitativ metod användes vilket inkluderade en fallstudie, där de involverade företagen behandlades som varsitt fall. Empirisk data samlades in genom semistrukturerade intervjuer med anställda från de två företagen. All insamlad data kategoriserades, kodades och analyserade med hjälp av komparativ analys. Kodningen utfördes baserat på de sju olika områdena dokumentation, organisation, kommunikation, utbildning, utveckling, verifikation och planering. De intervjuade utvecklarna och verifierarena pekade ut diverse fördelar, nackdelar och förbättringsfaktorer inom områdena som nämndes ovan. Majoriteten av åsikterna varierade, däremot kunde några gemensamma åsikter påvisas. Den mest förekommande förbättringsfaktorn bland utvecklarna var inom kommunikationsområdet, medan verifierarna tog upp utbildningsrelaterade aspekter som den vanligaste förbättringsfaktorn. Resultaten från denna studie kan användas för att peka ut delar som de undersökta företagen bör beakta vid användning av den agila metoden Scrum i kombination med säkerhetskritisk applikationsutveckling. Uppsatsen tillhandahåller empiriska bevis på hur personer som arbetar på de granskade företagen ser på svårigheter och möjligheterinom sitt arbete.

The traditional project methodology which is influenced by the waterfallmodel and planning tools such as the work breakdown structure and thecritical path method has been found to be redundant when contextualizedwithin the construction industry. Specifically, as they have been proven to beunable to ensure valuable and efficient work processes during the project’sdesign phase. Suggestively, both variables shall be fulfilled. This has beenfigured to be possible by utilizing the agile project method Scrum. In the strive to optimize the reoccurring issues of the project design, theinformation, work, and values must recreate flows. Variations averts this fromever happening by clogging the flows. Make-do is the primary cause ofvariations during the construction project and emerges from an unfulfilledplanning and a hierarchical communication. Within the levels of the pyramid inwhich the flows are expected to stream, the flows are put into an unavoidablerisk of encountering variations during each project hand-over. The moreactors that are taking part within the chain of flows, the greater the risk ofthe information becoming distorted, the workflow of being done in vain, andthe distance of the value flow to ever become attained. This wholeorganizational situation surrounding how the information misguides the workdraws its parallels with the telephone game, in which, during the game, thegiven information is jeopardized relative to the number of participating“children”. By establishing Scrum during the design phase, the communication paths areshortened by relating the design manager’s responsibilities to that of theScrum Master. The transformation implies that the design manager loses ittitle of being a project manager by converting the management responsibilityto the design workers. What remains is the design manager’s responsibility ofcoordinating the workers which is translated by assigning the work; this is anadded dimension within the prioritization system depicted by the ProductBacklog. Instead of having a design phase that is set out by an early providedplanning with the work breakdown structure and critical path method, theplanning is complemented by the design manager’s interface management ofthe product backlog which follows the required product specifications thatmaterializes upon the occurring Sprint meetings between group of designworkers and the project manager. / Den traditionella projektmetoden som upprättas med vattenfallsmodellen och planeringsverktyg som arbetsfördelningsstrukturen och kritiska linjen har länge blivit förklarad bristfällig inom byggindustrin. Detta genom att metoden har suttits i ett sammanhang där projekten inte åstadkommit värdefulla eller effektiva arbetsprocesser under byggprojektets design-fas—projekteringen. Förslagsvis ska båda av dessa två variabler bli uppnådda. Detta är förklarat möjligt med den agila metoden Scrum. För att optimera projekteringens återuppstående brister ska projektets information, arbeten och värden flöda i strömmar. Variationer avvärjer ifrån detta och täppar till flödena. Få det gjort är det främsta variationsskälet inom byggprojekten och uppstår när planeringarna inte blir fulländade och kommunikationen sker hierarkiskt. Inom pyramidnivåerna som kommunikation förväntas flöda inom ställs samtliga flöden inför en oundviklig mängd variationer vid varje projektöverlämning. Desto fler aktörer som deltar inom denna flödeskedja, desto större är risken av att informationen blir förvrängd, arbetsflöden sker förgäves och att värdeflöden inte blir uppnådda. Det hela organisatoriska scenariot kring hur informationen missvisar arbeten och värden liknar därför viskleken som, under lekens gång, sätter den tillgiva informationen för en risk av att bli missuppfattad relativt till mängden deltagande ”barn”. Med Scrum förkortas projekteringens kommunikationsvägar genom att hänföra projekteringsledaren med Scrum-mastern. Omvandlingen innebär att titeln förlorar sitt ledningsansvar som blir överlåtet till projekteringskonsulterna. Kvar återstår projekteringsledarens samordnaransvar som blir förklarat med arbetstilldelningen; detta blir en tillagd dimension i den prioriteringsordnade product backlogen. I stället för att projekteringen bedrivs av en tidigt förutsatt planering med arbetsfördelningsstrukturen och kritiska linjen kompletteras den med projekteringsledarens gränssnittshantering av backlogen enligt specifikationerna som uppstår under sprint-mötena mellan projekteringsgrupperna och projektledaren.

Failed projects are often caused by not detected failures and therefore tests should be performed at some time during the project to avoid those failures. In the agile method Scrum the tests of IT services are executed by the supplier to secure the quality of the services. In theory, no tests are performed by the product owner. This requires big amount of trust to the supplier and a close partnership. In agile methods the time and costs are fixed, and because of this there is also a risk that unfinished products are delivered on deadline. Little research about tests and Scrum can be found, and therefore the aim with this study is to evaluate how and when quality assurance and tests should be treated in the best way by the product owner in Scrum. The study aims to answer the question of which manual test type is relevant to perform by the product owner to ensure the quality of the IT services. The question about how and when the test should be executed should also be answered. The study is based on a case study at the company Standard Solutions Group (SSG) which is a technical consultancy. The methodology in the study involves interviews, observations, a survey, and a literature study. The different methods are used to gather information from different perspectives and should increase reliability. Acceptance tests are selected to be best suitable to be performed by the product owner. To answer the question about how the test should be executed the authors select to develop a checklist. The acceptance tests should be done continuously to create more efficiency, and it also should be easier to correct the errors. / Idag grundas ofta misslyckade projekt på att fel inte uppmärksammas och för att undvika dessa fel bör tester utföras någon gång under arbetet. I den agila metoden Scrum utförs tester på produkten av leverantören, däremot utförs i teorin inga tester från produktägarens sida, som är kunden i Scrum. Detta kräver stor tillit och ett nära samarbete mellan kund och leverantör. Eftersom agila metoder innebär att tiden och kostnaden är fast finns det även en risk att halvfärdiga produkter levereras vid deadline. Då tidigare forskning inte undersökt ämnet är syftet med arbetet att utvärdera hur och när kvalitetssäkring av leveranser på ett lämpligt sätt ska utföras från produktägarens sida i Scrum. Målet är dels att besvara frågan om vilken manuell testtyp som är relevant att utföra från produktägarens sida vid kvalitetssäkring av IT-tjänster. Dessutom ska även frågorna om hur och när det manuella testet bör utföras i Scrum besvaras. Denna studie baseras på en fallstudie som utförs hos Standard Solutions Group (SSG) som är en teknisk konsultverksamhet. Studien genomförs med hjälp aven övergripande metod som följs genom hela arbetet för att komma fram till en lösning. I studien används även andra modeller för att utföra observationer, enkätundersökning, intervjuer och en litteraturstudie. Detta för att få information från flera olika perspektiv vilket ökar studiens tillförlitlighet. Studien resulterar i atttest-typen acceptanstester är ett lämpligt test att utföra frånproduktägarens sida. En checklista utvecklas för att svara på frågan om hur testet ska utföras. För att skapa mer effektivitet så att fel enklare ska kunna åtgärdas utförs acceptanstestester kontinuerligt under arbetets gång.

<p>Enligt statistik från The Standish Group’s artikel Extreme Chaos (2001) tenderar IT-projekten att oftare få problem med tid, kostnad och kvalité aspekten i jämförelse med andra typer av projekt. I vår uppsats vill vi försöka förstå vad det är som skiljer IT-projekt i jämförelse med andra projekt. Kan det exempelvis vara så att man använder sig av fel projektledningsmodell?</p><p> </p><p>I denna studie har vi jämfört hur projekt utförts i byggbranschen respektive IT-branschen. Under studiens gång har fyra intervjuer inom dessa sektorer utförts, studien har även införskaffat ytterligare betydande information genom två expertintervjuer inom området. Studien är uppbyggd kring en rubrikstruktur utifrån viktiga kriterier som Extreme Chaos (2001) tar upp, även några kriterier från teorin ligger till grund för denna struktur. Det vi hittade var att det är av stor betydelse att man verkligen är införstådd med vad kunden vill få ut av projektet, att man verkligen talar samma språk. Att man använder sig av en begreppslista för att förtydliga svårbegripliga ord.</p><p> </p><p>Studien framhäver även att projektledarens roll inom IT-projekt mer är av stödjande karaktär i jämförelse med bygg, där projektledarrollen mer är av styrande karaktär. Det finns även tydliga tecken på att projektledningsmodellen har en stor betydelse för projektets utgång. Inom IT-projekt är ofta vägen till resultatet tämligen diffus på grund av dess komplexitet. Analysen visar en illustration över hur vi ser på projektutförandet. Den visar att det finns två typer av IT-projekt, den ena är industri-IT, vilket vi menar är installationer av redan färdigutvecklade produkter. Den andra är innovativ-IT, vilket vi menar är IT-projekt där målet är känt men vägen dit är okänd. I dessa fall är det av fördel att använda sig av en iterativ metod som exempelvis Scrum för att successivt ta sig an IT-projektet.</p>

Enligt statistik från The Standish Group’s artikel Extreme Chaos (2001) tenderar IT-projekten att oftare få problem med tid, kostnad och kvalité aspekten i jämförelse med andra typer av projekt. I vår uppsats vill vi försöka förstå vad det är som skiljer IT-projekt i jämförelse med andra projekt. Kan det exempelvis vara så att man använder sig av fel projektledningsmodell?   I denna studie har vi jämfört hur projekt utförts i byggbranschen respektive IT-branschen. Under studiens gång har fyra intervjuer inom dessa sektorer utförts, studien har även införskaffat ytterligare betydande information genom två expertintervjuer inom området. Studien är uppbyggd kring en rubrikstruktur utifrån viktiga kriterier som Extreme Chaos (2001) tar upp, även några kriterier från teorin ligger till grund för denna struktur. Det vi hittade var att det är av stor betydelse att man verkligen är införstådd med vad kunden vill få ut av projektet, att man verkligen talar samma språk. Att man använder sig av en begreppslista för att förtydliga svårbegripliga ord.   Studien framhäver även att projektledarens roll inom IT-projekt mer är av stödjande karaktär i jämförelse med bygg, där projektledarrollen mer är av styrande karaktär. Det finns även tydliga tecken på att projektledningsmodellen har en stor betydelse för projektets utgång. Inom IT-projekt är ofta vägen till resultatet tämligen diffus på grund av dess komplexitet. Analysen visar en illustration över hur vi ser på projektutförandet. Den visar att det finns två typer av IT-projekt, den ena är industri-IT, vilket vi menar är installationer av redan färdigutvecklade produkter. Den andra är innovativ-IT, vilket vi menar är IT-projekt där målet är känt men vägen dit är okänd. I dessa fall är det av fördel att använda sig av en iterativ metod som exempelvis Scrum för att successivt ta sig an IT-projektet.

De flesta organisationer idag jobbar i någon typ av projektbaserad arbetsform. Ett sätt att effektivisera sina projekt kan vara att använda sig av lämpliga IT-stödsystem. Genom att ge projektet en intern yta för kommunikation- och informationshantering kan både moral och samarbetseffektiviteten att öka. Ett intranät är ett system som fyller just dessa funktioner och som många företag redan har, men inte alltid använder till just projekt. Anledningen till att varför ett intranät inte alltid är används är p.g.a. den höga administrationstiden som krävs för att anpassa verktyget att passa just organisationens projekt. I den här studien undersöks vilket intranätverktyg som är mest lämpat för projekthantering och hur ett förbättrat stöd kan åstadkommas. I studien identifieras de tre populäraste intranätverktygen i Sverige som EPiServer, SiteVision och SharePoint. Dessa undersöks närmre genom semistrukturerade intervjuer med konsulter inom varje verktyg. Med en kvalitativ och kvantitativ analys av intervjuerna så bedöms SharePoint som dess mest lämpade intranät för projekthantering. En fallstudie utförs hos JSC IT-Partner AB – ett IT-konsultföretag i Småland. I fallstudien utvecklas en IT-artefakt under forskningsmetodiken Design Science med ett inslag av den agila systemutvecklingsmetoden Scrum. IT-artefakten är en SharePoint App som ämnar att underlätta skapandet av projektportaler i JSC:s intranät. Artefakten evalueras genom ett försök att replikera den projektportal som redan används av JSC, men som inte är automatiserad. Resultatet av evalueringen ligger till grund för studiens resultat som visar att ett förbättrat stöd för projekthantering kan uppnås inom intranät med hjälp av programmering. I slutet av studien diskuteras de begränsningar som kan upplevas när ett intranät används för projekthantering och de problem som uppkommit under utvecklingsprocessen av artefakten. I studien diskuteras inte konsekvenserna av att införa en organisations projektverksamhet i ett intranät. JSC använde sedan tidigare sitt intranät för projekthanteringen och därmed undersöks inte övergången från externa system till ett intranät. / Many organisations today work with some kind of project oriented working method. One way to make it more efficient could be to use suitable IT support systems. By giving a project an internal area for communication and information management could increase members both morale and social collaboration. An intranet is a system that fulfil these conditions and is already highly used by organisations, but not so much for project management. This is partially because of the high amount of administration time required for successfully adapting the system for the specific organisations projects. This study examines different intranet systems to find the most suitable for project management and how it can be improved. In this study the three most popular intranet systems in Sweden is identified as EPiServer, SiteVision and SharePoint. These systems are investigated further by semi-structured interviews with consultants from each of the systems. With a qualitative and quantitative analysis SharePoint is recognized as the most suitable system for project management. A case study is performed at JSC IT-Partner AB – and IT Consultant Company in Småland. During the case study an IT artefact is developed by the combination of the research method Design Science and the agile system development method Scrum. The artefact is a SharePoint App that intend to facilitate the creation of project portals in JSCs intranet. The artefact is evaluated by trying to replicate the existing project portal that is already used by JSC, but that is not automated. The result from the evaluation is used when analysing and discussing the result from this research that proves that project management can be improved in intranets by the help of programming. In the end of this report there is a discussion about different limits that may occur when using an intranet for project management and what problems that were encountered during the development process of the artefact. There is no discussion about what impact using an intranet for project management may have for the organisation. JSC was already using their intranet for project management at the time and the purpose of the case study was not to analyse the consequences when moving from an external system to the organisation’s internal intranet.

由於現今商業環境時常變動，使得使用者需求在系統開發過程中頻繁改變。傳統系統開發方式無法迅速回應使用者需求變更，強調彈性開發流程的敏捷開發方式逐漸廣為接受。敏捷開發並未探討系統設計議題而系統設計不佳會導致系統品質低落，使用軟體框架可以快速建立良好的分層結構，有助於穩定產品品質並提高軟體再用性。本研究以Scrum為基礎，結合Struts、Spring、Hibernate整合框架，建立一套系統開發方法，包含敏捷開發方式的彈性流程，兼顧系統擴充性及可維護性，研究方法為概念形成法與系統展示法，並以Java Web-Based雛型系統為例，說明相關作業內容。 / Due to the quick variation in the business environment, user requirements change frequently during the system development process. This induces the rising popularity of agile development method which emphasizes the development flexibility during the process. However, agile development method does not address the design issues and poor system design can easily cause poor system quality. Software framework helps to quickly build a good hierarchy structure and thus improve the product quality and software reusability. This study proposes a system development method based on Scrum with the integration of Struts、Spring and Hibernate frameworks. The method is embedded with the development flexibility from the agile method, as well as the system extensibility and maintainability from the software frameworks. The study is conducted with the research method of concept formulation, and would be continued with a Java Web-Based prototype development as an example to illustrate the relevant activities.

Submitted by Milena Rubi (milenarubi@ufscar.br) on 2017-06-01T14:03:52Z No. of bitstreams: 1 LEONESSA_Nathalia_2016.pdf: 56993911 bytes, checksum: c3674f0762a44d85df19038a13d9f2d2 (MD5) / Approved for entry into archive by Milena Rubi (milenarubi@ufscar.br) on 2017-06-01T14:14:25Z (GMT) No. of bitstreams: 1 LEONESSA_Nathalia_2016.pdf: 56993911 bytes, checksum: c3674f0762a44d85df19038a13d9f2d2 (MD5) / Approved for entry into archive by Milena Rubi (milenarubi@ufscar.br) on 2017-06-01T14:14:33Z (GMT) No. of bitstreams: 1 LEONESSA_Nathalia_2016.pdf: 56993911 bytes, checksum: c3674f0762a44d85df19038a13d9f2d2 (MD5) / Made available in DSpace on 2017-06-01T14:14:40Z (GMT). No. of bitstreams: 1 LEONESSA_Nathalia_2016.pdf: 56993911 bytes, checksum: c3674f0762a44d85df19038a13d9f2d2 (MD5) Previous issue date: 2016-12-12 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES) / The methodologies currently used by startups for market discovery and software development focus on a more agile and fast development, aiming to obtain learning about the potential market. Often, these methodologies set aside good software development practices to make the process faster and more dynamic, with constant end-user participation. If, on the one hand, the use of methodologies such as Scrum and RUP for software development can result in the development of technological solutions that are not used by users due to the lack of participation in software construction, on the other hand, they bring many benefits when it comes to project management and software quality. In contrast, the opposite occurs to the methodologies and tools currently used by startups, such as Lean Startup, Customer Development, Thinking Design and Business Model Canvas. These methodologies and tools focus on the discovery and validation of the market, without concern for the final quality of the product developed for the client, impacting directly. This impact can also be a waste of time in developing a product that no one will be able to use because of the large number of failures or even it never be finalized due to management problems. The lack of concern for good management of a development project, and its final quality, can do as much damage as the lack of approximation with the potential client. Moreover, in an environment of extreme uncertainty, unknown variables should be reduced in order to achieve overall development success, not just business models. The use of good Software Engineering practices may allow obtaining more information and technical data about the solution developed, which directly impact the user. This information can be used as a basis for decision making, thereby reducing risks related to final product quality and project management, making it easier for potential customers to use, and leaner development. In this sense, this work proposes a software development methodology for startups, Startup Kaizen (SK). SK integrates good practices of methodologies such as RUP and Scrum with methodologies focused on validation and market discovery, such as Lean Startup, Customer Development, Thinking Design and Business Model Canvas. This union of good software engineering practices with market discovery aims to minimize the risk variables for the creation of a new company, whether related to market or management and software quality. After the creation of Startup Kaizen, a case study was performed with its application with graduate students in Computer Science at the Federal University of São Carlos in Sorocaba. This application allowed the data collection to analyze the results in the form of a case study. / As metodologias atualmente utilizadas por startups para descoberta de mercado e desenvolvimento de software focam no desenvolvimento mais ágil e rápido, visando a obtenção de aprendizado sobre o mercado de atuação. Muitas vezes, essas metodologias deixam de lado boas práticas de desenvolvimento de software para que ele seja realizado de forma mais dinâmica e rápida, com constante participação do usuário final. Se, por um lado, a utilização de metodologias ágeis como Scrum e metodologias mais tradicionais como RUP, para o desenvolvimento de software pode resultar no desenvolvimento de soluções tecnológicas que não são utilizadas pelos usuários por falta de uma constante participação deles na construção do software, por outro lado, elas trazem inúmeros benefícios quando se trata de gerenciamento de projeto e qualidade de software. Em contrapartida, o oposto ocorre para as metodologias e ferramentas atualmente utilizadas por startups, tais como Lean Startup, Customer Development, Design Thinking e Business Model Canvas. Essas metodologias e ferramentas focam na descoberta e validação de mercado, sem a preocupação com a qualidade final do produto desenvolvido para o cliente, impactando-o diretamente. Esse impacto pode também acarretar um desperdício de tempo no desenvolvimento de um produto que ninguém conseguirá utilizar, devido à grande quantidade de falhas, ou até que nunca será finalizado, devido a problemas de gerenciamento. A falta de preocupação com um bom gerenciamento de um projeto de desenvolvimento, e sua qualidade final, podem trazer tantos prejuízos quanto a falta de aproximação com o potencial cliente. Além disso, no ambiente de extrema incerteza, as variáveis de insegurança devem ser reduzidas ao máximo possível visando a obtenção de sucesso no desenvolvimento como todo, e não apenas em relação a modelos de negócios. A utilização de boas práticas de engenharia de software pode possibilitar a obtenção de mais informações e dados técnicos sobre a solução desenvolvida, que impactam diretamente o usuário. Essas informações podem ser utilizadas como base na tomada de decisão, diminuindo assim, os riscos relacionadas a qualidade final do produto e gerenciamento de projeto, facilitando a utilização por seus potenciais clientes, além de um desenvolvimento mais enxuto. Neste sentido, este trabalho propõe uma metodologia de desenvolvimento de software para startups, o Startup Kaizen (SK). O SK agrega boas práticas de metodologias como RUP e Scrum com metodologias com foco na validação e descoberta de mercado, como Lean Startup, Customer Development, Design Thinking e Business Model Canvas. Essa união de boas práticas de engenharia de software com a descoberta de mercado, tem como objetivo minimizar as variáveis de risco para a criação de uma nova empresa, sejam elas relacionadas a mercado ou gerenciamento e qualidade de software. Após a criação do Startup Kaizen, foi realizado um estudo de caso com sua aplicação com alunos de pós-graduação em Ciências da Computação da Universidade Federal de São Carlos em Sorocaba. Essa aplicação permitiu a coleta de dados para análise dos resultados na forma de estudo de caso. / 33001014

O desenvolvimento de software entre equipes geograficamente distribuídas tem adquirido relevância devido a interesses das organizações, relacionados a custos de projetos, busca de profissionais multidisciplinares e especializados ou visando ampliar a cobertura de seus clientes, atendendo-os de forma mais globalizada. Porém, apesar dos benefícios existentes, há algumas dificuldades oriundas da distribuição de equipes que são inerentes da dispersão temporal e geográfica. Estas dificuldades incluem as diferenças culturais, linguísticas, temporais entre outras, que comprometem a qualidade da comunicação e consequentemente interferem na compreensão mútua entre as equipes que desenvolvem um mesmo projeto de software. O objetivo deste trabalho é apresentar uma melhoria de um processo de desenvolvimento distribuído de software (DDS), baseado em Scrum, capaz de minimizar as interferências e perdas de informações, descentralização de conhecimentos em pessoas específicas e melhorar no fluxo de comunicação e disseminação das informações. Um caso real foi abordado e para o desenvolvimento deste trabalho o método de pesquisa adotado foi a pesquisa-ação. Neste cenário real haviam problemas originados da comunicação ineficiente entre seus atores e exigiu que o desenvolvimento desta pesquisa tivesse várias iterações e retroalimentações até atingir a maturidade. A melhoria da comunicação foi alcançada e é a principal contribuição deste trabalho. / Software development between geographically distributed teams has acquired relevance due to interests of organizations, project-related costs, looking for multidisciplinary and specialized professionals or aiming to expand the coverage of its customers, serving them in a globalized form. However, despite the existing benefits, there are some difficulties originated from the distribution of teams that are inherent in the temporal and geographic dispersion. These difficulties include the cultural, linguistic, temporal among others, which affect the quality of communication and consequently interfere with the mutual comprehension between the teams which develop the same software project. Thus, the aim of this work is to present an improvement in the process of distributed software development (DSD) based on Scrum, capable to minimize interference and information losses, decentralization of knowledge in specific people and improve the communication flow and dissemination of information. A real case was discussed and as for the development of this work the action research was the approach employed in this study. In this scenario, problems originated from inefficient communication between their actors and demanded that the development of this research present several iterations and feedbacks in order to reach its maturity. Improved communication has been achieved and is the main contribution of this work.