Неа :) Еще раз, смотрим на граффик со стоимостью, раз привели, то о кей, пляшем от него. Мой вопрос звучит просто. Почему не тестируете требования? Почему это игнорируете? Почему не написаны критерии приемки требования до того как написаны требования?
В ТОС есть три метрики: скорость генерации дохода, накладные расходы и связанный капитал. Все ваши действия должны влиять на них выгодным образом. Смотрим на вашу проблему:
Проблема: долгий релизный цикл
И, возможно, всех бы устраивал процесс релиза, если бы не занимал в среднем 20 дней. При этом такая длительность не меняется уже в течение года.
Такой срок поставки кода не комфортен – если появился баг, который нужно срочно поправить, то не получится поправить его быстро.
Как ваша проблема соотноситься с метриками ТОС? Окей, ваш релизный цикл стал 15 дней? Денег больше заработали? Да? А если нет, то и начинать не надо, это уже потери.
Не корректно искали узкое место, ТОС работает со всей цепочкой поставки ценности. А у вас только хвост: dev -> e2e тесты -> ожидание установки на прод -> обновление сервисовё1 на проде. Так, что то что вы делали может быть субоптимизацией.
На пошатать: 20 из 26 релизов содержат изменения этого сервиса. Вопрос, почему если в очереди несколько релизов одного и того же сервиса их нельзя схлопнуть в один.
Смотрим на картинку: Относительная стоимость исправления ошибок в зависимости от времени и места обнаружения Самое выгодное это тестировать требования, самая низка стоимость исправления дефекта. Читаем статью, и что же, где баги надо править? Ну только не на этапе разработки требований....
Так звучала моя гипотеза: «Может, попробуем отмечать затраченное время в задачах? Это даст нам статистику, необходимую для будущего планирования».
Что имеем, как не умели декомпозировать, так и не умеем, но теперь еще и время начали записывать. Просто по текущим задачам пройтись и посмотреть, простое действие, вычитание, потом в эксельке посмотреть.
Кстати добавлю, в общем случае между тем сколько списали и когда будет сделано, связи то нет.
Я бы еще подкинул, поскольку солнечные панели это полупроводниковые приборы, а производство их весьма грязное, а еще эти панели нужно перерабатывать по окончании срока службы, то где же экологичьность то?
Канбан-метод не требует соблюдать или разделять ценности аджайла. Просто начните с того что есть сейчас, а куда вы придете, ну возможно разные варианты. Соответственно, поэтому канабан это не аджайл. Так же говориться на сайте канбан университета.
Рассматривали ли вы trivariate analysis/estimation (не смог найти корректного перевода)?
trivariate analysis/estimation очень похоже на PERT, не используем. Я писал выше, что оценка трудоемкости не позволяет уменьшить риски на проекте и как следствие зачем тратить на нее силы. Измерять трудоемкость нужно, она нужна что бы знать эффективность потока.
И второй вопрос - что и каким образом вы с вашим подходом к планированию отвечаете стекйхолдерам на вопрос "когда будет готов очередной epic"? Есть ли у вас сейчас какой-либо способ прогнозировать сроки, пусть и с точностью трамвайной остановки, имея на руках только сложность и важность/срочность задач?
Когда будет готово, можно ответить на основании статистики за сколько сделали. И к сожалению это не число, это распределение вероятностей. Самый простой способ это посчитать. Поставить: Jira Flow Companion, создать доску с эпиками, запустить анализатор, перейти на вкладку распределения Lead Time.
Там будет гистограмма распределения времени выполнения. Нужно задать вопрос стекйхолдерам, с какой вероятностью необходимо завершить эпик. Найти ее на графике, посмотреть сколько дней на оси Х. Вот это значение можно сообщить стейкхолдерам. Более подробно об этом я рассказывал тут: https://www.youtube.com/watch?v=L9XlVJ62mho&t=1988s
Без статистики, можно называть любые числа можно угадать, а можно нет.
Ну сайленты не громче, можно еще и кольца поставить, будут как тихая мембранка и пробел бумкать не будет при нормальных стабах.
Самые тихие это ножницы, у них ход минимальный.
Ну если хочется экстрима то есть короткоходные механические low profile.
Да не сильно дороже, на алике берется заготовка под клаву.
И дальше в нее ставятся свичи.
Заготовки, стоят от 3 до бесконечности, беспроводные от 5.
Собранные борды с такими свичами скорей всего пойдут от 10
А если это каил то от 15.
В теории то да, там правда еще надо это силикон как то сделать…
Но! Я не встречал в продаже раздельные клавиатуры под мембрану.
А под механику, с выбором свичей, есть…
Я бы добавил, механику можно кастомизировать очень сильно.
У меня например на на wsadqe и 12345 стоят сайленты, на остальных коричневые.
И еще можно подобрать себе какие угодно колпачки на клавиши, хоть из металла.
Это про kdif3 или про типы VCS?
Если про типы, ну так новичку не надо тогда и про черный и белый ящик рассказывать. Это вещи примерно одного порядка и нужны они для понимания. Другие же, более совершенные системы не рассматриваются.
Если про kdif3, то окей, пускай страдает, в конце концов все великие дела начинались в командной строке
Неа :) Еще раз, смотрим на граффик со стоимостью, раз привели, то о кей, пляшем от него. Мой вопрос звучит просто.
Почему не тестируете требования? Почему это игнорируете? Почему не написаны критерии приемки требования до того как написаны требования?
В ТОС есть три метрики: скорость генерации дохода, накладные расходы и связанный капитал. Все ваши действия должны влиять на них выгодным образом.
Смотрим на вашу проблему:
Как ваша проблема соотноситься с метриками ТОС? Окей, ваш релизный цикл стал 15 дней? Денег больше заработали? Да? А если нет, то и начинать не надо, это уже потери.
Не корректно искали узкое место, ТОС работает со всей цепочкой поставки ценности. А у вас только хвост: dev -> e2e тесты -> ожидание установки на прод -> обновление сервисовё1 на проде. Так, что то что вы делали может быть субоптимизацией.
На пошатать: 20 из 26 релизов содержат изменения этого сервиса. Вопрос, почему если в очереди несколько релизов одного и того же сервиса их нельзя схлопнуть в один.
Смотрим на картинку: Относительная стоимость исправления ошибок в зависимости от времени и места обнаружения
Самое выгодное это тестировать требования, самая низка стоимость исправления дефекта.
Читаем статью, и что же, где баги надо править? Ну только не на этапе разработки требований....
Нет не надо...
Автор:
Что имеем, как не умели декомпозировать, так и не умеем, но теперь еще и время начали записывать.
Просто по текущим задачам пройтись и посмотреть, простое действие, вычитание, потом в эксельке посмотреть.
Кстати добавлю, в общем случае между тем сколько списали и когда будет сделано, связи то нет.
Цель: проверяем гипотезу, что трекинг времени даст нам статистику для планирования, то есть мы сможем собирать аналитику и делать выводы.
А можно было просто вычесть из даты завершения, дату начала и получить данные для статистики
А зачем паролить архив?
Я бы еще подкинул, поскольку солнечные панели это полупроводниковые приборы, а производство их весьма грязное, а еще эти панели нужно перерабатывать по окончании срока службы, то где же экологичьность то?
Вместо получения прибыли компания начинает получать убытки.
Тогда вопрос уже другой, а зачем это бизнесу нужно?
Даже если это приводит к потерям?
В статье ничего не сказано, про то что субоптимизация зло
Канбан-метод не требует соблюдать или разделять ценности аджайла.
Просто начните с того что есть сейчас, а куда вы придете, ну возможно разные варианты.
Соответственно, поэтому канабан это не аджайл.
Так же говориться на сайте канбан университета.
Пригнувшись, и очень тихо. А Канбан-метод он как бы не аджайл...
trivariate analysis/estimation очень похоже на PERT, не используем. Я писал выше, что оценка трудоемкости не позволяет уменьшить риски на проекте и как следствие зачем тратить на нее силы. Измерять трудоемкость нужно, она нужна что бы знать эффективность потока.
Когда будет готово, можно ответить на основании статистики за сколько сделали. И к сожалению это не число, это распределение вероятностей.
Самый простой способ это посчитать. Поставить: Jira Flow Companion, создать доску с эпиками, запустить анализатор, перейти на вкладку распределения Lead Time.
Там будет гистограмма распределения времени выполнения. Нужно задать вопрос стекйхолдерам, с какой вероятностью необходимо завершить эпик.
Найти ее на графике, посмотреть сколько дней на оси Х.
Вот это значение можно сообщить стейкхолдерам.
Более подробно об этом я рассказывал тут: https://www.youtube.com/watch?v=L9XlVJ62mho&t=1988s
Без статистики, можно называть любые числа можно угадать, а можно нет.
Самые тихие это ножницы, у них ход минимальный.
Ну если хочется экстрима то есть короткоходные механические low profile.
И дальше в нее ставятся свичи.
Заготовки, стоят от 3 до бесконечности, беспроводные от 5.
Собранные борды с такими свичами скорей всего пойдут от 10
А если это каил то от 15.
Но! Я не встречал в продаже раздельные клавиатуры под мембрану.
А под механику, с выбором свичей, есть…
У меня например на на wsadqe и 12345 стоят сайленты, на остальных коричневые.
И еще можно подобрать себе какие угодно колпачки на клавиши, хоть из металла.
И да! Только механика бывает раздельной.
А еще есть Голдрат с ТОС
А до этого было поле, ярмарка с медведем и все спали укрывшись зипуном…
Если про типы, ну так новичку не надо тогда и про черный и белый ящик рассказывать. Это вещи примерно одного порядка и нужны они для понимания. Другие же, более совершенные системы не рассматриваются.
Если про kdif3, то окей, пускай страдает, в конце концов все великие дела начинались в командной строке