Samen + visie + werkwijze = Synergie
De som van elkaars expertise maken.
Goed en effectief leiderschap hangt nauw samen met de mate waarin de leider in staat is de bedrijfsdoelstellingen te koppelen aan de psychologische basisbehoeften van de medewerkers, zoals ontwikkeling, autonomie, verbondenheid, zingeving, en deze proactief te faciliteren. Frederik Eshuis. Zie ook JDR Model.
Gebalanceerde ontwerpen en oplossingen
Bij het realiseren van webdesign en ICT oplossingen zorgen we door synergie, elkaar versterkend, dat de gedeelde visie praktisch werkelijk wordt. Dit doen we samen door heldere communicatie, pakkend webdesign, interactieontwerp en gebruiksvriendelijke ICT oplossingen te maken. Waar nodig, gebruiken we daarbij hulpmiddelen zoals WordPress, Microsoft Office, Office365, Project en Nextcloud. Zo komen we tot een treffend resultaat en gaan we praktisch verder, vanuit uw en onze expertise. Vandaar:
IT's about people
In het juiste ritme de bestemming bereiken
Sinds 1998 mogen wij samenwerken met diverse organisaties. Vanuit onze gedeelde kennis en ervaring, hebben we samen een bedachtzame, flexibele manier van werken leren praktiseren dat tot passende resultaten leidt. Bij het onderdeel praktische aanpak hebben we dit kort op een rijtje gezet. Daarmee maken we de som van elkaars expertise: In de juiste tijd, plaats en hoeveelheid. Zo maken we gebalanceerd muziek, in een mooie cadans.
Samen praktisch doeltreffend
De manier waarop wij meestal werken is voortgevloeid uit onze praktijkervaring en vanuit diverse methodes, zoals de zeer effectieve creatief denken methodiek met de Zes Denkhoeden van Edward de Bono (engels), en verder de watervalmethode, de project management methode PMBOK, en de agile Scrum methode.
Hieronder beschrijven we onze werkwijze puntgewijs. Dat onderverdeeld is in Wie, wat, waar en wanner? Visualisatie en implementatie. Dit is bedachtzaam en praktisch flexibel. Zo krijgen we geen langdurige processen. Die worden toch vaak achterhaald door de actualiteit. We kunnen zo verantwoord samen de visie invullen, waarbij we kunnen inspelen op de eventueel veranderende omstandigheden. Als u wilt, dan kunnen we het project ook uitvoeren met een andere manier van werken. Bijvoorbeeld vanuit enterprise project, resource, portfolio en content management (EPM, PPM en ECM).
Met uw projectvisie en -doelstellingen, houden wij trouwens graag in het oog dat, minder doorgaans meer is, en vinden we duidelijke communicatie belangrijk.
De werkwijze op een rijtje
Graag betrekken we de sleutelfiguren zo goed mogelijk, en op de juiste momenten bij het project. Zo komen we tot meer draagvlak, beter passende en soepeler geaccepteerde eindproducten.
- Wie, wat, waar en wanneer.
- Uw visie en doelstellingen.
- De betrokken belanghebbenden (stakeholders) en samenwerkende partijen.
- De planning en eindproducten.
Naast de benodigde projectplanning en productbeschrijvingen, gebruiken we doorgaans ook een praktische puntenlijst. Deze lijst wordt gedurende het project bijgewerkt en ordenen we meestal op basis van de MoSCoW prioriteit.
- Visualisatie.
- Dit kan zowel door klikbare prototypes; met of zonder ontwerpsessies, als met schetsen, grafische of interactie ontwerpen.
- Zo nodig wordt dit gecombineerd met UML diagrammen of andere modellen.
- Eventueel kan dit worden uitgevoerd in een interactie of functioneel ontwerp.
- Implementatie.
- Incrementele ontwikkeling. Zie bijvoorbeeld agile Scrum methode. Afwijkingen, zoals hierboven, zijn mogelijk.
- Relevante documentatie.
- De nodige implementatiestappen:
- Opleiding, training of coaching.
- Realisatie in eventueel meerdere omgevingen.
Dit kan bijvoorbeeld worden uitgevoerd in een test- en productieomgeving, of middels een OTAP methodiek.
Data veiligheid & privacy
Met dit alles hebben wij ook aandacht voor veiligheid en de bescherming van uw en onze informatie. Vaak is dit een ondergeschoven kindje, terwijl het steeds belangrijker wordt. Het daarbij rekening houden met de menselijke factor is erg belangrijk. Vaak gaat het daarmee juist mis. Via e-mail, cloud of USB stick gebruik kan er al relatief eenvoudig een virus worden verspreid, of digitale inbraak (hack) worden uitgevoerd. De verspreiding van trojaanse paarden, virussen, cryptolockers (zoals Wannacry gijzel software) en bijvoorbeeld malware neemt hand over hand toe. In onze producten houden we daar rekening mee middels de mogelijke beveiliging en back-up oplossingen.
Handig samenwerken via private cloud
Documenten, media en andere digitale informatie bewaren we graag op één plek, waar we vanuit telefoon, tablet of laptop bij willen kunnen, waar we ook op de wereld zijn. Om dat te kunnen, privé en handig te kunnen samenwerken, hebben we sinds 2013 ervaring met ownCloud en vervolgens Nextcloud. Beide zijn gebruiksvriendelijke oplossingen met vele handige mogelijkheden. Het is overigens ook nog open source. Dat betekent dat de broncode vrij in te zien is en je er eventueel aan mee kunt helpen maken.
Met Nextcloud bijvoorbeeld kan je gegevens bewaren en met de gewenste personen en systemen delen. Zo kan je ook koppelen met systemen zoals DropBox, Google Drive, Sharepoint / Office365 / OneDrive, etc. Zo gewenst kunnen wij u deze cloud oplossing via onze server aanbieden.
Six Thinking Hats
In 1985, he [dr. Edward de Bono] authored ‘Six Thinking Hats’. This publication is considered to be one of his greatest literary works and provides the readers with effective tools for group discussion and individual thinking. It also provides a more detailed insight into the concept of ‘parallel thinking’ and ‘critical thinking’. This book introduced the concept of the ‘six thinking hats’ method, which Speedo Researchers used in the creation of their swimsuits, thus making de Bono’s ideas presented in the book, extremely popular.
De watervalmethode
Bron link onderaan
De watervalmethode is een methode voor softwareontwikkeling (een proces voor de verwezenlijking van software), waarin de ontwikkeling regelmatig vloeiend naar beneden loopt (als een waterval). De ontwikkeling loopt door een aantal fasen, namelijk: definitiestudie/analyse, basisontwerp, technisch ontwerp/detailontwerp, bouw, testen, integratie en beheer en onderhoud. Met deze methode hoopten de informaticabedrijven meer duidelijkheid te krijgen in hun software-projecten.
Het watervalmodel is afgeleid van de traditionele manier van werken in grote projecten in de constructiebouw. De bedoeling van deze manier van werken is dat het project in verschillende fasen wordt opgedeeld. Men start met fase 1 en begint niet eerder met fase 2 dan wanneer fase 1 is afgesloten. En wanneer in een van de fasen een fout ontdekt wordt, gaat men helemaal terug om die fase te corrigeren en de daaropvolgende stappen opnieuw uit te voeren
[...]
Vernieuwde watervalmethoden
Om zo veel mogelijk gebruik te maken van de voordelen en zo weinig mogelijk last te hebben van de nadelen is er een aantal vernieuwde watervalmethoden ontwikkeld. Hieronder wordt er een aantal genoemd.
Model van Royce
Het model van Royce beschrijft dat het verkeerd is dat er bij de watervalmethode niet teruggegaan kan worden naar de vorige fase. Vaak zal er in een fase blijken dat er in een vorige fase iets verkeerd is gegaan, het moet dan mogelijk zijn om gemakkelijker naar een vorige fase terug te gaan.
Het "sashimi"-model
Schematisch overzicht van de sashimi-watervalmethode met overlappende fasen...
Het sashimi-model is opgezet door Peter Degrace. De fasen zijn hetzelfde als in het traditionele watervalmodel, alleen nu overlappen de fasen elkaar ook. Door gebruik te maken van deze methode worden er veel minder bronnen verspild. De afbeelding hiernaast geeft weer hoe de fasen elkaar overlappen. Dit is echter een illustratie en dit geeft dus niet de werkelijke overlapping weer qua verhouding. Het verschil met het schematische overzicht van de standaard watervalmethode is dat de fasen deze keer tegen de doorlooptijd afgedrukt zijn. Dit betekent dat men bijvoorbeeld al begint met het ontwerp terwijl de analyse nog bezig is. Dit betekent ook dat men terug kan vallen op de analyse in de ontwerpfase.
Aorta lifecycle-model
Het Aorta lifecycle-model is een vernieuwd model waarin na elke cyclus terugkoppeling wordt gegeven naar de klant.
V-model
Het V-model is een lineaire softwareontwikkelmethode waarbij evenwichtig aandacht aan ontwikkeling en verificatie besteed wordt.
[...]
Project Management Body of Knowledge
Bron link onderaan
Het PMBOK is een poging om algemeen erkende projectmanagement informatie en gebruiken te beschrijven en standaardiseren. Na een eerste white paper editie verscheen het PMBOK in boekvorm in 1996. In 2000, 2004, 2008 en 2012 volgden de tweede tot en met vijfde editie.
Tijdens een project doorloopt het projectbeheer een periodieke cyclus van projectinitiatie, planning, uitvoering, controle & bijsturing en projectafsluiting. Een project dient volgens PMBOK te worden benaderd vanuit 10 verschillende aandachtsgebieden:
- Integraal beheer van alle aspecten van het project: die aspecten moeten ook in relatie gezien worden tot de portfolio en de strategie waar het project een onderdeel van is. Opstellen en verspreiden van planningen en voortgangsrapporten zijn hier de sleutelwoorden.
- Beheer van het doel van het project: wat valt binnen de opdracht en wat niet?
- Tijdsbeheer: controleren of het project nog steeds binnen de afgesproken tijdslimieten klaar zal zijn.
- Kostenbeheer: controleren of het project binnen de afgesproken budgetten gerealiseerd kan worden.
- Kwaliteitsbeheer: controleren of het project nog steeds tegemoetkomt aan alle contractueel vastgelegde eisen van de opdrachtgever.
- Personeelsbeheer: controleren of alle nodige competenties aanwezig zijn in het projectteam.
- Communicatiebeheer: respecteren van de afspraken over communicatie en rapporteringslijnen.
- Beheer van de risico’s: alle mogelijke operaties opzetten om potentiële extra uitdagingen onder controle te houden.
- Aankoopbeheer: controleren of de nodige infrastructuur op tijd besteld en beschikbaar is.
- Stakeholders beheren.
In tegenstelling tot een specifieke projectmanagement methode als Prince2 wordt PMBOK met name in de Verenigde Staten en het Verre Oosten gebruikt. PMBOK is het referentiewerk waarop het PMP-examen (Project Management Professional) is gebaseerd.
Externe link
Scrum (ontwikkelmethode)
Bron link onderaan
Scrum is een flexibele manier om (software)producten te maken. Er wordt gewerkt in multidisciplinaire teams die in korte sprints, met een vaste lengte van 1 tot 4 weken, werkende (software) producten opleveren. Scrum is een term die afkomstig is uit de rugbysport. Bij een scrum probeert een team samen een doel te bereiken en de wedstrijd te winnen. Samenwerking is heel belangrijk en men moet snel kunnen inspelen op veranderende omstandigheden.
Scrum wordt vaak gebruikt bij producten waarvan de klant c.q. gebruiker nog niet goed weet wat hij wil en waarbij men al doende leert om de eisen en wensen beter te beschrijven en in bruikbare producten om te zetten. Vaak weet men pas wat men wil als men het eerste product, het prototype, ziet en dan worden alsnog de eisen aangepast. Scrum heeft de flexibiliteit om met laat wijzigende eisen en wensen om te gaan. Scrum valt onder de Agile-softwareontwikkeling.
[...]
Doelstellingen
- In korte sprints snel werkende producten opleveren, waardoor snel duidelijk wordt of men goed bezig is. Dit beperkt de risico's van langdurige projecten waarin gebruikers of klanten soms pas na een jaar het resultaat kunnen zien en uitproberen.
- Snel duidelijkheid over de voortgang.
- Korte lijnen, snelle communicatie, teamwerk.
- Grotere betrokkenheid teamleden, concentratie op overzichtelijk deel van project
Ontwikkel iteraties Scrum
Theorie
Scrum is gebaseerd op de theorie van empirische procesbesturing, ofwel het empirisme. Empirisme gaat ervan uit dat kennis ontstaat uit ervaring en het nemen van beslissingen op basis van wat bekend is. Scrum gebruikt een iteratieve, incrementele aanpak om voorspelbaarheid te optimaliseren en risico’s te beheersen.
Drie pijlers vormen het fundament van elke implementatie van empirische procesbesturing:
transparantie, inspectie en aanpassing
Uitgangspunten
Scrum heeft de volgende uitgangspunten:
- Toewijding: de leden moeten zich er vol voor inzetten; het is geen deeltijdklus.
- Focus: men moet zich focussen op wat er in de sprints gedaan moet worden.
- Openheid: men moet elkaar goed op de hoogte houden van de voortgang en mogelijke problemen. (transparantie)
- Respect: men moet mensen met een andere achtergrond en expertise respecteren.
- Lef: men moet lef hebben om zaken te benoemen, vragen te stellen en met nieuwe oplossingen te komen.
Werkwijze
Scrum werkt met multidisciplinaire teams, die bij voorkeur in één ruimte werken, zodat er gemakkelijk kan worden overlegd. Het team wordt begeleid door een Scrum Master, die een faciliterende rol heeft. De Product Owner of Producteigenaar, is de klant of opdrachtgever, of een vertegenwoordiger daarvan. Hij of zij specificeert de gewenste resultaten, meestal in de vorm van user stories. Deze user stories worden bijgehouden in een lijst, de product backlog of werkvoorraad. De Producteigenaar sorteert de werkvoorraad op prioriteit. De belangrijkste user stories staan bovenaan.
Er wordt gewerkt in Sprints of iteraties. Die duren meestal van ca. een week tot een maand, met een tijdsduur van twee weken als meest gebruikelijke tijdsduur. Sprints zijn time boxed. Oftewel: Vantevoren staat vast hoe lang een sprint maximaal duurt, en wanneer deze is afgelopen. Aan het begin van een Sprint worden de user stories voor die Sprint bepaald en vastgelegd in de Sprint Backlog.
Sprints resulteren in zo tastbaar mogelijke resultaten. Tav. softwareontwikkeling kan dat betrekking hebben op bruikbare code, inclusief integratie, tests en documentatie, en liefst toepasbaar voor de klant of eindgebruiker.
Aan het eind van een Sprint vindt een Sprint Review plaats, waarbij het resultaat wordt getoond aan de product owner. Daarnaast vindt een evaluatie binnen het team plaats.
Rollen
Bij Scrum kent men de volgende drie hoofdrollen[1]. Deze zijn:
- Product Owner
- De Product Owner (producteigenaar) is de opdrachtgever of klant. Hij heeft het meeste belang bij het (software)product dat gemaakt wordt. Hij zorgt ervoor dat de rekening betaald wordt. Hij beheert ook de product backlog, hij bepaalt wat er moet gebeuren en in welke volgorde. In principe wordt begonnen met het belangrijkste, waar het meeste voordeel mee te behalen is, wat boven aan de product backlog staat.
- Ontwikkelteam
- Het ontwikkelteam is multidisciplinair samengesteld en is verantwoordelijk voor het afleveren van het (software)product aan het einde van elke sprint. Het team bestaat meestal uit 3 tot 9 personen. Het team organiseert zichzelf. Zij doen de analyse, ontwerp, ontwikkeling, test en documentatie en zorgen dat er aan het eind van de sprint een kant en klaar product is, dat in principe in productie genomen kan worden.
- Scrummaster
- De Scrum Master begeleidt en helpt het team door ervoor te zorgen dat het juiste scrumproces gevolgd wordt. Hij verzorgt ook eventuele trainingen. De scrummaster regelt alle vergaderingen. Ook regelt hij de voorzieningen zoals een werkruimte, hardware en software. De scrummaster zorgt ervoor dat het team niet lastig gevallen wordt door derden die met extra eisen tussendoor komen of die bijvoorbeeld tijdelijk mensen nodig hebben uit het team. De scrummaster is geen projectmanager. Hij regelt bijvoorbeeld niet de personele zaken zoals selectie, beoordeling en beloning van de mensen. Dit bevordert de openheid en samenwerking.
[...]
Andere Agile-methoden
- Extreme programming
- Agile Unified Process
- Crystal (softwareontwikkeling)
- Dynamic systems development method
- Test-driven development