Pull to refresh

Comments 9

Внедрили некоторое время назад. Теперь работаем вообще без выходных, затыкая 100500 неведомо откуда валящихся при финальных тестированиях багов. А ведь как все прекрасно выглядело: CI/CD, мириады интергационных тестов. Но продукт уже должен быть готов, а конь еще не валялся.
При старом добром waterfall продукт всегда выпускали с опережением и без авральных переработок.
Вывод: вся эта трихомудия Scrum, Safe и прочее говно-agile нужны только компаниям, которые лепят эту чушь и потом дерут три шкуры за тренинги.
Все вокруг, включая большинство менеджмента скрипят зубами поминая топ-менеджмент, поддавшийся на этот фейк-тренд.

Почему продавцы Scrum, Agile не рассказывают про результат, а рассказывают про то, какой у них красивый и правильный процесс в картинках?
Сначала результат, а потом уже процесс. Без результата обсуждать процесс нет смысла.

Ну почему же. Тот же Jeff Sutherland вполне себе рассказывает, и приводит цифры с ростом внедрения SCRUM от года к году. Ну и toyota (отцы — прародители) тоже рассказывает.


Другое дело, что результат для них и для вас может быть разным. Например для продавцов SCRUM или SAFe или Lean — результатом будет количество внедрений, но вам-то это скорее всего не так интересно, так? Но вообще когда придут вас обучать и тренировать — то все расскажут, если не вам лично, то как минимум вашему руководству.


Я ни то ни другое ни третье не продаю, а вот ссылкой могу поделиться, я ее нашел в буклетах SAFe — там говорят, что внедрение DevOps (одна из рекомендаций SAFe) — обещает снижение дефектов в 96 раз, в 2 раза снижает время затрачиваемое на исправление проблем с безопасностью, в 46 раз повышает частоту релизов (лучше time to market), на 29% повышает количество времени когда работники занимаются чем то новым (в противовес поддержки старого). Верить этому или нет? Вам решать. Но если интересно — скачайте отчет, посмотрите.

Jeff Sutherland вполне себе рассказывает,
А какие продукты он написал?
что внедрение DevOps (одна из рекомендаций SAFe) — обещает снижение дефектов в 96 раз, в 2 раза снижает время затрачиваемое на исправление проблем с безопасностью, в 46 раз повышает частоту релизов (лучше time to market), на 29% повышает количество времени когда работники занимаются чем то новым (в противовес поддержки старого).
На такое даже здравомыслящий гумманитарий не купится, не говоря уже про технаря.

Вот дедушка Брукс, который управлял разработкой семейством OS/360, говорит что производительность зависит от уровня программиста, нет?

какие продукты

Один. Pationtkeeper Собственно, после этого он привязал использованные там принципы разработки к тойотовскому scrumу (а в те времена в Америке молились на японские способы организации производства в автопроме) и начал его пиарить. Пипл схавал.

Работала в компании, где safe процессы были очень грамотно поставлены. Шли по планам и даже с опережением, 5ая итерация была на подтягивания хвостов, 6ая организационная. PIP каждые 3 месяца, где определяли scope разработки и тестирования.
Верю, что такой подход не каждой компании подходит, но при правильно поставленных процессах недостатки нивилируются достоинствами:
Достаточно длительное время реагирование на несоответствие реальности ожиданиям

Были выделенны специальные люди, кто достаточно быстро реагировали на такие ситуации и доносил до бизнеса
Огромное количество средств и денег тратится на коммуникацию и собрания

Полностью окупалось тем, что релизный цикл шел по расписанию, соответственно time to market было минимальным
Часто рекомендуемые решения в рамках фреймворка уже устар

Не очень понятный для меня минус, почему уже устаревают? Как так?

Согласна с одним из комментариев, SAFE при правильном внедрении приносит намного больше плюсов, чем минусов.

А именно:
1. Делает разработку прозрачной для бизнеса. SAFE подразумевает активное участие представителей бизнеса в планировании, приоритизации, принятии разработок и доработок.
2. Помогает не упустить зависимости от разработок в других командах (проработка связей).
3. Дает возможность командам развиваться (Итерация инноваций и планирования подразумевает не только работу с бэклогом команды, но так же и внедрение новых практик как для командного, так и для индивидуального развития участников).
4. Помогает осознать риски, найти ответственных или продумать варианты обхода при реализовавшемся риске (ROAM-инг рисков).
5. Делает работу команды более слаженной, у всех участников команды появляется в той или иной мере понимание, что в рамках конкретной задачи нужно сделать даже не по своим задачам, где исполнитель - другой участник команды (покер планирование).

SAFE - очень серьезный, проработанный фреймворк. Он действительно заимствует многие принципы из разных методологий. Его применение оправдано, но лишь в умелых руках, разумеется.

Ключевые слова при правильном внедрении

Если у руководства компании есть мудрость и воля для осуществления правильных действий (а их внедрять всегда больно), то выбор фреймворка не вторичен.

Sign up to leave a comment.

Articles