История внедрения Scrum в отделе внутренней разработки 1С

Управление - Управление проектом

93
Я работаю с 1С с 2004 года. В процессе своей работы я сменил несколько команд, и практически все они были командами внутренней разработки большого или среднего заказчика. В одной из команд (это был холдинг среднего размера) мы внедряли Scrum. Об этом я и хочу рассказать. Итак, мой доклад будет о внедрении Scrum. «Глубоких мыслей» не обещаю, просто постараюсь рассказать о том, как это было у нас, и возможно, пояснить, почему это было именно так

С чего все началось?

Что было в моей жизни до того, как я начал внедрять Scrum? 

Была работа, которую надо было делать. И был интерес к Agile. И в один прекрасный момент, в 2010 году, когда я проходил тренинг AgileBaseCamp, работа и хобби сошлись в одно, и я как-то резко понял, что у нас в команде нужно внедрять Scrum. Мне показалось, что это сможет нам помочь. 

Что у нас было на тот момент, когда мы начинали?

  • У нас была команда внутренней разработки – 4-5 человек.
  • Задачи к этому моменту уже «трекались». В качестве трекера мы использовали Mantis.
  • Документация для пользователей составлялась в Wiki.
  • Было понятие релиза.
    Несмотря на то, что у нас была внутренняя разработка, мы не имели доступа к базе. И значит, мы не могли залезть в базу и поправить, если что-то было не так. Мы выпускали релиз и выкладывали дистрибутив на внутренний открытый источник, а люди, которые сопровождали нашу базу 1С на филиалах (или на подразделениях холдинга), брали релиз оттуда. Получается, у нас было больше общего с внешней разработкой, потому  что, если находились какие-то баги, приходилось выпускать баг-фиксы и выкладывать новый релиз.
  • Был форум поддержки.
  • Также было несколько владельцев продукта (Product Owners). Это были заказчики так называемых профильных департаментов.

И был один руководитель (так называемый proxy-Product Owner), который собирал от них требования и выступал в качестве единого владельца продукта для нашей команды (собственно, так и рекомендуется в Scrum). 

 

Первые шаги

Начинали мы на внедрении. Многие говорят, что внедрение – это стресс. Но так как мы в тот момент внедряли учет на одном из предприятий, нам было удобно использовать внедрение для некоторой практики. И мы попробовали – начали с доски и со стенд-апов.

Это история о том, что Scrum можно внедрять «снизу», и это могут делать обычные разработчики. Я как разработчик пришел и говорю: «ребята, давайте попробуем работать по Scrum, начнем с доски, попробуем дейли-митинги, посмотрим, подходит ли это нам».

И оно завелось. На внедрении это было очень удобно: собраться стенд-апом у доски, постоять, подвигать эти тикеты, понять, что нам нужно сделать, что еще не сделано, в каком оно все статусе. Получалось нагляднее, чем это было в трекере, поскольку в трекере все лежало какой-то одной неподъемной кучей, а доска позволила нам как-то распределить наши задачи, расставить приоритеты. И, конечно, помогали дейли-митинги, которые мы проводили также у доски.

Через какое-то время стало понятно, что нам немного не хватает знаний и понимания, куда же двигаться дальше. Да, у нас есть доска. Вроде понятно, что нужно как-то проводить планирование, как-то делать ретроспективу. Но как именно? Тогда мы затащили руководителя на тренинг по Scrum. Вообще, мой совет программистам: общайтесь с руководителями и запускайте (завлейкате, заманивайте?) их на тренинги – это классная штука. После этого обычно начинаются положительные перемены. В частности, начиная с того момента, как мы это сделали, внедрение самой методологии пошло живее и лучше, поскольку появилась официальная поддержка руководства.

Если говорить про этапы процесса внедрения методологии Scrum снизу, то это было так:

  • Вначале мы собирались у доски сами по себе, как программисты – это вызывало у руководства любопытство, но не более. Нас спрашивали: «А что вы делаете?» – «У нас дейли-митинг». – «Хорошо, занимайтесь, лишь бы задачи вовремя делались».
  • Но в определенный момент, когда появилась официальная поддержка сверху, это внесло определенные изменения, стало проще двигаться дальше.
  •  

Второй этап. Что изменилось?

У нас появилась электронная доска (мы сами ее сделали). Сначала нам специально выделили время и сказали: «Ребята, есть много продуктов по Scrum, Agile (например, Redmine, Jira), все поддерживается. Подберите себе что-нибудь для работы». Но мы, как настоящие 1С-ники, решили изобрести велосипед и сделали для этого свою конфигурацию.

