archive-nl.com » NL » I » ITPEDIA.NL

Total: 523

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Scrum | Welkom op ITpedia
    features die zijn doelen helpt bereiken Advocaat van de klant begrijpt de behoefte van de organisatie die het product koopt en selecteert een mix van features die waardevol voor hem zijn Advocaat van de gebruiker kan vanuit de gebruiker uitleggen waarom het product wel of niet voor hem werkt en aangeven hoe hij het product wel wil kunnen gebruiken Materiedeskundige beantwoordt technische vragen over het domein o a gebruik gebruiker organisatie markt aan degenen die het product maken Ontwerper voegt business klant en gebruikersbehoeften samen in een productontwerp dat voor iedereen bevredigend is Bewaakt coherentie terwijl het product wordt gemaakt en uitgebreid Communicator is in staat om de visie achter en de bedoeling van het product te communiceren daarmee helpen feature en ontwerpbeslissingen te nemen Besluitnemer neemt bij conflicterende doelen belangen en of meningen moeilijke productbeslissingen 2 Word een ontwerpfacilitator Design isn t something that designers produce design is a process that designers facilitate Leah Buley Adaptive Path Idealiter denkt iedereen in je agile team mee over ontwerp Faciliteer het team daarin Gebruik bijvoorbeeld workshops om informatie te verzamelen en te analyseren ontwerpideeën te vormen anderen te betrekken in het ontwerpproces onderzoek en kennis te delen Design by community is not design by committee Leisa Reichelt Disambiguity Samenwerken in ontwerp betekent niet dat dat jij niet meer verantwoordelijk bent voor het ontwerp Gebruik je team klanten en gebruikers om informatie en inzichten te verzamelen en te betrekken in besluitvorming Sommige beslissingen neem je als team andere neem jij als ontwerper en product owner 3 Onderzoek modelleer en ontwerp vooraf maar niet teveel Ook in agile Scrum projecten is er een stap die altijd voor de iteratieve sprints komt het definiëren van het productbacklog Het productbacklog is de masterlijst van alle gewenste functionaliteiten in het product Bij de start van een agile project wordt niet verwacht dat er al een uitputtende lijst gemaakt kan worden Agile gaat immers uit van voortschrijdend inzicht Er wordt dan ook niet heel veel tijd in gestoken Meestal worden de meest voor de hand liggende dingen opgeschreven wat vaak al meer dan genoeg is voor de eerste sprint Dat neemt niet weg dat het maken van het productbacklog een fase op zich is waar veel aandacht aan besteed moet worden Dit is een ideaal moment om wat user research te doen en businessdoelen vast te stellen Probeer ook een globaal beeld te vormen van de interactie die jij bij het product en de gebruikers vindt passen Gebruik dit vervolgens allemaal bij het schrijven van de gebruikerscenario s user stories Denk ook alvast na hoe je in de rest van het project om wilt gaan met user usability research 4 Hak je ontwerpwerk in brokken maar voorkom dat ontwerptijd in het gedrang komt Dit kun je doen door ontwerpintensieve iteraties af te wisselen met ontwikkelintensieve iteraties Voor contentgedreven websites is dit een stuk lastiger dan voor de meeste applicaties In applicaties zijn functionaliteiten vaak te relateren aan specifieke acties knoppen menu items en daardoor goed te isoleren

    Original URL path: http://www.itpedia.nl/tag/scrum/ (2014-12-07)
    Open archived version from archive


  • Een website ontwerpen met agile design en scrum, wat heb je nodig? | Welkom op ITpedia
    en 4 weken met 3 weken als duidelijk optimum Fabrique onderscheidt deze sprints Sprint 0 De eerste sprint die als kwartiermakersfase zou kunnen worden gekenmerkt Alle benodigde aanleveringen worden gedaan research wordt gedaan persona s en scenario s worden opgesteld en er wordt een redelijk precieze omschrijving van de scope van het project gemaakt In Scrum heet dat laatste de product backlog Zelfgereguleerde sprints Soms plannen we een aantal gelijkvormige sprints achter elkaar Deze sprints zijn communicerende vaten Het team bewaakt zijn eigen voortgang velocity per sprint en stuurt indien nodig bij Dit is de klassieke Scrum aanpak Fixed deliverable sprints Het kan handiger zijn om elke sprint een vast resultaat te geven zoals een tak van een website of verschillende middelen Split sprints in dit sprinttype zijn in één ruimte twee scrum teams tegelijkertijd bezig een design team en een software ontwikkelingsteam Daily scrums zijn gezamenlijk maar het ontwikkelaarsteam loopt één sprint achter en bouwt wat het design team in de sprint ervoor heeft ontworpen Ja au Maar het werkt Sweep sprint Soms is het handiger om het rework op sprintresultaten niet meteen te doen maar al het rework te verzamelen in één laatste sprint Onze ervaring Fixed deliverable sprints is de meest laagdrempelige vorm om mee te beginnen De fixed deliverables geven houvast en zorgen dat je je geen zorgen hoeft te maken over ingewikkelde zaken zoals velocity of een grote homogene product backlog De meeste van onze Agile projecten hebben fixed deliverable sprints Agile projecten mèt ontwikkeling zijn bij ons split sprints We hebben geprobeerd om ontwerp en ontwikkeling in één sprint te vatten maar het is om allerlei redenen heel lastig zo niet onmogelijk om het efficiënt te laten gebeuren Het doet pijn om zo n waterval te moeten laten bestaan maar uit rondvraag blijkt dat ook anderen met hetzelfde probleem zitten Jammer Toch streven we er nog steeds naar om split sprints te voorkomen We proberen nog verschillende dingen uit bijvoorbeeld eerder prototypen of tweetallen maken van ontwerper en programmeur Product backlog Elke sprint bestaat uit meerdere stories Een story is een herkenbare min of meer op zichzelf staande eenheid in de sprint De verzameling van alle stories over het hele project heet de product backlog Hier zie je de product backlog van het Allerhande project voor Albert Heijn De items worden ingedeeld in drie groepen van grof idee naar ready for sprint Terwijl de sprints vorderen zorgt de product owner de klant er samen met de scrum master voor dat de product backlog gevuld blijft en dat de stories snel genoeg concreet worden Een story is ready for sprint als er genoeg input voor aanwezig is en er een redelijk heldere inschatting gemaakt kan worden van de bijbehorende ontwerp en ontwikkelinspanning TIP Besteed met een deel van het agile team iedere dag 10 minuten om stories te concretiseren en zo de volgende sprint voor te bereiden User stories Een story is geredeneerd vanuit een user benefit en ziet er bijvoorbeeld zo uit As a

    Original URL path: http://www.itpedia.nl/2012/03/19/een-website-ontwerpen-met-agile-design-en-scrum-wat-heb-je-nodig/ (2014-12-07)
    Open archived version from archive

  • Programmamanagement | Welkom op ITpedia
    organisatie in een komende periode gaat uitvoeren bij elkaar opgeteld worden geeft dat een indicatie van de werkdruk Op jaarbasis moet het totaal aantal FTE in dienst meer zijn dan alle uren opgeteld uit de projectplannen Bijvoorbeeld 10 projecten verbruiken samen 20 000 uur In de organisatie werken 20 FTE Per FTE wordt er in onze organisatie 1700 uur gewerkt Daarvan is 70 vrij voor projecten en 30 voor algemeen werk vergaderen email reistijd overige werkzaamheden studieverlof Netto komt dat neer op 20 x 1700 x 70 23800 uur per jaar beschikbaar voor projecten In dit voorbeeld is er dus globaal gezien voldoende capaciteit om deze projecten uit te voeren komend jaar Veel meer kan er niet bij zonder meer mensen in dienst te nemen ook hier is een marge nodig Bovenstaande controle is een globale controle op jaarbasis Daarnaast is een fijnere controle van de capaciteit nodig gespecificeerd naar de taken of rollen die projectmedewerkers hebben Die 20 FTE moet verder onderverdeeld worden naar verschillende rollen binnen een project bijvoorbeeld programmeurs projectleiders designers systeembeheerders Het kan best zo zijn dat er in totaal voldoende mensen in dienst zijn om de plannen voor komend jaar uit te voeren maar bijvoorbeeld te veel projectleiders en te weinig programmeurs Tenslotte moet de werklast aantal verwachte uren van de projecten niet alleen per jaar overeenkomen met het aantal beschikbare uren van de medewerkers dit moet ook gelden voor kortere periodes Als in het bovenstaande voorbeeld alle projecten gepland zijn in de eerste drie maanden van het jaar is er toch een knelpunt alhoewel er voldoende mensen in dienst zijn op jaarbasis De operationele verdeling van mensen op maand of zelfs weekbasis gebeurt op basis van de plannen van de fases van de projecten of tijdboxen als het gaat om cyclische projecten Daarnaast is een wekelijks of maandelijks overleg van programmamanager met alle projectleiders nodig om de mensen operationeel in te plannen Ten aanzien van tijd wordt een aantal klachten veelvuldig gehoord in projectorganisaties Er is geen goed beeld van de werkdruk die er heerst De sales afdeling of het management blijven er maar nieuwe projecten bij doen terwijl we nu al niet goed toekomen aan de projecten die we nu moeten uitvoeren Als één van de projecten uitloopt dan heeft dat heel veel gevolgen voor andere projecten Omdat we de resources moeten delen betekent dat vertraging in het eerste project ook alle andere projecten vertraagt De eerste klacht komt veel voor bij snel groeiende organisaties waar men vooral oog heeft voor het werven van zoveel mogelijk omzet Door bovenstaande controle mechanismen in te voeren ontstaat er overzicht over de capaciteit op jaarbasis en op operationele basis van maand tot maand of zelfs week tot week De tweede klacht heeft een paar oorzaken Allereerst is het bij organisaties waar deze klacht voorkomt vaak zo dat men niet goed in staat is oude projecten af te sluiten Elke keer als het project klaar zou moeten zijn komt er weer een nieuwe eis van de klant een nieuwe bug of een uitbreiding op het project Om dit tegen te gaan is het belangrijk om bij het begin van het project zo duidelijk mogelijke afspraken te maken wanneer het project klaar is Zie ook eerdere hoofdstukken over dit probleem Daarnaast geldt er bij de tweede klacht ook dat er sprake is van een te hoge werkdruk Omdat het zo druk is worden er geen marges tussen de projecten gepland Hierdoor heeft een kleine uitloop van een vorig project direct gevolgen heeft voor volgende projecten Tenslotte kan gezegd worden dat het tweede probleem minder vaak voor komt bij organisaties die cyclisch projectmanagement toepassen omdat daar met vaste tijdboxen gewerkt wordt Om de productiviteit te verhogen wordt personeel vaak op te veel projecten ingezet Een poging de verloren uurtjes te vullen met andere projecten leidt echter tot ernstige vertragingen Het volgende voorbeeld illustreert dat overgenomen en aangepast uit Goldratt 2002 Stel dat iemand een project A moet uitvoeren dat bestaat uit drie taken a en een project B moet uitvoeren dat bestaat uit drie taken b Elke taak kost 5 eenheden tijd Als hij ze uitvoert in de volgorde aaa bbb dan is taak A klaar na 5 5 5 15 eenheden Taak B is ook na 15 eenheden klaar gemeten vanaf het moment dat project B start Als hij ze echter niet na elkaar maar tegelijk dat wil zeggen door elkaar moet uitvoeren ziet het plaatje er anders uit Stel dat hij een taak a steeds afwisselt met een taak b De volgorde van werken is dan ababab Nu duurt het 5 5 5 5 5 25 eenheden voordat A klaar is en ook 25 eenheden voordat B klaar is Daarbij het feit dat het switchen tussen projecten zelf ook tijd kost nog niet meegenomen Volgens Goldratt 2002 is de praktijk dat veel personeel binnen organisaties ingezet wordt op veel verschillende projecten tegelijk een van de belangrijkste oorzaken van het feit dat projecten veel te lang duren Projecten waar een doorlooptijd van drie maanden voor staat duren in de praktijk soms wel meer dan twee jaar Als de projecten één voor één na elkaar werden gedaan waren ze elk na ongeveer drie maanden klaar geweest Uit bovenstaand voorbeeld maar bijvoorbeeld ook uit de kennis van de wachtrijtheorie blijkt dat het niet verstandig is om het personeel te vol te bezetten Uit kostenoverwegingen op korte termijn zijn management teams er vooral op gefocust om iedereen zo veel mogelijk te laten werken Hierdoor gaat er veel snelheid in projecten verloren Het kan best zo zijn dat het verhogen van de bezettingsgraad van het personeel met 10 leidt tot een verhoging van de gemiddelde doorlooptijd van projecten met 40 Deze kosten van vertraging zijn echter veel minder zichtbaar zeker in non profit organisaties Tijdschrijven Het is aan de programmamanager om bij aanvang van een nieuw project bovenstaande controles op financieel vlak en op gebied van urencapaciteit uit te voeren Dit moet hij tevens doen tussen de fases van een project dan

    Original URL path: http://www.itpedia.nl/2012/02/06/programmamanagement/ (2014-12-07)
    Open archived version from archive

  • Programmamanagement | Welkom op ITpedia
    euro nodig had Gelukkig is niet te achterhalen wat die programmeurs allemaal deden in de uren die ze schreven op de projecten Dus een beetje schuiven met uren en het klopt allemaal weer Logisch dat organisaties zo omgaan met hun gesubsidieerde projecten ze kunnen niet veel anders Het is een direct gevolg van het feit dat organisaties bij een aanvraag een totaal budget moeten opstellen waar ze later niet meer van mogen afwijken Een gevolg van deze situatie is dat de financiële projectrapportages van gesubsidieerde projecten met een korrel zout genomen moeten worden Vanuit het oogpunt van projectmanagement is dat jammer omdat nu niet goed te achterhalen is hoeveel projecten echt gekost hebben Vanuit het oogpunt van accountability van het subsidiegeld is het ook geen goede zaak Tijd Als alle begrotingen van de uren van de projecten die een organisatie in een komende periode gaat uitvoeren bij elkaar opgeteld worden geeft dat een indicatie van de werkdruk Op jaarbasis moet het totaal aantal FTE in dienst meer zijn dan alle uren opgeteld uit de projectplannen Bijvoorbeeld 10 projecten verbruiken samen 20 000 uur In de organisatie werken 20 FTE Per FTE wordt er in onze organisatie 1700 uur gewerkt Daarvan is 70 vrij voor projecten en 30 voor algemeen werk vergaderen email reistijd overige werkzaamheden studieverlof Netto komt dat neer op 20 x 1700 x 70 23800 uur per jaar beschikbaar voor projecten In dit voorbeeld is er dus globaal gezien voldoende capaciteit om deze projecten uit te voeren komend jaar Veel meer kan er niet bij zonder meer mensen in dienst te nemen ook hier is een marge nodig Bovenstaande controle is een globale controle op jaarbasis Daarnaast is een fijnere controle van de capaciteit nodig gespecificeerd naar de taken of rollen die projectmedewerkers hebben Die 20 FTE moet verder onderverdeeld worden naar verschillende rollen binnen een project bijvoorbeeld programmeurs projectleiders designers systeembeheerders Het kan best zo zijn dat er in totaal voldoende mensen in dienst zijn om de plannen voor komend jaar uit te voeren maar bijvoorbeeld te veel projectleiders en te weinig programmeurs Tenslotte moet de werklast aantal verwachte uren van de projecten niet alleen per jaar overeenkomen met het aantal beschikbare uren van de medewerkers dit moet ook gelden voor kortere periodes Als in het bovenstaande voorbeeld alle projecten gepland zijn in de eerste drie maanden van het jaar is er toch een knelpunt alhoewel er voldoende mensen in dienst zijn op jaarbasis De operationele verdeling van mensen op maand of zelfs weekbasis gebeurt op basis van de plannen van de fases van de projecten of tijdboxen als het gaat om cyclische projecten Daarnaast is een wekelijks of maandelijks overleg van programmamanager met alle projectleiders nodig om de mensen operationeel in te plannen Ten aanzien van tijd wordt een aantal klachten veelvuldig gehoord in projectorganisaties Er is geen goed beeld van de werkdruk die er heerst De sales afdeling of het management blijven er maar nieuwe projecten bij doen terwijl we nu al niet goed toekomen aan de projecten die we nu moeten uitvoeren Als één van de projecten uitloopt dan heeft dat heel veel gevolgen voor andere projecten Omdat we de resources moeten delen betekent dat vertraging in het eerste project ook alle andere projecten vertraagt De eerste klacht komt veel voor bij snel groeiende organisaties waar men vooral oog heeft voor het werven van zoveel mogelijk omzet Door bovenstaande controle mechanismen in te voeren ontstaat er overzicht over de capaciteit op jaarbasis en op operationele basis van maand tot maand of zelfs week tot week De tweede klacht heeft een paar oorzaken Allereerst is het bij organisaties waar deze klacht voorkomt vaak zo dat men niet goed in staat is oude projecten af te sluiten Elke keer als het project klaar zou moeten zijn komt er weer een nieuwe eis van de klant een nieuwe bug of een uitbreiding op het project Om dit tegen te gaan is het belangrijk om bij het begin van het project zo duidelijk mogelijke afspraken te maken wanneer het project klaar is Zie ook eerdere hoofdstukken over dit probleem Daarnaast geldt er bij de tweede klacht ook dat er sprake is van een te hoge werkdruk Omdat het zo druk is worden er geen marges tussen de projecten gepland Hierdoor heeft een kleine uitloop van een vorig project direct gevolgen heeft voor volgende projecten Tenslotte kan gezegd worden dat het tweede probleem minder vaak voor komt bij organisaties die cyclisch projectmanagement toepassen omdat daar met vaste tijdboxen gewerkt wordt Om de productiviteit te verhogen wordt personeel vaak op te veel projecten ingezet Een poging de verloren uurtjes te vullen met andere projecten leidt echter tot ernstige vertragingen Het volgende voorbeeld illustreert dat overgenomen en aangepast uit Goldratt 2002 Stel dat iemand een project A moet uitvoeren dat bestaat uit drie taken a en een project B moet uitvoeren dat bestaat uit drie taken b Elke taak kost 5 eenheden tijd Als hij ze uitvoert in de volgorde aaa bbb dan is taak A klaar na 5 5 5 15 eenheden Taak B is ook na 15 eenheden klaar gemeten vanaf het moment dat project B start Als hij ze echter niet na elkaar maar tegelijk dat wil zeggen door elkaar moet uitvoeren ziet het plaatje er anders uit Stel dat hij een taak a steeds afwisselt met een taak b De volgorde van werken is dan ababab Nu duurt het 5 5 5 5 5 25 eenheden voordat A klaar is en ook 25 eenheden voordat B klaar is Daarbij het feit dat het switchen tussen projecten zelf ook tijd kost nog niet meegenomen Volgens Goldratt 2002 is de praktijk dat veel personeel binnen organisaties ingezet wordt op veel verschillende projecten tegelijk een van de belangrijkste oorzaken van het feit dat projecten veel te lang duren Projecten waar een doorlooptijd van drie maanden voor staat duren in de praktijk soms wel meer dan twee jaar Als de projecten één voor één na elkaar werden gedaan waren ze elk

    Original URL path: http://www.itpedia.nl/tag/programmamanagement/ (2014-12-07)
    Open archived version from archive

  • Projectportfolio | Welkom op ITpedia
    euro nodig had Gelukkig is niet te achterhalen wat die programmeurs allemaal deden in de uren die ze schreven op de projecten Dus een beetje schuiven met uren en het klopt allemaal weer Logisch dat organisaties zo omgaan met hun gesubsidieerde projecten ze kunnen niet veel anders Het is een direct gevolg van het feit dat organisaties bij een aanvraag een totaal budget moeten opstellen waar ze later niet meer van mogen afwijken Een gevolg van deze situatie is dat de financiële projectrapportages van gesubsidieerde projecten met een korrel zout genomen moeten worden Vanuit het oogpunt van projectmanagement is dat jammer omdat nu niet goed te achterhalen is hoeveel projecten echt gekost hebben Vanuit het oogpunt van accountability van het subsidiegeld is het ook geen goede zaak Tijd Als alle begrotingen van de uren van de projecten die een organisatie in een komende periode gaat uitvoeren bij elkaar opgeteld worden geeft dat een indicatie van de werkdruk Op jaarbasis moet het totaal aantal FTE in dienst meer zijn dan alle uren opgeteld uit de projectplannen Bijvoorbeeld 10 projecten verbruiken samen 20 000 uur In de organisatie werken 20 FTE Per FTE wordt er in onze organisatie 1700 uur gewerkt Daarvan is 70 vrij voor projecten en 30 voor algemeen werk vergaderen email reistijd overige werkzaamheden studieverlof Netto komt dat neer op 20 x 1700 x 70 23800 uur per jaar beschikbaar voor projecten In dit voorbeeld is er dus globaal gezien voldoende capaciteit om deze projecten uit te voeren komend jaar Veel meer kan er niet bij zonder meer mensen in dienst te nemen ook hier is een marge nodig Bovenstaande controle is een globale controle op jaarbasis Daarnaast is een fijnere controle van de capaciteit nodig gespecificeerd naar de taken of rollen die projectmedewerkers hebben Die 20 FTE moet verder onderverdeeld worden naar verschillende rollen binnen een project bijvoorbeeld programmeurs projectleiders designers systeembeheerders Het kan best zo zijn dat er in totaal voldoende mensen in dienst zijn om de plannen voor komend jaar uit te voeren maar bijvoorbeeld te veel projectleiders en te weinig programmeurs Tenslotte moet de werklast aantal verwachte uren van de projecten niet alleen per jaar overeenkomen met het aantal beschikbare uren van de medewerkers dit moet ook gelden voor kortere periodes Als in het bovenstaande voorbeeld alle projecten gepland zijn in de eerste drie maanden van het jaar is er toch een knelpunt alhoewel er voldoende mensen in dienst zijn op jaarbasis De operationele verdeling van mensen op maand of zelfs weekbasis gebeurt op basis van de plannen van de fases van de projecten of tijdboxen als het gaat om cyclische projecten Daarnaast is een wekelijks of maandelijks overleg van programmamanager met alle projectleiders nodig om de mensen operationeel in te plannen Ten aanzien van tijd wordt een aantal klachten veelvuldig gehoord in projectorganisaties Er is geen goed beeld van de werkdruk die er heerst De sales afdeling of het management blijven er maar nieuwe projecten bij doen terwijl we nu al niet goed toekomen aan de projecten die we nu moeten uitvoeren Als één van de projecten uitloopt dan heeft dat heel veel gevolgen voor andere projecten Omdat we de resources moeten delen betekent dat vertraging in het eerste project ook alle andere projecten vertraagt De eerste klacht komt veel voor bij snel groeiende organisaties waar men vooral oog heeft voor het werven van zoveel mogelijk omzet Door bovenstaande controle mechanismen in te voeren ontstaat er overzicht over de capaciteit op jaarbasis en op operationele basis van maand tot maand of zelfs week tot week De tweede klacht heeft een paar oorzaken Allereerst is het bij organisaties waar deze klacht voorkomt vaak zo dat men niet goed in staat is oude projecten af te sluiten Elke keer als het project klaar zou moeten zijn komt er weer een nieuwe eis van de klant een nieuwe bug of een uitbreiding op het project Om dit tegen te gaan is het belangrijk om bij het begin van het project zo duidelijk mogelijke afspraken te maken wanneer het project klaar is Zie ook eerdere hoofdstukken over dit probleem Daarnaast geldt er bij de tweede klacht ook dat er sprake is van een te hoge werkdruk Omdat het zo druk is worden er geen marges tussen de projecten gepland Hierdoor heeft een kleine uitloop van een vorig project direct gevolgen heeft voor volgende projecten Tenslotte kan gezegd worden dat het tweede probleem minder vaak voor komt bij organisaties die cyclisch projectmanagement toepassen omdat daar met vaste tijdboxen gewerkt wordt Om de productiviteit te verhogen wordt personeel vaak op te veel projecten ingezet Een poging de verloren uurtjes te vullen met andere projecten leidt echter tot ernstige vertragingen Het volgende voorbeeld illustreert dat overgenomen en aangepast uit Goldratt 2002 Stel dat iemand een project A moet uitvoeren dat bestaat uit drie taken a en een project B moet uitvoeren dat bestaat uit drie taken b Elke taak kost 5 eenheden tijd Als hij ze uitvoert in de volgorde aaa bbb dan is taak A klaar na 5 5 5 15 eenheden Taak B is ook na 15 eenheden klaar gemeten vanaf het moment dat project B start Als hij ze echter niet na elkaar maar tegelijk dat wil zeggen door elkaar moet uitvoeren ziet het plaatje er anders uit Stel dat hij een taak a steeds afwisselt met een taak b De volgorde van werken is dan ababab Nu duurt het 5 5 5 5 5 25 eenheden voordat A klaar is en ook 25 eenheden voordat B klaar is Daarbij het feit dat het switchen tussen projecten zelf ook tijd kost nog niet meegenomen Volgens Goldratt 2002 is de praktijk dat veel personeel binnen organisaties ingezet wordt op veel verschillende projecten tegelijk een van de belangrijkste oorzaken van het feit dat projecten veel te lang duren Projecten waar een doorlooptijd van drie maanden voor staat duren in de praktijk soms wel meer dan twee jaar Als de projecten één voor één na elkaar werden gedaan waren ze elk

    Original URL path: http://www.itpedia.nl/tag/projectportfolio/ (2014-12-07)
    Open archived version from archive

  • Combi`s van gesloten en open software | Welkom op ITpedia
    kijken naar uw systeem voor e mail agenda contactpersonen en dergelijke Outlook is het eerste dat nu in u opkomt Outlook is een applicatie op de desktop ook wel client genoemd Aan de serverkant heeft u daarvoor Microsoft Exchange nodig al of niet opgenomen in een Microsoft Small Business Server Althans dat was zo in de oude wereld toen alles nog in één kleur werd geverfd Inmiddels zijn er hele goede vervangers voor MS Exchange beschikbaar zoals het in Delft ontwikkelde Zarafa Deze software is grotendeels open source scheelt ongeveer de helft in de kosten en het leuke u kunt gewoon MS Outlook op de pc s blijven gebruiken zie hiervoor het praktijkvoorbeeld van Uitgeverij Boom elders op deze pagina s Uw medewerkers merken dan niks van deze verandering Maar u kunt Zarafa ook gebruiken als webmail oplossing al dan niet aanvullend op MS Outlook op de kantoor pc s of in combinatie met open source mailprogramma s als Thunderbird Er zijn daarnaast ook open source oplossingen die de complete mailomgeving vervangen dus niet alleen de Microsoft serversoftware maar ook de Outlook client zoals de Zimbra Collaboration Suite Zimbra werkt op basis van Linux serversoftware En laten we Gmail in combinatie met Google Apps niet vergeten Ook dat is een alternatieve omgeving voor bedrijfscommunicatie maar dan helemaal online U hoeft daar niets meer voor te installeren U heeft er alleen uw browser voor nodig En deze omgeving is voorlopig helemaal gratis Misschien niet de beste oplossing voor een groter gevestigd bedrijf maar voor een startende onderneming kan dit ideaal zijn CrossOver Eigenlijk is er voor bijna iedere soort gesloten software wel een open source alternatief dat u zou kunnen overwegen Het duidelijkst is dat wel bij de kantoorsoftware OpenOffice org is een prima alternatief het kost u nul euro aan licenties en is allesbehalve eenkennig waar het gaat om operating systems OpenOffice kan uit de voeten met Windows Linux Mac OS Sun Solaris en FreeBSD Maar het omgekeerde kan ook Als u of uw mensen liever verder willen met MS Office dan hoeft u helemaal nog niet vast te zitten aan Windows als operating system Met hulpprogramma s als Wine em Crossover Linux kunt u MS Office blijven gebruiken maar dan op een goedkopere Linux machine Ook op allerlei andere gebieden zijn er open alternatieven en combinatiemogelijkheden met gesloten software zoals voor Content Management Systemen ERP CRM en database systemen Denk niet te gauw dat iets niet kan Virtualisatie Naast combi s van open en gesloten software is er een nieuwe mogelijkheid die virtualisatie wordt genoemd Daarmee komt u in de riante situatie te verkeren dat het niet meer uitmaakt op welk operating system een applicatie draait In plaats van één operating system werkt u met een tussenlaag waarin verschillende operating systems functioneren Van daaruit kunt u iedere applicatie starten Of die nou op Linux op Windows op Mac OS FreeBSD Solaris of op Pietje Puk draait Dat is ideaal als u van alles het beste wilt gebruiken U komt

    Original URL path: http://www.itpedia.nl/2011/12/27/combis-van-gesloten-en-open-software/ (2014-12-07)
    Open archived version from archive

  • Kostenbesparing | Welkom op ITpedia
    dit evengoed tamelijk gesloten werelden waren met maar weinig bruggen naar de buren Door de alomtegenwoordigheid van het internet begint er nu een einde te komen aan dit tijdperk van verzuilde bedrijfssoftware Zeven van de tien webservers draaien op Apache software met Linux als operating system en mysql als database Dat is allemaal open source software U werkt dus mogelijk al geruime tijd met Linux en met andere open source software zonder dat u het zelf in de gaten heeft namelijk onder de motorkap van uw website En het blijft niet bij die Apache webserver Ook veel fileservers draaien inmiddels op Linux en kunnen dan via het hulpprogramma Samba met de rest van uw Windows omgeving en vooral de Active Directory praten En wat dacht u van firewalls Heel wat maken gebruik van open source software Kortom er zijn inmiddels allerlei soorten open software volop in gebruik Let wel middenin Windows omgevingen We gaan daarom langzaamaan toe naar een situatie waarin we niet meer spreken over Windows omgevingen of Linux omgevingen Het zijn gewoon omgevingen en ze zijn allemaal hybride dat wil zeggen dat ze uit software van verschillende herkomst zullen bestaan Multiculti maar dan digitaal Helft goedkoper En u hoeft niet passief op die fraaie toekomst te wachten want er zijn nu al een hoop lucratieve combinaties mogelijk Laten we om te beginnen maar eens kijken naar uw systeem voor e mail agenda contactpersonen en dergelijke Outlook is het eerste dat nu in u opkomt Outlook is een applicatie op de desktop ook wel client genoemd Aan de serverkant heeft u daarvoor Microsoft Exchange nodig al of niet opgenomen in een Microsoft Small Business Server Althans dat was zo in de oude wereld toen alles nog in één kleur werd geverfd Inmiddels zijn er hele goede vervangers voor MS Exchange beschikbaar zoals het in Delft ontwikkelde Zarafa Deze software is grotendeels open source scheelt ongeveer de helft in de kosten en het leuke u kunt gewoon MS Outlook op de pc s blijven gebruiken zie hiervoor het praktijkvoorbeeld van Uitgeverij Boom elders op deze pagina s Uw medewerkers merken dan niks van deze verandering Maar u kunt Zarafa ook gebruiken als webmail oplossing al dan niet aanvullend op MS Outlook op de kantoor pc s of in combinatie met open source mailprogramma s als Thunderbird Er zijn daarnaast ook open source oplossingen die de complete mailomgeving vervangen dus niet alleen de Microsoft serversoftware maar ook de Outlook client zoals de Zimbra Collaboration Suite Zimbra werkt op basis van Linux serversoftware En laten we Gmail in combinatie met Google Apps niet vergeten Ook dat is een alternatieve omgeving voor bedrijfscommunicatie maar dan helemaal online U hoeft daar niets meer voor te installeren U heeft er alleen uw browser voor nodig En deze omgeving is voorlopig helemaal gratis Misschien niet de beste oplossing voor een groter gevestigd bedrijf maar voor een startende onderneming kan dit ideaal zijn CrossOver Eigenlijk is er voor bijna iedere soort gesloten software wel een open source

    Original URL path: http://www.itpedia.nl/tag/kostenbesparing/ (2014-12-07)
    Open archived version from archive

  • Opensource | Welkom op ITpedia
    al te veel verrassingen te staan De enkeling die tegen deze stroom oproeide en zich tot de Mac of tot Linux bekeerde ontdekte al snel dat dit evengoed tamelijk gesloten werelden waren met maar weinig bruggen naar de buren Door de alomtegenwoordigheid van het internet begint er nu een einde te komen aan dit tijdperk van verzuilde bedrijfssoftware Zeven van de tien webservers draaien op Apache software met Linux als operating system en mysql als database Dat is allemaal open source software U werkt dus mogelijk al geruime tijd met Linux en met andere open source software zonder dat u het zelf in de gaten heeft namelijk onder de motorkap van uw website En het blijft niet bij die Apache webserver Ook veel fileservers draaien inmiddels op Linux en kunnen dan via het hulpprogramma Samba met de rest van uw Windows omgeving en vooral de Active Directory praten En wat dacht u van firewalls Heel wat maken gebruik van open source software Kortom er zijn inmiddels allerlei soorten open software volop in gebruik Let wel middenin Windows omgevingen We gaan daarom langzaamaan toe naar een situatie waarin we niet meer spreken over Windows omgevingen of Linux omgevingen Het zijn gewoon omgevingen en ze zijn allemaal hybride dat wil zeggen dat ze uit software van verschillende herkomst zullen bestaan Multiculti maar dan digitaal Helft goedkoper En u hoeft niet passief op die fraaie toekomst te wachten want er zijn nu al een hoop lucratieve combinaties mogelijk Laten we om te beginnen maar eens kijken naar uw systeem voor e mail agenda contactpersonen en dergelijke Outlook is het eerste dat nu in u opkomt Outlook is een applicatie op de desktop ook wel client genoemd Aan de serverkant heeft u daarvoor Microsoft Exchange nodig al of niet opgenomen in een Microsoft Small Business Server Althans dat was zo in de oude wereld toen alles nog in één kleur werd geverfd Inmiddels zijn er hele goede vervangers voor MS Exchange beschikbaar zoals het in Delft ontwikkelde Zarafa Deze software is grotendeels open source scheelt ongeveer de helft in de kosten en het leuke u kunt gewoon MS Outlook op de pc s blijven gebruiken zie hiervoor het praktijkvoorbeeld van Uitgeverij Boom elders op deze pagina s Uw medewerkers merken dan niks van deze verandering Maar u kunt Zarafa ook gebruiken als webmail oplossing al dan niet aanvullend op MS Outlook op de kantoor pc s of in combinatie met open source mailprogramma s als Thunderbird Er zijn daarnaast ook open source oplossingen die de complete mailomgeving vervangen dus niet alleen de Microsoft serversoftware maar ook de Outlook client zoals de Zimbra Collaboration Suite Zimbra werkt op basis van Linux serversoftware En laten we Gmail in combinatie met Google Apps niet vergeten Ook dat is een alternatieve omgeving voor bedrijfscommunicatie maar dan helemaal online U hoeft daar niets meer voor te installeren U heeft er alleen uw browser voor nodig En deze omgeving is voorlopig helemaal gratis Misschien niet de beste oplossing voor een

    Original URL path: http://www.itpedia.nl/tag/opensource/ (2014-12-07)
    Open archived version from archive



  •