Как стать автором
Обновить
7
0

Архитектор

Отправить сообщение

Я ничего обидного не сказал, вполне рабочие схемы управления. В некоторых условиях только они и работают. А второе мной высказанное предположение - это когда команда самоорганизовалось, а менеджер, если он хороший менеджер, не ломает эту систему.

В канбане не меняются сущности, не важно синтез или анализ. Когда на конвейер подается деталь она не изменяется, болт не станет гайкой.

У вас хромает базовый принцип управления, нет объективного контроля. Невозможно нормально посчитать WIP и построить CFD. Поэтому у вас не канбан.

Хорошо, а теперь поясните, каким образом данный фрагмент подтверждает ваши слова "вы вынесли анализ вперед, значит у вас не скрам"?

Разработчики не смогут просто взять в работу задачи, у них обязательно будут возникать вопросы, они подойдут к аналитикам (про аналитическую поддержку я в статье написал). А у вас аналитики за спринтом, Scrum Team у вас не кроссфункциональная, значит ваш скрам не полноценный. Поэтому у вас не скрам.

PS: Я понимаю, что у вас всё на ручном приводе и ситуационное управление, вы как менеждер проекта сидите и разруливаете кейсы. Процесс не описан, а если даже описан, то только в общих чертах. Возможен еще второй вариант, вам ничего не говорят, а вы уверены, что так оно и работает. Спорить больше не будем, мнениями обменялись, польза от этого для каждого какая-то есть.

Поясняю, сборка автомобиля - это синтез (из известных деталей собирается известная вещь). Процесс формализованный, результат определен, можно полностью автоматизировать.

Разбор "хотелки заказчика" - это анализ (из непонятной вещи делаем декомпозицию на понятные).

Откройте Скрам гайд и попробуйте найти подтверждение своих слов. Но не найдете, так как слово "анализ" там вообще не встречается.

Скрам гайд:

As Scrum’s use spreads, developers, researchers, analysts,
scientists, and other specialists do the work. We use the word “developers” in Scrum not to exclude, but to simplify.

Или думаете Кен Швабер и Джефф Сазерленд держат специальный секретный отдел аналитиков и никому про него не говорят?

Сборка на автомобильном конвейере это 100% формализованный процесс, там 99% работы лучше поручить роботам. Разработка софта, а тем более анализ - это интеллектуальная деятельность. Вы, надеюсь, понимаете разницу.

Ну это вы сказали "стори", а имели ввиду всё что угодно. Вы, надеюсь, знаете, что такое User Story или Job Story.

Как-то нечестно играете, подмена понятий началась. :(

В сраме анализ производится разработчиками, вы вынесли анализ вперед, значит у вас не скрам.

Строительный архитектор не выбирает материалы, он занимается планировкой, фасадами и инсоляцией. Конструкционной частью (где материалы) занимается главный инженер проекта (ГИП). Стоимостью занимается сметчик.

"Архитектор в ИТ" имеет кардинально другой смысл, он больше похож на ГИП в строительном проекте.

Зачем вы называете канбаном то, что придумали в рамках локальной самодеятельности? Задачи у вас меняю тип и разбиваются произвольно. WIP нормально вы не посчитаете, и значит CFD ваш врёт, т.е. то что нарисовала jira не дает правильного представления о ситуации на проекте. Потому что вы играет по своим правилам и не соблюдаете канбан. Тип задачи "стори" вы записываете всё подряд, ну значит и скрама у вас нет. И канбана нет. Сплошной волюнтаризм. :)

Так я не спорю, что его нужно за скрам, мы расходимся в понимании как.

То что у вас - это не канбан, так как задача не может поменять тип при движении по доске. Change Requests не может стать Story. Из Change Requests могут появится стори, а может несколько сторей, а может не появится, а может нужно изменить какую-то сторю, а может снова открыть закрытую, а может ролевую модель нужно поменять, а может формат выгрузки, а может интеграцию описать, а может <что угодно>... Это же анализ!

Да причем тут канбан? Я сказал, что сказал аналитик не работает по сторям. Стори это результат работы аналитика. А Merrynose сам себе противоречит, говорит «Именно так он и работает» и дальше говорит, что аналитик работает по «хотелкам от заказчика» (но это же не стори), далее он говорит «на выходе – готовые к реализации стори» (но они же создаются на доске разработки).

Ну так я тоже само и сказал, внимательнее почитайте. «Задачи аналитика» и «стори для разработки» находятся на разных досках.

