SÄHKÖISTEN PALVELUIDEN ARKKITEHTUURI- JA RAKENNUSTOIMISTO

Transkriptio

1 SÄHKÖISTEN PALVELUIDEN ARKKITEHTUURI- JA RAKENNUSTOIMISTO

2 Customer Communication in Agile Software Development Projects

3 Structure Salum Abdul-Rahman (me) & Gofore (Some slides in Finnish, deal with it) Theory of Communication Agile vs Waterfall Communication Toolbox Relationship Development

4 Salum Abdul-Rahman BSc Automation and System Technology from Aalto University MSc Information Technology Tampere University of Technology Part-time in IT service / software development since 2007, Full time since 2013 Areas of interest: Open Source Project Management Agile SWD Knowledge Management

5 Software and Services WHAT IS GOFORE

6 Our Mission To save finnish society by improving productivity by implementing better information systems.

7 Gofore lyhyesti IT-johdon konsultoinnin ja tietojärjestelmien kehittämisen asiantuntijayritys Vahvassa kasvussa liikevaihto 6 MEUR (2013) Yhteensä 80 asiantuntijaa Helsingissä ja Tampereella perustettu v Taloudellisesti vakavarainen liikevoitto yli 10 % viimeiset yhdeksän vuotta ASIAKASTYYTYVÄISYYS Yli 98 % asiakkaista pitää ratkaisujamme ja palvelujamme parempina tai saman tasoisina kuin kilpailijoilla. Asiakastyytyväisyystutkimus 12/2013, Innolink Research HENKILÖSTÖTYYTYVÄISYYS Työilmapiirin kouluarvosana 9,47 Yhteishenki 9,45 Suvaitsevaisuus 9,30 Tasavertainen kohtelu asemastani riippumatta 9,39 Tasa-arvoinen kohtelu sukupuolestani riippumatta 9,67 Henkilöstötyytyväisyystutkimus 11/2013, Barona IT

8 Kehitys ja historia

9 Palvelutarjonta ARKKITEHTUURITOIMISTO IT-johdon asiantuntijapalvelut Arkkitehtuurikonsultointi Kehityshankkeiden valmistelu ja johtaminen Avoimen tiedon palvelut RAKENNUSTOIMISTO Tietojärjestelmien kehityspalvelut UX-palvelut Ohjelmistokehityspalvelut Jatkuvat palvelut Kokonaisarkkitehtuurin hallinnan palvelu Kartturi

10 Fokuksessa julkishallinto VAHVA TOIMIALAOSAAMINEN Liikenne Älyliikenne Liikenteen ohjaus ja hallinta Joukkoliikenne OPETUSALAN EKOSYSTEEMIN INTEGRAATTORI Opetus Koulutusjärjestelmien digitalisoinnin murros TOIMITTAJARIIPPUMATON ARKKITEHTUURIKUMPPANI Hyvinvointi Hyvinvointi uudistuksen kourissa o o o Sote-uudistus Potilaan voimaannuttaminen, omahoito Potilasjärjestelmien elinkaari

11 Some Past Projects Consulting Finnish Transport Agency Finnish National Board of Education Software Development Occucapational Safety and Health Administration Avoindata.fi Kela.fi

12 Consulting Projects Finnish Transport Agency Traffic Infromation Architecture specification Service Oriented Traffic Infromation System Architecture Design Finnish National Board of Education Combining different service providers with end user driven service design System architecture specification Process modelling SOA -design

13 Tehokkuutta työsuojeluhallinnolle Tehokkuutta uudella tietojärjestelmällä Työsuojeluhallinnossa vuosittain työsuojelutarkastusta Gofore toimittajaksi julkisen kilpailutuksen kautta Toteutus osaprojekteissa v palvelukeskeinen arkkitehtuurimalli KuntaIT:n SOA-teknologialinjausten mukainen toteutus ketterä iteratiivinen prosessimalli Julkisen sektorin tuottavin tietojärjestelmähanke

14 Valtori tiedon avaamisen työkalut avoimesti ja ketterästi Julkinen data avoimeksi ja käyttöön hallitusohjelman kestävän talouskasvun sekä työllisyyden ja kilpailukyvyn vahvistaminen Työkalut julkishallinnolle avoimesti ja ketterästi avoimen lähdekoodin tuotteilla (mm. CKAN, Drupal) ympäristöt pilvestä Täysin uusien palveluiden kehittäminen kansallisen avoimen datan portaalin kehittäminen kansallisen palvelutietovarannon kehittäminen kansallisen yhteentoimivuusportaalin kehittäminen prototyyppien ja demojen tekeminen osana uusia palveluita

15 Ketterästi Kelalle Kela.fi-palvelu suosittu julkishallinnon verkkopalvelu Gofore julkisen kilpailutuksen voittajaksi parhailla laatu- ja hintapisteillä Ketterä toteutus Domino-ympäristöstä Liferay-portaalipalvelimen päälle mm. Scrum-menetelmän käyttö Täydellinen ilme- ja käyttöliittymäuudistus kela.fi-palvelu suunnannäyttäjänä julkishallinnon verkkopalveluissa