Трекер никуда не делся (на рисунке показан наш трекер Mantis), но путь вопроса преобразился. Если раньше вопрос попадал в трекер и там же отслеживалось его состояние (плюс было какое-то обсуждение), то теперь стало немного по-другому. Трекер по традиции остался, туда собирались все требования, а в дальнейшем Product Owner принимал решение, пойдет требование в разработку или нет.

Если Product Owner решал, что требование должно пойти в разработку, то оно автоматически попадало в другой трекер, который мы назвали ScrumWork. Там расставлялись приоритеты, давалась оценка. 

Там была доска итерации, где мы могли перемещать тикеты. Многие инструменты для Agile также позволяют это делать.

Что еще поменялось в процессе? В форме тикета появились специальные подсказки, критерии готовности задачи. Например, мы ввели обязательное заполнение описания для первого демо, чтобы конкретизировать, как продемонстрировать решение для этой задачи.

Также в карточке тикета появились специальные поля для привязки к нему документации,  чтобы тестировщик не забыл проверить то, что вопрос документирован и описан. Это достаточно важная деталь.

Конечно же, помимо всего прочего, у нас осталась и железная доска. Почему мы ее оставили?

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

В данном конкретном примере еще и календарик есть, и на нем можно отследить, сколько дней итерации прошло. Например, посмотрев сюда, мы можем увидеть, что до конца итерации еще целая неделя есть (итерации у нас были трехнедельные, я об этом чуть позже подробнее расскажу), а при этом почти все вопросы практически уже готовы либо находятся на тестировании. Сразу видно, что итерация идет хорошо, можно было на нее еще больше запланировать (сначала мы немного ошибались с планированием, а потом сориентировались).

 

Следующий этап. Поддержка

Доска менялась, становилась больше. 

Какая еще практика появилась?

Доска – это хорошо, это разработка, тикеты движутся вперед. Но есть еще поддержка. Бывает, конечно, что у заказчика есть выделенная команда поддержки, но это бывает очень редко. У нас поддержка также относилась к команде внутренней разработки. И мы придумали внедрить у себя такую штуку, как полоса пожарной машины.

Что происходило? Обычный процесс – разработчик закончил предыдущую задачу, подходит к доске, выбирает себе какой-то тикет, перевешивает его в работу и идет делать. И мы договорились, что если в «Полосе пожарной машины» есть красный тикет, то из работы ничего не берется, а берется и срочно решается вот этот конкретный вопрос.

И как только мы это сделали, все сразу рухнуло. Потому что разработчики начали брать эти красные тикеты, их пошло еще больше, все стало плохо, и мы стали думать, как сделать так, чтобы стало хорошо. И сделали.

Что мы сделали? Мы выделили одного разработчика, который занимался поддержкой. Но решили его менять по неделям. То есть, какой-то несчастный человек на неделю назначался в качестве саппорта. По возможности он брал задачи из основной итерации, но главным его приоритетом было решение вопросов по поддержке.

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

Причем одной из практик, которая тоже принесла пользу, была торжественная передача этой пожарной машины, потому что в ходе передачи можно было попутно сообщить: «Ты знаешь, у меня на прошлой неделе были вот такие вопросы, я их не решил, ты жди, они к тебе тоже прилетят».

Собственно, практика пожарного, дейли-митинги, доска.

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

Но нам удалось решить эту проблему. Что помогло? Когда начинался разговор «за жизнь», мы говорили так – давайте про это отдельно, на пост-дейли-митинге. Кому интересно, тот остается. Это переносило все лишнее на потом, и дейли-митинг становился «пульсом команды» – собрались, синхронизировались, поняли, кто что делает. Правда, иногда, если это действительно было нужно, пост-дейли-митинги затягивались до нескольких часов.

 

Планирование

Дальше еще одна хорошая практика в Scrum, одна из самых главных, – планирование.

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

  • На начало планирования Product Owner имел приоритезированный Backlog продукта, где у него набирались задачи на итерацию.
  • Для тех задач, которые еще не были оценены, выставлялась оценка с помощью Planning poker.
  • Что было интересного на планировании? Мы стали ставить на итерацию некую цель, имеющую определенную бизнес-ценность. Не просто «давайте за следующую неделю повесим как можно больше тикетов, и всем будет отлично». От генерирования огромного числа тикетов обычно никому отлично не бывает. Имеется в виду какая-то конкретная цель: внедрить блок учета конкретно для того-то или запустить давно желаемую «фичу» (что-то, что имеет ценность для заказчика). Это было важно для того, чтобы мы могли что-то показать заказчику на демо и соотнести поставленную цель с реальностью – выполнена она или нет. Я всем советую на планировании пытаться поставить цель итерации. Хотя надо сказать, что это не всегда возможно, особенно если делается большая «фича». Запустить «1/28 от этой большой фичи» – как цель звучит не очень хорошо. Но, конечно, бывало и так.

