1081

Управление Проектом / Re: Литература по управлению проектами

« : 22 Января 2008, 15:08:27 »

Вот сообщество ЖЖ ru_pm запостило список книг по УП:
http://community.livejournal.com/ru_pm/87277.html

По-моему, перемудрили они с этой высокотехнологичной картой. Я лучше по-старинке, списками книг и аннотациями буду пользоваться.

1082

Тестирование / Re: Место тестирования в процессе разработки ПО

« : 10 Января 2008, 19:07:33 »

В вашем случае вы поимели больше проблем от TDD, чем +? Т.е. если есть тесты и приложение заточено только на них, то TDD подходит как никогда. Если же придется потом изменять приложение, то проблем будет больше?! Так?

Я бы только не стал сразу обобщать наш опыт на другие проекты. Все проекты разные, и везде разные риски.

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

Вместо этого мы сделали то, что должны были сделать с самого начала: официально получили необходимые спецификации и начали их грызть, приводя приложение в соответствие не тестам, но требованиям. При этом денежки с установки терминалов, прошедших сертификацию, нам уже капали.

Так что в данном конкретном проекте - TDD не панацея и не может быть принято в качестве базового метода, но иногда вполне оправдывает себя в тактических целях.

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

1083

Тестирование / Re: Место тестирования в процессе разработки ПО

« : 10 Января 2008, 13:14:43 »

Как показал опыт - если пользователи сами будут выгребать ошибки, то это будет происходить постоянно.

Нет, только до тех пор, пока они не найдут другого поставщика.

Может поговорим тогда о Test Driven Development?

Далеко не везде применимо. AgileRussia проводили в прошлом году семинар по TDD. Я после него поразмышлял немного и обнаружил (!), что мы-то, оказывается, такой метод уже применяли!

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

Приведу пример, чтобы было понятнее, о чём речь. В стандарте EMV есть специальный тэг - PAN sequence number, который записывается на карту и не изменяется до конца её жизни. Обычно, когда вы открываете карточный счёт в банке и получаете карточку, значение этого тэга выставляется в 1. Когда срок действия карты заканчивается, вам выпускают новую карту с тем же номером, а значение этого тэга увеличивают на 1. Так в теории. На практике же возможны ещё такие варианты: номер тэга всегда выставлен в 0, либо этот тэг вообще отсутствует (не записан на карту). На самом деле, в реальной жизни вариантов ещё больше (например, значение тэга выставлено в FFFF, что вообще не соответствует спецификации EMV).

Поведение терминала в этих случаях должно различаться - если тэг есть и выставлен в 0, его так и нужно посылать со значением 0. Если тэга нет вообще, то и посылать его не нужно (кажется очевидным, но количество возможных вариаций на эту тему потрясает, из-за чего, видимо, в MasterCard и придумали соответствующие тесты).


Так вот, о TDD. Проходя очередную сертификацию, мы "подгоняли" поведение терминала под критерии прохождения всех тестов MasterCard. То есть занимались практически чистым Test-Driven Development - вместо глубокого и детального изучения спецификаций (а на это в области смарт-карт реально полжизни можно угробить, к тому же они непрерывно изменяются) извлекали "требования" непосредственно из тестов. Отличие только в том, что тесты разрабатывали не мы сами, а получали их от авторитетного источника.

Сертификацию прошли успешно, но выявились следующие проблемы:
- сертификация, пройденная в одном банке, совершенно не гарантирует успешного прохождения сертификации в другом банке - набор тестов будет несколько другим, и опять придётся править приложение "на лету", что, вообще говоря, противоречит сертификационной процедуре;
- кое в чём требования MasterCard не совпадают с требованиями, например, VISA - и приложение, "заточенное" под тесты Master Card, может не пройти визовские тесты (что будет очень неприятным сюрпризом для банка, и ещё более неприятным для нас, особенно если десятки или сотни терминалов уже установлены в точках);
- ну и, как предсказывает TDD, появляется тот самый "вонючий" код, который очень трудно сопровождать. А рефакторинг сертифицированного приложения - это очень и очень муторное занятие (а сертификатами оно обкладывается по полной программе, и при этом каждый сертифицирующий орган свято уверен, что любое изменение в приложении требует его повторной сертификации).

1084

Управление Проектом / Re: Про проектный офис :-)

« : 09 Января 2008, 17:16:37 »