16 Asiakkaitamme A-Insinöörit Alma Media Barona Group Cargotec CSC Tieteen tietotekniikan keskus Elisa Eläketurvakeskus Enfo Eniro Finland FCG Fimlab Laboratoriot Oy Fonecta Helsingin yliopisto Ideapark Kansalliskirjasto Kansaneläkelaitos Kauppalehti Kuntaliitto Labkotec Liikennevirasto Liikenteen turvallisuusvirasto Medbit Oikeusministeriö Oikeusrekisterikeskus Opetushallitus Opetus- ja kulttuuriministeriö Patentti- ja rekisterihallitus Pirkanmaan ELY-keskus Pirkanmaan sairaanhoitopiiri Puolustusvoimat Rikosseuraamuslaitos Satakunnan sairaanhoitopiiri Sosiaali- ja terveysministeriö Sponda Suomi24 Tampereen ammattikorkeakoulu Tampereen ev.lut. seurakuntayhtymä Tampereen kaupunki Tampereen sähkölaitos Terveyden ja hyvinvoinnin laitos Turvallisuus- ja kemikaalivirasto Työ- ja elinkeinoministeriö Valtori Valtiovarainministeriö Vantaan kaupunki Varsinais-Suomen sairaanhoitopiiri

17 Theory of Communication

18 Communication Sender Channel Receiver Medium Message - Symbols Other Models

19 Wiio's laws Communication usually fails, except by accident. If communication can fail, it will. If communication cannot fail, it still most usually fails. If communication seems to succeed in the intended way, there's a misunderstanding. If you are content with your message, communication certainly fails. If a message can be interpreted in several ways, it will be interpreted in a manner that maximizes the damage. There is always someone who knows better than you what you meant with your message. The more we communicate, the worse communication succeeds. The more we communicate, the faster misunderstandings propagate. In mass communication, the important thing is not how things are but how they seem to be. The importance of a news item is inversely proportional to the square of the distance. The more important the situation is, the more probably you forget an essential thing that you remembered a moment ago.

20 Agile Software Developement

21 Waterfall customer communication Marketing, Sales Negotiations Requirements specification Progress reports QA reports Documentation Handoff, Thank you s, and Assigning Blame.

22 Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

23 Waterfall vs. Agile More communication More informal communication More unstructured communication Better communication

24 Waterfall vs. Agile Documentation is Communication Less documentation? More relevant documentation Updated documentation Condensed expression Availailability of documentation Predefined communication

25 Waterfall vs. Agile Agile is for people Individuals and interactions not roles Customer collaboration Contract negotiation Trust is established through communication and delivered software

26 Agile is freedom! Be systematic in choices of communication Agile is iterative, improve your communication Find the communication methods and tools that work for your project Every project is different Don t be blinded by the Dream Team When the project is over the Documentation is the only way you are still communicating with the customer?

27 Freedom is Responibility Agile teams have have more personal freedom Agile teams have more personal responsibility Responsibility Tools Features Methods Communication

28 A Word on contracts Waterfall contracts should allow for changemanagement during the project Agile contracts need to reflect agile values Change in personel is a big issue

29 Communication toolbox

30 What is valuable in communication Timing (Speed, Predictability) Exacteness Persistence Trust

31 What are you talking about (Message) Business Cases Requirements Management Configuration Management Project Management Feedback

32 Customer Needs Every choice a developer makes is a business decision. The customer can not be informed about every decision made Communication requires effort

33 Balance Between Communication Costs Quality Low communicationn threshold Time needed Developer Customer

34 Expressions (Symbols) Unstructured Natural languages Pictures Diagrams Charts Video Animation Protoypes Non-functional Functional Structured Ontologies Domain Models System Models Domain Specific Languages Descriptive Computable

35 Unstructured Natural languages Informal communication necessary for relationship development Inexact Expressive Tools provide structure Use cases User stories Bug reports

36 Pictures Information Visualization Charts Diagrams Video Effort cost Animation tools Easy to use Easy to misuse

37 Prototypes Picture Paper prototypes Mock devices/environments Tool for facilitating communication

38 Structured Ontologies Domain Models System Models Domain Specific Languages Descriptive Computable

39 Methods (Medium) Personal Meetings Instant messaging Issue trackers Wikis Documents

40 Shared Space Personal Relationship Meetings Efficiency of information transfer decreases with size Being a good President or Secretary requires skill Working together

41 Through the Screen Instant messaging

42 Virtual Shared Space Issue trackers Usability vs functionality Project workflow fit Wikis Searchability Learning curve Accessibility Update

43 Documents As static as you want to be Mix and match content Persistent? Usability?

44 Publicity of Communication Organizational client Department boundary Company boundary Open Source development

45 Relationships

46 Realtionship Management Business Value Personal Relationships Professionalism Roles Customer Aptitude

47 Professionalism Be trustworthy Be confident Know when/where to vent Don t over do it. Don t Be A Dick

48 Roles Developer QA UX Project Manager Customer Project Manager Specialists

49 Roles (Scrum) Developer Product Owner Scrum Master Customer

50 Customer Domain Expertise Technical Expertise Communication Skills Lanuage profiency Tool profiency Relationship Respect Trust

51 After the Project Do not unjustly criticize previous clients by name. Constructive criticism? Maintaining the relationship?

52 Conclusion Everything that the customer can observe is communication Choose the best tools Improve Build trust Don t be a dick. (Wheaton s Law) "Communication usually fails, except by accident (Wiio's 1st law)

53 Questions & Discussion

54 FEEDBACK