Теперь по поводу оценки. Оценка по методу Planning poker проводилась в неких условных единицах (в так называемых «попугаях»). При планировании мы договаривались, что за итерацию команда сможет сделать определенное количество этих «попугаев».

Вот здесь на слайде показаны наши реальные цифры:

  • Сначала мы вообще ничего не понимали, и там стоит прочерк.
  • Потом мы начали что-то понимать и определили, что оценка на итерацию у нас будет 80 «попугаев»,
  • Но уже на пятой итерации оценка упала до 34. Это нормально, потому что мы решили поменять систему оценок (стоимость единицы стала больше).
  • Потом запланированная стоимость наших итераций выровнялась и в последующем была плюс-минус одинаковой.
Правда, видно, что десятую итерацию вдруг оценили в 19 "попугаев". Но там стоимость оценки не поменялась, там изменился состав команды – людей стало меньше и, соответственно, на результат запланировано меньше часов.

 

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

  • Длина итерации в днях.
  • Количество людей.
  • Идеальные человеко-часы.
  • Какие-то буферы (аутсорсеры, возможная поддержка).
  • Итого получаем чистых часов.

Тут есть пункт Velocity – это стоимость одного Story Point («попугая») в часах по результатам предыдущей итерации. Соответственно, взяв эту стоимость, мы понимали, что при планировании следующей итерации мы можем взять задач на 54 Story Point. Мы старались брать немного больше (с запасом). Некоторые, наоборот, перестраховываются, берут меньше.

Соответственно, фактически в конце итерации мы понимали, сколько по факту было сделано (здесь 65). И, соотнося с реальными часами, проводили фактический расчет Velocity. У нас по факту получалось 0,12. Вот это вот 0,12 шло уже на следующую итерацию как планируемая скорость команды.

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

 

Состав итерации

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

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

  • Демо. Во время демо ответственный за проект (так называемый архитектор проекта) становился, показывал, что в проекте поменялось. Даже если заказчика не было, демо проводилось «для себя», для того чтобы сама команда понимала, какие изменения произошли. И если кто-то всю итерацию пилил свою гайку, особо не обращая внимания на дейли-митинги и на окружающих, то на демо он имел возможность посмотреть, что же поменялось. И это было важно, в том числе для поддержки.
  • Дальше, после демо, проводилась ретроспектива. Мне вообще кажется, что ретроспектива для команды – это такая вещь в процессе, которую можно улучшать практически бесконечно. Сколько она у нас ни шла, я как Scrum-мастер ей никогда не был доволен. Хотелось, чтобы она проходила лучше, эффективнее, быстрее двигала процесс вперед.
    Какие сложности возникали на ретроспективе? Для нас, как для команды, которая изначально внедряла Scrum «снизу», обсуждение того, что у нас было в процессе сложного, плохого или хорошего, обычно выглядело так: «Ну вот, такая-то обработка была сложная». – «Нет, подожди, не обработка сложная, что в процессе было сложного? Или что можно улучшить?» С самого начала было очень тяжело объяснить, что ретроспектива – это не про код, а именно про сам процесс.
  • Code-review. Не буду долго останавливаться. Есть такая инженерная практика, когда из кода вычитываются определенные интересные места. У разработчиков друг в друга летят тонны конфетти – все же любят, когда его код вычитывают и критикуют.
  • И планирование. Поначалу, когда этих активностей не было, планирование занимало полтора дня: понедельник и часть вторника. Было тяжело, непонятно было, как это делать. А потом мы привели его в чувство, оно стало занимать полдня – все планируется, итерация набирается, приоритеты расставляются, заказчик доволен. Важное выполняется в первую очередь, неважное – во вторую. Все замечательно.
  • Конец итерации – это релиз. Какие-то абсолютно рутинные активности: собрать cf-ник, md-шник, выложить его, упорядочить. Все это делается в четверг, потому что все знают, что плохая примета выпускать релиз в пятницу, поскольку это испорченные выходные.
  • Ну и пятница – инженерный день. Это даже не из Scrum. Мы могли себе позволить какой-то день, отведенный под то, чтобы разработчик мог почитать мануалы, сделать какой-то прототип для следующей итерации, попробовать какую-то новую функцию или установить себе свежий релиз платформы 8.3, который пока заказчику не нужен, но можно что-то там для себя поковырять. Я не знаю, наверное, не все могут себе позволить инженерный день. Но мы могли, хотя это и дорого – это целый день работы программиста. Но считается, что в долгосрочной перспективе это очень полезно, на самом деле.

