Telegram Group & Telegram Channel
Распаковка рюкзака с конференции 3. Закон Миллера, Монте-Карло и dogfooding

Еще порция заметок с недавней Merge.

Большинство аналитиков неправильно используют требования и их классификацию. А ты? Рассказ о подходах к классификации требований и ее целях. Доклад в программе.
По закону Миллера кратковременная память человека оперирует количеством элементов от 5 до 9. Как только вы пытаетесь впихнуть в границы анализа больше, получается каша, которую сложно обработать. Мозг пытается сгруппировать увиденное и свести к посильному количеству знакомых объектов, так за деталями теряются цели и "дорисовываются" объекты.
Принципы ООП тоже работают для требований, помогают сократить количество объектов. Абстрагирование — выделение только значимых элементов. Инкапсуляция - скрывание деталей системы и фокус на её взаимодействии с внешним миром.
Классификация помогает выделить уровни информации и на каждом оперировать только теми объектами, что для него значимы. Плохо работает "верхнеуровневое БТ", где вперемешку указаны цели доработки, требования к решению, куски архитектуры и json-схемы.
📌Классификация требований не для обозначения уровней детализации, а для снижения сложности
📌Требования задают контракт: зоны ответственности и компетенций
📌Формулировать системные требования нужно так, чтобы оставить проработку деталей реализации другим компетенциям. За деталями теряется целое и возникают лишние ограничения
📌Не следует подменять работу с требованиями полным проектирование системы.

Тут вспомнила доклад Юрия Куприянова на Flow, что требования плотно связаны с решением, что описание требований свелось к придумыванию решения вместе с заказчиком. Есть и такое мнение.

От покера до футболок, выбор метода оценки ИТ задач. Доклад в программе. Советы по методам оценки задач. Метод важно выбрать соответственно ситуации. Если 10 специалистов час сидят на встрече по планированию задач, это суммарно10 часов рабочего времени потрачено. У каждого метода свои условия применения и своя чувствительность к неопределенности, зависимостям, сложности. Речь шла о таких методах:
📌Scrum покер, когда используются карты с цифрой оценки и участники одновременно открывают свои карты. Подходит для небольших команд и хорош вовлечением участников, требует опыта и времени на обсуждение.
📌Метод футболок, когда оценка дается буквой S,M,L. Подходит для небольших команд, простой и понятный, но не точный.
📌Три амиго, когда эксперты разных областей (DEV,BA/SA,QA) обсуждают задачу. Хорош для задач с высоким уровнем неопределенности, требует времени ключевых экспертов.
📌PERT, когда оцениваются сценарии оптимистичный (O), наиболее вероятный (R), пессимистичный (P). Итоговую оценку подсчитывают как (O+4*R+P)\6. Учитывает неопределенность, подходит для сложных и долгосрочных проектов, но сложен и зависит от точности оценок.
📌Монте-Карло, статистический метод на основе данных о сроках выполнения задач из таск-трекера. Для начала нужны данные не менее, чем за 7 недель работы команды. Метод зависит от качества статистической модели, но хорошо визуализирует результаты расчетов и подходит для сложных проектов. Несколько слов о методе привозила с Dump в феврале тут.

Пока ждем записей докладов в общем доступе можно посмотреть в этом канале пост о техниках оценки задач.

Dogfooding as a Service - как "сломать" продукт так, чтобы команда тебе была благодарна. Доклад в программе. Dogfooding – это использование сотрудниками компании продуктов этой же компании для анализа достоинств и недостатков. Название пришло от производителей собачьего корма, среди которых кто-то утверждал что готов съесть свой прекрасный продукт сам, а кто-то съел банку корма на собрании акционеров (подробнее в статье)
Доклад о том, как организован процесс. Смутили две вещи. 1) Процесс на добровольных началах и организаторы, и участники работают на добровольных началах вне основных задач. 2) По наблюдениям автора не более 50% собранных замечаний ложатся в бэклоги команд разработки, а остальное – дубли, уже известные идеи и пр.

На этом все распаковала. Всем прекрасных майских выходных 🔅

#конференции



group-telegram.com/pro_ba_it/244
Create:
Last Update:

Распаковка рюкзака с конференции 3. Закон Миллера, Монте-Карло и dogfooding

Еще порция заметок с недавней Merge.