Да уж, даже с т.з. эргономики там все не ладно :-). Но меня поражает другое -- эта организация, претендует на интеграцию всего ИТ Газпрома! И в то же время демонстрирует отсутствие элементарной компетенции в вопросах управления проектами. Глядя на это меня посещают грустные мысли -- о том насколько неэффективны инвестиции в ИТ в госсекторе и окологосударственных структурах. И конечно вопрос квалификации кадров, работающих в этом секторе. ... А за эту неэффективность я плачу в виде тарифов на газ/электричество/...

Казалось бы, при чём тут нанотехнологии...

Впрочем, здесь не политический форум.

1085

Бизнес-анализ и Целеполагание / Re: Обещанная статья про целеполагание

« : 28 Декабря 2007, 12:43:39 »

Сумбурный текст со скандальным названием "Из жизни проктологов"

Почему сумбурный? Чувствуется, что написано на одном дыхании, читается легко, и всё понятно.

1086

xP Xd Agile ICONIX пр. / Re: Agile and Iterations

« : 26 Декабря 2007, 19:24:00 »

Скорее всего, "человек, считающий себя экспертом Agile", держит в голове какие-нибудь интернет-проекты, в которых путь от разработчика до "продакшена" ограничивается двумя панелями в Total Commander. В этой сфере, как я понимаю, вообще часто принято работать "с колёс".

Я вот сейчас параллельно работаю над тремя приложениями: 1) одно для POS терминала, 2) одно серверное, и 3) наш project tracker на PHP.

Для 3-го варианта завершение итерации с выходом на "продакшн" абсолютно допустимо - покодил чуть-чуть на своём лэптопе, убедился, что фича работает, и тут же выложил. Риски минимальны, заказчик внутренний, код простой и легко читаемый - никакого формализма. И что характерно, так было с самого начала проекта - на разработку самой первой версии (учёт текущих задач) ушла примерно неделя, без оформления Vision и разработки архитектуры. Очень уж простое приложение.

Для 2-го - невозможно в принципе, после минимальных изменений в коде его нужно очень тщательно тестировать (чем мы весь последний месяц и занимаемся), и само понятие итерации становится очень расплывчатым. (Помнится, Асхат Урузбаев говорил, что характерный признак Agile - короткие итерации).

Для 1-го допустимо с оговорками, что понимать под "продакшеном". Я в любом случае отправляю приложение заказчику, так что для меня недельная итерация завершена, а вот что он с ним будет делать - гонять на тестовом терминале или сразу заменять софт в нескольких сотнях терминалов - две очень большие разницы.


В общем, каждому проекту - индивидуальный подход (или, как говорил нам бригадир в трудовом лагере на прополке, "каждому кустику поклониться надо" ).

1087

Бизнес-анализ и Целеполагание / Re: Вопрос по "оригинальной методике бизнес моделирования" от автора Е.Б. Золотухина

« : 25 Декабря 2007, 18:37:07 »

Ничего не понял

Я всё жду - не дождусь, когда же появятся переводчики на базе нейросистем. ИМХО, технически уже вполне реализуемо.

1088

Управление Проектом / Re: Руководитель проекта, как им стать?

« : 25 Декабря 2007, 17:10:32 »

Вставлю и я свои две копейки.

Меня в работе ПМ раньше ничто не привлекало. Вообще. Когда оказалось, что дальнейшее развитие компании невозможно без выделения некоторой руководящей и организующей роли (это я сейчас так красиво выражаюсь, в то время я и слов таких не знал), эту роль возложили на меня. Не освободив при этом от собственно программистской деятельности.

Года два я пребывал в состоянии стресса, отстаивал свою позицию программиста, ругался с директором и серьёзно подумывал о смене работы (не ушёл только потому, что меня вовремя подсадили на крючок кредита на квартиру). Ни навыков, ни знаний, ни даже общего представления о руководстве проектами у меня не было (то есть были, конечно, дилетантско-технарские "представления", о которых смешно сейчас вспоминать). И вот только в последний год, после прочтения увесистой стопки книг, посещения семинаров (исключительно бесплатных ), общения на форумах, среди которых этот занимает сейчас, пожалуй, первое место, я начал, наконец, понимать, что примерно нужно делать - и работать снова стало интересно.

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

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

1089

Системный Анализ и Требования / Re: Управление требованиями

« : 19 Декабря 2007, 14:51:56 »