Вот такой у нас был состав итерации, так мы ее проводили.

 

Заключение

И вот… так у нас в конечном итоге стало (мне эта картинка самому очень нравится).

Раньше, когда разработчик брал и перевешивал тикет, он писал на нем свою фамилию - то есть тикет взял такой-то. А потом, через какое-то время, мы стали клеить вот такие аватарки. Взял вопрос – наклеил аватарку.

Почему мне это очень дорого? Потому что, когда люди начинают с чем-то играть, они перестают этого бояться. И когда появились аватарки – я понял, что доска и все, что мы делаем, вошло в какой-то рабочий ритм, стало привычным и знакомым. То есть можно сказать, что внедрение методологии состоялось, хотя этот процесс – он, конечно, бесконечный.

Вот такое личное, очень дорогое мне замечание.

 

***********

Данная статья написана по материалам доклада, прочитанного автором на Конференции Инфостарта IE 2014 29-31 октября 2014 года.

Приглашаем вас на новую конференцию INFOSTART EVENT 2018 Education.

93

См. также

Комментарии
Избранное Подписка Сортировка: Древо
1. borodabmc 26.02.15 16:08 Сейчас в теме
Вкратце расскажу наш путь к Agile... За чашечкой чая в одно прекрасное утро подумали, что стало скучно работать в полном хаосе и пошли гуглить...
Начинали сначала с чистого "КАНБАНа". У каждого отдельная доска, только со своими задачами. Реализовали и на доске и в своей CRM. Аналитиками бросались задачи на конкретных разработчиков или в общую корзину. Вначале по правилу "кто первый встал, того и тапки", то есть кто-раньше поставил задачу, ту задачу быстрее брали в работу. Вначале все было достаточно хорошо. Но кампания росла, и в такой адаптации уже не помогало, а зачастую мешало работать. Стало не хватать адекватного планирования...(чтоб хоть банально закрыть вопрос со сроками, которые озвучивать заказчикам). В итоге прикрутили приоритеты к задача - тоже мало.
Начали внедрять Scrum со всеми артефактами (user story, спринтами, ролями, доской, и т. д.).
Тяжело было вначале донести людям (те, с которыми поднимали Канбан, давно слились), которые привыкли работать в хаосе и постоянно в режиме хотфикса... Пришлось даже пенделей отвесить некоторым: вроде собрались, замутили спринт, на выходе - спринт мертвый... почему... не понятно, чего от них хотят... Собрались, еще раз объяснил, что Scrum, в первую очередь, - это командная работа... Вроде прислушались... Второй спринт взлетел... В итоге работает несколько команд на проектах.
С дежурным хорошая идея, тоже пытался, чтоб был человек дежурный на второй линии поддержки, если первый уровень не справляется. Тяжело пошло... продукты разные, проекты тоже... (от розницы до автотранспорта)... и универсальных бойцов мало...
По итогу:
Scrum завелся, разработка на проектах.
Вопрос поддержки - два уровня... если первый не справляется то задача прогерам.
Борюсь с офисной мудой - чтоб прогеры меньше отвлекались на вопросы аналитиков и консультанотов (особенно если они вообще не по теме)
asisdes; firma-modul; spawn8995; blindcat2006; Agrognom; Perk0n; zfilin; +7 Ответить
2. Silenser 487 27.02.15 11:12 Сейчас в теме
Видимо меня заминусуют, но я не вижу реальных плюсов от новой схемы. Трекер + приоритеты решали бы все описанные проблемы на ура, а так удлинили цикл разработки и увеличили время на планирование и сопутствующие вещи, что в итоге выльется в падение производительности людей, которые будут отвлечены от работы занесением дополнительных аналитик в новую систему.
Вопрос саппорта решается выделением времени сотрудников на этот самый саппорт с ведением длинных тикетов, которые имеют шанс перейти на другого сотрудника, в трекере.
Вопрос взаимовлияния разработки решается либо наличием архитектора системы, либо документированием аналитиками.
Так к чему же эта работа ради самой работы?
ПС: это не попытка наехать на автора, скорее вопрос, обусловленный личным негативным опытом, когда внедрением подобной схемы закончилось развалом команды (из 12 работников отдела ИТ 10 покинули компанию, при этом ни одна из заявленных новым РП целей не была выполнена в срок, что было объяснено старыми кадрами, но даже набор новых не дал результатов, все как в анекдоте про 3 конверта)
davydoff; ivv1970; olgerd666; +3 Ответить
8. Сурикат 182 17.08.17 13:32 Сейчас в теме
(2)
Если мы говорим о порелизной разработке, то гибкие методологии удобнее, чем приоритеты.
+ при наличии сильно изменяющихся требований они дают определенные плюсы. Мы же выкатываем почти всегда законченную функциональность

