Как стать автором
Обновить

Комментарии 26

То чувство, когда узнал, что Kanban это что-то между скрамом и водопадом и совсем не Agile. Картинка получилась красивой, но вообще говоря, Kanban более гибкий чем Scrum, и хорош, когда ты даже на спринт запланировать не можешь.

А тезис заложен хороший - когда простая мысль, что для каждого кейса хорош свой инструмент, который поможет выбрать грамотный PM, и не надо везде пихать Scrum, наконец осядет в головах широкой общественности (Заказчика), мир станет чуточку лучше.

По сути Kanban, Waterfall, Scrum и Agile — это как тёплое, мягкое, солёное и светлое (разные критерии, которые между собой нельзя сравнивать), на схеме показано именно их взаимодействие. И вы правы, что канбан более гибкий, чем скрам. Но мы рассматривали его как способ управления разработкой и визуализации процессов, а не отдельный фреймворк (канбан-метод), который вы имеете в виду.

И спасибо за оценку тезиса! В своей работе всегда следуем этому принципу.

Спасибо и вам. Рады, что было полезно!

В список литературы я бы еще добавил "Черную книгу менеджера" от Стратоплана.

Имеем:


Scrum — набор инструментов, фреймворк, с помощью которого реализуется Agile-подход.

и картинку к


Эти понятия пересекаются и взаимодействуют между собой следующим образом:

Разве не должно быть на картинке так что Scrum это часть Agile? Да и канбан как методика вроде бы тоже относиртя к Agile.

Не совсем верно. Agile — это философия, у неё нет приёмов и инструментов. Scrum — один из методов, через который Agile реализуется. Что касается канбан-визуализации: её можно использовать вне Agile. Человек может совершенно не знать принципов философии, но для удобства применять этот метод, двигая карточки на доске.

"Благодаря этой истории мы приняли решение передать процесс согласований условий контракта аккаунт-менеджерам." - мне интересно, сколько проектов понадобилось, чтобы поручить написание кода программистам?

Но это я так... злобствую. Еще попросил бы не примерять на неизвестных людей всякие интимные подробности, которые, в лучшем случае, интерпретируются как "оговорка по Фрейду".

Материал, на мой взгляд, приличный. Несмотря на свежесть мысли "соблюдать золотую середину применяя индивидуальный подход", многие частенько забывают про обе ее половины.

"Благодаря этой истории мы приняли решение передать процесс согласований условий контракта аккаунт-менеджерам." - мне интересно, сколько проектов понадобилось, чтобы поручить написание кода программистам?

Действительно, это произошло не сразу. Наша компания была основана 2 людьми, которые делали всё сами. Постепенно мы масштабировались и закрывали компетенции уже конкретными специалистами. Кстати, мы до сих пор иногда не даём разработчикам писать код, просим сначала подумать ;)

Waterfall — условно существующая каскадная модель разработки. Здесь процесс воспринимается как поток, а переход от одного этапа к другому происходит только после успешного завершения предыдущего.

А не чё, что водопад уже с 60-70-х годох в чистом виде нигде не используется, а для популиризации agile его везде для сравнения за уши тянут - никого не трогает.

Потому что на предполагаемые проблемы с чистой моделью водопада было введено множество модифицированных моделей водопада. Эти модели могут отражать некоторые или все критические замечания по поводу «чистой» модели водопада.

К ним относятся модели

  • быстрого развития (modified waterfalls), которые Стив МакКоннелл называет «модифицированными водопадами»

  • «модель сашими» (sashimi model) Питера ДеГрейса (водопад с перекрывающимися фазами)

  • водопад с подпроектами и водопад с уменьшением риска. Существуют и другие комбинации моделей разработки программного обеспечения, такие как «инкрементная водопадная модель» итд.

И все эти модели уже есть гибкие. Т.е. если бы сравнение шло с ними, то в некоторых местах не видно было-бы никакой разницы. Но нет, надо сравнивать с динозаврами, как в СССР всегда сравнивали с 1913-м годом, чтобы воочию показать, какой "огромный" прогресс имеет место быть.

