The Zen Of Scrum
Scrum е най-бързо развиващата се “гъвкава” методология за разработка на софтуер. Не толкова сурова и крайна в изискванията си както Extreme programming (XP) и в същото време разбираема и лесно приложима в редица проекти.
Въпреки, че идеята на гъвкавите методологии е да се прилагат в малки екипи, те намират все по-широка употреба и в големи корпорации, както и в държавни организации на запад. Аз самият я намирам за доста прагматична и успешно приложима в множество проекти, въпреки че има особености, които, ако бъдат пренебрегнати, могат да доведат до неуспех. В курса “Основи на управлението на софтуерни проекти“, който водя във фирма RammSoft, има една голяма лекция, посветена на гъвкавите методологии и по-специално на Scrum.
Категории: Гъвкави методологии | Няма коментари
Гнилите ябълки в екипа
Така Steve McConnell нарича в книгата си Rapid Development онези членове на екипа, които не само не успяват да се сработят с останалите, но и активно се противопоставят (да не кажа “саботират”) на екипната работа. Хората, които ме познават, знаят, че почитам изключително много тази книга и нейния автор, но може би малцина знаят, че точно тази тема е една от най-важните и най-спорните в книгата и че аз категорично подкрепям позицията, че такива хора не само вършат много малко полезна работа, но и лесно могат да разрушат всичко, което екипът е постигнал.
Не случайно ги наричат “гнили ябълки” – от поговорката, че една гнила ябълка може да развали целия кош – това определение е много точно. А някои колеги-блогъри употребяват термина “рак”, който звучи доста по-страшно, но показва доста точно ефекта от подобни хора в софтуерния екип.
За темата ме подсети Jeff Atwood, който е също верен (по)читател на McConnell и даже е нарекъл своя блог по името на една от рубриките в книгата.
Ето как можем да разпознаем такива хора в екипа си:
- Те се стараят да прикрият невежеството си вместо да се опитат да научат нещо от своите колеги. “Не знам как да обясня идеите си. Знам само, че те просто си работят.” или “Моят код е твърде сложен, за да бъде тестван.” (И двете са истински цитати.)
- Те имат засилено желание за уединение. “Нямам нужда някой да ми преглежда кода.”
- Те си пазят територията. “Никой не може да оправи бъговете в моя код. Аз съм твърде зает в момента, но ще ги погледна следващата седмица.”
- Те непрекъснато мърморят срещу решенията на екипа и постоянно подновява стари дискусии дълго след като решението е взето и екипът е продължил напред. “Продължавам да мисля, че трябва да се върнем назад и да променим онази идея, за който говорехме миналия месец. Това, което избрахме, няма да проработи.”
- Другите хора от екипа се заяждат с един и същи човек или често се оплакват от него. Програмистите не винаги обичат да критикуват или да се оплакват директно, така че ако започнете да чуват често заядливи забележки в офиса, знайте, че имате проблем.
- Те не се ангажират с проблемите на екипа. Нерядко решават да си вземат отпуск точно в най-напрегнатите моменти за проекта.
Приоритизация на изискванията по метода MoSCoW
Приоритизацията на изискванията и задачите е едно от най-важните задължения на всеки един проектен мениджър. Независимо колко успешно е стартирал един проект, рано или късно стигаме до ситуация, в която трябва да изберем кои изисквания да изпълним и кои да откажем, за да успеем да се включим в поставените срокове.
Най-добре е това разпределение да бъде направено в самото начало и методът MoSCoW е един от най-простите, но за сметка на това най-ефективни подходи.
Той възниква за пръв път в методологията DSDM (Dynamic Software Development Method) – един от първите “гъвкави” подходи, но е приложим във всеки един проект, независимо от избраната управленска методология. “Московският метод” (двете “о”-та са поставени за благозвучие и така се е получило съвпадението с името на руската столица) е прост начин за категоризиране на изискванията по важност, за да може на всички участници в проекта да бъде ясно кое е важно за клиента и кое – не.
Съкращението MoSCoW означава:
Must have (задължително трябва да го има)
Should have (би трябвало да го има)
Could have (добре би било да го има)
Won’t have (няма да го има)
Какво означава това в детайли?
Продължи към пълния текст »
Категории: Бизнес анализ, Управление на проекти | 1 коментар
Българската секция на Международния институт по бизнес анализ е вече факт
Щастлив съм да обявя, че българските бизнес аналитици вече се сдобиха със своя собствена професионална общност. На 27.01.2009 г. беше проведено учредително събрание на българската секция на Международния институт по бизнес анализ. Учредителният протокол бе подписан от 19 члена на института (на снимката горе).
Международният институт по бизнес анализ (IIBA) е световна организация на професионалисти, които работят за установяването и поддържането на общоприети стандарти и добри практики в областта на бизнес анализа. Българската секция бе създадена от желанието на родните специалисти по бизнес анализ да се обединят в професионална общност, чрез която да подпомогнат развитието, споделянето и разпространението на знания и идеи, както и утвърждаването на бизнес анализа като значима и престижна експертна дейност в България.
-
RSS абонамент
Препоръчвам ви
Връзки
Авторски права
-
Admin
