А вот тут вынужден расстроить. 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 или даже бумажный лист). Ключевое слово — «приходится». Все эти сложности как бы намекают, что копаем не там где надо. И, хотя менеджерам, которые выросли из программистов (сам таким был) такая функция кажется очевидной, на самом деле ниоткуда не следует, что управление проектом и управление задачами работают в одних и тех же терминах.
Даже программы мы давно уже не пишутся ассемблере, для этого используются языки высокого уровня, которые, конечно, не дают возможностей управления на уровне регистров, но внятно говорят машине чего мы от неё хотим.
Так вот, к чему это я. Модель проекта, с которой работает менеджер и модель задач, с которой работают разработчики — это разные вещи и между ними не всегда возможна автоматическая синхронизация. Дажа, я бы сказал, она вредна. Проект включает в себя много факторов, и программирование — это только малая часть, далеко не всегда самая трудоемкая. А «интерфейс между слоями» — это совместная работа менеджера проекта, тимлида, аналитика и других заинтересованных лиц. Потому что слоёв не два, а гораздо больше.
Вот не поверите, только сегодня размышлял о том, что пора уже написать о том, что нужно отделять мух от котлет управление производством от управления проектами. Тогда снимается львиная доля проблем и сложностей.
Боюсь, что это скорее Ваше заблуждение, по поводу количества свободного времени у менеджера.
Если менеджер занимается делом, то у него ответственности и забот гораздо больше чем у любого разработчика, и неважно, насколько разработчик опытный. Кроме того, проблема, описанная в статье, находится в зоне ответственности менеджера. Именно потому, что у него, в отличие от разработчиков, есть доступ к информации и возможности влияния на ситуацию. Работа у него такая.
Так вся эта кухня для того и придумана. В идеальном случае человек входит в систему под личной учеткой, потом приходит на специальную веб-страничку и говорит: «дай ка мне доступ к серверу ABCDEF». И ему сразу открывается терминал в эту систему.
Пароли в данной ситуации — это только средство предоставить ему доступ.
Так все эти «велосипеды» отчасти и придуманы для того, чтобы приладить многофакторную аутентификацию к тем системам, устройствам и т.п., которые сами этого делать не умеют. Я вижу два основных плюса от использования подобных систем:
1. Строгая аутентификация пользователей, причем для всех систем используется один каталог пользователей.
2. Централизованный аудит обращения ко всем системам.
Но я ни в коем случае не буду утверждать, что эти системы нужно обязательно ставить всем и везде. Стоят они не дешево, преимущества, действительно, сходу не очевидны. Так что перед принятием решения о внедрении (или не внедрении) подобных решений, сначала нужно прийти к пониманию почему и зачем это делается.
p.s. Я с безответственными и безынициативными работать так и не научился :)
Однозначного ответа на этот вопрос нет. Большинству разработчиков комфортнее работать в условиях, когда все решения уже приняты заранее и при случае можно свалить ответственность на тех, кто ставил задачу, дескать сами виноваты. Но встречаются и такие, которые хотят проявить инициативу, но им не дают, потому что ответственность за принятые решения несет кто-то другой. То, что кажется разработчику лучше, удобнее и полезнее, совершенно не обязательно окажется приемлемо для конечного заказчика.
На мой взгляд, без инициативы невозможен профессиональный рост. Но, как следствие связи инициативы и ответственности, рост происходит тогда, когда вместе с проявлением инициативы вы берете на себя и ответственность за то, что делаете. Безответственная инициатива обычно приносит больше вреда чем пользы.
Скажите, пожалуйста, какого размера была команда на этапе «Think IT», кто в неё входил?
2. Да, проект состоит из одного (довольно большого) репозитория. На нескольких организовать управляемый процесс довольно трудно :(
3. Каждая задача до завершения ведется в отдельной ветке и вливается в один из стволов (dev || release) только после завершения и предварительного тестирования на стенде разработчика. Я не стал пока про это писать, чтобы не усложнять. Таких веток в работе в идеальном случае — по количеству разработчиков, но иногда какие-то ProofOfConcept могут жить подольше. Могут двое работать в одной feature-ветке, например делая согласованные изменения на фронтенде и бэкенде. Вообще, стараемся делать так, чтобы эти ветки не висели долго. Делим задачи так, чтобы они делались за несколько дней и вливались в ствол. Старые ветки периодически чистим.
4. Для поддержки старых версий есть два варианта. Первый — очень-очень осторожно сделать маленький-маленький хотфикс с последующим Sanity тестированием. Редкий кейс, стараемся избегать. Предпочитаем исправить обнаруженный баг в текущем релизе и обычным порядком выставить обновление.
К сожалению, мне этот пост попался на глаза только сейчас. Полгода назад, когда всё только начиналось, я не знал слов «Эволюционное управление» и действовал скорее интуитивно. Однако, модель управления, которая в итоге получилась, очень напоминает, то что описано в статье.
Такая модель — точно не серебряная пуля. Типовые проекты делаются по другому. Если вы точно знаете что хотите получить и влияние неопределённости на ваши планы минимально — все эти танцы неуместны.
Совсем другая картина — когда ни вы, ни ваши заказчики точно не знаете что должно получиться в итоге, и имеете душевные силы признаться в этом себе и друг другу. Вот тут начинает в полный рост влиять используемый способ уменьшения неопределённостей. Я пришел к эволюционной идее после книг Талеба, он тоже рассказывает про «постепенное прилаживание», я адаптировал его идеи на программный код и управление требованиями.
Вредно, если кратко — потому что борьба с ветряными мельницами непродуктивна. Если все засинхронизировать, все планы будут прозрачно перетекать и обновляться, то возникнет ложное ощущение того, что все под контролем. А в управлении проектом, повторюсь, задачи разработки — они даже не на втором плане по важности. Отсутствие такой прозрачной автоматизации в мелочах порождает необходимость немножко поработать головой и руками. Мозг не умеет работать с большим количеством мелких артефактов, приходится их обобщать. А это помогает расширить угол зрения.
Microsoft при первом релизе TFS запилили примитивную интеграцию TFS с Project, этим мало кто воспользовался — они и не стали развивать. Ничего личного. Просто бизнес.
Даже программы мы давно уже не пишутся ассемблере, для этого используются языки высокого уровня, которые, конечно, не дают возможностей управления на уровне регистров, но внятно говорят машине чего мы от неё хотим.
Так вот, к чему это я. Модель проекта, с которой работает менеджер и модель задач, с которой работают разработчики — это разные вещи и между ними не всегда возможна автоматическая синхронизация. Дажа, я бы сказал, она вредна. Проект включает в себя много факторов, и программирование — это только малая часть, далеко не всегда самая трудоемкая. А «интерфейс между слоями» — это совместная работа менеджера проекта, тимлида, аналитика и других заинтересованных лиц. Потому что слоёв не два, а гораздо больше.
мух от котлетуправление производством от управления проектами. Тогда снимается львиная доля проблем и сложностей.можно подумать, до этого все его специально делали плохо.
Если менеджер занимается делом, то у него ответственности и забот гораздо больше чем у любого разработчика, и неважно, насколько разработчик опытный. Кроме того, проблема, описанная в статье, находится в зоне ответственности менеджера. Именно потому, что у него, в отличие от разработчиков, есть доступ к информации и возможности влияния на ситуацию. Работа у него такая.
К сожалению опоздал к возможности плюсовать топик :(, отыгрался на карме.
Пароли в данной ситуации — это только средство предоставить ему доступ.
1. Строгая аутентификация пользователей, причем для всех систем используется один каталог пользователей.
2. Централизованный аудит обращения ко всем системам.
Но я ни в коем случае не буду утверждать, что эти системы нужно обязательно ставить всем и везде. Стоят они не дешево, преимущества, действительно, сходу не очевидны. Так что перед принятием решения о внедрении (или не внедрении) подобных решений, сначала нужно прийти к пониманию почему и зачем это делается.