<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Reacties op: Websites op maat in het watervalmodel: Analysefase</title>
	<atom:link href="http://www.publishr.nl/2009/11/websites-op-maat-in-het-watervalmodel-analysefase/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.publishr.nl/2009/11/websites-op-maat-in-het-watervalmodel-analysefase/</link>
	<description>tips en trends in uitgeefland</description>
        	<lastBuildDate>Fri, 30 Jul 2010 08:02:27 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=3.0</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>Door: Watervalmodel: Functioneel ontwerp &#124; Publishr</title>
		<link>http://www.publishr.nl/2009/11/websites-op-maat-in-het-watervalmodel-analysefase/comment-page-1/#comment-2899</link>
		<dc:creator>Watervalmodel: Functioneel ontwerp &#124; Publishr</dc:creator>
		<pubDate>Wed, 18 Nov 2009 20:07:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.publishr.nl/?p=3304#comment-2899</guid>
		<description>[...] een reeks over het tot stand komen van een maatwerk-website. Een introductie en een artikel over de analysefase en ontwerpfase gingen hieraan vooraf. In dit artikel wordt besproken wat er in een functioneel [...]</description>
		<content:encoded><![CDATA[<p>[...] een reeks over het tot stand komen van een maatwerk-website. Een introductie en een artikel over de analysefase en ontwerpfase gingen hieraan vooraf. In dit artikel wordt besproken wat er in een functioneel [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Bart Lelieveld</title>
		<link>http://www.publishr.nl/2009/11/websites-op-maat-in-het-watervalmodel-analysefase/comment-page-1/#comment-2843</link>
		<dc:creator>Bart Lelieveld</dc:creator>
		<pubDate>Wed, 11 Nov 2009 10:09:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.publishr.nl/?p=3304#comment-2843</guid>
		<description>Beste Lenard, bedankt voor je reactie!

Ik denk ook dat sommige projecten zeker gebaat kunnen zijn met een dergelijke aanpak, of dat het zinnig kan zijn om bepaalde onderdelen op die manier aan te vliegen. Dit zijn mijns inziens vaak projecten met een hogere &#039;R&amp;D&#039;- factor. Als je vooraf niet weet wat er gebouwd moet worden en geen ontwerpen kunt maken, dan kan Scrum / Agile een optie zijn. 

Scrum / Agile development stellen ook wel echt eisen aan de betrokkenheid van de opdrachtgever in het project. Deze is budgethouder en bepaalt welke functionaliteit er gebouwd gaat worden of niet. Als je expert bent in het bouwen van sites en applicaties durf ik echter ook wel te beweren dat een goed ontwerp vooraf toch een strak project oplevert en dat je niet perse scrum / agile aan de slag moet...wellicht was dit niet mogelijk bij AEGON dat weet ik natuurlijk niet..maar het implementeren van goed gedocumenteerde webservices zou toch niet heel spannend moeten zijn??

Kun je aangeven waarom je betreurt dat er niet met een V-model is gewerkt? ik ben erg benieuwd naar de problemen die je bent tegengekomen die je binnen het watervalmodel niet goed hebt kunnen oplossen.

PS: Mijn ervaring met Scrum / Agile is dat op het eind van het project de kwaliteit te wensen overlaat (beheersbaarheid,onderhoud,doorontwikkeling, architectuur etc) en dat de klant keuzes heeft moeten maken in welke functionaliteit hij laat vallen (en dus uiteindelijk niet alles heeft). 

Wat is jouw ervaring hiermee?</description>
		<content:encoded><![CDATA[<p>Beste Lenard, bedankt voor je reactie!</p>
<p>Ik denk ook dat sommige projecten zeker gebaat kunnen zijn met een dergelijke aanpak, of dat het zinnig kan zijn om bepaalde onderdelen op die manier aan te vliegen. Dit zijn mijns inziens vaak projecten met een hogere &#8216;R&amp;D&#8217;- factor. Als je vooraf niet weet wat er gebouwd moet worden en geen ontwerpen kunt maken, dan kan Scrum / Agile een optie zijn. </p>
<p>Scrum / Agile development stellen ook wel echt eisen aan de betrokkenheid van de opdrachtgever in het project. Deze is budgethouder en bepaalt welke functionaliteit er gebouwd gaat worden of niet. Als je expert bent in het bouwen van sites en applicaties durf ik echter ook wel te beweren dat een goed ontwerp vooraf toch een strak project oplevert en dat je niet perse scrum / agile aan de slag moet&#8230;wellicht was dit niet mogelijk bij AEGON dat weet ik natuurlijk niet..maar het implementeren van goed gedocumenteerde webservices zou toch niet heel spannend moeten zijn??</p>
<p>Kun je aangeven waarom je betreurt dat er niet met een V-model is gewerkt? ik ben erg benieuwd naar de problemen die je bent tegengekomen die je binnen het watervalmodel niet goed hebt kunnen oplossen.</p>
<p>PS: Mijn ervaring met Scrum / Agile is dat op het eind van het project de kwaliteit te wensen overlaat (beheersbaarheid,onderhoud,doorontwikkeling, architectuur etc) en dat de klant keuzes heeft moeten maken in welke functionaliteit hij laat vallen (en dus uiteindelijk niet alles heeft). </p>
<p>Wat is jouw ervaring hiermee?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Lenard Kaptein</title>
		<link>http://www.publishr.nl/2009/11/websites-op-maat-in-het-watervalmodel-analysefase/comment-page-1/#comment-2837</link>
		<dc:creator>Lenard Kaptein</dc:creator>
		<pubDate>Tue, 10 Nov 2009 21:20:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.publishr.nl/?p=3304#comment-2837</guid>
		<description>Bart,
Naar mijn mening en ervaring is de waterval als basis voor website ontwikkeling helemaal geen slechte; eenvoudig te begrijpen en te beheersen. Belangrijk is m.i. dat je als leverancier of projectmanager (analoog aan situationeel leiding geven) tijdig weet te onderkennen wanneer je moet kiezen voor een andere benadering/methode. In de praktijk zie je m.i. ook dat &quot;waterval projecten&quot; agile achtige uitstapjes kennen of andersom.
Op het moment doe ik de eindfase van een portal project bij AEGON waarbij ik vooral omdat er diverse webservices geimplementeerd moeten worden dagelijks betreur dat er niet strak volgens een &quot;V&quot; of &quot;Dual V&quot; model ontwikkeld is. Aan de andere kant had de eindgebruikers interface beter op een agile manier benaderd kunnen worden. 
Vooral de laatste maanden heb ik gekozen om scrum en agile technieken te gebruiken: sprint concept van scrum om in 4-6 weken de laatste &quot;build&quot; te maken. Agile om de laatste RFC´s met de ontwikkelaar achter het scherm te implementeren. Ik leg deze keuzen niet voor aan opdrachtgever of team als: zullen we nu maar eens gaan &quot;scrummen&quot;? maar stel ze het concept van de sprint voor als manier om sneller en interactiever met een oplevering te komen.

Mijn motto: Kies niet dogmatisch voor één methode maar kies voor een basis methode en pas die aan afhankelijk van de omstandigheden en ontwikkelingen.</description>
		<content:encoded><![CDATA[<p>Bart,<br />
Naar mijn mening en ervaring is de waterval als basis voor website ontwikkeling helemaal geen slechte; eenvoudig te begrijpen en te beheersen. Belangrijk is m.i. dat je als leverancier of projectmanager (analoog aan situationeel leiding geven) tijdig weet te onderkennen wanneer je moet kiezen voor een andere benadering/methode. In de praktijk zie je m.i. ook dat &#8220;waterval projecten&#8221; agile achtige uitstapjes kennen of andersom.<br />
Op het moment doe ik de eindfase van een portal project bij AEGON waarbij ik vooral omdat er diverse webservices geimplementeerd moeten worden dagelijks betreur dat er niet strak volgens een &#8220;V&#8221; of &#8220;Dual V&#8221; model ontwikkeld is. Aan de andere kant had de eindgebruikers interface beter op een agile manier benaderd kunnen worden.<br />
Vooral de laatste maanden heb ik gekozen om scrum en agile technieken te gebruiken: sprint concept van scrum om in 4-6 weken de laatste &#8220;build&#8221; te maken. Agile om de laatste RFC´s met de ontwikkelaar achter het scherm te implementeren. Ik leg deze keuzen niet voor aan opdrachtgever of team als: zullen we nu maar eens gaan &#8220;scrummen&#8221;? maar stel ze het concept van de sprint voor als manier om sneller en interactiever met een oplevering te komen.</p>
<p>Mijn motto: Kies niet dogmatisch voor één methode maar kies voor een basis methode en pas die aan afhankelijk van de omstandigheden en ontwikkelingen.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Websites op maat in het watermodel: ontwerpfase &#124; Publishr</title>
		<link>http://www.publishr.nl/2009/11/websites-op-maat-in-het-watervalmodel-analysefase/comment-page-1/#comment-2823</link>
		<dc:creator>Websites op maat in het watermodel: ontwerpfase &#124; Publishr</dc:creator>
		<pubDate>Tue, 10 Nov 2009 11:29:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.publishr.nl/?p=3304#comment-2823</guid>
		<description>[...] over het tot stand komen van een maatwerk-website. Een introductie en het artikel over de Analysefase  gingen hier reeds aan vooraf. Per fase wordt een omschrijving van de acties, de deliverables en de [...]</description>
		<content:encoded><![CDATA[<p>[...] over het tot stand komen van een maatwerk-website. Een introductie en het artikel over de Analysefase  gingen hier reeds aan vooraf. Per fase wordt een omschrijving van de acties, de deliverables en de [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Bart Lelieveld</title>
		<link>http://www.publishr.nl/2009/11/websites-op-maat-in-het-watervalmodel-analysefase/comment-page-1/#comment-2652</link>
		<dc:creator>Bart Lelieveld</dc:creator>
		<pubDate>Wed, 04 Nov 2009 16:12:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.publishr.nl/?p=3304#comment-2652</guid>
		<description>Hi Marco,

allereerst dank voor jouw reactie. Het klopt dat het een ouder model is. Wiki beweert zelfs uit 1970. Ik ben er echter van overtuigd dat het een prima methodiek is om een website of webapplicatie in de lucht te brengen. Wij hebben hem zelf namelijk helemaal geoptimaliseerd zodat we binnen planning en budget opleveren en een kwalitatief goed product neer zetten.

Natuurlijk zijn er zijn legio methodieken die gehanteerd kunnen worden. We zijn bekend met Scrum, RUP, DSDM, Extreme en Agile programming, maar toch blijf \ik terugkomen bij deze vertrouwde methode. Welke methodiek heeft jouw voorkeur?</description>
		<content:encoded><![CDATA[<p>Hi Marco,</p>
<p>allereerst dank voor jouw reactie. Het klopt dat het een ouder model is. Wiki beweert zelfs uit 1970. Ik ben er echter van overtuigd dat het een prima methodiek is om een website of webapplicatie in de lucht te brengen. Wij hebben hem zelf namelijk helemaal geoptimaliseerd zodat we binnen planning en budget opleveren en een kwalitatief goed product neer zetten.</p>
<p>Natuurlijk zijn er zijn legio methodieken die gehanteerd kunnen worden. We zijn bekend met Scrum, RUP, DSDM, Extreme en Agile programming, maar toch blijf \ik terugkomen bij deze vertrouwde methode. Welke methodiek heeft jouw voorkeur?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Marco</title>
		<link>http://www.publishr.nl/2009/11/websites-op-maat-in-het-watervalmodel-analysefase/comment-page-1/#comment-2651</link>
		<dc:creator>Marco</dc:creator>
		<pubDate>Wed, 04 Nov 2009 15:51:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.publishr.nl/?p=3304#comment-2651</guid>
		<description>Is de watervalmethode niet een beetje gedateerd? Er zijn veel meer ontwikkelmethodes die je zou kunnen hanteren.</description>
		<content:encoded><![CDATA[<p>Is de watervalmethode niet een beetje gedateerd? Er zijn veel meer ontwikkelmethodes die je zou kunnen hanteren.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Served from: www.publishr.nl @ 2010-07-31 06:40:59 by W3 Total Cache -->