четверг, 6 августа 2009 г.

Управление требованиями к ПО

Дочитал до конца use-case аналитику Коберна, про которую рассказывал в прошлом посте. Удивительная книга! Читается, если вникать, безусловно очень медленно – язык тяжеловат. Но вникать надо – только когда разберешься, да попробуешь, да покрутишь описанные приемы на конкретных реальных проектах, начинаешь ощущать  фактическую пользу от прочитанного!

Лично мне приёмы Коберна во многом более чем близки! Я согласен, что хорошее текстовое описание доминирует над всякими там UML-диаграммами. По крайней мере в начальной стадии – в любом случае сначала придется разобраться, а что мы вообще пытаемся сделать, а как собственно оно примерно будет работать, а уж только потом “рисовать”. Все эти UML-рисования суть есть уже проектирование, причем проектирование скорее техническое, когда уже ясно “что, куда и зачем”. Но на начальном этапе требования кружочками да эллипсами не выразить – от текста никуда не деться.

Раньше подобные текстовые списки “требований” вел в своей же Aml Pages. Aml Pages обладает для такой работы ощутимыми преимуществами:

  • Текст, текст и только текст. Но не “ничего кроме” текста! Надо? Можно и файл прицепить, и гиперссылки поставить, и отформатировать, и рисунки и все такое в том же духе. Но это дополнительный функционал.
  • Мгновенное и наглядное изменение “статуса”, “важности” записи через автоматическую подсветку, стили форматирования, категории, иконки. Т.е. все-же нужную атрибутику можно менять “на лету” – причем изменения будут наглядны – что может быть нагляднее цвета.
  • Отсутствие излишнего формализма. Не нужно вводить даты, проценты завершенности и тому подобную хрень. Всё это, возможно, и понадобиться, но позже. Сначала только описание самих требований, пожеланий пользователей, багов и.т.д.

Но все же в Aml Pages это были скорее простые wish list – списки пожеланий – безо всякой лишней иерархичности, зависимостей. А вот когда уже понадобилось вести действительно именно списки “требований”, что завершено, что нет, какое требование часть другого, то от иерархий никуда не деться. Требования по сути своей иерархичны.

Попробовал поискать софт для управления требованиями… Ан фиг! Или уж монструозные приложения от гигантов вроде IBM или Rational, которые ну очень уж и сложны в использовании, или… или просто напросто ничего нет.

Пробую использовать ToDoList. Единственное, что хоть каким-то образом выполняет обязательные требования: иерархичность, простенький учёт (завершено\нет), и немонструозность.
Но юзабилити ToDoList хромает более чем! Так себе, на “троечку”. Очень много лишнего – рабочая область очень сильно перегружена элементами управления.
Близкие по смыслу элементы разбросаны по всему экрану, вроде приоритет задачи показывается в гриде, а изменить его можно в комбобоксе аж на другом конце экрана. Да чего уж там - невозможность подвигать столбцы в гриде. В общем, “хорошо, но мало” ©.

Вот и чего теперь делать? Как и в чем управляться с требованиями? Похоже, опять двадцать пять! “Что же? Мне всю жизнь по этой пустыне мотаться!?!” (© Сухов). 
Как же это?  “Снова здорова” - писать что-то с нуля самому? Дык не хочется! Народ, а вы чем пользуетесь?

4 комментария:

  1. Так ToDoList же, кажись, опен-сорс?

    ОтветитьУдалить
  2. Про ToDoList
    Вот и я подумываю, а не прикрутить простенький функционал, чтобы хотя бы можно было те же самые статусы до приоритеты задач выбирать двойным кликом непосредственно из грида...
    По идее, такое вполне можно сделать, причем аккуратненько вживить в код основного проекта несколько "сбоку", не перелопачивая сильно исходники, чтобы потом не мучаться с каждым новым релизом ToDoList.

    ОтветитьУдалить
  3. Про LeaderTask
    1) Достаточно требователен к вычислительными ресурсам... В процессе разработки у меня и так есть чем загрузить и проц, и память. Если обычный запуск или даже просто переключение на LeaderTask вызывает неслабое такое потрескивание жесткого диска с характерным, а главное продолжительным наблюдением песочных часов в курсоре мыши, то какие уж тут нафиг "быстрые записи"!?!

    2) Да к тому же еще и модальные диалоги используют. Т.е. если возникает нужда отредактировать описание задачи, требований, то сначала запускается диалог, только потом можно отредактировать текст, а потом еще нужно нажать "ОК" чтобы сохранить, закрыть и вернуться к гриду...

    Куда млин столько действий-то!?! Это очень неудобно, тем более что в процессе сбора, описания требований такие "редакторские" действия ну очень чАсты, и этот бесконечный клик-писать-опять-клик банально мешает работе.
    Тем более что без такого модального диалога в редактировании можно очень даже запросто обойтись. Кодится такое практически тривиально. И никаких модальных диалогов да кнопок "ОК".

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

    ОтветитьУдалить