Стоит только начать попытки её применять - как обнаруживаюся дыры,
при попытке самостоятельно залатать которые сильно рискуешь попасть на подозрение в ереси и неуважении мировых Гуру.

Поправочка: подозрение в неуважении к мировым Гуру со стороны их фанатичных последователей. Сами Гуру, как правило, постоянно оговариваются в стиле "марксизм - не догма, а руководство к действию".

Я, кстати, все разновидности стрелочек UML лично для себя, извините за выражение, похерил. Если я пытаюсь кому-то что-то объяснить с помощью диаграммы, я не могу полагаться на то, что он понимает значение всех типов наконечников стрелок всех версий UML, а демонстрация собственных знаний обычно не является моей целью. Поэтому рисую, какие придётся - главное убедиться, что собеседник в этот момент понимает их назначение так же, как я.

1090

Сообщество Аналитиков / Re: Личные сайты и блоги посетителей сайта

« : 19 Декабря 2007, 12:10:33 »

Личный сайт у меня есть, www.greesha.ru, но с его форматом я пока не определился. Скорее всего, буду издавать что-то вроде персональной газеты. Руки вот только не доходят довести движок до ума. А пока там висит наполовину выполненный совместно с Galogen'ом перевод глоссария OpenUp.

Блог завёл на it4business, но активно его не веду:
http://it4business.ru/forum/index.php?automodule=blog&blogid=60&

1091

Варианты Использования (Use Case) / Re: Что такое вариант использования или прецедент

« : 18 Декабря 2007, 18:28:22 »

граф (в математике) — объект, состоящий из вершин и соединяющих их ребер.

С третьего курса помню: "граф - это совокупность множества с заданным на нём бинарным отношением".

1092

Варианты Использования (Use Case) / Re: Что такое вариант использования или прецедент

« : 18 Декабря 2007, 18:13:05 »

Ха! Множества... А вот кто может сходу дать математическое определение графа, а, аналитики? А ведь весь UML, по сути, сводится к набору графов.

1093

Обучение / Re: Подскажите курсы для системных аналитиков

« : 14 Декабря 2007, 16:21:07 »

У меня сразу два вопроса:
1. Сколько дней курс за 300 евро без НДС, это за всю группу или, если за человека, то какой размер группы?
2. Чего ждете от курса? Я посмотрел на содержание тренинга от ТЕКАМА - это все есть в литературе. А получить-то что хотите кроме систематизации знаний? Что поднять? Может, правда вам коучинг нужен?

1. Это за человека. Минимальный размер группы, как мне написал Петелин - 5 человек.

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

Всё это можно сделать из без тренинга, но при этом "хождение по граблям" будет более длительным.

1094

Обучение / Re: Подскажите курсы для системных аналитиков

« : 10 Декабря 2007, 17:43:05 »

Сходили наши тестировщики на курсы Люксофт. Им не очень понравилось: курсы учебный центр проводит для своих сотрудников, добавляя в группу обучаемых "со стороны". Ну, нравится-не нравится, а пользу я уже чувствую - по крайней мере, у них появились осмысленные вопросы и замечания к нашему баг-трекеру. Так что я считаю, что время потрачено не зря.
Но ближайший курс для аналитиков, как я говорил, у них назначен на апрель, а мы так долго ждать не можем.

С ТЕКАМА, как я тоже уже говорил, у нас не сложилось: заставлять сотрудников тратить выходные дни на обучение мы не будем.

С Денисом Петелиным списались. Интересная получается ситуация: во-первых 300 у. е. за курс  - это в евро (ну, это сейчас нормально), во-вторых, цена указана без НДС (уже не так нормально), в-третьих, оказывается за проведение обучения в специально выделенном классе нужно платить 500 у. е. в день (это, как я понял, тоже без НДС). Условий же для проведения занятий в собственном офисе у нас нет.

В общем, некуда деваться маленькой компании с ограниченным бюджетом. Алчные консалтеры  настроены на доение крупных клиентов (что характерно, я их за это не виню - а думаю, может, самому в консалтеры податься?)

Придётся мне, видно, тряхнуть стариной и самому прочитать курс лекций для наших спецалистов.

1095

Работа / Re: Кто где работает территориально?

« : 07 Декабря 2007, 11:52:13 »

Едете из Королева или из Юбилейного?

Из Мытищ, с Тайнинской.