И очень сильно зависит от культуры команды. Если люди не понимают какие проблемы такие методологии решают, то они и не зайдут
3. 1Service2 12.05.16 12:08 Сейчас в теме
4. 1c-intelligence 5705 17.08.17 11:53 Сейчас в теме
Расскажите, пожалуйста, насколько возросла скорость разработки в попугаях за время использования скрама?
10. zfilin 1960 18.08.17 14:45 Сейчас в теме
(4) Давно все это было. Скорость "в попугаях" плавала, то росла, то уменьшалась. Сейчас не отвечу на этот вопрос.
Главным было то, что повысилась управляемость и прогнозируемость процесса разработки.

(5) Спасибо. Это стенограмма с выступления.

(6) Вы немного ошибаетесь. "Боитесь" это не то слово. Просто разработка и поддержка это немного разные виды деятельности и не все могут мгновенно вынырнуть из отладчика, ответить на вопрос "почему у меня не проводится реализация", а потом так же быстро погрузиться обратно в отладчик.
Именно с таким дроблением времени и была призвана бороться пожарная машина. Ну, а что описал я это с иронией словами "несчастный" и "обречен", так в любом даже самом серьезном деле есть время "погыгыкать".
14. 1c-intelligence 5705 21.08.17 19:45 Сейчас в теме
(10)
Главным было то, что повысилась управляемость и прогнозируемость процесса разработки.


Два вопроса, если позволите:
1. Управляемость и прогнозируемость процесса разработки вы как-то измеряли? Как определили, что они повысились?
2. Почему вы назвали это "главным"? Оно было главным изначально, как цель? Или стало главным в итоге, как лучший из полученных результатов?

Спасибо.
16. zfilin 1960 30.08.17 14:35 Сейчас в теме
(14)
1. Повышение управляемости стало очень заметно заказчику. Мы не вели "количество положительных отзывов" как исчисляемую метрику, но улучшение было видно "невооруженным взглядом".
После внедрения заказчики (руководители профильных департаментов, например) начали получать достаточно точную информацию о том, в какие сроки будет реализован тот или иной запрашиваемый функционал, против "ну, будет готово когда-нибудь, как будет готово".
Получив доступ к бэклогу и возможность присутствовать (по желанию) на митингах, стали понимать какая фича находится в разработке в данный момент, какая запланирована в эту итерацию, а какая отложена до следующей. Что в конечном итоге привело к пониманию, какие требования и задачи менять уже нельзя, а где еще можно сказать "я передумал, давайте тут поменяем, у вас оно все-равно на следующую итерацию запланированно".
Присутствуя на демо заказчики могли видеть получившийся результат и могли тут же внести в бэклог какие-то новые требования, корректировки на следующую итерацию. А не получали обратную связь уже от конечных пользователей, когда тех уже "достала эта тупая 1С".
То-есть разработка стала более понятной и прозрачной для заказчика и как следствие, заказчик получил возможность этот процесс _разумно_ "направлять" в русло интересов бизнеса, в конце-концов.
17. zfilin 1960 30.08.17 14:37 Сейчас в теме
(14) Про управляемость процесса внутри комманды писать не буду, сам Scrum достаточно хорошо и красиво описывает это. Митинги, ретроспектива, доска - все это иструменты упорядочивающие отношения внутри команды и во многих статьях про это и так уже сказано.
19. zfilin 1960 30.08.17 14:59 Сейчас в теме
(14) 2. Да, это изначально было основной целью. Скорость все-таки была на втором месте.
15. Yashazz 2295 23.08.17 19:28 Сейчас в теме
(10)
Скорость "в попугаях" плавала, то росла, то уменьшалась... Главным было то, что повысилась управляемость и прогнозируемость процесса разработки.

