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