Ну, если доводить до крайности, то примерно так :). Отмечу только, что решение проблем не исключает постановки и достижения целей. Можно, к примеру, поставить бизнес-цель "заработать миллиард". Но, поскольку просто так миллиард никто не отдаст, нужно будет найти того, кто готов заплатить этот миллиард, понять за что он готов его заплатить, и предложить ему достойное решение. Ну, или найти миллиард людей, готовых заплатить за что-то по рублю и сделать одно решение для них всех. Но это уже ближе к бизнес-моделям, а не аналитическим.
Мой опыт говорит, что не бывает задачи без проблемы, которую она решает. Если есть задача, значит у кого-то что-то болит настолько, что он готов потратить ресурсы (и немалые: разработка - дорогое удовольствие) на уменьшение или устранение этой боли. И задача бизнеса чаще всего заключается в том, чтобы предложить этому "кому-то" какое-то решение, получив за это деньги. На которые и создается программное решение.
Стрелочки на рисунке 4 показывают не движение, а направление ответов на вопрос "зачем?".
Изменение в системе делаем зачем? - чтобы определенным образом изменить её поведение.
А поведение меняем зачем? - чтобы сценарии нужные выполнялись.
А сценарии такие нам нужны зачем? - чтобы решить определенные проблемы и достичь заявленных целей.
Без такой трассировки часто случается, что когда дело доходит до изменения системы, то уже забывается зачем все это делалось. И формально вроде все задачи выполнены, а цели не достигнуты. Явная трассировка помогает помнить, что, метафорически выражаясь, мы крутим педали не чтобы выдать определенный RPS оборотов колеса, а чтобы оказаться дома до того, как начнется гроза. И когда молния жалит в мокрое место, то уже не важно, что колеса крутились так, как было написано в джире.
Оно и так, по-моему, в виде статьи малость перегружено получилось, если сюда еще и архитектуру добавить - будет вообще нечитаемо. Про архитектурные модели я рассказывал на Archdays в 2022-м, кажется, а тут решил сфокусироваться именно на моделях "вокруг" архитектуры. А в C4 верхний уровень для этого как раз и предназначен.
"Колонка" на карте историй примерно соответствует кейсу, а строка - глубине реализации/проработки группы кейсов в очередной поставке. Соответственно, каждая UserStory - это одно содержательное, качественное, наблюдаемое и проверяемое изменение системы.
С точки зрения артефактов - простор для фантазии полный. Идеально, когда все в одной системе, перевязано ссылками и можно от одного прийти к другому, но я кроме Sparx EA подобных инструментов не видел.
Поэтому на практике это отдельная диаграмма юзкейсов (я рисовал в PlantUML, Archi, Draw.IO, в конце-концов, просто выписывал в виде списка), в которой юзкейсы как-то идентифицированны. Эту диаграмму полезно выкладывать в общий репозиторий для чтения и ознакомления всех заинтересованных. И отдельная карта историй, заголовки колонок которой коррелируют с названиями/идентификаторами юзкейсов. Читаемость и понятность важнее формализма. В последнее время в качестве артефакта для карты историй использую простую табличку в Confluence, где на месте UserStory поначалу (на этапе моделирования) просто краткое тезисное описание, которое по мере согласования/утверждения скоупа инкремента заменяется ссылкой на соответствующую Story в джире.
А вот тут вынужден расстроить. SysML и рядом не стоит с кодогенерацией, этот язык придуман и создан для других целей. С его помощью моделируют сложные конструкции, состоящие из множества разнообразных элементов, выполняющих разные задачи и взаимно влияющие друг на друга. Код здесь — это лишь малая часть и никто не мешает моделировать структуру программного модуля (который в SysML модели может выглядеть всего ли как как один квадратик блока с указанием входов и выходов) с помощью доброго старого UML и всех прилагающихся к нему кодогенераторов.
Это значит что объекты в модели создавались, связи и атрибуты проставлялись, а диаграммы при этом использовалось как временное поле для рисования — накидал элементов, прочертил связи, потом почистил. Соответственно, в модели связи накапливаются, по ним можно последовательно двигаться, но диаграмм, отображающих сразу комплекс связей, не остаётся.
Ну да. Только менеджер должен понимать кто перед ним и задачи ставить соответствующие.
p.s. Я с безответственными и безынициативными работать так и не научился :)
В упоминаемой проблеме есть два аспекта — инициатива и ответственность. В статье разбирается только один аспект, связанный с инициативой: «Нужно ли и можно ли разработчикам проявлять инициативу?»
Однозначного ответа на этот вопрос нет. Большинству разработчиков комфортнее работать в условиях, когда все решения уже приняты заранее и при случае можно свалить ответственность на тех, кто ставил задачу, дескать сами виноваты. Но встречаются и такие, которые хотят проявить инициативу, но им не дают, потому что ответственность за принятые решения несет кто-то другой. То, что кажется разработчику лучше, удобнее и полезнее, совершенно не обязательно окажется приемлемо для конечного заказчика.
На мой взгляд, без инициативы невозможен профессиональный рост. Но, как следствие связи инициативы и ответственности, рост происходит тогда, когда вместе с проявлением инициативы вы берете на себя и ответственность за то, что делаете. Безответственная инициатива обычно приносит больше вреда чем пользы.
Да, на первый взгляд одно и то же, различие в деталях. В GitFlow для каждого релиза стартуют отдельную ветку, которая потом сливается с мастером. Использование release branch полезно, когда нужно релизить несколько версий одновременно, но мы предпочли сфокусироваться на коротком цикле выпуска. У нас ветка релиза всегда одна, каждый следующий планируемый релиз просто вливается в неё из dev. Ветки dev & release друг от друга по сути почти не отличаются и больше похожи на develop из GitFlow. А то что в GitFlow называется release branch у нас не прижилось. Ветки обрабатываются сервером сборки абсолютно одинаково, результаты сборки деплоятся на разных стендах. В ветке release ведется разработка также как и в dev, но границы возможных изменений в release жестко ограничены, чтобы процесс был сходящимся. Также существенная разница приоритетах усилий по тестированию и исправлению ошибок — основное внимание уделяется ветке release, dev тестируется и правится по остаточному принципу. Все усилия фокусируются на стабилизации и выпуске релиза.
1. Одновременно работают 6 разработчиков. Планируем расти.
2. Да, проект состоит из одного (довольно большого) репозитория. На нескольких организовать управляемый процесс довольно трудно :(
3. Каждая задача до завершения ведется в отдельной ветке и вливается в один из стволов (dev || release) только после завершения и предварительного тестирования на стенде разработчика. Я не стал пока про это писать, чтобы не усложнять. Таких веток в работе в идеальном случае — по количеству разработчиков, но иногда какие-то ProofOfConcept могут жить подольше. Могут двое работать в одной feature-ветке, например делая согласованные изменения на фронтенде и бэкенде. Вообще, стараемся делать так, чтобы эти ветки не висели долго. Делим задачи так, чтобы они делались за несколько дней и вливались в ствол. Старые ветки периодически чистим.
4. Для поддержки старых версий есть два варианта. Первый — очень-очень осторожно сделать маленький-маленький хотфикс с последующим Sanity тестированием. Редкий кейс, стараемся избегать. Предпочитаем исправить обнаруженный баг в текущем релизе и обычным порядком выставить обновление.
Пусть и с некоторым опозданием, но хочется добавить позитива в эту ветку обсуждения.
К сожалению, мне этот пост попался на глаза только сейчас. Полгода назад, когда всё только начиналось, я не знал слов «Эволюционное управление» и действовал скорее интуитивно. Однако, модель управления, которая в итоге получилась, очень напоминает, то что описано в статье.
Такая модель — точно не серебряная пуля. Типовые проекты делаются по другому. Если вы точно знаете что хотите получить и влияние неопределённости на ваши планы минимально — все эти танцы неуместны.
Совсем другая картина — когда ни вы, ни ваши заказчики точно не знаете что должно получиться в итоге, и имеете душевные силы признаться в этом себе и друг другу. Вот тут начинает в полный рост влиять используемый способ уменьшения неопределённостей. Я пришел к эволюционной идее после книг Талеба, он тоже рассказывает про «постепенное прилаживание», я адаптировал его идеи на программный код и управление требованиями.
И еще, забыл написать почему вредно :)
Вредно, если кратко — потому что борьба с ветряными мельницами непродуктивна. Если все засинхронизировать, все планы будут прозрачно перетекать и обновляться, то возникнет ложное ощущение того, что все под контролем. А в управлении проектом, повторюсь, задачи разработки — они даже не на втором плане по важности. Отсутствие такой прозрачной автоматизации в мелочах порождает необходимость немножко поработать головой и руками. Мозг не умеет работать с большим количеством мелких артефактов, приходится их обобщать. А это помогает расширить угол зрения.
А вот тут ответ очень простой. Средства вполне могут быть. Но средства сами по себе никакую проблему не решают. Проблему (теоретически) смогут решить люди, которые эти средства будут использовать. Чтобы проблемы решались, эти люди должны уметь и понимать довольно много разных полезных вещей и еще больше делать. Чтобы был заметный эффект, потребуется не только система, которая что-то там умеет делать, но и реальное изменение в подходах к работе. Эти изменения коснутся не только менеджеров, но и программистов и руководителей. Людей способных и желающих провернуть подобные изменения в своих организациях слишком мало, чтобы сформировать рынок, который бы окупил создание подобной системы.
Microsoft при первом релизе TFS запилили примитивную интеграцию TFS с Project, этим мало кто воспользовался — они и не стали развивать. Ничего личного. Просто бизнес.
По моему опыту, сложности возникают всегда при попытке синхронизировать изменения между средством управления задачами (TFS, Jira, Redmine, Trac и т.п.) и инструментом управления проектом (как правило — Project, но может быть и Excel или даже бумажный лист). Ключевое слово — «приходится». Все эти сложности как бы намекают, что копаем не там где надо. И, хотя менеджерам, которые выросли из программистов (сам таким был) такая функция кажется очевидной, на самом деле ниоткуда не следует, что управление проектом и управление задачами работают в одних и тех же терминах.
Даже программы мы давно уже не пишутся ассемблере, для этого используются языки высокого уровня, которые, конечно, не дают возможностей управления на уровне регистров, но внятно говорят машине чего мы от неё хотим.
Так вот, к чему это я. Модель проекта, с которой работает менеджер и модель задач, с которой работают разработчики — это разные вещи и между ними не всегда возможна автоматическая синхронизация. Дажа, я бы сказал, она вредна. Проект включает в себя много факторов, и программирование — это только малая часть, далеко не всегда самая трудоемкая. А «интерфейс между слоями» — это совместная работа менеджера проекта, тимлида, аналитика и других заинтересованных лиц. Потому что слоёв не два, а гораздо больше.
Вот не поверите, только сегодня размышлял о том, что пора уже написать о том, что нужно отделять мух от котлет управление производством от управления проектами. Тогда снимается львиная доля проблем и сложностей.
Ну, если доводить до крайности, то примерно так :). Отмечу только, что решение проблем не исключает постановки и достижения целей. Можно, к примеру, поставить бизнес-цель "заработать миллиард". Но, поскольку просто так миллиард никто не отдаст, нужно будет найти того, кто готов заплатить этот миллиард, понять за что он готов его заплатить, и предложить ему достойное решение. Ну, или найти миллиард людей, готовых заплатить за что-то по рублю и сделать одно решение для них всех. Но это уже ближе к бизнес-моделям, а не аналитическим.
Мой опыт говорит, что не бывает задачи без проблемы, которую она решает. Если есть задача, значит у кого-то что-то болит настолько, что он готов потратить ресурсы (и немалые: разработка - дорогое удовольствие) на уменьшение или устранение этой боли. И задача бизнеса чаще всего заключается в том, чтобы предложить этому "кому-то" какое-то решение, получив за это деньги. На которые и создается программное решение.
Стрелочки на рисунке 4 показывают не движение, а направление ответов на вопрос "зачем?".
Изменение в системе делаем зачем? - чтобы определенным образом изменить её поведение.
А поведение меняем зачем? - чтобы сценарии нужные выполнялись.
А сценарии такие нам нужны зачем? - чтобы решить определенные проблемы и достичь заявленных целей.
Без такой трассировки часто случается, что когда дело доходит до изменения системы, то уже забывается зачем все это делалось. И формально вроде все задачи выполнены, а цели не достигнуты. Явная трассировка помогает помнить, что, метафорически выражаясь, мы крутим педали не чтобы выдать определенный RPS оборотов колеса, а чтобы оказаться дома до того, как начнется гроза. И когда молния жалит в мокрое место, то уже не важно, что колеса крутились так, как было написано в джире.
Оно и так, по-моему, в виде статьи малость перегружено получилось, если сюда еще и архитектуру добавить - будет вообще нечитаемо. Про архитектурные модели я рассказывал на Archdays в 2022-м, кажется, а тут решил сфокусироваться именно на моделях "вокруг" архитектуры. А в C4 верхний уровень для этого как раз и предназначен.
"Колонка" на карте историй примерно соответствует кейсу, а строка - глубине реализации/проработки группы кейсов в очередной поставке. Соответственно, каждая UserStory - это одно содержательное, качественное, наблюдаемое и проверяемое изменение системы.
С точки зрения артефактов - простор для фантазии полный. Идеально, когда все в одной системе, перевязано ссылками и можно от одного прийти к другому, но я кроме Sparx EA подобных инструментов не видел.
Поэтому на практике это отдельная диаграмма юзкейсов (я рисовал в PlantUML, Archi, Draw.IO, в конце-концов, просто выписывал в виде списка), в которой юзкейсы как-то идентифицированны. Эту диаграмму полезно выкладывать в общий репозиторий для чтения и ознакомления всех заинтересованных. И отдельная карта историй, заголовки колонок которой коррелируют с названиями/идентификаторами юзкейсов. Читаемость и понятность важнее формализма. В последнее время в качестве артефакта для карты историй использую простую табличку в Confluence, где на месте UserStory поначалу (на этапе моделирования) просто краткое тезисное описание, которое по мере согласования/утверждения скоупа инкремента заменяется ссылкой на соответствующую Story в джире.
p.s. Я с безответственными и безынициативными работать так и не научился :)
Однозначного ответа на этот вопрос нет. Большинству разработчиков комфортнее работать в условиях, когда все решения уже приняты заранее и при случае можно свалить ответственность на тех, кто ставил задачу, дескать сами виноваты. Но встречаются и такие, которые хотят проявить инициативу, но им не дают, потому что ответственность за принятые решения несет кто-то другой. То, что кажется разработчику лучше, удобнее и полезнее, совершенно не обязательно окажется приемлемо для конечного заказчика.
На мой взгляд, без инициативы невозможен профессиональный рост. Но, как следствие связи инициативы и ответственности, рост происходит тогда, когда вместе с проявлением инициативы вы берете на себя и ответственность за то, что делаете. Безответственная инициатива обычно приносит больше вреда чем пользы.
Скажите, пожалуйста, какого размера была команда на этапе «Think IT», кто в неё входил?
2. Да, проект состоит из одного (довольно большого) репозитория. На нескольких организовать управляемый процесс довольно трудно :(
3. Каждая задача до завершения ведется в отдельной ветке и вливается в один из стволов (dev || release) только после завершения и предварительного тестирования на стенде разработчика. Я не стал пока про это писать, чтобы не усложнять. Таких веток в работе в идеальном случае — по количеству разработчиков, но иногда какие-то ProofOfConcept могут жить подольше. Могут двое работать в одной feature-ветке, например делая согласованные изменения на фронтенде и бэкенде. Вообще, стараемся делать так, чтобы эти ветки не висели долго. Делим задачи так, чтобы они делались за несколько дней и вливались в ствол. Старые ветки периодически чистим.
4. Для поддержки старых версий есть два варианта. Первый — очень-очень осторожно сделать маленький-маленький хотфикс с последующим Sanity тестированием. Редкий кейс, стараемся избегать. Предпочитаем исправить обнаруженный баг в текущем релизе и обычным порядком выставить обновление.
К сожалению, мне этот пост попался на глаза только сейчас. Полгода назад, когда всё только начиналось, я не знал слов «Эволюционное управление» и действовал скорее интуитивно. Однако, модель управления, которая в итоге получилась, очень напоминает, то что описано в статье.
Такая модель — точно не серебряная пуля. Типовые проекты делаются по другому. Если вы точно знаете что хотите получить и влияние неопределённости на ваши планы минимально — все эти танцы неуместны.
Совсем другая картина — когда ни вы, ни ваши заказчики точно не знаете что должно получиться в итоге, и имеете душевные силы признаться в этом себе и друг другу. Вот тут начинает в полный рост влиять используемый способ уменьшения неопределённостей. Я пришел к эволюционной идее после книг Талеба, он тоже рассказывает про «постепенное прилаживание», я адаптировал его идеи на программный код и управление требованиями.
Вредно, если кратко — потому что борьба с ветряными мельницами непродуктивна. Если все засинхронизировать, все планы будут прозрачно перетекать и обновляться, то возникнет ложное ощущение того, что все под контролем. А в управлении проектом, повторюсь, задачи разработки — они даже не на втором плане по важности. Отсутствие такой прозрачной автоматизации в мелочах порождает необходимость немножко поработать головой и руками. Мозг не умеет работать с большим количеством мелких артефактов, приходится их обобщать. А это помогает расширить угол зрения.
Microsoft при первом релизе TFS запилили примитивную интеграцию TFS с Project, этим мало кто воспользовался — они и не стали развивать. Ничего личного. Просто бизнес.
Даже программы мы давно уже не пишутся ассемблере, для этого используются языки высокого уровня, которые, конечно, не дают возможностей управления на уровне регистров, но внятно говорят машине чего мы от неё хотим.
Так вот, к чему это я. Модель проекта, с которой работает менеджер и модель задач, с которой работают разработчики — это разные вещи и между ними не всегда возможна автоматическая синхронизация. Дажа, я бы сказал, она вредна. Проект включает в себя много факторов, и программирование — это только малая часть, далеко не всегда самая трудоемкая. А «интерфейс между слоями» — это совместная работа менеджера проекта, тимлида, аналитика и других заинтересованных лиц. Потому что слоёв не два, а гораздо больше.
мух от котлетуправление производством от управления проектами. Тогда снимается львиная доля проблем и сложностей.можно подумать, до этого все его специально делали плохо.