А вот и момент истины. То есть, все вышеописанные прыжки и гримасы выполнялись исключительно ради собственного удобства внутренней группы айтишников, и никак - подчёркиваю, никак - не принесли пользы бизнесу, за счёт которого айтишники кормились и чьё время, по сути, тратили на эту фигню. Поясню: управляемость - это очень красивое слово, за которым не стоит ничего. Ни умения фрагментировать задачу и контролировать её решение, ни прозрачности для руководства, ни мониторинга занятости. Управляемость. Волшебное нечто из лексикона всяких коучей... Прогнозируемость - это очень смешное слово. Требования бизнеса априорно непредсказуемы, т.к. это всегда может быть как задача рынка, так и шлея под хвостом гендира или главбуха. Прогнозировать разработку это как угадывать цены на нефть. Заложите худший сценарий и может быть частично угадаете, но всегда без конкретики.
А самое главное, человекочасы, скорость, с которой бизнес получает отдачу от айти, не изменилась. Вот и видим, что служебное сервисное подразделение вместо полезной деятельности занималось какой-то самоценной, пардон, фигнёй. Да ещё и на статьи об этом время тратють... Непорядок, робятки, с точки зрения гендира - явный непорядок.

Интересно, долго этот сферический в вакууме просуществовал? Долго ли придерживались сиих положений?
1c-intelligence; +1 Ответить
18. zfilin 1960 30.08.17 14:57 Сейчас в теме
(15) Я думаю, что вы противник agile-подходов, что нормально. Agile не серебрянная пуля и не обязан всем нравится.

Но пришли вы в комментарии к статье не для того, чтобы узнать что-то новое, а для того, чтобы:

Зубоскалить:
"долго этот сферический в вакууме просуществовал?" - вам же на самом деле не интересно долго или нет.

Додумывать за топикстартера:
"и никак - подчёркиваю, никак - не принесли пользы бизнесу" - это не так, почитайте (16).

Говорить провокационные глупости:
"самое главное, человекочасы, скорость, с которой бизнес получает отдачу от айти, не изменилась" - очевидно, что скорость создания никому ненужного функционала никому не принесет пользы. Вопрос не в том "как быстро", а "делаем ли мы то, что нужно".

Демонстрировать полное незнакомство с вопросом, типа "слышал звон":
"ни умения фрагментировать задачу и контролировать её решение, ни прозрачности для руководства" - это все, что вы опровергаете, заложено в 12 принципов agile и метолологии.
Без фрагментации невозможно планирование и нормальное ведение бэклогов. Для контроля есть дэйли-митинги, для прозрачности - демо. И еще много чего. Начните хотя бы с этого - http://agilerussia.ru/category/books/

Боюсь, нам с вами не по-пути.
22. Yashazz 2295 31.08.17 20:24 Сейчас в теме
(18)
вам же на самом деле не интересно долго или нет
Эдак Вы лихо решаете за других, что кому интересно и что кому нет. За своих клиентов так же уверенно решаете?) Если я спросил, значит, интересно. Я статистику провалов веду - ну, если кто вообще признаётся. Обычно это выдыхается и вырождается в пределах года. Что, хватит духу сказать, сколько прожил более-менее полно внедрённый подход? Или увильнёте?

"и никак - подчёркиваю, никак - не принесли пользы бизнесу" - это не так, почитайте (16).
Супер. На момент моей реплики (16) ещё не было, но спасибо за отсылку. Теперь по делу: Вы понимаете, что никакие сроки реализации не имеют смысла, т.к. всегда есть нечто супер-срочное и сверх-горящее? И что это именно сферический конь в вакууме? Насчёт прозрачности соглашусь, только это никому не интересно, на самом деле. Менеджеру плевать, что он может узнать, чем занят программер. Менеджер хочет, чтоб программер всё бросил и реализовал менеджерскую хотелку) Так что в изрядной мере тоже самоцель, юзерам мало интересная.

"самое главное, человекочасы, скорость, с которой бизнес получает отдачу от айти, не изменилась" - очевидно, что скорость создания никому ненужного функционала никому не принесет пользы. Вопрос не в том "как быстро", а "делаем ли мы то, что нужно".
Стоп-стоп-стоп. Вы ж сами сказали, что скорость не выросла. Не путайте тёплое с мягким. Если Вы под "то, что нужно" подразумеваете внутренний самоконтроль группы разработчиков, то это вопрос даже не управления проектом, а чёткости поставленной задачи (ТЗ) и профессионализма исполнителей.

"ни умения фрагментировать задачу и контролировать её решение, ни прозрачности для руководства" - это все, что вы опровергаете, заложено в 12 принципов agile и метолологии.
В теории - может быть. На практике, повторюсь, сперва пафос, а после пшик и проблемы. Я говорю от чистой практики.

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