Далее я говорю, что на доске аналитика «это некое обобщённое предложение», а Merrynose опять отрицает и говорит: «Да нет же. На доске я и вся команда увидим ход подготовки сторей», хотя текстом ранее он сказал, что у аналитика на входе «хотелки заказчика».  А хотелки как раз приземляются на доску аналитика в «некоторое обобщённое предложение, что нужно проанализировать/спроектировать.»

Вот и встал у меня вопрос «Зачем я должен это разжевывать?»

Ну, а вам что неясно, вы же аналитик?

Вы слишком вольно судите о том, что я не слышал. А вот ваша уверенность в вашем стандартном подходе как бы "user story driven analisys", который работает только для определенных проектов, у меня уменьшает интерес к диалогу.

Эти вопросы были «на подумать», в IT любое организационное решение всегда требует адаптации под конкретных людей. Вспомните, что написано в начале любой книги про Agile: «Люди и взаимодействие важнее процессов и инструментов». После этого можно дальше не читать, а переходить к изучению книг по психологии, ответы там.

Аналитик не работает по сторям, набор сторей и не только сторей может быть результатом проработки задачи аналитика. Соответственно задача с доски аналитика никогда не перепрыгнет на доску разработки. Задачи анализа зависят от внешних обстоятельств намного сильнее, чем задачи разработки, они могут замораживаться, закрываться, перекрываться в зависимости от пользователей, заказчика, владельца продукта, менеджера проекта и текущего понимая предметной области, а понимание приходит во процессе анализа. Максимум, что вы создадите на этой доске – это некое обобщённое предложение, что нужно проанализировать/спроектировать. В момент постановку задачи аналитику у вас недостаточно понимания что и как нужно, иначе зачем делать анализ? Доску отдельную можно сделать, я это написал в статье, но только не такую как вы описали. Также есть вопрос о необходимости доски, когда у вас 2 или даже 1 аналитик в команде. Вы ходите всю эту аналитическую кухню, с непонятными задачами показать разработчикам? Аналитик же должен рассказать «что сделал», «что будет делать» и «проблемах». А разработчики его поймут за отведенное дейликом время, ему они смогут помочь? Или у вас проект идет спокойно, времени вагон, разработчикам нечего больше делать, кроме как помогать аналитику? У них есть в этом компетенции? Тогда у вас кросс-функциональная команда, зачем вам канбан, вам как раз нужен скрам…

Понимаете, я не зря написал в начале статьи: «Если вы думаете, что я дам вам какие-то решения, то увы, нет.» У меня найдутся решения, их множество, но они специфичны для конкретных проектов, универсального решения нет.

Осмелюсь спросить, а нужно ли по этой аналитической доске проводить отдельные дейли митинги? Будут ли они интересны разработчикам? А ретроспектива отдельная для аналитиков нужна? Это всё еще скрам? Мы всё еще одна команда?

Кажущиеся положительные рациональные моменты вашего предложения с лихвой перекрываются отрицательными последствиями, которые вы почему-то не указали.

Ну, вот тут нет, в реальности я вижу другое, часто рулят разработчики, а аналитики, как обслуживающий персонал, подносят постановки задач и описывают приянтое разработчиками решение. Не скажу, что это правильно.

Прошу, не называете это "Системой управления предприятием", так как вы находитесь "в километре от" задач управления предприятием и копаете не туда. Рекомендую задуматься над самим понятием "управление".

Попробуйте использовать понятие «Программный продукт» вместо «Программное обеспечение», всё заиграет другими красками.

А кто делал проект Москвы-Сити, например?

Архитектурную часть - архитекторы, строительную часть - инженеры-строители.

Сейчас архитектор - дизайнер потому, что строительство исходит не из рациональности, а из профита.

Довольно странное противопоставление рациональности и выгоды.

...обеспечения гибкости и лучшего пользовательского опыта.

Извините, но вы так дойдете до того, что заявите про то, что было время, когда строительные архитекторы CJM проектировали.

Архитекторы уже тогда понимали, что вот эти фасады, стены - это временное - сегодня ДК, а завтра пятёрочка,

Как правило проект предназначен для решения конкретных задач, а например, проектирование храма в архитектурном принципе не предполагает открытия в нем Пятерочки.

Кому нужен в Windows 11 таскбар как в Windows 10 используйте https://github.com/valinet/ExplorerPatcher
Можно размещать слева/справа :)

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность