++++ Это мой любимый голос. "Как папа был маленьким" заслушана просто до дыр с ребенком. Я не знал его в лицо и визжжал, когда по голосу узнал в каком-то российском сериале ))
Несколько раз упоминалось в статье :) Тут хочется вспомнить цитату в духе, что группа высокогрейдовых людей без организации ведёт себя как группа, а не как высокогрейдовая группа)
Ну это и так было понятно, что aw прикольнее sw. Хотелось бы конкретных примеров и инстурментов.
Хорошо, например, согласовать спеку с 5 людьми асинхронно. Но на деле это приводит к тому, что люди забивают, их надо пинговать, у них всегда есть более срочные дела, чем спека. Плюс еще одинаковые замечания, плюс нет влияния одних замечаний на других людей.
Мне больше нравится подход амазона, когда к встрече надо подготовиться и первая часть встречи тратится на молчаливое чтение документации.
Спасибо за развернутый ответ! Общий принцип понял. Единственное, у меня в голове обратноя соотношение - юзер стори нечто более глобальное и общее, чем юзкейс. "Я как пользователь хочу, чтобы система позволяла управлять доступами, чтобы кто попало не прошел, а кто не попало - прошел". И дальше уже юзкейсы - это конкретные шаги. Возможно, даже не целые юзкейсы, а slices
Поэтому колонки бы у меня были в виде юзерсторях, а юзкейсы уже по нима бы двигались.
Но как будто бы переход на doc-as-a-code прошел бы у вас проще. Условно, взять какой-нибудь диплодок (или аналог), сделать публичный урл для заказчика, сделать внутренний урл для себя, инклюдами вкючать нужные блоки во внешнюю доку, релизиться вместе с продуктом.
О том, что дело именно в воспроизведении. С таким же успехом можно утверждать, что колеса круглые, потому что люди увидели луну и по её подобию создали.
Почему, например, дело не в наиболее удобном формате для большинства пользователей.
Денис, отличная статья! Показан пример, что даже для примитивной и давно известной программы в ТЗ нужно подумать о различных аспектах в различных направлениях.
Придирки к аудитории, БТ/ПТ интересны, конечно, но как будто оторваны от реальности. Мне подход с ТЗ кажется понятным и как учебный пример довольно хорошо показывает, что бы я отдавал разработчикам. Вряд ли токарь на заводе, вытачивая деталь, будет метаться в сомнениях насчет аудитории, для которой эта датель нужна. Знание могло бы быть ему полезно, но важнее размеры детали на чертеже. Другие люди зарнее об этом подумали, вероятно.
Рассуждения про интерфейс и кнопки из 1970х касаются лишь одного раздела из ТЗ и достаточно легко абстрагироваться, что в реальной задаче в этом разделе могли быть другие требования.
Статью добавляю в закладки на два случая:
Подскажи, как мне писать ТЗ разработчику, когда не знаю, с чего начать
Ой, что там писать, делать надо, по ходу разберемся...
Ведь всё, что кроме, легко уладить с помощью зонта
Веду такой дневник в чатботе. Потом можно разные выгрузки просить сделать.
Но вероятно через ии-плангины к обсидиан тоже можно
++++ Это мой любимый голос. "Как папа был маленьким" заслушана просто до дыр с ребенком. Я не знал его в лицо и визжжал, когда по голосу узнал в каком-то российском сериале ))
Несколько раз упоминалось в статье :) Тут хочется вспомнить цитату в духе, что группа высокогрейдовых людей без организации ведёт себя как группа, а не как высокогрейдовая группа)
Источник не помню, но смысл такой
Правильно было бы написать "только"
Челики просто загнали в нейронку и выплюнули сюда результат. Пингвин_кланяется.jpg
Ну это и так было понятно, что aw прикольнее sw. Хотелось бы конкретных примеров и инстурментов.
Хорошо, например, согласовать спеку с 5 людьми асинхронно. Но на деле это приводит к тому, что люди забивают, их надо пинговать, у них всегда есть более срочные дела, чем спека. Плюс еще одинаковые замечания, плюс нет влияния одних замечаний на других людей.
Мне больше нравится подход амазона, когда к встрече надо подготовиться и первая часть встречи тратится на молчаливое чтение документации.
puml полезен, если, например, нужно автоматически генерить схему. Ну и для SD, да, там как сценарий пишешь, а он схему рисует.
Там, где важнее красота, puml бессилен
Спасибо за развернутый ответ! Общий принцип понял. Единственное, у меня в голове обратноя соотношение - юзер стори нечто более глобальное и общее, чем юзкейс. "Я как пользователь хочу, чтобы система позволяла управлять доступами, чтобы кто попало не прошел, а кто не попало - прошел". И дальше уже юзкейсы - это конкретные шаги. Возможно, даже не целые юзкейсы, а slices
Поэтому колонки бы у меня были в виде юзерсторях, а юзкейсы уже по нима бы двигались.
С точки зрения разработчика - это DoR, получается?
Можете уточнить, как User Story из "Модели полезных инкрементов" связываются с Use Cases из "Модели сценариев"?
И, например, как это лучше оформлять с точки зрения артефактов? Один общий документ с usecases в конфлюенсе и отдельно юзер стори мэпа в миро?
Интересный подход!
Но как будто бы переход на doc-as-a-code прошел бы у вас проще. Условно, взять какой-нибудь диплодок (или аналог), сделать публичный урл для заказчика, сделать внутренний урл для себя, инклюдами вкючать нужные блоки во внешнюю доку, релизиться вместе с продуктом.
Мне несколько не понятно, почему знание особенностей железа перевешивается на аналитиков
Разработчики же тоже принимали участие в работе с требованиями - мозговой штурм, согласовывали их? Можно сказать:
Разработчики не знали особенностей операционных систем и не учли их
Можно продолжить дальше:
Архитекторы не знали особенностей операционных систем и не учли их
Я бы предложил смотреть, что "Было бы лучше, если бы аналитик знали", но не уходить в крайность "Аналитик должен знать"
Задача аналитика - верифицировать об экспертов
Никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью
Мне больше по душе плясать от Проект/продукта, под ним уже бизнес-требования, бизнес-модели, фт, нфт и т.д.
О том, что дело именно в воспроизведении. С таким же успехом можно утверждать, что колеса круглые, потому что люди увидели луну и по её подобию создали.
Почему, например, дело не в наиболее удобном формате для большинства пользователей.
Денис, отличная статья! Показан пример, что даже для примитивной и давно известной программы в ТЗ нужно подумать о различных аспектах в различных направлениях.
Придирки к аудитории, БТ/ПТ интересны, конечно, но как будто оторваны от реальности. Мне подход с ТЗ кажется понятным и как учебный пример довольно хорошо показывает, что бы я отдавал разработчикам. Вряд ли токарь на заводе, вытачивая деталь, будет метаться в сомнениях насчет аудитории, для которой эта датель нужна. Знание могло бы быть ему полезно, но важнее размеры детали на чертеже. Другие люди зарнее об этом подумали, вероятно.
Рассуждения про интерфейс и кнопки из 1970х касаются лишь одного раздела из ТЗ и достаточно легко абстрагироваться, что в реальной задаче в этом разделе могли быть другие требования.
Статью добавляю в закладки на два случая:
Подскажи, как мне писать ТЗ разработчику, когда не знаю, с чего начать
Ой, что там писать, делать надо, по ходу разберемся...
на чем основано ваше предположение? есть ссылки на исследования?
такое ощущение, что вы берете рассуждения о правильной архитектуре из воздуха