<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>McWolf.net &#187; szacowanie</title>
	<atom:link href="http://www.mcwolf.net/article/tag/szacowanie/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mcwolf.net</link>
	<description>Zarządzanie Projektami IT, Metodyki, Techniki i Porady</description>
	<lastBuildDate>Thu, 11 Nov 2010 12:27:21 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Szacowanie Projektów &#8211; Część 3 Jak Szacować zadania</title>
		<link>http://www.mcwolf.net/article/szacowanie-czasu-zadan/</link>
		<comments>http://www.mcwolf.net/article/szacowanie-czasu-zadan/#comments</comments>
		<pubDate>Mon, 31 May 2010 12:36:19 +0000</pubDate>
		<dc:creator>Tomasz Wolfram</dc:creator>
				<category><![CDATA[Artefakty i Narzędzia]]></category>
		<category><![CDATA[Metryki]]></category>
		<category><![CDATA[Szacowanie Projektów]]></category>
		<category><![CDATA[estimating]]></category>
		<category><![CDATA[Estymacja]]></category>
		<category><![CDATA[szacowanie]]></category>
		<category><![CDATA[Zarządzanie Projektami]]></category>

		<guid isPermaLink="false">http://www.mcwolf.net/?p=364</guid>
		<description><![CDATA[Kiedy wiemy już jak ułatwić sobie estymowanie całych projektów i na co zwrócić uwagę przygotowując oszacowania, czas przejść do technik i metod szacowania poszczególnych zadań.
Najprostszym sposobem szacowania zadań jest oczywiście przypisanie im określonej wartości liczbowej, wyrażającą liczbę godzin potrzebną do wykonania zadania.  Ważne, jest aby...]]></description>
			<content:encoded><![CDATA[<p><a href="http://www.mcwolf.net/wp-content/uploads/1173624_68004559.jpg"><img class="alignleft size-medium wp-image-410" title="1173624_68004559" src="http://www.mcwolf.net/wp-content/uploads/1173624_68004559-300x180.jpg" alt="" width="240" height="144" /></a>Kiedy wiemy już jak ułatwić sobie <a title="Metody szacowania całych projektów " href="http://www.mcwolf.net/article/szacowanie-czasu-trwania-projektu/" target="_blank">estymowanie całych projektów</a> i na co zwrócić uwagę p<a href="http://www.mcwolf.net/article/szacowanie-czasu-wykonania/" target="_blank">rzygotowując oszacowania</a>, czas przejść do technik i metod szacowania poszczególnych zadań.<span id="more-364"></span></p>
<p>Najprostszym sposobem szacowania zadań jest oczywiście przypisanie im określonej wartości liczbowej, wyrażającą liczbę godzin potrzebną do wykonania zadania.  Ważne, jest aby zadanie którego określam czas było odpowiednio małe. (Więcej na temat dzielenia projektu na zadania znajdowało się w <a title="Szacowanie czasu trwania projeków" href="http://www.mcwolf.net/article/szacowanie-czasu-trwania-projektu/" target="_blank">części 2</a>).</p>
<p>Taki sposób szacowań jest dalece nieidealny. Powodując wiele problemów, a przede wszystkim błędów. Dlatego wymyślono kilka metod, które mogą pomóc.</p>
<h3>Szacowanie ważone (trójpunktowe)</h3>
<p>Technika szacowania trójpunktowego, pochodzi z Metody PERT.  Zdecydowanie jest jedną z najchętniej przeze mnie wykorzystywanych.  Polega na wyliczeniu wartości czasu wykonania zadania na podstawie 3 pośrednich wartości:</p>
<ul>
<li>Szacunek  optymistyczny (To)</li>
<li>Szacunek realistyczny (Tr)</li>
<li>Szacunek Pesymistyczny (Tp)</li>
</ul>
<p>Wartość czasu oblicza się ze wzoru na średnią ważona z następującymi wagami:</p>
<p>T = (To + 4*Tr + Tp) / 6.</p>
<p>Z mojego doświadczenia wartości wag, powinny być jednak różnicowane w zależności od wykonawcy zadania. Na przykład niedoświadczony, początkujący programista, ma zwykle tendencję do podawania znacznie bardziej optymistycznych wartości, niż jego doświadczony kolega. Dla takich osób możemy przyjąć na przykład następujące wagi:</p>
<p>T = (To + 3*Tr+2*Tp) / 6</p>
<p>Szacowanie trójpunktowe jest niezwykle efektywne ponieważ zmusza do zastanowienia się chwilę dłużej za nim podamy prognozowane przez Nas wartości. Poza tym mamy większą świadomość co oznaczają zapisane liczby. W przypadku gdy mamy tylko jedną wartość, to tak naprawdę nie wiemy czy ktoś napisał swoją wersję pesymistyczną, czy może optymistyczną.</p>
<h3>Szacowanie względne</h3>
<p>Technika ta, o ile dobrze pamiętam, popularyzowana jest w metodykach zwinnych. Pomysł polega na tym, aby wybrać sobie jedno zadanie, które będzie nam łatwo oszacować  i każde inne zadanie porównywać i zapisywać jako wielokrotność tego pierwszego.</p>
<p>Wybrane przez Nas zadanie jako wzorcowe powinno być dość małe. Gdybyśmy wskazali duże zadanie (np. 20h), to zapewne w projekcie znalazłoby się sporo prac, które musiałyby być jakimiś wartościami ułamkowymi. O ile stosowanie jeszcze miar na poziomie 0,5 jest w porządku, to już rozdrabnianie się na ułamki typu 1/4, 1/5 itp. wprowadzałoby tylko niepotrzebnie wiele bałaganu.</p>
<p>Metoda ta posiada jeszcze drugi problem. W projekcie, nawet w części programistycznej wiele zadań jest drastycznie różnych od siebie i ciężko jest je porównywać. Weźmy na przykład zadanie zmiany układu wyświetlania strony, a zintegrowanie portalu z systemem płatności. Jakby nie patrzeć, to że przebudowanie widoku zajmuje mi 4h, jakoś nie rozjaśnia sprawy ile czasu potrzeba na integrację z zewnętrznym systemem.</p>
<p>Dlatego moim zdaniem warto korzystać z metody szacowania względnego jako uzupełnienia, a nie samodzielnej techniki.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.mcwolf.net/article/szacowanie-czasu-zadan/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Szacowanie Projektów – Część 2 Jak Oszacować czas trwania projektu</title>
		<link>http://www.mcwolf.net/article/szacowanie-czasu-trwania-projektu/</link>
		<comments>http://www.mcwolf.net/article/szacowanie-czasu-trwania-projektu/#comments</comments>
		<pubDate>Sun, 16 May 2010 09:28:18 +0000</pubDate>
		<dc:creator>Tomasz Wolfram</dc:creator>
				<category><![CDATA[Artefakty i Narzędzia]]></category>
		<category><![CDATA[Metryki]]></category>
		<category><![CDATA[Szacowanie Projektów]]></category>
		<category><![CDATA[Estymacja]]></category>
		<category><![CDATA[szacowanie]]></category>
		<category><![CDATA[Zarządzanie Projektami]]></category>

		<guid isPermaLink="false">http://www.mcwolf.net/?p=337</guid>
		<description><![CDATA[W części pierwszej opisałem ogólne zasady przygotowywania wszelkich oszacowań, których stosowanie może ułatwić nam życie i zaoszczędzić nieporozumień. Teraz skoncentruje się na opisaniu metod szacowania czasu całych projektów. 
Do rzeczy, jak ułatwić szacowanie czasu trwania projektu?
Do szacowania całkowitego czasu wykonywania projektów można podejść na kilka...]]></description>
			<content:encoded><![CDATA[<p><a href="http://www.mcwolf.net/wp-content/uploads/darts.jpg"><img class="alignleft size-medium wp-image-371" title="darts" src="http://www.mcwolf.net/wp-content/uploads/darts-300x225.jpg" alt="Estimating by Darts throw" width="210" height="158" /></a>W części pierwszej opisałem <a href="http://www.mcwolf.net/article/szacowanie-czasu-wykonania/" target="_blank">ogólne zasady przygotowywania wszelkich oszacowań</a>, których stosowanie może ułatwić nam życie i zaoszczędzić nieporozumień. Teraz skoncentruje się na opisaniu metod szacowania czasu całych projektów. <span id="more-337"></span></p>
<h2>Do rzeczy, jak ułatwić szacowanie czasu trwania projektu?</h2>
<p>Do szacowania całkowitego czasu wykonywania projektów można podejść na kilka sposobów. Poniżej lista podstawowych metod.</p>
<h3>Szacowanie Oddolne (Wstępujące)</h3>
<p>Jest to jedna z najbardziej pracochłonnych metod szacowania, dzięki czemu jest zdecydowanie najdokładniejsza.</p>
<p>Szacowanie oddolne polega na podzieleniu całego projektu na jak najmniejsze zadania, dla których oszacowania czasu wykonania może być dość dokładne.</p>
<p>Dzieląc projekt na zadania, powinniśmy dokonywać ich podziału do momentu w którym dane zadanie nie będzie przekraczać kilku dni roboczych. Jako optimum przyjmowane są różne wartości, osobiście jako maksimum polecam 40h (1 tydzień roboczy), ale ideałem są zadanie w zakresie od 4-16h.Przykładem podziałów zadań do wykonywania takiego szacowania są listy zadań WBS (WorkBench Structure).</p>
<p>Metoda szacowania oddolnego jest najbardziej przydatna w momencie planowania całego projektu, kiedy podjęliśmy już decyzję odnośnie sposobu realizacji i znamy zasoby jakimi dysponujemy oraz dokładnie stawiane nam wymagania.</p>
<p>Ciężko stosować ta metodą w pełnym zakresie do przygotowywania wstępnych szacunków projektu na etapie jego definiowania, kiedy niespisane są jeszcze wymagania projektu. Choć już wtedy warto podzielić projekt na mniejsze części.</p>
<h3>Szacowanie Odgórne (Historyczne / Zstępujące ).</h3>
<p>Jest to jedna z lepszych metod, która w połączeniu z szacowaniem oddolnym daje doskonałe rezultaty. Metoda szacowania odgórnego polega na wykorzystaniu danych z wcześniej realizowanych projektów.</p>
<p>No i tu właśnie mamy problem, bo jeśli nie mamy doświadczenia z poprzednich, podobnych projektów, to niestety nie możemy skorzystać z tej techniki. Drugi problem, to nawet jeśli realizowaliśmy wcześniej zbliżone projekty, to nie zawsze dysponujemy danymi historycznymi odnośnie rzeczywistych czasów wykonywania zadań.</p>
<p>Dlatego tak ważne jest, aby już od swojego pierwszego projektu archwizować dane zawierające nasze poprzednie szacunki wraz z realnie uzyskanymi wartościami.</p>
<p>Metodę szacowania odgórnego możemy oczywiście stosować również do pewnych, wybranych części danego projektu. Ponieważ, często się zdarza, że realizujemy projekt podobny, ale z jakimiś dodatkowymi funkcjami. Możemy, więc skorzystać z tej metody do oszacowania wykonania wspólnej części obu projektów. Metodę szacowania odgórnego najczęściej wykorzystuje się na etapie definiowania projektu, kiedy znamy jego ogólne założenia. (Np. przygotowywanie oferty dla klienta).</p>
<h3>Szacowanie Parametryczne</h3>
<p>Kolejna metoda jest nieco zbliżona do szacowania odgórnego, ponieważ korzysta również z danych historycznych. Szacowanie parametryczne polega na zastosowaniu modelu matematycznego.</p>
<p>Na przykład możemy korzystając z danych historycznych określić, że poszczególne fazy projektu Planowanie, realizacja, wdrożenie trwały odpowiednie 20, 40, 20 procent całkowitego czasu projektu. Więc możemy dokonać założenia, że teraz będzie podobnie.</p>
<p>Można również próbować szacować wielkość projektu, przeliczać to na linie kodu, a te na ilość pracy. Istnieją tablice definiujące ilość linii kodu na dzień roboczy dla wybranych języków programowania. Technika ta jest podstawą metody COCOMO (którą opiszę w części trzeciej &#8211; szacowanie zadań). Osobiście nigdy nie przekonałem się do tego typu szacowania i traktuje je bardziej jako ciekawostkę. Choć metoda ta była kiedyś stosowana dość szeroko.</p>
<h2>O czym warto pamiętać szacując?</h2>
<h3>Stosowanie Buforów (rezerw) czasowych</h3>
<p>Szacując całkowity czas trwania projektu należy koniecznie wziąć pod uwagę bufor czasowy.</p>
<p>Ważne jest, aby doliczać rezerwę do całkowitego czasu trwania projektu, a nie jak często się to zdarza do poszczególnych zadań. W drugim przypadku mamy mocno zaciemniony obraz tego ile naprawdę doliczyliśmy czasu do całego projektu, co znacznie utrudnia nam kontrolę.</p>
<p>Jeśli szacujemy na przykład, że czas realizacji projektu to 10 tygodni i doliczamy bufor 10%. To wiemy, że mamy 1 tydzień zapasu i w każdym momencie trwania projektu jesteśmy w stanie określić, jak wiele czas</p>
<p>u z rezerwy wykorzystaliśmy.Poza tym przeszacowywanie każdego zadanie wpływa często również na obniżenie naszej wydajności, bo skoro widzimy, że mamy czas, często spowalniamy naszą pracę, mniej koncentrując się na wykonaniu zadań.</p>
<p>Wielkość buforu zależy bardzo mocno od złożoności projektu i naszego doświadczenia. Jeżeli robiliśmy podobny projekt, dysponujemy danymi archiwalnymi, to możemy założyć bufor na około 10% czasu trwania. Jeśli jednak brakuje nam doświadczenia, a projekt jest bardzo złożony to bufor czasowy może wynieść nawet około 50%+.</p>
<h3>Aktualizaca Szacunków</h3>
<p>W zasadzie z wcześniejszymi szacunkami, można zrobić dwie rzeczy, albo wywalić do koszta, albo zaktualizować. Pozostawienie ich gdzieś w obiegu to jak zakładanie sobie pętli na szyję. Zawsze po pewnym czasie pracy, niektóre nasze szacunki będą się okazywały trafne inne nie. Możemy, więc albo wykonać nowe oszacowanie, albo zaktualizować istniejące. Jeżeli, wybierzemy drugą opcję, którą polecam, bardzo dobry przykład opisywania zadań zaproponował Joel Spolsky. Propozycję tę przedstawię w kolejnej części.</p>
<h3>Jeśli robimy coś po raz pierwszy</h3>
<p>Koniecznie trzeba uważać jeśli robimy coś po raz pierwszy. Zawsze potrzebujemy na to zdecydowanie więcej czasu, niż gdy dana czynność wykonywana jest ponownie.</p>
<p>Mimo, że na przykład wykonywaliśmy już integracje z system płatności, to wykonanie integracji z podobnym system innego dostawcy zajmie nam jednak więcej czasu. Zawsze musimy uwzględnić czas na naukę.</p>
<h3><a href="http://www.mcwolf.net/wp-content/uploads/backlog.png"><img class="size-medium wp-image-359 alignright" title="Project Backlog" src="http://www.mcwolf.net/wp-content/uploads/backlog-300x243.png" alt="Project Backlog - Google Dosc" width="300" height="243" /></a></h3>
<h2>Zbieraj dane, zapisuje czasy realizacji, szacuj i jeszcze raz szacuj!</h2>
<p>Podsumowując, szacowanie jest bardzo trudnym zadaniem, szczególnie jeśli brak nam doświadczenia. Dlatego ważne jest, aby ćwiczyć się w szacowaniu i już od pierwszych swoich projektów próbować estymować.</p>
<p>Koniecznie należy archiwizować otrzymywane czasy i w trakcie wykonywania zadań zapisywać rzeczywiście otrzymane wartości. Te informację mogą się okazać ( i z pewnością się okażą) prawdziwym błogosławieństwem w przyszłości. Do zbierania danych nie potrzeba super narzędzi, wystarczy zwykły arkusz kalkulacyjny (np. Google Docs, który sprawdzi się również w pracy grupowej). Można również korzystać z dedykowanych rozwiązań, bardzo ciekawą darmową pozycją jest Feng Office.</p>
<p>W trzeciej części postaram opisać się sposoby radzenia z szacowaniem poszczególnych zadań w projekcie.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.mcwolf.net/article/szacowanie-czasu-trwania-projektu/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Szacowanie Projektów &#8211; Część 1 Jak przygotowywać oszacowanie.</title>
		<link>http://www.mcwolf.net/article/szacowanie-czasu-wykonania/</link>
		<comments>http://www.mcwolf.net/article/szacowanie-czasu-wykonania/#comments</comments>
		<pubDate>Thu, 13 May 2010 23:36:28 +0000</pubDate>
		<dc:creator>Tomasz Wolfram</dc:creator>
				<category><![CDATA[Artefakty i Narzędzia]]></category>
		<category><![CDATA[Inżynieria Wymagań]]></category>
		<category><![CDATA[Metodyki Zwinne - Agile]]></category>
		<category><![CDATA[Metryki]]></category>
		<category><![CDATA[Programowanie]]></category>
		<category><![CDATA[Szacowanie Projektów]]></category>
		<category><![CDATA[Zarządzanie Projektami]]></category>
		<category><![CDATA[czas]]></category>
		<category><![CDATA[estimating]]></category>
		<category><![CDATA[szacowanie]]></category>
		<category><![CDATA[Wymagania Projektu]]></category>
		<category><![CDATA[Zarządzanie]]></category>

		<guid isPermaLink="false">http://www.mcwolf.net/?p=316</guid>
		<description><![CDATA[Każda osoba, która miała okazję pracować przy projektach programistycznych, na pewno spotkała się z problem szacowania czasu wykonywania. Zwykle jest to jedna z pierwszych rzeczy o które pyta Nas klient, kierownik,  czy nawet my sami musimy sobie zadać pytanie za nim zaczniemy coś robić - ...]]></description>
			<content:encoded><![CDATA[<p><a href="http://www.mcwolf.net/wp-content/uploads/708452_62978186.jpg"><img class="alignleft size-medium wp-image-322" title="708452_62978186" src="http://www.mcwolf.net/wp-content/uploads/708452_62978186-225x300.jpg" alt="Szacowanie Czasu - Klepsydra" width="203" height="270" /></a>Każda osoba, która miała okazję pracować przy projektach programistycznych, na pewno spotkała się z problem szacowania czasu wykonywania. Zwykle jest to jedna z pierwszych rzeczy o które pyta Nas klient, kierownik,  czy nawet my sami musimy sobie zadać pytanie za nim zaczniemy coś robić -  Ile czasu będzie na to potrzebne?</p>
<p>Większość z Nas szczególnie, ta mniej doświadczona zwykle bardzo nie lubi dokonywać oszacowania. Nic dziwnego skoro często zadania to przypomina chodzenie po omacku.  Dlatego postaram się tutaj jak najszerzej omówić dostępne metody i narzędzia.</p>
<p>Zacznę od kwestii o których powinniśmy pamiętać wykonując wszelkie oszacowania, później przejdę do <a href="/article/szacowanie-czasu-trwania-projektu/">sposobów na szacowanie całych projektów</a>, w części trzeciej opiszę metody szacowania czasu trwania poszczególnych zadań, a na koniec wspomnę trochę o dostępnych narzędziach.<span id="more-316"></span></p>
<h2>Zaczynamy &#8211; czyli jak zabierać się do szacowania czasu?</h2>
<p>Oszacowanie czasu trwania całego projektu, to zadanie naprawdę trudne. Szczególnie na początku projektu w fazie przygotowawczej, kiedy tak na prawdę nie do końca wiemy jeszcze co trzeba w projekcie zrobić. Ale za nim powiem, jak można sobie pomóc, to ustalmy z czego powinno się składać takie formalne oszacowanie.</p>
<h3>1. Założenia</h3>
<p>Każde oszacowanie projektu powinno mieć pokrótce opisane założenia, dla których zostało dokonane. Czyli jakie rzeczy zostały uwzględnione, a co nawet ważniejsze, czego ewentualnie nie uwzględniono. Jakie było zakładane rozwiązanie i jakie zaplanowano zasoby. Generalnie wszystkie czynniki, które mogą znacząco wpłynąć na czas trwania projektu.</p>
<h3>2.  Odchylenie , czyli dokładność oszacowania.<strong><br />
</strong></h3>
<p>Powinniśmy sobie zdawać sprawę w jakim stopniu dokładny jest prognozowany czas. Czasem mamy naprawdę dużą pewność (np. robiliśmy już podobne projekty) i możemy sobie założyć, że oszacowanie może mieć odchylenie rzędu 10 &#8211; 20%.  Czasem jednak trafiamy do dzikiej nieznanej krainy i nasze szacunki mogą być naprawdę bardzo orientacyjne. W takim przypadku odchylenie, może sięgać do np. 100% czasu trwania. Jeśli chodzi o wyznaczanie wielkości odchylenia to osobiście przyjmuje pięciostopniową skalę (jak w większości ciężko mierzalnych metryk, taka ilość daje sporą elastyczność, a nie powoduje jeszcze bałaganu).</p>
<ul>
<li>Bardzo Niskie 0 &#8211; 10%</li>
<li>Niskie  10 &#8211; 20%</li>
<li>Średnie 20-40%</li>
<li>Wysokie 40 &#8211; 70%</li>
<li>Bardzo Wysokie 70%+</li>
</ul>
<p>Warto zwrócić uwagę, że w tym przypadku im większy poziom odchylenia, tym szerszy jego przedział.</p>
<h3>3.  Czas ważności Oszacowania</h3>
<p>Zaleca się też, choć wszystko zależy od przeznaczenia oszacowania, aby określić jego czas ważności. Tzn na przykład, że oszacowanie aktualne jest do końca Marca. (bo wtedy będziemy mieli więcej szczegółów) Zabezpiecza Nas to na wypadek, gdyby ktoś później wyciągał nam takie archiwalne oszacowanie i dochodził jego wyegzekwowania.</p>
<p>Osobiście, niestety raczej rzadko zdarza mi się określać czas ważności oszacowania. Wykonywane oszacowania zwykle są po prostu aktualizowane w ramach napływających danych, czy wykonywania prac, występowania problemów itd.</p>
<h3>4. Nakład pracy, a czas trwania</h3>
<p>Bardzo ważna rzecz, której trzeba mieć świadomość, jak również zaznaczyć w opisie oszacowania. Pojęcia &#8216;nakładu pracy&#8217; i &#8216;czasu trwania&#8217; są często stosowane zamiennie, co jest wielkim nieporozumieniem i trzeba je twardo rozgraniczyć.</p>
<p>Nakład pracy, opisuje szacunek ile godzin roboczych należy poświęcić na zrealizowanie projektu/zadania. Zaś Czas trwania, musi do nakładu pracy doliczyć takie kwestie jak dostępność zasobów, dni wolne, realizację innych projektów i zobowiązań itp.</p>
<p>Koniecznie należy zaznaczyć w oszacowaniu, którą z tych wartości prognozujemy. Inaczej nieraz spotkałem się z nieporozumieniami. Programista mówi, że wykonanie jakieś funkcjonalności to 3 dni roboty, a klient rozumie,  że za 3 dni otrzyma gotowe rozwiązanie.</p>
<h2>Podsumowanie</h2>
<p>Stosowanie wszystkich tutaj wymienionych elementów oczywiście nie jest konieczne. Ale często zabezpiecza nad przed mogącymi wystąpić problemami. W kolejnej części opiszę zasady <a href="/article/szacowanie-czasu-trwania-projektu/">szacowania całych projektów</a>, a później przejdę do szacowania zadań.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.mcwolf.net/article/szacowanie-czasu-wykonania/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
