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