Всё правильно, именно поэтому в определении мы использовали «условно существующая». Сам Ройс, кстати, когда описывал эту модель разработки, сразу сказал, что она так не используется. Но это было на второй странице :)

Также наш материал рассчитан на новичков, поэтому у нас не было задачи дать углубленные знания. Нам кажется, что прежде чем погружаться в детали, нужно выстроить прочный фундамент.

Вместе с этим процессы разработки продукта становятся прозрачнее и уменьшаются риски, что проект не будет принят.

Мне вот интересно, как вообще себе предствляют ситуацию те, кто такое пишет?

Принят - это значит, что сделано то, о чём договорились. Договорились - это значит описали ожидаемую систему/продукт с её параметрами и функциями. Если договора на конкретные детали нет, а детали обсуждаются каждые 1-10 недель, где вообще находится граница, когда будет что-то принято или нет? Ведь в каждом спринте всё меняется, иногда переворачивается вверх ногами.Как люди себе представляют себе само выражение "принят" в таком случае?

Мне вот интересно, как вообще себе предствляют ситуацию те, кто такое пишет?

Если совем упрощать, то речь идёт о следующем: у вас есть заказ на условный год работы.


В первом случае вы берёте ТЗ, год по нему работаете и только потом первый раз показываете результат заказчику.


Во втором случае вы берёте ТЗ, делаете что-то месяц, потом показываете результат заказчику и в случае необходимости изменяете ТЗ. И так двенадцать раз.


В каком случае выше вероятность что ожидания заказчика не совпадут с полученным результатом?


П.С. И да, второй вариaнт тоже имеет свои минусы. Например больше оверхэд и следовательно меньше "продуктивностъ". Но это уже отдельный вопрос.

И так двенадцать раз

Мне думается, что когда 12 раз, то вероятность того, что 12 раз или год - непланируемы. потому что ...

условный год

расчитывается, когда знаешь, что делать.Когда знаешь, что делать, но по ходу дела это меняется, размерность год - теряет смысл.

Мне думается, что когда 12 раз, то вероятность того, что 12 раз или год — непланируемы. потому что ...

Ну давайте возьмём "раз в месяц до окончания проекта".


Когда знаешь, что делать, но по ходу дела это меняется, размерность год — теряет смысл.

Откуда вы узнаете что что-то там по ходу дела меняется? Ну если клинету ничего не показывать пока не готово? В хрустальном шаре увидите? :)

Во втором случае вы берёте ТЗ, делаете что-то месяц, потом показываете результат заказчику и в случае необходимости изменяете ТЗ. И так двенадцать раз.

Вашего вопроса не понял. Это же ваши слова выше, и они имеют смысл. Потому что в этом то и суть agile, что не через год встречаются заказчик и исполнитель. Но если это так и изменения будут по ходу дела проявляться, то тогда как можно говорить, что что-то будет длится год если не известно, что будет сделано.

Короче противоречие , но мало кого это волнует. И если это не будет работать, то проблему будут не в методике искать, а в неправильном использовании agile. А сама противоречивая методика не имеет права поддаваться сомнению.

Нет там никакого противоречия. В аджайле обычно есть MVP, который с 99, 9% вероятностью укладывается в сроки. И который обязателен.


А все остальные хотелки уже идут по возможности. То есть например если нет сильных отклонений от первоначального ТЗ.

Не, ну как может быть изначальный срок обязательными, если по дороге все/многое может меняться? Ведь воочию вижу каждый день именно неподтвеождение этого тезиса.

Или есть сроки, тогда всякие изменения по ходу не имеют место быть, или постоянные изменения, но тогда срок только действует на них, но никак на изначальный срок.

С чего вы взяли что меняться может вот прямо всё?


Ещё раз: обычно есть MVP или как-то по другому называемая "обязательная часть". Она либо в принципе не изменяема, либо как минимум изменяема только при условии что изменения не ставят под вопрос сроки проекта.


А если клиент вдруг решает что ему это уже не нужно и нужно что-то вот совсем другое, то проект прекращается со всеми вытекающими. Точно так же как и не в аджайле.

Как вы можете на 2-м месяце определить, насколько сдвинут некоторые изменения весь срок? Может быть у вас и правда стеклянный шар и там всё будет видно.

Но у меня как то не получается согласовать изменения/общий срок/неизменение бюджета итд. В момент изменений все уверены что риски вроде всегда есть, но их не воспринимают как основопалагающие. И только, когда сроки сдачи еально начинают поджимать, вот тогда "..а почему вы не конкретно давали понять, что срок можнт срывается,? И не важно, что мы там хотели, вы же обещали...".

У меня сложилась такая вещь, что или общий план (roadmap) с конкретным сроком и бюджетом. Но без изменений по ходу дела. Или конкретное количество заданий на один спринт (или PI), и общее представление, но без ответственности за общий план, срок и бюджет.

Как вы можете на 2-м месяце определить, насколько сдвинут некоторые изменения весь срок? Может быть у вас и правда стеклянный шар и там всё будет видно.

Когда вы получаете ТЗ, то как вы определяете сколько времени уйдёт на его реализацию? Вы же для этого стеклянный шар не используете.


Но у меня как то не получается согласовать изменения/общий срок/неизменение бюджета итд

И если у вас не получается, то это невозможно в принципе? Или как это понимать?


И только, когда сроки сдачи еально начинают поджимать, вот тогда "… а почему вы не конкретно давали понять, что срок можнт срывается,? И не важно, что мы там хотели, вы же обещали...".

Ну так может вам стоит научиться "конкретно давать понять что сроки возможно срываются"? Потому что вы похоже это как-то и без стеклянного шара понимаете и только до клиентов донести не можете...

Принят — это когда обе стороны удовлетворены финальным решением. Вы можете сравнивать его с изначальными требованиями, но в течение разработки скоуп работ часто меняется. Это происходит по многим причинам.

Например, если бы вы в 2019 году решили создать Android-приложение для управления sms и привлечь к этому аутсорс-компанию, то новые условия Google заставили бы вас отказаться от этой затеи. Другой пример: в 2018 году в Евросоюзе приняли GDPR — Общий регламент по защите персональных данных. Из-за этого европейские банки получили дополнительные ограничения и изменяли требования для разработчиков, которые создавали им цифровые продукты.

В целом, все IT-проекты обладают нативной сложностью: невозможно спроектировать всё сразу. Даже в государственных проектах, где чётко прописаны все требования, на этапе приёмки есть Changelog — журнал изменений, в котором указано, какие фичи были запланированы и по какой причине от них отказались в ходе разработки.

Пересечения не точны:

  1. Кружочек Scrum - должен быть внутри кружочка Agile. Иначе выходит, что Scrum может существовать без идеологии Agile (в тех местах, где они не пересекаются)

  2. Kanban может прекрасно дополнять любую другую реализацию по Agile, не обязательно Scrum. Однако, на диаграмме Kanban пересекается только со Scrum, но не с Agile

В общем, кружочек Agile нужно увеличить и сдвигать вправо вниз, пока он не поглотит кружочек меньшего размера, под названием Scrum

В остальном - всё "по полочкам", спасибо!

Хорошие наблюдения, спасибо!

Действительно, чтобы правильно настроить и применять скрам, должно быть понимание, что такое аджайл. Но в реальности часто бывает так, что команды не знают основных принципов философии, но пользуются скрамом, потому что это toolbox — некий набор инструментов.

Кстати, как думаете, если Daily Meeting — это пассатижи, то что такое Agile? ;)

Если Daily Meeting — это пассатижи, то Agile — это базовые концепции слесарной работы.

Конечно же, пассатижами можно и гвозди забивать, и делать это ежедневно. Можно и микроскопом тоже забить. Возможно, при такой схеме работы когда-то и придёт понимание, как инструмент нужно использовать. А может и нет.

И появится очередная сотня статей о том, какие плохие нынче пассатижи, гвозди плохо ими забиваются… с рекомендациями, как процесс улучшить....;)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории