Приходится совершать революцию чтобы он заработал. Он хорош в комплексной среде (по Cynefin framework) для продуктовой работы в компаниях с уровнем зрелости 2 или хотя бы 1.5, по Kanban Maturity model. Вот тут сам боженька велел его начать использовать.
Я так понимаю 1.5 это от свидетелей оценки в стори поинтов с точностью до третьего знака до запятой?
Выражаясь языком экономики, стоимость ритуалов SCRUM составляет 15% от стоимости команды. Эти средства уходят не на разработку, а на разговоры о том, кто что сегодня сделает, жалобы на процессы, игру в карты, показ сделанной работы руководству собственной фирмы и показ того же самого представителям заказчика.
Это координационные издержки, они всегда есть, что со скрамом, что без скрама. Поэтому вопрос сколько их было до скрама и сколько со скрамом и после этого можно да сравнить и тогда можно говорить о это ужас ужас или нет. Скорей всего без скрама вы их даже посчитать не можете :) так что...
Во-первых, эта методология проста для понимания благодаря четкой линейной структуре. Чтобы работать по водопадной методологии, не нужно становиться гуру менеджмента — достаточно последовательно идти по шести основным проектным фазам: определение требований, проектирование, разработка, тестирование, внедрение и сопровождение.
О да! Гайд по водопаду обновляется каждый месяц! А какие конференции проходят ух! Доклады просто закачаешься!
PS. Автор ПМ и почему то запихнул внедрение и сопровождение в фазы проекта, наверно 9 версию пмбока вышла и он от туда это взял
Такое ощущение, что создатели аджаила совершенно не учли наличие тестировщиков. Потому как, если спринт две недели - неделю программисты кодят, неделю тестировщики тестируют. Что делать программистам вторую неделю?
А где в манифесте написано про спринты? Правильно нет там этого. Это про идеалогию...
Согласен, что в случае правильно построенного бизнеса TTM влияетна скорость генерации дохода, а остальные сильно не влияют. Но я спрашивал про вашу компанию, как у вас? А не про сферического бизнеса в вакуме
Вы забыли, что речь идет про учебник для начинающих в IT.Усложнять им картину, рассказывая про пока ненужные им понятия, это примерно как в начальных классах школы говорить, что на самом деле на ноль можно делить.
Нет, вообще мимо аналогия. Прочитав ваш учебник человек получает необходимые знания для выполнения работы младшим тестировщиком. А то что я сказал про ключи это база, это словарь и понятия.
Либо у него нет базы, тогда он не может быть тестировщиком, потому что не понимает, что от него хотят. В этом случае, зачем ему читать 700 страниц, когда есть намного более полные и менее объемные учебники....
Это неправильный подход. Есть проверенные десятилетиями отраслевые подходы, стандарты и архитектуры.
Окей, то есть продукт зарабатывает деньги, но это не правильные деньги...
Ccылки на эти отраслевые подходы, стандарты можно? На IEEE, на ISO и ГОСТ?
И если для конкретного продукта предлагается нестандартное решение, то это должно быть подтверждено очень вескими аргументами. Потому что на другой чаше весов гениального решения "в нашем случае так сделать было лучше/быстрее/эффективней" - продукт, который потом сложно или невозможно поддерживать.
Раз пошла речь о стандартах ГОСТ 25010-2015 атрибут качества сопровождаемость, либо вы в него вложились и тогда измения в продукте дешевы либо нет. Это ни как не связанно с тем какие решения вы использовали.
"Может быть физически" или "может быть, но за это нужно оторвать руки"?
На основании чего отрывать руки будете? На основе эмоций?
В любой нормальной базе данных между exams и teacher будет связь по teacher_id.
В базе будет та связь, которая необходима для решения задач поставленных перед продуктом, а не потому что у кого то есть фантазии. Во первых суррогатные ключи могут быть и составными. Во вторых есть еще естественные ключи.
Посмотрел тест по БД. Вопрос: 01/04 Сколько внешних ключей содержится в таблице Exams? Правильный ответ, нет информации, потому в вопросе нет информации о фк. А название полей это просто название полей. Дальше смотреть не стал, подозреваю, что все остальное так же безграмотно
Итак: По поводу принципа ТОС - согласно ТОС узкое место всегда ОДНО, это хорошо раскрывается в «Критическая цепь», но вы пишете «5 разных типов задач, 5 разных воркфлоу = 5 разных узких мест» Если вашу логику перенести на производство тогда 5 разных выпускаемых продуктов имеют 5 узких мест, а номенклатура завода может насчитывать тысячи наименований производимой продукции, согласно вашей логике ТОС в принципе неприменим нигде, но практика показывает обратное.
«Критическая цепь» это книга по управлению проектами, где описано что есть критический путь и как можно его застраховать через введение буферов.
Но мы сейчас чуть о другом.
Напомню, алгоритм определения узкого звена по Голдрату: В книге перечисляются пять основных этапов теории ограничений:
Определите. Определите узкое место системы.
Эксплуатируйте. Используйте это узкое место, повышая его пропускную способность за счет изменения процессов, процедур обслуживания оборудования, обучения, политик и т.д.
Подчиненный: Подчиняет пропускную способность всех других рабочих центров этому рабочему центру.
Улучшайте. Инвестируйте в этот рабочий центр, чтобы увеличить его пропускную способность - добавьте оборудования, рабочей силы и т.д.
Инерция. Начните процесс заново на линии, чтобы определить новое узкое место.
Так, ровно то что вы описали и происходит в цели. Напоминаю, что в зависимости от заказов у них узкое звено болталось по всему заводу. То на работе, то на печке, то ... Потому, что они были ВЫНУЖДЕНЫ ПЕРЕНАСТРАИВАТЬ ОБРУДОВАНИЕ ПОД ВЫПУСК КАЖДОГО НОВОГО ЗАКАЗА. И каждый раз применяли ТОС для поиска узкого звена. И да заказы можно формировать в пачки, что бы уменьшить время на переналадку оборудования.
В разработке ПО КАЖДАЯ задача по своей сути это другой, совершенно другой заказ. Он требует под себя другую тех карту и можно сказать перенастройку оборудования.
Если вернуться к нашему примеру то у вас пропущен первый этап, поиск узкого места в рамках ВСЕЙ системы, вместо этого вы ищете его в локальных процессах. Конечно после этого все сыпется.
Поговорим про ВСЮ систему. У Голдрата кстати, то же не вся система рассмотрена в цели. Если бы там была вся система, и они разместили ограничение на рынке(Сателитная программа)! То они бы заказы брали только те для которых прибыль максимальна, а время на производство минимально. То бишь оборудование не требовало бы перенастройки и это уже похоже на конвейр...
Фактически в ИТ мы имеем систему состоящую из двух частей. Дискавери и Деливери. В дискавери происходит селекция идей, их проработка и осознание их ценностей. Грубо говоря на вход приходя тысячи идей и большинство из них идут в мусор. Из них остаются, пускай десятки и вот они доходят до деливери части. В статье описана ТОЛЬКО деливери часть и начинается она как раз с бэклога идей. Напомню, мы же говорим про СИСТЕМУ целиком, про сквозной процесс поставки ценности. Это означает, что мы протаскиваем запрос клиента до финиша и мы четко понимаем, что как стыкуются то что хотел клиент с тем, что мы поставили. Если это так. То у нас высокий уровень зрелости, 3 уровень по КММ. К этому уровню мы уже отстроили деливери, мы точно его понимаем и в идеале у нас есть простые модели. Так что прекрасно знаем где у нас узкое звено в деливери. Более того мы его можем предсказать через мат. модели. И можем максимально его использовать.
То что я писал, относится к уровню ниже 3, где мы еще разбираемся с тем как мы ценность поставляем и как попадаем в ожидания. В статье описан простой рабочий механизм понимания как работает ваше деливери.
Далее «Проект Феникс» в сравнении с Целью конечно же слабее, так как это всего лишь частный случай применения принципов ТОС в разработке и эксплуатации (Development , Operations- DevOps) т.е там описывается общий подход к процессу работы всей системы включающий все этапы работы, а не только сопровождения/обеспечения как Вы утверждаете. Суть как раз в этом надо рассматривать всю систему в целом все этапы и только тогда можно найти настоящее бутылочное горлышко .
Эх, не читали что я написал про феникс. Штош... в Фениксе НЕ РАССМАТРИВАЕТСЯ ВСЯ СИСТЕМА, там нет принятия решения о том, что берется в работу, а что нет. Там ни слова нет про требования и про анализ. Там не ничего про проработку идей.. Так что там только деливери. Причем не про всю его часть, а так начиная с разработки...
PS.Кстати феникс и кейс XIT очень похожи в чем то. PPS. Все что есть в фениксе описано, хорошо было известно в ИТ компаниях и использовалось, все это было описано и итиле и в исо и в симсонах, куда уж без них
Спасибо за статью, но простите вам стоит перечитать еще раз «Цель», после нее «Цель 2», «Критическая цепь», потом «Выбор» и наконец «Проект Феникс».
Цель знаю практически наизусть. Цель 2, Критическая цепь - помню хорошо. Выбор - прочитал... Проект Феникс - весьма слабая книга, ну очень. На момент когда писалась, это было да. Но в 2023 нет. Кстати она не про разработку а про обеспечение. Как говорится бледная тень итила.
Можно было прекратить читать, вы в корне не верно поняли принцип ТОС. А после того как вы канбан противопоставили ТОС…
Окей, в чем тогда заключается принцип ТОС?
Еще. Я не противопоставил канбан ТОС, я в статье говорю, что у ТОС есть ограничения и она слабо подходит для задач связанных с умственным трудом. Точно так же большинство ККШ бесполезны в ИТ, слишком большие вариации. И мыслительные инструменты ТОС то же весьма тяжелы, разрешение тучи я видел всего два раза и сотен попыток с ней поработать.
Совсем грустно стало, по этому поводу снова советую «Проект Феникс»
Проект Феникс, о чем книга: Мысли
Мы постоянно путаем Людей и Чем они занимаются
Мне следует играть по правилам с тех пор, как я стал тем самым человеком, который их устанавливает.
Усовершенствование, осуществляемое где-то, кроме бутылочного горлышка это иллюзия.
Вопрос, а почему пошли по понятному пути вместо правильного?
Что помешало?
Зачем оцениваете человека когда можете оценить его работу?
Приходится совершать революцию чтобы он заработал. Он хорош в комплексной среде (по Cynefin framework) для продуктовой работы в компаниях с уровнем зрелости 2 или хотя бы 1.5, по Kanban Maturity model. Вот тут сам боженька велел его начать использовать.Я так понимаю 1.5 это от свидетелей оценки в стори поинтов с точностью до третьего знака до запятой?
Вообще то скрам это прыжок сразу на ML3.
Там местами буквы перепутаны должно быть: Kanban Management Professional
Выражаясь языком экономики, стоимость ритуалов SCRUM составляет 15% от стоимости команды. Эти средства уходят не на разработку, а на разговоры о том, кто что сегодня сделает, жалобы на процессы, игру в карты, показ сделанной работы руководству собственной фирмы и показ того же самого представителям заказчика.Это координационные издержки, они всегда есть, что со скрамом, что без скрама.
Поэтому вопрос сколько их было до скрама и сколько со скрамом и после этого можно да сравнить и тогда можно говорить о это ужас ужас или нет.
Скорей всего без скрама вы их даже посчитать не можете :) так что...
Достоинства WaterfallВо-первых, эта методология проста для понимания благодаря четкой линейной структуре. Чтобы работать по водопадной методологии, не нужно становиться гуру менеджмента — достаточно последовательно идти по шести основным проектным фазам: определение требований, проектирование, разработка, тестирование, внедрение и сопровождение.О да! Гайд по водопаду обновляется каждый месяц! А какие конференции проходят ух! Доклады просто закачаешься!
PS. Автор ПМ и почему то запихнул внедрение и сопровождение в фазы проекта, наверно 9 версию пмбока вышла и он от туда это взял
Тихо ругаясь. Раньше хрен кто отличит абстрактный класс от интерфейса, теперь же хрен кто отличит спринт от итерации
Такое ощущение, что создатели аджаила совершенно не учли наличие тестировщиков. Потому как, если спринт две недели - неделю программисты кодят, неделю тестировщики тестируют. Что делать программистам вторую неделю?А где в манифесте написано про спринты? Правильно нет там этого. Это про идеалогию...
Scrum, Kanban и другие «эталонные» методы ведения проектов далеко не идеальны и многое упускают.
Метко сказано, наш выбор: ГОСТ 2, 19, 54869! Только хардкор!
Согласен, что в случае правильно построенного бизнеса TTM влияет на скорость генерации дохода, а остальные сильно не влияют. Но я спрашивал про вашу компанию, как у вас? А не про сферического бизнеса в вакуме
А теперь вопрос.
Как вот эти метрики:
Time to market (TTM) — время доставки до рынка.
Time to lead (TTL) — время производства.
Committed vs Delivered (C\D) — соблюдение сроков.
Velocity — скорость.
Delivery — кол-во доставок до прома.
Rollback — кол-во откатов с прома.
Duration — нахождение задачи в статусе.
Quantity — кол-во сделанных задач.
Показатель качества — работа с инцидентами прома
Влияют на:
Скорость генерации дохода
Операционные расходы
Связанный капитал
А если не влияют, то зачем мереем?
По QA на русском для ИТ практически ничего нет. Для понимания можно начать с ГОСТ ИСО 9000-2015 и ГОСТ ИСО 9001-2015
Вы забыли, что речь идет про учебник для начинающих в IT.Усложнять им картину, рассказывая про пока ненужные им понятия, это примерно как в начальных классах школы говорить, что на самом деле на ноль можно делить.Нет, вообще мимо аналогия. Прочитав ваш учебник человек получает необходимые знания для выполнения работы младшим тестировщиком. А то что я сказал про ключи это база, это словарь и понятия.
Либо у него нет базы, тогда он не может быть тестировщиком, потому что не понимает, что от него хотят. В этом случае, зачем ему читать 700 страниц, когда есть намного более полные и менее объемные учебники....
Это неправильный подход. Есть проверенные десятилетиями отраслевые подходы, стандарты и архитектуры.Окей, то есть продукт зарабатывает деньги, но это не правильные деньги...
Ccылки на эти отраслевые подходы, стандарты можно? На IEEE, на ISO и ГОСТ?
И если для конкретного продукта предлагается нестандартное решение, то это должно быть подтверждено очень вескими аргументами. Потому что на другой чаше весов гениального решения "в нашем случае так сделать было лучше/быстрее/эффективней" - продукт, который потом сложно или невозможно поддерживать.Раз пошла речь о стандартах ГОСТ 25010-2015 атрибут качества сопровождаемость, либо вы в него вложились и тогда измения в продукте дешевы либо нет. Это ни как не связанно с тем какие решения вы использовали.
Если начинать студентов на первом же этапе грузить возможными частными случаями, то у них в голове будет тотальная каша.При чем тут частные случаи. ФК однозначно определяется на основе метаданных. Нет матданных это не ФК.
А то потом начинаются перлы в стиле у вас teacher_uuid, а надо teacher_id.
Переучивать людей дорого.
"Может быть физически" или "может быть, но за это нужно оторвать руки"?На основании чего отрывать руки будете? На основе эмоций?
В любой нормальной базе данных между exams и teacher будет связь по teacher_id.В базе будет та связь, которая необходима для решения задач поставленных перед продуктом, а не потому что у кого то есть фантазии.
Во первых суррогатные ключи могут быть и составными.
Во вторых есть еще естественные ключи.
только на "приговоренных" проектах.Компания атласиан резко напряглась, поскольку ее продукты стали резко приговоренные
Посмотрел тест по БД.
Вопрос: 01/04 Сколько внешних ключей содержится в таблице Exams?
Правильный ответ, нет информации, потому в вопросе нет информации о фк. А название полей это просто название полей.
Дальше смотреть не стал, подозреваю, что все остальное так же безграмотно
Только про QA в этом учебнике ни слова. Даже до QC не добрались. Что мешает просто написать: 100-Year Testing-Textbook
«Критическая цепь» это книга по управлению проектами, где описано что есть критический путь и как можно его застраховать через введение буферов.
Но мы сейчас чуть о другом.
Напомню, алгоритм определения узкого звена по Голдрату:
В книге перечисляются пять основных этапов теории ограничений:
Определите. Определите узкое место системы.
Эксплуатируйте. Используйте это узкое место, повышая его пропускную способность за счет изменения процессов, процедур обслуживания оборудования, обучения, политик и т.д.
Подчиненный: Подчиняет пропускную способность всех других рабочих центров этому рабочему центру.
Улучшайте. Инвестируйте в этот рабочий центр, чтобы увеличить его пропускную способность - добавьте оборудования, рабочей силы и т.д.
Инерция. Начните процесс заново на линии, чтобы определить новое узкое место.
Так, ровно то что вы описали и происходит в цели. Напоминаю, что в зависимости от заказов у них узкое звено болталось по всему заводу. То на работе, то на печке, то ...
Потому, что они были ВЫНУЖДЕНЫ ПЕРЕНАСТРАИВАТЬ ОБРУДОВАНИЕ ПОД ВЫПУСК КАЖДОГО НОВОГО ЗАКАЗА. И каждый раз применяли ТОС для поиска узкого звена. И да заказы можно формировать в пачки, что бы уменьшить время на переналадку оборудования.
В разработке ПО КАЖДАЯ задача по своей сути это другой, совершенно другой заказ. Он требует под себя другую тех карту и можно сказать перенастройку оборудования.
Поговорим про ВСЮ систему.
У Голдрата кстати, то же не вся система рассмотрена в цели. Если бы там была вся система, и они разместили ограничение на рынке(Сателитная программа)! То они бы заказы брали только те для которых прибыль максимальна, а время на производство минимально. То бишь оборудование не требовало бы перенастройки и это уже похоже на конвейр...
Фактически в ИТ мы имеем систему состоящую из двух частей. Дискавери и Деливери. В дискавери происходит селекция идей, их проработка и осознание их ценностей. Грубо говоря на вход приходя тысячи идей и большинство из них идут в мусор. Из них остаются, пускай десятки и вот они доходят до деливери части. В статье описана ТОЛЬКО деливери часть и начинается она как раз с бэклога идей.
Напомню, мы же говорим про СИСТЕМУ целиком, про сквозной процесс поставки ценности. Это означает, что мы протаскиваем запрос клиента до финиша и мы четко понимаем, что как стыкуются то что хотел клиент с тем, что мы поставили. Если это так. То у нас высокий уровень зрелости, 3 уровень по КММ. К этому уровню мы уже отстроили деливери, мы точно его понимаем и в идеале у нас есть простые модели. Так что прекрасно знаем где у нас узкое звено в деливери. Более того мы его можем предсказать через мат. модели. И можем максимально его использовать.
То что я писал, относится к уровню ниже 3, где мы еще разбираемся с тем как мы ценность поставляем и как попадаем в ожидания. В статье описан простой рабочий механизм понимания как работает ваше деливери.
Эх, не читали что я написал про феникс. Штош... в Фениксе НЕ РАССМАТРИВАЕТСЯ ВСЯ СИСТЕМА, там нет принятия решения о том, что берется в работу, а что нет. Там ни слова нет про требования и про анализ. Там не ничего про проработку идей.. Так что там только деливери. Причем не про всю его часть, а так начиная с разработки...
PS.Кстати феникс и кейс XIT очень похожи в чем то.
PPS. Все что есть в фениксе описано, хорошо было известно в ИТ компаниях и использовалось, все это было описано и итиле и в исо и в симсонах, куда уж без них
Цель знаю практически наизусть. Цель 2, Критическая цепь - помню хорошо. Выбор - прочитал... Проект Феникс - весьма слабая книга, ну очень. На момент когда писалась, это было да. Но в 2023 нет. Кстати она не про разработку а про обеспечение. Как говорится бледная тень итила.
Окей, в чем тогда заключается принцип ТОС?
Еще. Я не противопоставил канбан ТОС, я в статье говорю, что у ТОС есть ограничения и она слабо подходит для задач связанных с умственным трудом. Точно так же большинство ККШ бесполезны в ИТ, слишком большие вариации. И мыслительные инструменты ТОС то же весьма тяжелы, разрешение тучи я видел всего два раза и сотен попыток с ней поработать.
Проект Феникс, о чем книга:
Мысли
Мы постоянно путаем Людей и Чем они занимаются
Мне следует играть по правилам с тех пор, как я стал тем самым человеком, который их устанавливает.
Усовершенствование, осуществляемое где-то, кроме бутылочного горлышка это иллюзия.
Пути
I. Бороться с дефектами рабочего процесса.
Налаживать взаимодействие производственных участков
Направлять ход работы
Задать темп в зависимости от ограничения.
Вся организация должна достигать своих целей, а не только ее часть…
II. Создание быстрой обратной связи.
Нужно стремиться к однонаправленному течение, которое увеличивает отдачу и минимизирует вариативность системы.
III. Улучшение ежедневной работы даже важнее чем выполнение ее.
Мы постоянно работаем с системой,
Мы закрепляем полезные привычки и занимаемся совершенствованием чего-либо.
Мы должны постоянно давить на систему с целью избавиться от тех недостатков, которые в ней есть. Четыре типа работы
Бизнес-проекты
Внутренние проекты IT-сопровождения
Изменения
Незапланированная работа (антиработа)
Невыплаченный технический долг. Приведет к тому, что все, что в итоге будет сделано.Это только незапланированная работа
Текстовое представление майнд карты по книге.