Denis
Я сейчас вижу, что при старте продукта и разработки некого MVP наиболее оптимален Waterfall с итерациями и milestone, затем сопровождение по схеме вроде Scrum + Kanban, как его в EPAM назвале – Scrumban.
Николай
Ksenya
А что, никто не использует приоритеты для задач?
4 приоритета использовали для затыкания кейсов "пришол СЕО и принес контракт", "опять налажали и ничего не работает", "опаздываем", "полет штатный".
Ksenya
Но, к слову, матрицы используются в Incident Management по Impact-Urgency :)
Ksenya
http://wiki.en.it-processmaps.com/index.php/Checklist_Incident_Priority
Ksenya
в девелопменте, в итоге, оставили 3 приоритета (нормальный, критичный, блокер), критичный был редко. Сапортовые тикеты в массовом сервисе раскладывали по матрице, это просто. Внутренний тех долг шел с приоритетом "нормальный". При работе по скрам разводить приоритеты - локальное зло ))
Николай
Вот кстати!..
В саппорте приоритет, понятно, срочность
А в разработке??..
Это срочность или важность?)
Denis
Зависит от момента относительно итерации/релиза
Oleg
Сложность еще же есть
Ksenya
Вот кстати!..
В саппорте приоритет, понятно, срочность
А в разработке??..
Это срочность или важность?)
неправильно. В сапорте приоритет определяется Влиянием и Срочностью )
Oleg
Это я про разработку
Oleg
А в поддержке влияние и приоритет
Николай
Какой приоритет будет у важной несрочной задачи?
А у срочной не оч важной?)
Геннадий
Мы использовали срочность только в тикетах от пользователей. То есть если говорить скрамным языком - в user store, вместе с user point. И то в качестве локальной записочки такой при учёте что делать в ближайшее время. Понадобилось для того, чтобы мелкие тикеты протаскивать быстрее, так как заказчик не понимал что так долго делаются тикеты, где две кнопки нажать.
Николай
приоритет - производная от влияния и срочности :)
Ну ок, влияние... Надо подтянуть матчасть)
Николай
Мы использовали срочность только в тикетах от пользователей. То есть если говорить скрамным языком - в user store, вместе с user point. И то в качестве локальной записочки такой при учёте что делать в ближайшее время. Понадобилось для того, чтобы мелкие тикеты протаскивать быстрее, так как заказчик не понимал что так долго делаются тикеты, где две кнопки нажать.
Это скорее про сложность, а не срочность вроде бы
Геннадий
Это скорее про сложность, а не срочность вроде бы
Нет. Есть простые штуки, которые надо сделать очень срочно. Типа сделать вид, что мы оперативно работаем.
Oleg
Вообще что мешает добавить еще критерий для определения приоритета задачи?
Николай
Нет. Есть простые штуки, которые надо сделать очень срочно. Типа сделать вид, что мы оперативно работаем.
Ок, про сложность+срочность ))
Иногда просят срочно сто-нить типа кнопки "сделать все хорошо" ;))
Николай
Вот мне из-за такой неоднозначности никогда не нравился термин Приоритет
В отличие от рассматриваемых напр в класс-х ТМх срочности и важности
А ещё и сложность ведь есть...
Ок, когда есть система его формализации, и ВСЕ (в тч заказчики) её однозначно понимают, но...
Где прям вот такое есть???
Николай
Ну, за исключением саппорта, где с ним попроще вроде как
Oleg
А правильно я выше прочитал, что при agile регламентация не требуется?
Oleg
Многие здесь практикуют разработку без регламентов?
Ksenya
Вот мне из-за такой неоднозначности никогда не нравился термин Приоритет
В отличие от рассматриваемых напр в класс-х ТМх срочности и важности
А ещё и сложность ведь есть...
Ок, когда есть система его формализации, и ВСЕ (в тч заказчики) её однозначно понимают, но...
Где прям вот такое есть???
приоритет, как рыба, бывает только одной свежести )
Геннадий
У нас приоритет, он же срочность, ставил менеджер проекта, после разговора со всеми. При разработке это делалось чисто интуитивно. В тех поддержке было более чётко всё, так как критерии SLA прописывали прямо текстом в договоре. Приоритет ставил именно заказчик, так как ему виднее критичность для сервиса. С заказчиком проводили периодически беседы, рассказывали трудности. Заказчик был адекватный, подстраивался.
Slava
Геннадий
Шикарно :)
Slava
Lego4scrum придумали чтобы взрослые люди могли наконец поиграть в Лего :)
Denis
@neemah а чем методология от фреймворков отличается? :)
Слава, ответишь на вопрос, как поиграете?)
Timur
По поводу докер - я недавно гуглил себя инструмент для простых смертных для управления инфраструктурой - его нет. DevOps это очень сложно ;/
про докер -- это я пример "маркетингового привлекательного хода" привел. у аджайла есть скрам, а у девопса докер
Николай
Многие здесь практикуют разработку без регламентов?
Oleg возьмите скрам (или др) гайд, выкиньте (не торопясь) невыполнимое, допишите недостающее, назовите документ "Регламент" - готово! ))
Oleg
Oleg возьмите скрам (или др) гайд, выкиньте (не торопясь) невыполнимое, допишите недостающее, назовите документ "Регламент" - готово! ))
Николай, последнее время часто приходиться слышать следующее: а мы по аджайл, скрвм работаем- у нас нет документации на разработанное решение. А нам не нужны никакие правила и регламенты, иы де по аджаил работаем - это обычная практика?:)
Karina
уже сто раз это обсуждали - нет, это не обычная практика
Ksenya
Ksenya
даже "нет регламента" != нет документа, описывающего цели проекта, средства, участников и результаты :)
Denis
Slava
Чтобы ответить на вопрос надо понять что такое модель
Геннадий
Про методологию и framework. Методология изначально философское понятие, наука, изучающая методы чего-то. Там было разделение на теорию и практику, у нас как раз практика. Если брать Agile в широком смысле, то это как раз может быть методологией. А scrum, kanban и т. д. - это как раз методы, можно сказать организации труда, разработки софта и т.д. Это даже методики, поскольку содержат очень конкретные приёмы и подходы. Framework - тоже слово с широким смыслом, в нашем контексте это может равняться методу или методики.
Slava
Главное чтобы покупатели были счастливы :)
Геннадий
И ведь всё равно, термины, которые прорабатываешь, работают только в той группе, где их проработал. Приходишь в новое место, все равно надо синхронизировать язык.
Дмитрий
А это разве не базовое правило общения с людьми ?
Дмитрий
Хочешь что то объяснить - убедись, что у вас общая терминология :)
Denis
И ведь всё равно, термины, которые прорабатываешь, работают только в той группе, где их проработал. Приходишь в новое место, все равно надо синхронизировать язык.
Вот как раз про синхронизацию эти вопросы были :) спасибо
Denis
Про методологию и framework. Методология изначально философское понятие, наука, изучающая методы чего-то. Там было разделение на теорию и практику, у нас как раз практика. Если брать Agile в широком смысле, то это как раз может быть методологией. А scrum, kanban и т. д. - это как раз методы, можно сказать организации труда, разработки софта и т.д. Это даже методики, поскольку содержат очень конкретные приёмы и подходы. Framework - тоже слово с широким смыслом, в нашем контексте это может равняться методу или методики.
Алексей Пименов мне однажды раскрыл глаза про методологию и методы, казалось бы простая вещь, а ведь многие ставят знак = между ними.
Геннадий
На самом деле в бытовом смысле не страшно, мы ведь тут не научное знание отрабатываем. В научном мире также нет чётких границ, кто во что горазд. Только в определённых кругах есть договорённости. А читаешь чью-нибудь работу, а там методология=метод=методика=подход=способ=принцип.... ну и т.д.
Николай
Николай, последнее время часто приходиться слышать следующее: а мы по аджайл, скрвм работаем- у нас нет документации на разработанное решение. А нам не нужны никакие правила и регламенты, иы де по аджаил работаем - это обычная практика?:)
Oleg вас вводят в заблуждение - в аджайле есть правила. Некоторые из них очень строги.
Николай
На самом деле в бытовом смысле не страшно, мы ведь тут не научное знание отрабатываем. В научном мире также нет чётких границ, кто во что горазд. Только в определённых кругах есть договорённости. А читаешь чью-нибудь работу, а там методология=метод=методика=подход=способ=принцип.... ну и т.д.
ага, и не понеслась!.. "у нас тут аджайл!.. какие правила??" - из той же серии примерно 😄
Геннадий
ага, и не понеслась!.. "у нас тут аджайл!.. какие правила??" - из той же серии примерно 😄
Не совсем, поскольку мы сейчас про смыслы. Если все одинаково понимают то "облачко" смысла, на которое мы сейчас повесим слово Scrum, не всё ли равно, к какой категории бытия это явления сейчас отнесёт идеалист исходя из мировозрения математизма в настроении волюнтаризма? Основной фокус ведь на самой сути скрама, не так ли? А если не все одинаково понимают смысл слово Scrum, ну так описывайте его, чтобы обозначить именно эту тучку. И плевать, что про вас сейчас подумает философ, лингвист или филолог. Хоть горшком.
Oleg
Ага. Получается, что все в этом чате имеют фреймворк разработки, включая регламентную базу, которая описывает правила процесса разработки?
Oleg
Скажите, пжалуйста, что вы регламентируете и в каком объеме?
Oleg
даже "нет регламента" != нет документа, описывающего цели проекта, средства, участников и результаты :)
Ксения, под регламентом я понимаю, как минимум, документ, который описывает базовые принципы существующего процесса. Т.е. не значит, что это должен быть "классический" документ с ролями, функциями, сроками, эскалациями и т.д.
Karina
Обсуждение зашло в тупик, вам не кажется?
Oleg
Какое из? ITIL vs DevOps . Про приоритезацию задач ?
Геннадий
Олег, а зачем Вам вообще регламенты? В каждой организации своя уникальная ситуация.
Oleg
Олег, а зачем Вам вообще регламенты? В каждой организации своя уникальная ситуация.
Мне они нужны, чтобы новый сотрудник работал по общим принятым правилам
Oleg
Мы здесь не можем договориться по терминам, а вы спрашиваете зачем они нужны в организации?
Oleg
А также интересует практика коллег.
Oleg
Здорово конечно, что есть скрам, канбан, лин и т.д.Но я не встречал готового решения, которое не требовалось бы как-то под себя подстраивать.
Геннадий
Тогда это здорово. Вот моя практика показывает следующее. У Вас уже существует некий коллектив, который что-то и как-то делает. Вот берёте, выкидываете всех умных дядек и умные книжки, просто наблюдаете и записываете кто что делает и в какой последовательности. Просто для себя карандашом. В результате для себя необходимо получить описание бизнес-процесса, последовательность. Важно, чтобы это был результат наблюдения, а не придумка из головы. Поскольку так нового коллегу подправят если что другие. Дальше я делал два документа. Один - это просто визуальная схемка с последовательностью. Я использовал IDEF0, но все реально зависит от деталей, этот стандарт иногда очень плох. Сотрудник сухие длинные инструкции никогда не запомнит. Второй документ - это уже нудное текстовое описание. Задача описать частые ошибки, ключевые точки. В общем уже наработанный опыт. Второй документ при необходимости в конкретной ситуации. Чаще всего его можно не делать, если нет опасного производтсва. Первый листок вешал на стену перед сотрудником. Потом я с ним ходил строевым шагом, то есть сначала контролировал каждый шаг, если были отклонения - поправлял. Потом контроль реже, потом снять.
Denis
Ksenya
Ксения, под регламентом я понимаю, как минимум, документ, который описывает базовые принципы существующего процесса. Т.е. не значит, что это должен быть "классический" документ с ролями, функциями, сроками, эскалациями и т.д.
Вот, термины уже "плывут". Я могу набросать список документов и регламентов из практики, что-то работало лучше, что-то хуже. Но в хорошем true agile коллективе могло не быть ни одной бумажки, и был результат - и наоборот, бумажек могло быть много, а результат отрицательный :) (за исключением почесанного ЧСВ менеджера :)
Ksenya
Но тоже интересно, что у кого прижилось.
Геннадий
У нас в разработке (7 чел группа), прижился сильно модифицированный скрам. В техподдержке вообще своё на ходу изобретали.
Oleg
Тогда это здорово. Вот моя практика показывает следующее. У Вас уже существует некий коллектив, который что-то и как-то делает. Вот берёте, выкидываете всех умных дядек и умные книжки, просто наблюдаете и записываете кто что делает и в какой последовательности. Просто для себя карандашом. В результате для себя необходимо получить описание бизнес-процесса, последовательность. Важно, чтобы это был результат наблюдения, а не придумка из головы. Поскольку так нового коллегу подправят если что другие. Дальше я делал два документа. Один - это просто визуальная схемка с последовательностью. Я использовал IDEF0, но все реально зависит от деталей, этот стандарт иногда очень плох. Сотрудник сухие длинные инструкции никогда не запомнит. Второй документ - это уже нудное текстовое описание. Задача описать частые ошибки, ключевые точки. В общем уже наработанный опыт. Второй документ при необходимости в конкретной ситуации. Чаще всего его можно не делать, если нет опасного производтсва. Первый листок вешал на стену перед сотрудником. Потом я с ним ходил строевым шагом, то есть сначала контролировал каждый шаг, если были отклонения - поправлял. Потом контроль реже, потом снять.
Здорово, когда есть команда и какой-то процесс. Я же спрашивал про описание процесса, есть ли оно? Как оптимизировать и описать понятно. Как вы относитесь к японским практикам/методикам?
Oleg
А про сроки и эскалацию – это в SLA описываете?
Опычно регламент описывает роли и взаимодействия участников. Т.е. SLA может и не быть;)
Ksenya
А про сроки и эскалацию – это в SLA описываете?
Есть регламент проекта, есть т наз service description. SLA как часть контракта на сервис содержит сроки реакций и схемы эскалации, конечно. В паспорте проекта обычно попроще пишут: ответственных + зоны, если критично/дорого - то тайминги тоже.
Denis
Роли мы сейчас как раз завершаем описывать, а вот как Взаимодействие правильно описать? Чеклист
Denis
Oleg
Роли мы сейчас как раз завершаем описывать, а вот как Взаимодействие правильно описать? Чеклист
Проще через блок-схемы , т.е. рисуете свой процесс в BPMN, например, а далее описываете по процедурам(шагам) процесс
Геннадий
Олег, я, видимо не ясно выразил мысль. Не процесса в отрыве от конкретной ситуации. Нет двух одинаковых процессов в природе. Все рождается конкретно своё. Нет двух одинаковых детей у двух разных мам. Вы про мои процессы? Да, есть частичное описание тех, которым нам показались ключевыми. Конкретно ТЗ общими мазками, timeline, с milestone, который у нас живёт и меняется, кроме milestone. Схемка процесса разработки в IDEF0. Всякая финансовая хрень типа аккаунтинга часов с трудозатратами.
Slava
На практике - подстройка под себя не потому что надо, а потому что не было носителя знаний концепции. Со скрамом - отсутствие скрам мастера
Ksenya
Service description - это те же пять пунктов SLA?
Нет. Погуглите service contracts templates, SLA/OLA это только часть контракта.
Oleg
Олег, я, видимо не ясно выразил мысль. Не процесса в отрыве от конкретной ситуации. Нет двух одинаковых процессов в природе. Все рождается конкретно своё. Нет двух одинаковых детей у двух разных мам. Вы про мои процессы? Да, есть частичное описание тех, которым нам показались ключевыми. Конкретно ТЗ общими мазками, timeline, с milestone, который у нас живёт и меняется, кроме milestone. Схемка процесса разработки в IDEF0. Всякая финансовая хрень типа аккаунтинга часов с трудозатратами.
Геннадий, спасибо! Интересно. Извиняюсь за неточность формулировок в своих вопросах