Всем привет!
Давненько не виделись и вот сегодня есть время немного пообщаться о методологиях разработки, кто они вообще такие есть…
Многие, прочитав предыдущий абзац, могут сказать, что все это глупость, есть только одна рабочая методология (!), которую они (а может быть и вы) применяете на практике. Однако спешу вас обрадовать.
Мы абстрагируемся от той или иной методологии, потому как есть несколько нюансов.
Итак… Какова цель любого проекта? Получить готовый продукт (решение), успешно осуществлять его продажи, выполнить контракт. Для того, чтобы это работало — нужна хорошая и квалифицированная команда.
Кроме того, очень немаловажный, чуть ли не самый главный, фактор — коммуникации в команде. Коммуникации в команде важны, потому что каждый участник команды должен чувствовать себя неотъемлемой частью команды, а команда в целом должна быть ориентирована на успех проекта. Но это все вода ;)
Итак, коммуникации, взаимодействие, knowledge transfer, ориентация на результат. Это является мета-целью любой методологии. Есть много противоречий у разных сторонников, например распределение по ролям (RUP), или многозадачность (XP)… В конечном итоге все сводится к повышению качества и увеличению производительности.
А это означает, что у всех методологий есть общий знаменатель, который позволяет говорить о чем то более общим, чем конкретизация.
Сразу оговорюсь, что я — сторонних eXtreme Programming, однако здесь специально не буду рассматривать преимущества или недостатки XP. Об этом были посты ( и ).
Здесь мы поговорим о том, что какая бы методология не применялась — конечная цель всегда одна.
Все методологии описывают набор взаимодействия ресурсов на проекте. Под ресурсами будем понимать время, а также участников команды. Как показывает опыт (в том числе и отрицательный), есть масса примеров удачного и неудачного использования методологий.
Например, команда, работающая по Agile с менеджером-теоретиком, который всегда старался делать все по книжке, не уложилась в срок и бюджет лишь из-за того, что он не смог дать адекватные оценки… Другой пример показывает, как некоторые команды пытались внедрить SCRUM, но в итоге все пошло совсем не так.
Проблема в этих примерах всегда одна. «Когда ты приложил лестницу, чтобы залезть наверх — подумай, у правильной ли стенки она поставлена?».
Управляя автомобилем, водитель редко (в идеале никогда) задумывается о том, как устроена система управления клапанами и зачем ей нужно регулировать высоту подъема каждого клапана, а также на каком такте хода двигателя какой клапан располагается на нужной высоте (но это меня что-то на лирику потянуло..)
Каждый менеджер/участник команды, применяющий методологию, не должен задумываться о теоретической составляющей этого. Методология — лишь инструмент, позволяющий осуществлять:
* тайм-менеджмент
* внутренние коммуникации
* оперативный контроль
* и тп.
В идеале, вы никогда не должны задумываться, КАК?
Вы вообще не должны задумываться :)
Удачное проектное решение — это успешное применение той или иной методологии для достижения оптимальных результатов в команде. В современном мире все применяемые решения смахивают на гибриды, потому что удачная практика рекомендует брать инструмент из XP и применять его в SCRUM, пользоваться шаблонами документов из RUP, использовать MS Project для учета и распределения времени…
Но все это полная фигня, которой забивают голову те, кому больше нечем заняться ;)
Я рекомендую несколько простых шагов для того, чтобы определить, как нужно строить управление проектом и работу команды (это касается каждого внутри команды), достаточно ответить на несколько вопросов:
1. Понимание — Что нам нужно делать? Зачем нам это нужно делать? Почему нам нужно делать это сейчас?
2. Концентрация — Как нам делать это? Какова последовательность действий? Какие действия нужно выполнить для конкретной цели?
3. Оценка — Сколько времени уйдет на это действие? Почему это действие должно быть раньше чем другое? Сколько времени уйдет у другого участника команды на то же действие и почему?
4. Результат — Что мы хотим получить? Что будет, когда мы это получим? Что мы будем делать дальше?
Возможно перечень вопросов неполный, однако это хороший старт. Особенно для тех, кто пока незнаком с некоторыми словами из моей статьи.
Итак, когда мы выбрали направление, разработали план, нужно незамедлительно приступать к реализации данного плана — обсуждать план после его принятия — означает создавать другой план. Разработайте план так, чтобы никогда (или по минимуму) его не корректировать.
Ответственные за выполнение плана все! Вся команда — это единый организм, а значит план распространяется на всю команду, на руки, ноги, голову этого организма.
Исходя из поставленных целей и сроков, выбираются инструменты для реализации. Думаю это не составляет большой сложности. Здесь есть немаловажный фактор — старайтесь выйти за рамки и отойти от стандартов, которые вам навязывают. Главное — удобство, доступность и эффективность.
что ж. возможно…
от себя скажу: техника успешно применялась на команде в 6 человек.
однако никто не гарантирует что конкретная методология может быть успешна на конкретном проекте. все познается в сравнении.
Уважаемый Netcoder!
Вы пишете слишком поверхностные рекомендации, вышеприведенный материал итак очевиден и интуитивно применяется большинством более-менее устоявшихся команд! Рекомендую Вам писать более конкретные обзоры :)
спаибо за критику. постараюсь учесть в будущих постах на тему тайм менеджмента…
хотя я стараюсь подчеркнуть здесь то что интуитивно применяется — для новичков может быть совсем не ясно, а следовательно требует разъяснений… стараюсь разжевать и разлоижть по пополчкам материал, который может быть описан в толстых книжках, чтобы народу можно \было сэкономить время. но спасибо за замечания, это очень полезно для меня и я постараюсь учесть в будущем
А мне и нашей команде, а также нашему менеджеру Володе материал был довольно полезен и поучителен. Он даже после этого обещал зарегаттся на этом сайте ;)
Комментарии (14)
RSS свернуть / развернутьrobertino
от себя скажу: техника успешно применялась на команде в 6 человек.
однако никто не гарантирует что конкретная методология может быть успешна на конкретном проекте. все познается в сравнении.
NetCoder
Вы пишете слишком поверхностные рекомендации, вышеприведенный материал итак очевиден и интуитивно применяется большинством более-менее устоявшихся команд! Рекомендую Вам писать более конкретные обзоры :)
drugndrop
хотя я стараюсь подчеркнуть здесь то что интуитивно применяется — для новичков может быть совсем не ясно, а следовательно требует разъяснений… стараюсь разжевать и разлоижть по пополчкам материал, который может быть описан в толстых книжках, чтобы народу можно \было сэкономить время. но спасибо за замечания, это очень полезно для меня и я постараюсь учесть в будущем
NetCoder
drugndrop
AlexVoronin
не знал что у нас есть олд-скул поклонники ))))
NetCoder
webdesigner
NetCoder
AlexVoronin
AlexVoronin
Botan
CrystalMan
NetCoder
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.