ну не знаю, у большинства под вечер мозг уже не особо варит. А если оффлайн, то и вовсе люди начинают поглядывать на часы, что мол скоро домой и пытаются быстрее ливнуть, не вникая особо.
ну нечто подобное же в канбане Битрикс24, кто ответственный на том и таска, таска он "затеи" до внедрения как правило одна для маленьких задач, если не начинает декомпозироваться на более мелкие. Заказчик как правило видет весь жизненный путь, однако много тех.деталей в комментариев удручают Заказчиков порой, а технарям порой не хочется всю "кухню" разработки/тестирования выносить наружу. Но из двух бед выбирают меньшее
Наоборот, они как полярные мнения для баланса между требованиями и реализацией. Ну и да, им нужно совместно договариваться и искать золотую середину треугольника (контент-сроки-бюджет). Чтобы не получилось в духе: "Дайте нам такой отчёт и точка, ничего не хотим слышать, сами разбирайтесь, выжспециалисты. " или наоборот "Не нужен вам этот отчёт, вот есть два (или три), в которых вся эта инфа есть уже"
Такое ощущение, что создатели аджаила совершенно не учли наличие тестировщиков
Да, но нет. В практике приходили иногда к трем одновременным спринтам: В №1 идёт сбор требований, аналитика, прототипирование и согласования. в №2 сама разработка. в №3 тестирование, авторская приемка, пользовательское тестирование и перенос в прод. Потом сдвиг вправо. Собственно получается искусственное раздутие спринта в 3 раза и разбитие его 3 этапа (ну или опять таки мини-каскад). Но всем есть чем заняться в каждой итерации, НО всегда есть тех.долг от предыдущего спринта, который нужно обязательно включать в текущий или следующий.
Хм, с одной стороны понимаю выгорание автора (типичное кстати) и озвученные им проблемы (распространённые тоже). Однако не сочтите за грубость, но: "Шерифа не волнуют проблемы индейцев" (с). Вы хотите, чтобы руководство глубже погружалось в проблемы кода? Так пожалуйста, только вдобавок вы получите тотал контроль и кучу микроменеджмента. И поверьте, прям взвоете ещё больше от этого (не раз на это натыкался). А ну ещё такое погружение вызовет естественный провал в бизнес-задачах руководства (читаем - профита), которое бесспорно повлияет и на подчиненные команды.
И как не странно, но поддержу довод о том, что если не смогли донести проблему до руководства, т.е. эскалировать так, чтобы поняли и приняли, то это осталось проблемой вашего уровня. Потому что да, это ваша работа. Другое дело, когда наверху не хотят слышать и всячески динамят (но только когда это именно так, а не так кажется). Тогда да, как уже кто то писал выше - есть несколько путей (признать поражение и уходить, поднять флаг и менять систему, стать хедом)
По поводу лавины тех.долга не совсем согласен с его обнулением. Да, с одной стороны это чистит действительно неактуальные таски, но с другой рождает типовой негатив у заказчиков: разрабы не только месяцами не исправляют ошибки, но ещё и молча закрывают несделанные задачи. Добавьте теперь к этому вертикальную связь заказчиков к своим руководителям. И когда наверху собираются 2 инфоповода: от технарей, мол техдолг растёт, и от заказчиков (внутренних/внешних), что технари "ничего не делают".
По аналогии с компьютерной программой - она не самодостаточна, нужен компьютер, который сможет её интерпретировать и выполнить
Кажется у С.Лема было так: "То, что может сделать маленький компьютер, имея большую программу, большой компьютер может сделать имея маленькую программу, следовательно бесконечно большая программа может работать без всякого компьютера"
А если серьёзно, то да "яйцу" и прочим аналогиям нужна именно "среда", позволяющая распространяться "яйцу". Ну или заражать "среду", кому как удобнее.
Ну так с этого же автор вроде и начал, что Waterfall (а о чистом нём как раз и PMBoK), не догма, а сборник бест-практикс, как рекомендаций, а не пошаговая инструкция, от которой нельзя отступиться. И для длинных тяжёлых проектов это отличная практическая методология, чтобы добежать вообще для финиша. А если у Вас проектик по созданию сайта на дюжину страниц с одной интеграцией с каким нибудь лидогенератором, то Вы будете ли, как пример, сосредоточенно матрицу рисков вести или критический путь рассчитывать?
Попытка подружить линейность каскада с "аа,побежали" скрама, ну и плюс безмерная любовь к канбану. Тут стоит добавить, что много лет был больше со стороны бизнеса, поэтому каскад бизнес-целей для их реализации декомпозировался на организационные, операционные и иногда технические задачи. Если из вышеуказанного примера выкинуть уровень со спринтами, то получается вполне обычный бизнес-роадмап, положенный на канбан.
Понимаю боль автора и сообщества PM, спасибо за структурное изложение мыслей!
Ни Waterfall, ни Agile, ни любая другая существующая методология разработки ПО — не истина в последней инстанции, а всего лишь отправная точка. Это как Open Source: каждый берет нужное и допиливает под свои задачи.
С поправкой на это добавлю от себя. Вроде бы где то писал, но всё же. Была практика в энтерпрайз финтеха такого гибрида: 1) Каскад как брутто бизнес и технических целей, для долгосрочного и краткосрочного планирования (квартал). 2) Канбан внутри квартала по следующим стадиям Инициатива(с согласованием ЛПР)-РазвёрнутоеБизнесТребование - ФункциональноеТребование(Согласованное и оцененное разработкой). Что в последней стадии, то уходит в спринты. 3) Спринты на месяц. Причём с пониманием, что новая фича требует организационных, юридических и других изменений. К примеру, при внедрении расчёта ПДН(показателя долговой нагрузки) и МПЛ(макропруденциальных лимитов) постоянно были качели, т.к. для расчёта в системе базис это Правила расчёта, а чтобы написать эти Правила сильно влияет, можно ли так или иначе посчитать в системе. Такого рода фичи внедрять как раз помогает прямой контакт бизнеса и разработки. иначе можно бесконечно футболить мячики. 4) Внутри такого длинного спринта тоже Канбан с классическими стадиями реализации, вплоть до досрочного переноса в прод автономных готовых фич. P.S. Да, при этом разумеется, также были форс мажоры в виде переноса в следующий спринт, внеочередных горячих пирожков, фальшстарты и псевдо-фичи(которые в следующем спринте уже были не нужны). Но в целом был тоже интересный и успешный опыт
Если вам сложно найти ответы, самое время пойти за ними к руководству. Когда вы их получите, важно будет донести эту информацию до команды.
Много написано конечно правильно (и не только теоретически), но вот тут прям триггернуло. К сожалению, по моему опыту в 50% случаях от руководства невозможно получить ответы не только на вышеуказанные вопросы про миссию (да не будет холивара), а и по более практичным/операционным. И не всегда дело то в занятости и всё такое ...
Хм. Да, неактуальная документация, разрозненные куски требований и легаси боль любого проекта/продукта, которому больше полгодика. По поводу соглашений добавил бы глубину/формат (шаблоны) документирования. Иначе часто бывает, что крупная фича описывается в одном абзаце, а небольшой багфикс в ТЗ на несколько листов. Из своего опыта документирования часто натыкался на грабли, когда при обогащении бизнес-требований в функциональные (полу-ТЗ) получалась солянка, когда подобный документ бизнес уже не может согласовывать (ибо не понимает), а для разрабов становится в духе:
Как говорится, большая документация сама защищает себя от прочтения, не так ли?
Тут в общем нужно найти золотую середину исчерпывающей глубины, как для бизнеса, так и для аналитиков/разрабов/QA. Важный момент, к которому пришёл, нельзя разрывать отдельно бизнес и функциональные требования по разным документам, т.к. в ходе уточнения требований/тестов/апдейтов бизнес-требования безнадёжно устаревают.
Крутой кейс ! Я только на юзерском уровне экспериментирую с девайсами Яндекса и тоже наткнулся, на еле-совместимость. Кондиционер возможно только включить в последнем режиме, который был, а у телевизора одна команда на включение/выключение, т.е. это не свитч, непонятно выключаешь ты его или наоборот включаешь. Со всеми вытекающими сценариев автоматизации. Ну а так уже привык к "Алиса, пока" или "Алиса, я дома" с соответствующим набором команд. Ну и разумеется в Новый год отдельные розетки под гирлянды)
Хм. А я то то уже и не помню времён, когда не пользовался на работе таск-трекерами и канбаном. Перепробовал много разных (как правило это зависит от того, что юзает кампания). Но с учётом темы импортозамещения и функциональности всё больше становлюсь приверженцем Битрикс24. А вот в плане личных дел было дело даже в ватсап чаты сам собой делал и там ToDo вёл и только пару лет назад пересел на AnyDo и теперь тоже доволен)
Ох, прям пробрало от ностальгии) Был у меня случай как то в 90х, Win95 потеряла какую то dll и отказывалась запускаться вместо со сжатым диском со всеми файлами, взять было неоткуда. В итоге на лето пришлось пересесть с C++ на тот самый Borland Pascal, а потом и вовсе на Asm (только вот не помню какой был IDE). в Pascal писал простенькую графическую оконную библиотечку с окнами и мышкой, в астме тоже самое, но побоялся лезть в графику, успел только в 80х25 сваять. Читаю статью и пускаю скупую мужскую слезу теперь, но кажется теперь у меня +1 хобби будет)
Всегда дико раздражали такие форматы встреч, даже со стенограммами, но когда нет ответов на вопросы что/кто/когда. В духе мэрфологии "В совещаниях экономятся минуты, но теряются часы". Ну или более русское -ППР (расшифровывать аббревиатуру не буду, ибо матом). Касательно коммуникаций между подразделениями приводящих к коммуникациям ради коммуникаций заметил масштабируемость от размера компании, были не редки случаи, когда весь день прошёл во встречах по разным проектам/процессам/проблемам и к вечеру с ужасом обнаруживаешь, что поработать (сделать что то полезного) за сегодня и не успел.
Про фасилитацию встреч бесспорно важно написано, но порой для адекватного времени/результатов встречи (в т.ч. и с follow-up) достаточно модератора, к которому прислушиваются участники (не "секретарь")
попробую перефразировать. В моем случае допущения это рамки проект "наоборот". Допущения в данном случае у меня шире, чем исключения. В них обычно не только то, что не делаем в проекте вообще (или и на текущей фазе), но и нормативные отсылки (что используем например строго будущую редакцию какого то ФЗ, которая вступит в силу через 3 месяца) или например допущение, что интеграция с таким то сервисом уже существует, отлажена и работает в рамках соседнего ТЗ.
ну не знаю, у большинства под вечер мозг уже не особо варит. А если оффлайн, то и вовсе люди начинают поглядывать на часы, что мол скоро домой и пытаются быстрее ливнуть, не вникая особо.
ну нечто подобное же в канбане Битрикс24, кто ответственный на том и таска, таска он "затеи" до внедрения как правило одна для маленьких задач, если не начинает декомпозироваться на более мелкие. Заказчик как правило видет весь жизненный путь, однако много тех.деталей в комментариев удручают Заказчиков порой, а технарям порой не хочется всю "кухню" разработки/тестирования выносить наружу. Но из двух бед выбирают меньшее
Наоборот, они как полярные мнения для баланса между требованиями и реализацией. Ну и да, им нужно совместно договариваться и искать золотую середину треугольника (контент-сроки-бюджет). Чтобы не получилось в духе: "Дайте нам такой отчёт и точка, ничего не хотим слышать, сами разбирайтесь, выжспециалисты. " или наоборот "Не нужен вам этот отчёт, вот есть два (или три), в которых вся эта инфа есть уже"
Про самоорганизацию это из руководства по scrum (Кен Швабер и Джефф Сазерленд)
Да, но нет. В практике приходили иногда к трем одновременным спринтам: В №1 идёт сбор требований, аналитика, прототипирование и согласования. в №2 сама разработка. в №3 тестирование, авторская приемка, пользовательское тестирование и перенос в прод. Потом сдвиг вправо. Собственно получается искусственное раздутие спринта в 3 раза и разбитие его 3 этапа (ну или опять таки мини-каскад). Но всем есть чем заняться в каждой итерации, НО всегда есть тех.долг от предыдущего спринта, который нужно обязательно включать в текущий или следующий.
Поддерживаю! Жанр преподнесения материала отличный) На сценарий очень похоже)
Хм, с одной стороны понимаю выгорание автора (типичное кстати) и озвученные им проблемы (распространённые тоже). Однако не сочтите за грубость, но: "Шерифа не волнуют проблемы индейцев" (с). Вы хотите, чтобы руководство глубже погружалось в проблемы кода? Так пожалуйста, только вдобавок вы получите тотал контроль и кучу микроменеджмента. И поверьте, прям взвоете ещё больше от этого (не раз на это натыкался). А ну ещё такое погружение вызовет естественный провал в бизнес-задачах руководства (читаем - профита), которое бесспорно повлияет и на подчиненные команды.
И как не странно, но поддержу довод о том, что если не смогли донести проблему до руководства, т.е. эскалировать так, чтобы поняли и приняли, то это осталось проблемой вашего уровня. Потому что да, это ваша работа. Другое дело, когда наверху не хотят слышать и всячески динамят (но только когда это именно так, а не так кажется). Тогда да, как уже кто то писал выше - есть несколько путей (признать поражение и уходить, поднять флаг и менять систему, стать хедом)
По поводу лавины тех.долга не совсем согласен с его обнулением. Да, с одной стороны это чистит действительно неактуальные таски, но с другой рождает типовой негатив у заказчиков: разрабы не только месяцами не исправляют ошибки, но ещё и молча закрывают несделанные задачи. Добавьте теперь к этому вертикальную связь заказчиков к своим руководителям. И когда наверху собираются 2 инфоповода: от технарей, мол техдолг растёт, и от заказчиков (внутренних/внешних), что технари "ничего не делают".
Кажется у С.Лема было так: "То, что может сделать маленький компьютер, имея большую программу, большой компьютер может сделать имея маленькую программу, следовательно бесконечно большая программа может работать без всякого компьютера"
А если серьёзно, то да "яйцу" и прочим аналогиям нужна именно "среда", позволяющая распространяться "яйцу". Ну или заражать "среду", кому как удобнее.
анекдот как вирус, прям флешбек по Матрице когда агент Смит, объясняет свою версию Нео, что человечество это вирус)
Ну так с этого же автор вроде и начал, что Waterfall (а о чистом нём как раз и PMBoK), не догма, а сборник бест-практикс, как рекомендаций, а не пошаговая инструкция, от которой нельзя отступиться. И для длинных тяжёлых проектов это отличная практическая методология, чтобы добежать вообще для финиша. А если у Вас проектик по созданию сайта на дюжину страниц с одной интеграцией с каким нибудь лидогенератором, то Вы будете ли, как пример, сосредоточенно матрицу рисков вести или критический путь рассчитывать?
Попытка подружить линейность каскада с "аа,побежали" скрама, ну и плюс безмерная любовь к канбану. Тут стоит добавить, что много лет был больше со стороны бизнеса, поэтому каскад бизнес-целей для их реализации декомпозировался на организационные, операционные и иногда технические задачи. Если из вышеуказанного примера выкинуть уровень со спринтами, то получается вполне обычный бизнес-роадмап, положенный на канбан.
+сюда же(особенно если задействовано несколько систем) BMPN или EPC (она лучше читается с обеих сторон баррикад). Ну и скриншоты/прототипы экранов.
Понимаю боль автора и сообщества PM, спасибо за структурное изложение мыслей!
С поправкой на это добавлю от себя. Вроде бы где то писал, но всё же. Была практика в энтерпрайз финтеха такого гибрида:
1) Каскад как брутто бизнес и технических целей, для долгосрочного и краткосрочного планирования (квартал).
2) Канбан внутри квартала по следующим стадиям Инициатива(с согласованием ЛПР)-РазвёрнутоеБизнесТребование - ФункциональноеТребование(Согласованное и оцененное разработкой). Что в последней стадии, то уходит в спринты.
3) Спринты на месяц. Причём с пониманием, что новая фича требует организационных, юридических и других изменений. К примеру, при внедрении расчёта ПДН(показателя долговой нагрузки) и МПЛ(макропруденциальных лимитов) постоянно были качели, т.к. для расчёта в системе базис это Правила расчёта, а чтобы написать эти Правила сильно влияет, можно ли так или иначе посчитать в системе. Такого рода фичи внедрять как раз помогает прямой контакт бизнеса и разработки. иначе можно бесконечно футболить мячики.
4) Внутри такого длинного спринта тоже Канбан с классическими стадиями реализации, вплоть до досрочного переноса в прод автономных готовых фич.
P.S. Да, при этом разумеется, также были форс мажоры в виде переноса в следующий спринт, внеочередных горячих пирожков, фальшстарты и псевдо-фичи(которые в следующем спринте уже были не нужны). Но в целом был тоже интересный и успешный опыт
Много написано конечно правильно (и не только теоретически), но вот тут прям триггернуло. К сожалению, по моему опыту в 50% случаях от руководства невозможно получить ответы не только на вышеуказанные вопросы про миссию (да не будет холивара), а и по более практичным/операционным. И не всегда дело то в занятости и всё такое ...
Хм. Да, неактуальная документация, разрозненные куски требований и легаси боль любого проекта/продукта, которому больше полгодика. По поводу соглашений добавил бы глубину/формат (
шаблоны) документирования. Иначе часто бывает, что крупная фича описывается в одном абзаце, а небольшой багфикс в ТЗ на несколько листов. Из своего опыта документирования часто натыкался на грабли, когда при обогащении бизнес-требований в функциональные (полу-ТЗ) получалась солянка, когда подобный документ бизнес уже не может согласовывать (ибо не понимает), а для разрабов становится в духе:Тут в общем нужно найти золотую середину исчерпывающей глубины, как для бизнеса, так и для аналитиков/разрабов/QA. Важный момент, к которому пришёл, нельзя разрывать отдельно бизнес и функциональные требования по разным документам, т.к. в ходе уточнения требований/тестов/апдейтов бизнес-требования безнадёжно устаревают.
А вот это украду, попробуем)
Крутой кейс ! Я только на юзерском уровне экспериментирую с девайсами Яндекса и тоже наткнулся, на еле-совместимость. Кондиционер возможно только включить в последнем режиме, который был, а у телевизора одна команда на включение/выключение, т.е. это не свитч, непонятно выключаешь ты его или наоборот включаешь. Со всеми вытекающими сценариев автоматизации. Ну а так уже привык к "Алиса, пока" или "Алиса, я дома" с соответствующим набором команд. Ну и разумеется в Новый год отдельные розетки под гирлянды)
Хм. А я то то уже и не помню времён, когда не пользовался на работе таск-трекерами и канбаном. Перепробовал много разных (как правило это зависит от того, что юзает кампания). Но с учётом темы импортозамещения и функциональности всё больше становлюсь приверженцем Битрикс24. А вот в плане личных дел было дело даже в ватсап чаты сам собой делал и там ToDo вёл и только пару лет назад пересел на AnyDo и теперь тоже доволен)
Hidden text
Ох, прям пробрало от ностальгии) Был у меня случай как то в 90х, Win95 потеряла какую то dll и отказывалась запускаться вместо со сжатым диском со всеми файлами, взять было неоткуда. В итоге на лето пришлось пересесть с C++ на тот самый Borland Pascal, а потом и вовсе на Asm (только вот не помню какой был IDE). в Pascal писал простенькую графическую оконную библиотечку с окнами и мышкой, в астме тоже самое, но побоялся лезть в графику, успел только в 80х25 сваять. Читаю статью и пускаю скупую мужскую слезу теперь, но кажется теперь у меня +1 хобби будет)
Всегда дико раздражали такие форматы встреч, даже со стенограммами, но когда нет ответов на вопросы что/кто/когда. В духе мэрфологии "В совещаниях экономятся минуты, но теряются часы". Ну или более русское -ППР (расшифровывать аббревиатуру не буду, ибо матом).
Касательно коммуникаций между подразделениями приводящих к коммуникациям ради коммуникаций заметил масштабируемость от размера компании, были не редки случаи, когда весь день прошёл во встречах по разным проектам/процессам/проблемам и к вечеру с ужасом обнаруживаешь, что поработать (сделать что то полезного) за сегодня и не успел.
Про фасилитацию встреч бесспорно важно написано, но порой для адекватного времени/результатов встречи (в т.ч. и с follow-up) достаточно модератора, к которому прислушиваются участники (не "секретарь")
попробую перефразировать. В моем случае допущения это рамки проект "наоборот". Допущения в данном случае у меня шире, чем исключения. В них обычно не только то, что не делаем в проекте вообще (или и на текущей фазе), но и нормативные отсылки (что используем например строго будущую редакцию какого то ФЗ, которая вступит в силу через 3 месяца) или например допущение, что интеграция с таким то сервисом уже существует, отлажена и работает в рамках соседнего ТЗ.