Я тут Вам немножко изобразил реакцию прагматика на всякие заумные изыски, притом, что нужда в решении заявленных вопросов безусловно есть. А Вы грубите. В общем, нашей группе компаний эту методологию в своём изложении Вы, увы, не продали)))
25. zfilin 1960 01.09.17 10:48 Сейчас в теме
(22) Если вам нужны ответы на вопросы, приходите в личку. Расскажу все что знаю. Кстати, у меня к вам тоже есть несколько вопросов.
Но я думаю, что вы скажете что-то типа "а что нельзя ответить мне в комментариях?" и в личке я вас не дождусь, потому что вы тролль и вам не важно получить информацию и новые знания, а важно публично провоцировать участников обсуждения.
5. genayo 17.08.17 12:01 Сейчас в теме
Вот, наконец то статья с нормальными практическими примерами, а не чистая теория...
6. Vovan1975 14 17.08.17 12:40 Сейчас в теме
У несчастного на рабочем месте стояла большая красная машина (та, которая на картинке). И все знали, кто на этой неделе обречен общаться с пользователями и заниматься их сиюминутными проблемами.


вот в этом, ребята, ваша проблема. Вы боитесь общаться с народом.
корум; +1 Ответить
7. Vovan1975 14 17.08.17 12:45 Сейчас в теме
и да, не могу не оставить это здесь:
"SCRUM или шабаш ведьм"
http://blog.jdevelop.com/software/2014/03/25/lifestyle.html
9. 1c-intelligence 5705 18.08.17 08:44 Сейчас в теме
(7)
и да, не могу не оставить это здесь:
"SCRUM или шабаш ведьм"
http://blog.jdevelop.com/software/2014/03/25/lifestyle.html


вы сами что думаете про то, что написано по этой ссылке?
11. zfilin 1960 18.08.17 14:59 Сейчас в теме
(7) Я могу вам еще одну ссылку дать, тоже интересную - https://ebanoe.it/2016/12/26/woxapp-scrum-slavery/

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

Сейчас совершенно очевидно, что
методология работает,
проекты делаются успешно,
пытаться всунуть ее где надо и не надо не следует,
успешно начать работать по scrum получится более вероятно у той команды, которая в принципе готова работать, следовать правилам и по необходимости менять их разумно, не доводя до идиотизма, чем у тех, кто не заинтересован в этом.
А значит, успешные проекты на scrum не столько заслуга самого scrum, сколько команды или начальства или scrum-мастера, которые могли бы выбрать и какую-то другую практику взаимодействия или даже придумать совершенно собственную и все бы так же получилось.

И да, сейчас я не использую гибкие методологии, потому что в конкретно данный момент не вижу это для своей комманды целесообразным. Однако, как только понадобится, я с удовольствием снова ими воспользуюсь.
12. Vovanches 18.08.17 15:47 Сейчас в теме
Люди, откуда у вас столько времени, чтобы заниматься этой фигней?
Yashazz; vitalbasl; +2 Ответить
13. tailer2 18.08.17 15:53 Сейчас в теме
20. Neco 124 31.08.17 14:12 Сейчас в теме
Во всех этих играх с Agile важно, чтобы ваш заказчик знал, понимал и участвовал в процессах планирования и демо. Нужно объяснить сотрудникам заказчика, что задачи выполняются по приоритету, приоритет вот это бэклог и что надо, как-то в него заглядывать а не строчить гневные письма типа когда вы это сделаете.
23. Yashazz 2295 31.08.17 22:14 Сейчас в теме
(20) Заказчик не будет никуда заглядывать. Вы можете предоставить сотни удобнейших бэклогов, равно как и любых иных средств мониторинга процесса. Заказчик, а особенно внутреннее руководство, хочет простых вещей, чтоб всё и побыстрее. И если заказчик вдруг узнаёт, что вместо экстенсивного роста скорости выполнения работ исполнители заняты какой-то малопонятной внутренней интенсификацией с каким-то эйджилом, то единственная реакция, нормальная бизнесовая реакция, такова: "вам что там, делать нехрен?". А сотрудники заказчика будут в меру своей скандальности орать, что всё просрочено, ничего не работает итд.

Как вы не поймёте, что тут вообще главное другое. Что никому, кроме вас самих и вашей группы разрабов, не интересно всё это и бесполезно. Что эмоциональный неадекват истеричных заказчиков, которые в сети ужастиков начитались, визита ФНС испужались, чё-то где-то слышали от знакомых итд, никак не коррелирует с вашей "прозрачностью и управляемостью", и единственное, чем его можно перекрыть - силовой административной поддержкой либо сверхбыстрым выполнением ВСЕХ задач СРАЗУ. И в том, и в другом случае всё вышеопубликованное в лучшем случае страдание фигнёй. В худшем - нецелевая трата времени и сил. Году, помнится. в 2002-м одного такого при мне вышибли с его группой коллег, с треском. Из достаточно крупной телекоммуникационной конторы. Потому как он на вопросы главбуха про какие-то спринты рассказывал, а "у него крыжики и краснота". Будьте реалистами, коллеги.
24. alex_sh2008 5 01.09.17 09:09 Сейчас в теме
(23)
Будьте реалистами, коллеги.

