Архив за Май, 2011

Что лежит за забором?

Вторник, Май 31st, 2011

Если оно выглядит как утка, плавает как утка и крякает как утка, то это, вероятно, утка и есть.

(c) Капитан Очевидность. http://lurkmore.ru/Капитан_Очевидность

Когда-то давным-давно (а может и совсем недавно) в одной солидной (а может и не очень) фирме (а может госучреждении) над большим (а может и крохотным) проектом трудились инженеры разных специальностей.
Если честно, то совершенно неважно где, когда и как, т.к. ситуация повторяется в куче разных фирм (пруфлинк). Так что считайте историю выдуманной на основе постов в форуме.

В какой-то момент при анализе предметной области выяснилось, что в спецификации требований пропущено описание очень важного функционала. Функционал был весьма нетривиальным, и без подробного анализа и описания пытаться реализовать его было бы э-э-э… нерационально. Если кому интересно, то это был функционал перевода объекта в состояние дубликат с передачей дочерних элементов дублируемому объекту. Ведущий аналитик, который отвечал за этот модуль, написать этот юзкейс оказался не в состоянии. справедливости ради, надо отметить, что с ходу написать этот юзкейс не смогла и группа аналитиков, собравшихся на ЛАФ-2010 (посмотреть можно в материалах с конференции ЛАФ-2010). Да, юзкейск хитрый и требует времени на обдумывание. Вполне себе юзкейс на полдня-день. Не на пятнадцать минут. Ну, или надо быть ведущим аналитиком.
Впрочем, мы отвлеклись. Ведущий аналитик передал эту задачу техническому писателю. Технический писатель не смог решить ее самостоятельно и обратился за помощью к тестировщику. Тестировщик объяснил, синтаксис юзкейсов и как писать именно этот юзкейс. Технический писатель сделал описание. Задача выполнена. Но кто же здесь аналитик, невзирая на то, что написано в трудовой книжке?

  • Если инженер знает, как писать спецификации требований и пишет их на проекте, то будьте уверенны, что он аналитик и есть. Невзирая на то, что написано в трудовой.
  • Если инженер не знает,  как писать спецификации требований, но пишет их на проекте со слов другого инженера, то будьте уверенны, что он есть помощник аналитика. Невзирая на то, что написано в трудовой.
  • Если в трудовой у инженера написано аналитик, но он не умеет писать требования и не пишет их на проекте, то будьте уверены - он не аналитик.

Холмс взял протянутую калошу, осмотрел ее, понюхал, полизал языком и наконец, откусивши кусок, с трудом разжевал его и проглотил.

- Теперь я понимаю! - радостно сказал он.

Мы вперили в него взоры, полные ожидания.

- Я понимаю… Ясно, что эта калоша резиновая!

Изумленные, мы вскочили с кресел..

Agile или не Agile?

Понедельник, Май 23rd, 2011

Agile предлагает сместить фокус внимания с процессов и артефактов на людей и коммуникации.

Таким образом, если рассказывая вам о какой либо методологии рассказчик концентрируется на процессах и артефактах:

  • SRS;
  • стендап митинге;
  • бэклог-е;
  • парном программировании;
  • ректроспективе;

то вам рассказывают о еще одной процессной методологии. Не Agile. Методология может быть сколько угодно эффективной, но не Agile.

Если же вам рассказывают о людях и коммуникациях:

  • фильтрах на вход и на выход;
  • информационных сквозняках;
  • “Тихой гавани”;
  • “Информационном радиаторе”;

То перед вами один из вариантов Agile.

Это легко прочесть, но трудно принять. Современный нам рынок легко принимает процессы и плохо людей.
———————————————————————–

Смотри:

Дополнительно:

  • http://intr13.ru/2010/02/28/560
  • http://itblogs.ru/blogs/bishop/archive/2010/02/20/58592.aspx
  • http://www.eldar.com/node/271