Комментарии 11
Ну смотрите, вы начинающий стоматолог и вам все сложно и все непонятно. Хотите, чтобы вам такой стоматолог лечил зубы по аджайлу?
Конечно, стоматология это не ИТ, но моя метафора показывает, что модель Кеневина не слишком подходит для оценки, так как, например, не оценивает риски и не учитывает последствия.
Хороший вопрос))) Честно говоря я не очень знаком с работой стоматолога, только "по ту сторону кресла")) Но могу предположить, что работа начинающего стоматолога должна быть похожа на джуна разработки, поэтому:
Начинающий работает с простейшими действиями под контролем - например работает ассистентом - подает инструменты, вставляет слюноотсос, смешивает пломбы ну и так далее. Тут он работает по инструкциям.
Статья больше про командные практики, так что рассматривать когда только 1 начинающий стоматолог - не совсем корректно, представим что у нас есть какой-то набор стоматологов с различным опытом и среди них есть начинающие.
По жалобе клиента, по телефону, не всегда можно определить конечную цель. То есть жалуется что болит зуб - это может быть кариес, может быть уже пульпит, может кариес, но еще и кариес в 5 других зубах и так далее. Поэтому стоматологи по телефону говорят "консультация будет стоить хххх рублей". После обследования можно более точно описать конечную цель, но в процессе могут возникнуть неожиданные факторы, так что точную сумму за лечение не всегда можно получить. Все это говорит что мы как раз в квадрате сложное и непонятное.
Для организации работы клиники стоматологии в принципе подходит KanBan - задачи внешние (позвонил клиент записался), задачи хорошо оцениваются. У нас есть набор специалистов с известными скиллами, при поступлении нового обращения можно понять кто и когда сможет заняться, всегда видна загрузка сотрудников, методология предусматривает "консилиум врачей" под названием каденция))
Так что стоматологию тоже можно организовать по эджайлу, но это не точно)))
Имхо, Инструкции и Водопад -- это одно и тоже: заранее определенный порядок действий ведущий к заранее определенному результату. Визуализируете вы этот порядок действий в виде Гант-чарта или в виде нумерованного списка -- вопрос личных предпочтений и необходимости.
В больших проектах можно (и, зачастую, нужно) использовать совокупность подходов:
Роадмэп в виде гант-чарта (Водопад), чтобы согласовать с заказчиком очередность блоков работ
Канбан для управления процессом сбора требований, так как много внешних задач.
Скрам для управления командой разработки
Инструкции и Водопад -- это одно и тоже
По моему мнению водопад - это набор инструкций в определенной последовательности (так что с утверждением согласен), отличие состоит в том, что набор в каждом проекте может отличаться, а если работаешь по инструкциям, то всегда делаешь a,b,c и последовательность не меняется.
В больших проектах можно (и, зачастую, нужно) использовать совокупность подходов
Абсолютно согласен, я даже это по сути и написал в конце, все эти подходы между собой сочетаются. Целью статьи было показать, как не делать ошибок на определенных стадиях проекта, жизненного цикла подразделения и так далее.
Я искренне завидую людям у которых ни разу не было такого, что приходит заказчик и просит срочно дать оценку проекту сформулированному одним предложением. А когда такое случается, то чаще всего как раз рисуется диаграмма Ганта, в которой куча допущений и сроки/стоимость по которой постоянно превышаются. А если так, то у меня возникает вопрос, зачем вообще было тратить время на эту диаграмму Ганта и давать ложную надежду заказчику. Так как часто наблюдаю неправильный подход, а так же меня об этом спрашивали из других компаний, то решил почему бы не написать статью)
Мне кажется ошибочным не разделять понятия "методика" и м"етодология", потому как последняя и даёт ответ на subj
Иногда и сортировка "пузырьком" самая эффективная
По-моему, автор в статье пытается изобрести велосипед.
Есть понятие операционной деятельности (известной, повторяющейся) и для неё пишут инструкции. Есть понятие проектной деятельности (по созданию уникального продукта или услуги) и для неё используют проектные подходы: водопад, agile (который есть фреймворк, а не методология) и другие.
Автор решил замешать немного мух в котлеты придумать понятие "задача". В один момент "задача" - это операционная деятельность; в другой момент - проектная. И длинный пост, по каким маркерам одно отличить от другого.
Если же развить тему и посмотреть на проектные подходы (пожалуйста, не называйте их методологиями; скорее, модель жизненного цикла), то их выбирают по целой пачке параметров:
требования;
команда разработки;
планируемые пользователи результата;
и т.д. и т.п.
Одной понятности/непонятности маловато будет.
В общем, Ликбез форева. Ждём развития темы.
Как ни странно я абсолютно согласен про велосипед) Тем не менее видя большое количество велосипедов с квадратными колесами, без педалей и так далее даже у опытных выскопоставленных руководителей, я подумал что может не так плохо еще раз описать его устройство? Перед этим погуглил и понял что именно практическое разделение нигде не описано.
Это моя первая статья и решил мерить фидбэк рейтингом - если положительный, значит кому-то помогло. А попасть во всю аудиторию хабра.. с первого раза... наверно было бы слишком оптимистичным ожиданием))
>>Для этого класса задач самой правильной методологией будет водопад. Данная методология дает следующие плюсы:
А не подскажите, что по этому поводу написано в водопад-гайде последней редакции или что говорили на конференции по методологии водопад?
Я всегда стараюсь отвечать честно. Поэтому не буду гуглить, ответ я не знаю) В своей работе я уже лет 5 не встречал проектов, которые можно было бы эффективно делать по водопаду (возможно у меня отсталое понимание водопада, вопрос спровоцировал меня почитать что говорит последний водопад-гайд))
Единственное на эджайл дейс мы обсуждали как-то в кулуарах когда применим эджайл и водопад и на сколько я понял водопад-гайд начинает включать элементы гибкой разработки, но опять же не уверен.
Задача выбора способа организовать работу является задачей комплексной в терминах Кеневина. Поэтому ошибкой является любая попытка описать алгоритм его выбора, отличный от «пробуй - ощути - реагируй». Однако, компании в такой неопределенности существовать не могут, поэтому алгоритм выглядит как-то так: попробуйте то, что проще заводится у вас. Если какой-то параметр результативности не сходится (инструкция не приводит к результату или отсутствует, проект постоянно едет вправо или требует доп ресурсов, невозможно сформулировать ни одной гипотезы), то нужно остановиться и сменить способ выполнения работы.
Как правило, способ организации работы определяется из стратегии компании. Если компания считает своим конкурентным преимуществом надежность, то она будет строить процессы, позволяющие ее контролировать. Выбросы неопределенности будут купироваться другими способами. Если компания про скорость и адаптивность - там будет какой-то аджайл. Если безопасность - что-то еще. Поэтому выбор не всегда за теми, кто думает, что выбор есть. Основная причина - любой компании сложно поддерживать несколько способов управления. Поэтому любой неосновной способ будет мимикрировать под основной.
В целом я согласен, если не получается не нужно биться в закрытую дверь, но статья как раз направлена то, чтобы меньше делать ошибок. Не надо всегда начинать с инструкций и если не получается, то стоит проанализировать почему. Являясь поклонником гибких методологий я вижу что скрам далеко не всегда взлетает и у меня есть внутренний тренинг "что может пойти не так" на 3 часа, где я рассказываю какие типичные проблемы вижу и как можно их купировать. Если здесь есть поклонники водопада, то скорее всего у них так же есть понимание какие типичные ошибки допускают и как с ними справляться. Поэтому всегда нужно стараться использовать правильный подход.
Я как раз утверждаю, что подход не зависит от стратегии компании, а зависит от класса решаемых задач/проектов. Конечно есть всегда зависимость от личных целей, если цель работать именно в этой компании, то лучше подстраиваться под принятые подходы, у меня цель эффективные команды, поэтому стараюсь подбирать оптимальную методологию под каждую (кстати у меня есть из всех 4 квадратов подходы))), а когда мне явно запретят это делать, то я наверно найду новую компанию) Ведь ни один из этих подходов не отрицает безопасность, надежность, скорость, они говорят как в тех или иных ситуациях достичь их оптимальным образом. Например часто гибкие методологии приравнивают к стартаперско-хипстерскому подходу, но я в корне не согласен и у меня в конвейере производства команд скрама участвуют опсеки, выделенные опсы, они постоянно интересуются прогрессом, вносят изменения еще на стадии разработки и в итоге продукт получается более качественный и безопасный.
Как выбрать подходящую методологию