Agile и создали реалисты. Нужно просто правильно применять эти методики в реальной жизни. Насколько я понял сейчас эта фишка среди 1С стала очень популярна, при это люди толком не понимают, а что же это такое на самом деле, вот и вылезают проблемы о которых вы говорите. На самом деле именно Agile и помогает работать с не адекватными заказчиками, главное что бы команда которая для себя выбрала именно эту методику должна точно оценивать риски. Одна команда не сможет одновременно и писать продукт и поддерживать его, проект развалится очень быстро.
21. deminded 7 31.08.17 17:43 Сейчас в теме
Очень похоже на нашу историю, но у нас еще куча нерешенных проблем =) Есть и отличия:
Дежурный у нас меняется ежедневно;
Продукт один, эпиков много и они относятся к разным бизнеса;
Для оценки в "Попугаях" решили ввести список эталонных задач;
Вместо инженерного дня у нас под технологические задачи выделено отдельное количество SP в спринте;
Мы зависли в переходе от оценок Tasks к User Story, но уже понимаем, что надо когда берем в спринт User Story делить ее на кучу Tasks, одна из которых будет документация...
26. Yashazz 2295 01.09.17 15:11 Сейчас в теме
В личку пришёл. Если хотите слегка пооффтопить прямо тут - с 03.09.17 буду к вашим услугам.

потому что вы тролль
Знаете, очень забавно выглядит, когда абсолютно (подчёркиваю, абсолютно) все виденные/читанные мной проповедники подобных систем, будучи предметно спрошены о конкретном выхлопе, впадают в тот или иной неадекват и пытаются прекратить общение.
Я вот вас спрашиваю: что получил бизнес, кроме прозрачности? Вы стали успевать втиснуть критическую задачу между плановыми так, чтобы их сроки не сдвинулись? Вы распределили ресурсы так, что разработчики перестали трудиться сверхурочно при факапах?
28. zfilin 1960 01.09.17 16:34 Сейчас в теме
27. Yashazz 2295 01.09.17 15:21 Сейчас в теме
А самое главное, что никакие обвинения в троллинге не способны опровергнуть зримый и ощутимый опыт. Опыт стабильного провала всех этих эйджил-заумей. Когда руководители проектов и отделов доводили всё до полнейшего трындеца и, извините, мне сотоварищи приходилось своим горбом вытаскивать проекты. Когда приходилось при всей этой красотени лично вправлять мозги заказчикам и терпеть их матюки. Когда отбирали премию именно потому, что мы "вместо работы всякие хрени сами себе внедряем". Когда, наконец, 1С триумфально внедряет Agile и качество платформы, начиная с 8.3.7, падает ниже плинтуса, каждый релизит своё, багтрекер живёт своей жизнью, ранее исправленное всплывает опять, и с подблоками внутри платформы бардак полнейший.
Опыт, он штука такая. Факт есть факт.
29. zfilin 1960 01.09.17 16:34 Сейчас в теме
30. genayo 01.09.17 17:26 Сейчас в теме
(29) Жаль, что в личку. Работа с возражениями - очень интересный навык :)
31. zfilin 1960 01.09.17 21:45 Сейчас в теме
(30) Если в личной переписке станет понятно, что я ошибся и уважаемый Яков Коган не тролль или, возможно, у нас в беседе будут важные мысли в тему публикации, то мы обязательно вернемся в комментарии. До тех пор треду лучше обойтись без наших препирательств.
32. Yashazz 2295 04.09.17 01:12 Сейчас в теме
Заметьте, я высказался по публикации, а автор - по моей персоне. Разницу ощущаете?)
33. alex_sh2008 5 14.09.17 09:29 Сейчас в теме
(32)Ну и чем все закончилось, мировая или ошибки ни кто не хочет признавать?
34. Yashazz 2295 17.09.17 13:49 Сейчас в теме
(33) Довольно конструктивно пообщались в личке, пришли к выводу, что "стороны опубликуют совместное коммюнике", на этом всё и зависло. Работа не волк, работа "ворк". И я замотался, и Александр, видимо, тоже.
36. zfilin 1960 20.09.17 15:12 Сейчас в теме
(33) (34) Так и есть. Насыпало работы и разъездов.
При первой же возможности итоги опубликуем.
Оставьте свое сообщение