Читаю Вигерса. Заметки для себя
Глава 1. стр.5 Взаимодействие между разработчиками и заказчиками ограничивается внешним видом пользовательского интерфейса и не затрагивает того, что же действительно клиенты собираются делать с помощью приложения
На работе начали внедрять систему бюджетирования- попытка не первая, поэтому исхожу из того , что заказчик с ней знаком , однако пока как в книге- до фунционала не доходит , пока только про внешний вид
стр.6. Основной закон: требования должны быть документированы — Был выбор из нескольких WMS , как выяснилось документированных требований нет — пока ничего не выбрали, адресное хранение товаров делаю сам
Очень понравилось как подтверждение своего мнения- постоянно с этим сталкиваюсь —
стр 11. — каких требований не должно быть- Спецификация требований не содержит деталей дизайна или реализации (кроме известных ограничений) …
стр .15 Если разработчики не записывают требования, с которыми заказчики уже согласились, как могут они удовлетворить этих заказчи
ков? , и далее …У вас не будет оправдания, если вы начнете писать код до того, как просмотрите требования перед следующим шагом. Итерации при кодировании стоят гораздо дороже, чем при разработке концепций. …Если вы не записываете даже подразумеваемые и предполагаемые требования,не удивляйтесь, если продукт не будет отвечать ожиданиям пользователей.
на стр.17 В любом случае трудно добраться до людей, которые непосредственно будут иметь дело с продуктом, а выразители мнения пользователей не всегда понимают, что тем нужно в реальности — к сожалению , это так
стр.18 -19 Про «золочение»
Под «золочением» понимают такие ситуации, когда разработчики добавляют функции, которых нет в спецификации, но им кажется, что это
понравится пользователям. Зачастую же клиентам не нужны такие избыточные возможности, получается, что время, отведенное на реализацию тратится впустую. Прежде чем просто вставлять новые функции,разработчики и аналитики должны представить свои творческие идеи на суд заказчиков. Задача команды — четко соблюдать требование спецификации, а не действовать за спиной клиентов без одобрения.
Пользователи иногда требуют функции или элементы интерфейса которые выглядят отлично, но не представляют особой ценности для продукта. Все, что вы захотите добавить, стоит времени и денег, поэтому постарайтесь осознать ценность своевременного выпуска продукта.
У меня из собственной практики есть примеры в обратную сторону -я придумал
рассылку отчетов по расписанию,
измерения для Apdex,
которые впоследствии получили признание в компании и начали использоваться
стр 20 Привлечение пользователей к созданию требований порождает восхищение продуктом и верность клиентов — очень хорошо и очень нравится
по второй главе почему то нет заметок- заново перечитать что ли?
Глава 3. стр.41 Про методики разработки ПО- Лучший прием на сегодня таков: не разрабатывать или не приобретать полнофункциональное решение, а дополнить имеющийся пакет средств разработчика различными возможностями, позволяющими решать самые разнообразные проблемы.
— похоже на итеративную модель разработки против каскадной
Про лучшие приемы (good practice? ) — высокоэффективные способы, которые при работе над определенными проектами и в определенных ситуациях существенно повышают шансы профессиональных разработчиков ПО на успех.
— страхуется человек-определенные проекты, определенные ситуации- если не получилось- то у вас не те проеты и не те ситуации? не нравится это
Далее приведены эти приемы -около 50-и опять- приемы годятся не для всех ситуаций,..и что надо руководствоваться трезвым расчетом,здравым смыслом и опытом- книга и так написана на основе опыта и …, не теоретическая она