Большинство аналитиков неправильно используют требования и их классификацию. А ты? Рассказ о подходах к классификации требований и ее целях. Доклад в программе.
По закону Миллера кратковременная память человека оперирует количеством элементов от 5 до 9. Как только вы пытаетесь впихнуть в границы анализа больше, получается каша, которую сложно обработать. Мозг пытается сгруппировать увиденное и свести к посильному количеству знакомых объектов, так за деталями теряются цели и "дорисовываются" объекты.
Принципы ООП тоже работают для требований, помогают сократить количество объектов. Абстрагирование — выделение только значимых элементов. Инкапсуляция - скрывание деталей системы и фокус на её взаимодействии с внешним миром.
Классификация помогает выделить уровни информации и на каждом оперировать только теми объектами, что для него значимы. Плохо работает "верхнеуровневое БТ", где вперемешку указаны цели доработки, требования к решению, куски архитектуры и json-схемы.
📌Классификация требований не для обозначения уровней детализации, а для снижения сложности
📌Требования задают контракт: зоны ответственности и компетенций
📌Формулировать системные требования нужно так, чтобы оставить проработку деталей реализации другим компетенциям. За деталями теряется целое и возникают лишние ограничения
📌Не следует подменять работу с требованиями полным проектирование системы.

Тут вспомнила доклад Юрия Куприянова на Flow, что требования плотно связаны с решением, что описание требований свелось к придумыванию решения вместе с заказчиком. Есть и такое мнение.

От покера до футболок, выбор метода оценки ИТ задач. Доклад в программе. Советы по методам оценки задач. Метод важно выбрать соответственно ситуации. Если 10 специалистов час сидят на встрече по планированию задач, это суммарно10 часов рабочего времени потрачено. У каждого метода свои условия применения и своя чувствительность к неопределенности, зависимостям, сложности. Речь шла о таких методах:
📌Scrum покер, когда используются карты с цифрой оценки и участники одновременно открывают свои карты. Подходит для небольших команд и хорош вовлечением участников, требует опыта и времени на обсуждение.
📌Метод футболок, когда оценка дается буквой S,M,L. Подходит для небольших команд, простой и понятный, но не точный.
📌Три амиго, когда эксперты разных областей (DEV,BA/SA,QA) обсуждают задачу. Хорош для задач с высоким уровнем неопределенности, требует времени ключевых экспертов.
📌PERT, когда оцениваются сценарии оптимистичный (O), наиболее вероятный (R), пессимистичный (P). Итоговую оценку подсчитывают как (O+4*R+P)\6. Учитывает неопределенность, подходит для сложных и долгосрочных проектов, но сложен и зависит от точности оценок.
📌Монте-Карло, статистический метод на основе данных о сроках выполнения задач из таск-трекера. Для начала нужны данные не менее, чем за 7 недель работы команды. Метод зависит от качества статистической модели, но хорошо визуализирует результаты расчетов и подходит для сложных проектов. Несколько слов о методе привозила с Dump в феврале тут.

Пока ждем записей докладов в общем доступе можно посмотреть в этом канале пост о техниках оценки задач.

Dogfooding as a Service - как "сломать" продукт так, чтобы команда тебе была благодарна. Доклад в программе. Dogfooding – это использование сотрудниками компании продуктов этой же компании для анализа достоинств и недостатков. Название пришло от производителей собачьего корма, среди которых кто-то утверждал что готов съесть свой прекрасный продукт сам, а кто-то съел банку корма на собрании акционеров (подробнее в статье)
Доклад о том, как организован процесс. Смутили две вещи. 1) Процесс на добровольных началах и организаторы, и участники работают на добровольных началах вне основных задач. 2) По наблюдениям автора не более 50% собранных замечаний ложатся в бэклоги команд разработки, а остальное – дубли, уже известные идеи и пр.

На этом все распаковала. Всем прекрасных майских выходных 🔅

#конференции

BY Про_БА


Warning: Undefined variable $i in /var/www/group-telegram/post.php on line 260

Share with your friend now:
group-telegram.com/pro_ba_it/244

View MORE
Open in Telegram


Telegram | DID YOU KNOW?

Date: |

"Markets were cheering this economic recovery and return to strong economic growth, but the cheers will turn to tears if the inflation outbreak pushes businesses and consumers to the brink of recession," he added. Again, in contrast to Facebook, Google and Twitter, Telegram's founder Pavel Durov runs his company in relative secrecy from Dubai. Pavel Durov, Telegram's CEO, is known as "the Russian Mark Zuckerberg," for co-founding VKontakte, which is Russian for "in touch," a Facebook imitator that became the country's most popular social networking site. Artem Kliuchnikov and his family fled Ukraine just days before the Russian invasion. "He has kind of an old-school cyber-libertarian world view where technology is there to set you free," Maréchal said.
from us


Telegram Про_БА
FROM American