usecase.ru – вариант использования

В статьях Проектирование бизнес-приложения: Анализ и Проектирование бизнес-приложения: Анализ 2 я показал подход к возможному способу анализа функциональности системы. Теперь следует более подробно осветить этот процесс на основе примера.

Возьмем для примера интернет-магазин по продаже книг для небольшого издательства.

От заказчика (коммерческого директора Василия) поступило следующее письмо:

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

Данное письмо подразумевает выполнение первого этапа работ – анализ потребностей заказчика и формирование технического задания (ТЗ). Любая работа требует организации и контроля. Для этого руководитель подразделения, где обитают разработчики, аналитики и другие спецы, назначает руководителя проекта. Руководитель проекта формирует команду проекта.

В команду проекта должны войти следующие роли:

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

Рассмотрим работу самой главной роли на этапе анализа – работу аналитика.

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

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

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

В результате наших первых встреч с рабочей группой был получен документ по следующему шаблону: Шаблон документа-концепции

После согласования первой версии документа необходимо по полученным высокоуровневым параметрам системы подобрать бесплатные или коммерческие аналоги системы. Если аналог найден, то задача в некоторой степени упрощается – далее будет производиться внедрение системы и ее настройка под требования заказчика. Если удовлетворяющего аналога нет или стоимость и/или трудоемкость внедрения превысит стоимость и трудоемкость разработки своими силами, то принимается решение о разработке новой системы или отказ от системы вообще.

6 февраля 2010, в субботу в Москву приехала культовая группа Depeche Mode. Приехала, естественно, чтобы порадовать своих фанатов. В очередной раз…

В девяностые группа Depeche Mode покорила весь мир своей музыкой – на звездном небе зажглась новая супер-звезда. Россия не стала исключением – здесь группа завоевала особую популярность. Открывшиеся в начале девяностых ворота советской цензуры, появившиеся альтернативные советско-попсовому стилю радиостанции позволили осуществить массированный удар по умам (и ушам) слушателей. В этот момент слушателям открылись такие альбомы, как Black Celebration, Music for the Masses и просто культовые Violator и Songs of Faith and Devotion. Такая популярность породила даже несколько групп, имитирующих неповторимый саунд Депешей (например, группа Технология).

Девяностые были моей юностью. Я, как и многоие другие, полюбил Depeche Mode за их неповторимую, ни на что не похожую музыку. Я и сейчас несу в себе эту любовь. Не до фанатизма, нет. Но очень глубоко и сильно.

Предыдущие три концерта я не посещал. Уже и не помню по каким причинам. Ну а в прошлом году, как только узнал (март или апрель 2009 года), что Depeche Mode в очередной раз приезжают в Москву, прожужжал все уши жене… В итоге, все попытки заиметь заветные билетики мягко пресекались моей супругой, а на день рождения был сделан подарок в виде двух заветных кусочков бумаги с голограммой и штих-кодом. Сразу крышу не снесло… Видимо, на фоне долгого ожидания и текущих жизненных активностей не сразу дошло до головного мозга, что впереди предстоит такое эпохальное событие. А может это связано и с возрастом и складом ума – почти перестал удивляться пожизни, трезво оценивая любое событие. Но накануне концерта, начиная с вечера пятницы, пошел процесс выброса адреналина и эндорфина в кровь.

Настал вечер концертного дня. В 18:00 решили поехать на концерт на машине – жена не восприняла мои доводы, что лучше ехать на метро по ряду причин. Москва была свободная, машин практически не было. Но не в районе Олимпийского! Я решил поехать через Цветной Бульвар, т.к. ехали через центр города - это была грандиозная ошибка. Цветной стоял почти мертвяком. Олимпийский проспект тоже. Все ехали на концерт. Это было видно по лицам водителей и пассажиров.

С горем пополам добрались до Олимпийского. Встала новая проблема – где припарковать машину. Я вспомнил, что напротив театра Дурова есть площадка, на которой можно оставить машину. Вспомнил, как оказалось, не я один – вся площадка была заставлена машинами. Чудом удалось найти свободное местечко в сугробе какого-то импровизированного тупичка, где и была оставлена наша машина.

Трансфер от машины до места на трибуне не вызвал каких-либо трудностей. По пути заметил, что милиционер с мегафоном ходил вдоль длиннющей очереди у пятого подъезда и говорил: «Все владельцы билетов пятого подъезда могут пройти через третий». На очередь эта фраза никакого действия не оказывала. Мы же развернулись и направились к третьему подъезду, где прошли без очереди.

На местах в зале, вернее на трибуне, оказались примерно в 19:45. Уже доигрывала какая-то группа на разогреве (название так и не разобрал). По стилю некоторых песен было чем-то похоже на Depeche Mode девяностых. Около восьми разогревайщики распрощались с публикой и отправиличь восвояси. На сцене начали копошиться техники, подготавливая оборудование к депешам. Подготовили достаточно быстро, т.к. вскоре за работу принялся какой-то диджей, крутивший музыку вплоть до выхода депешей, в то время, как публика откровенно скучала и требовала «продолжения банкета».

С выходом коллектива зал взорвался! Шоу началось!

Первые композиции, те, что из новых, как-то не особо радостно были встречены публикой – активность проявляла только фан-зона, да и то как-то вяло. Все переменилось  началом Walking In My Shoes – сразу стало понятно, что народ пошел на старых депешей. Это ощущение усиливалось с каждой новой и каждой старой песней – новые встречались прохладно, а старые разрывали зал бурей эмоций. Похоже, депеши поняли и смирились с тем, что их более ранее творчество вызывает у публики более острые, бурные эмоции.

Стоит отметить, что на трибунах находились в основном зрелые люди – от 30 и старше. Сразу было видно, что это старая гвардия, такая же, как и я сам. И при этом эти люди вытворяли такие чудеса!… Трибуны поднималдись в едином эмоциональном порыве, аплодировали, танцевали и подпевали. Просто восхитительное зрелище!

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

Одним словом, организация концерта была не на высоте. К тому же нас еще час минимум продержали в пустом зале на трибунах – ждали пока танцпол разойдется. Т.к. дело было вечером, а делать было нечего, то народ стебался по полной! На танцпол один за другим с пятиминутным перерывам вылезли два транспортера, которые были встречены бурными овациями и криками трибун.

Несмотря на минусы, у меня останется в памяти данный концерт с положительнвми эмоциями- сбылась многолетняя мечта, увидел кумиров своей молодости.

Произвел небольшую реорганизацию на блоге. Теперь есть две рубрики – «О жизни» и «Разработка ПО», которые заимели свои поддомены http://life.usecase.ru/ и http://dev.usecase.ru/ соответственно. Основной http://www.usecase.ru/ будет содержать обе рубрики.

В первой рубрике я буду публиковать то, что меня волнует, но не связано с работой. Во второй же буду писать исключительно о делах околопрограммистских – от разработки до управления разработкой. Так же в дальнейшем я могу дополнить список рубрик интересующими меня темами.

В этом году я осуществил свою мечту – начал кататься на горных лыжах (на картинке не я ).

Прошлой зимой (начало 2009 года) у меня возникло желание научиться кататься на горных лыжах – друг зажег огонек на новогодние праздники. Некоторое время ушло на изучание вопроса с теоретической точки зрения. Далее начал выбирать оборудование, ища информацию в Интернете, советуясь с друзьями и знакомыми. Процесс этот затянулся, да и погода была «не айс». В итоге отложил все до следующего сезона.

Осенью 2009-го на работе знакомые предложили купить абонемент на сезон в один из подмосковных «горнолыжных» клубов – Волен, который расположен совсем недалеко от моей дачи. И тут началось…

Абонемент был куплен практически не раздумывая. Ну а раз на абонемент были потрачены достаточно немалые деньги, то уже не оставалось раздумий о необходимости покупки оборудования – покупать! И не раздумывая!

На свой день рождения поехал в Спортмастер покупать лыжи (за несколько дней до этого видел там горные лыжи, ботинки, крепления и т.п.). Приехал… посмотрел… поговорил с консультантами… и купил лыжи! При этом почему-то на купленные лыжи не оказалось креплений и моего размера ботинок. «Да фигня», - подумал я, – «куплю в другом месте» . Не тут то было – крепления отдельно от лыж не продавались, ботинки обязательно надо мерять, чтобы подошли по жесткости и размеру.

По рекомендации друга был выбран магазин Кант, куда я направился посмотреть крепления и ботинки. Под действием магии расставленного обрудования я решился на покупку полного комплекта оборудования в этом магазине не смотря на наличие уже купленного комплекта лыж. Итак, купил лыжи, крепления, ботинки, палки и маску. Причем, лыжи обошлись дешевле, чем в Спортмастере. Попутно были куплены два комплекта беговых лыж для родственников – подарок на Новый Год. Ставший уже ненужным комплект лыж был отвезен обратно в Спортмастер, где был сдан без проблем.

Итак, первые два шага были сделаны (абонемент и оборудование). Теперь осталось приступить к обучению. Слава Богу, перед Новым Годом выпал обильный снег, установилась морозная погода.

Сразу после празднования Нового Года на даче была осуществлена вылазка в Волен (жена, дочка и другие родственники остались на даче, чтобы не видеть моего позора). Нет, первого числа был отходняк… Второго тоже… Третьего января я рано утром, около 9:00 приехал в Волен, где стал искать инструкторов. Девушка-администратор, сидевшая с инструкторами, почему-то направила меня в Степаново, посмотрев на мой скипасс (тот самы абонемент). Думаю, ну ладно, поеду в Степаново (дополнительный крюк в несколько килиметров по дороге, не внушающей доверия – узко, скользко, с плохим покрытием и крутыми поворотами).

В Степаново мне объяснили, что скипасс единый на Волен и Степаново – одна контора. Среди инструкторов был найден первый свободный – Андрей и оплачен час занятий. На учебном склоне я понял, что теоретическая подготовка хорошо, но практика ничего не заменит. За час занятий я вспотел как в дикую жару, подвернул ногу, получил несколько падений и долгожданную практику правильного управления лыжами. Зато сколько удовольствия!

Ногу я подвернул прилично – в ближайшие два дня почти не ходил. По этой же причине было отложенно следующее посещение «горнолыжного» курорта и занятия с инструктором.

Пятого января утром я чувствовал себя лучше, поэтому поехал продолжать обучение. Этот день я провел уже не на учебном склоне, а на реальных склонах, хоть и небольшой сложности. В первый раз спускаться было стрёмно. Потом попривык. Падал во время спуска достаточно часто, остобенно в начале. Потом освоился и стало получаться все лучше и лучше. Инструктор закончил вливание в меня очередной порции правильного поведения на лыжах, после чего я остался покататься еще – закреплять успехи.

Успехи дали свои плоды – нога опять отказалась ходить. На лечение были брошены все имеющиеся силы – жена, медикаменты и относительный покой.

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

Он потащил меня на склон средней сложности. Стоя наверху и глядя на достаточно крутой для меня склон, я вспомнил все нецензурные слова… в том числе и вслух (вспомнил ролик из интернета «Славик незаменим»). Мондраж перед неизвестным продолжался относительно долго, но я себя пересилил и начал спускаться. Ура! После этого спуска было уже не страшно. Первые несколько спусков, естественно, не обошлись без падений. Несколько раз падал так, что лыжи отстегивались. Но в итоге, склон был покорен!

Дальше я стал кататься в свое удовольствие, наращивать технику. С каждым разом все уверенней и уверенней. От этого удовольствие еще больше росло.

Мои успехи в покорении подмосковных «гор» достатоно скромны – как ни как совсем начинающий, но я чувствую, что уже не смогу без этого жить – рвусь каждые выходные покататься. Несколько огорчают морозы, при которых не особо комфортно кататься (-15 вполне нормально переносятся, а более низкая тепература совсем некомфортна).

До конца сезона планирую поднять технику до приличного уровня, а на следующий рвануть в настоящие горы с друзьями.

Итак, архитектура системы создана. Теперь необходимо воплощать полученные идеи в жизнь. Но торопиться здесь тоже не стоит.

Первоначально необходимо определить последовательность реализации требований. Первыми пойдут требования для построения разработанной архитектуры – будем строить скелет системы. Далее должны идти требования от наиболее важных к наименее важным. Для каждого требования должны быть созданы задачи на реализацию, а для каждой задачи должна быть проставлена оценочная трудоемкость реализации.

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

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

Теперь вернемся к программированию. Каждый программист получает задачу и приступает к ее реализации. Первоначально программист должен еще раз проверить оценочную трудоемкость и при необходимости откорректировать ее. Далее он должен реализовывать задачу в максимально короткие сроки с наивысшим качеством.

Что значит «реализовывать задачу в максимально короткие сроки с наивысшим качеством»?  А значит это следующее:

1. Программист должен сосредоточиться на одной задаче и целиком посвятить себя ей до завершения работ. Редкие люди могут делать одновременно два дела, а частое переключение не позволяет работать эффективно.
2. Программист не должен самостоятельно додумывать нечетко описанные требования или задачи – для этого есть аналитики и архитекторы, в обязанность которых входит получение однозначных, непротиворечивых и полных требований к системе.
3. Если поставленная задача не является типовой, то ее следует обсудить в команде разработки (например, за чашкой чая) – часто кто-нибудь уже реализовывал подобную задачу в своей практике или знает уже частично или полностью реализованное решение (часто бывает проще купить какой-то компонент, чем изобретать велосипед и платить за это лишние деньги).
4. Когда выбран вариант реализации, то его следует обсудить с архитектором и коллегами по команде, т.к. иногда решение может не вписываться в архитектуру или негативно влиять на соседние компоненты системы, разрабатываемые коллегами.
5. Реализация задачи должна обязательно сопровождаться тестирование. Наиболее эффективном способом является автоматизированное юнит-тестирование (unit tests) и проверка покрытия кода (code coverage). Но и о ручной проверке так же не следует забывать, т.к. не всегда программист может учесть в юнит-тесте всю необходимую проверку.

Итак, задача реализована. Что дальше? Дальше наиболее оптимальным вариантом является проверка написанного кода тим-лидером или другим программистом (желательно, более опытным для проверки эффективности реализации, а менее опытному для повышения уровня). По результатам проверки задача может быть отправлена на доработку по замечаниям.

После реализации задачи она должна передаваться на документирование и функциональное тестирование.

Документирование подразумевает создание как минимум двух документов:

1. инструкции пользователя – полное руководство по использованию системы с точки зрения пользователя.
2. инструкции администратора – полное руководство по установке, настройке и поддержанию системы в работоспособном состоянии.

Функциональное тестирование состоит из:

1. Создания тестов для проверки требований. Обычно создаются комплексные тесты, проверяющие несколько требований.
2. Проверки инструкций на достаточность, легкую воспринимаемость и соответствие требованиям и тестам.
3. Проведение тестов по установке, настройке и использованию системы.

По результатам проводимых тестов задачи могут отправляться на доработку или приниматься решение о выпуске стабильного или промежуточного дистрибутива системы.

Вот этот пост Андрея Колесова натолкнул меня на рассуждения о наших программистах.

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

На самой заре 90-х прошлого века я занялся программированием как хобби. Это было интересно, увлекательно. Этакий драйв. Информации по программированию было недостаточно. Были программистские журналы, были какие-то книжки, но они давали лишь пример решения каких-то специфичных задач, а зачастую вообще ничего не давали – авторы писали «мусор». Поэтому у меня все задачи, которые я себе ставил, носили скорее исследовательский характер. При решении этих задач я часто изобретал «велосипед».

Следует отметить, что желание стать профессиональным программистом сподвигло меня на поиск интересной специальности для обучения в институте (на самом деле, в университете). Мне как раз стало интересно направление систем автоматизированного проектирования (САПР) – перспективное, сложное и интересное направление. Реклама сотрудников института сработала и я поступил на соответствующий факультет. Но правда жизни оказалась не такой радужной – на факультете САПР готовили не программистов, а инженеров, которые иногда могут автоматизировать свои расчеты в этих системах САПР. Какое же это было разочарование для меня! Итогом этого разочарования стало то, что я просто бросил институт, не окончив обучения.

Ближе к концу 90-х я занялся программированием профессионально. Это не значит, что до этого я был ламером – наоборот, технические знания были достаточно высокие. Просто я стал получать деньги за то, что так нравится.

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

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

Обучение в институте показало, что в институте не готовят профессиональных программистов. Да, были занятия, которые корелировались с программированием (правда, в таком убогом виде, что это невозможно применять в реальности), а по методологиям разработки, можно сказать, вообще ничего оне было (за исключением одного из предметов, но там было все настолько обще и скудно в теории, что на практике это, опять же, невозможно применять). В итоге, успешно окончив институт, я отказался от предложения поступить в аспирантуру – не видел, что она могла бы мне дать, да и что я мог бы принести реально полезное в нашу «науку». Ну а разочарование в нашей системе образования оказалось настолько огромным, что сильно сказывается и сейчас.

С самообразованием повезло значительно лучше – я профессионально вырос, мог выполнять работу архитектора. При этом изучил различные методологии (класса Agile и Rigorous – строгие), которые стал применять и адаптировать в своей команде. Как мне кажется, я получил очень хорошие знания и научился применять на практике знания от технических до методологических. Как это часто бывает с самообразованием, часто приходилось учиться на своих ошибках, но это лучше, чем ничего.

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

Отдельно расскажу о тех, кто приходил ко мне на собеседования и не получил «счастливый билет». Самооценка у соискателей очень завышена (возможно, что в этом тоже виноват миф об «отличных русских программистах»). Зачастую, приходят совершенно неподготовленные люди, получившие базовые знания о языке программирования и верящие в то, что они могут творить чудеса. При этом они не могут выполнять работу в коллективе, не могут проанализировать задачу и затребовать недостающую информацию. Так же очень часто (около 90% от общего количества) встречаются и те, кто при недостатке информации или наличии противоречий в задании выбирает собственное решение, которое не согласовывает с коллегами (иногда после такого приходится очень долго выправлять ситуацию, чтобы устранить результаты такого «творчества»).

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

1. Разработчик должен понимать, что разработка – это не только умение программировать, но и коллективная работа. От каждого конкретного разработчика зависит общий успех проекта. В данном случае действует правило: подвел один – пострадали все.
2. У разработчика должен быть внутренний стимул к самостоятельному развитию, обучению. Нет ничего хуже, если человек остановился в развитии и не пытается получать и активно применять информацию в работе.
3. Необходимо знать, какие методологии используются при разработке (класса Agile и Rigorous – строгие, например RUP или MSF). Просто знать названия недостаточно, необходимо понимание самих процессов в команде и какие документы должны готовиться при этом. Следует так же учитывать, что в каждой команде присутствует своя адаптация того или иного процесса разработки (хуже, когда ее нет).
4. Необходимо понимать, что в большинстве случаев поставленная задача или уже была решена кем-то в подобной ситуации, или при решении задачи можно использовать уже разработанное другими (дополнительные компоненты и фрэймворки). Чтобы не изобретать велосипед, необходимо посоветоваться с коллегами (может, кто припомнит какое-либо решение, свое или чужое), изучить внутреннюю документацию по проекту или поискать в Интернете.
5. Иногда определенное решение задачи может повлиять негативно на другие компоненты разрабатываемой системы. Чтобы измежать этого, требуется обязательно консультроваться с разработчиками «соседних» компонентов и архитекторами на предмет совместимости решения и системы.
6. Если разработчик делает оценку задачи, то он должен всестронне проанализировать ее. При этом должны быть определены риски (придуманное в первом приближении решение может не удовлетворять требованиям к производительности или новая технология может сильно затянуть разработку или вообще остановить ее) и пути их устранения, основные направления решения и альтернативные варианты, каким образом будет проводиться тестирование. Часто разработчик оценивает некий идеальный вариант, даже не закладывая время на тестирование и отладку. Из-за этого он срывает сроки и подводит своих коллег.
7. После выполнения задачи любой разработчик должен проанализировать результаты своей работы и сделать выводы. Иногда, полученное решение является удовлетворительным на текущий момент, но в дальнейшем потребует переработки. Для этого можно вести список потенциально проблемных мест в решении, чтобы заранее предотвращать возможные негативные последствия, а не ждать, когда гром грянет.

Видите, что я описал параметры для разработчиков, а не программистов? Дело в том, что разработчиком может быть как программист, так и тестировщик и архитектор, одним словом, создатель системы. Ну а данные параметры применимы ко всем – они универсальны.

Постоянно сталкиваюсь с такой проблемой: разработчики очень часто придумывают дополнительные задания для поставленных задач зачастую «додумывая» что-то вместо заказчика. При этом на такие дополнительные работы уходит иногда приличная доля времени.

Вот правила, которые я стараюсь донести до каждого члена команды разработки:

1. Никогда не делайте работу сверх той, что определена заданием (я могу и не заплатить за такую «доработку»).
2. Если возникают неоднозначности или что-то непонятно, то обратитесь как можно раньше к тому, кто помог бы разрешить все вопросы (часто разработчик может неправильно «додумать» задачу).
3. После получения задания проконсультируйтесь с аналитиком или другим ответственным за требования лицом по поводу реализации, разрисуйте полностью свое решение, чтобы всем было понятно, что в результате получится (реализация должна соответствовать ожиданиям заказчика). Когда решение согласовано со всеми заинтересованными лицами, его можно задокументировать и приложить к проектной документации.

Очень часто я встречаю непонимание различий между командой и группой. В то же время эти различия принципиальны.

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

Команда базируется на понятии группы, но каждый член команды осознает, что поставленные перед ним задачи важны не столько для него самого, сколько для решения единой общей задачи, поставленной перед командой.

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

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

Что же необходимо сделать для создания команды?

1. Объяснить цели (стратегические, тактические, оперативные), которые команда достигает при решении поставленных задач.
2. Нацелить каждого члена команды на совместное решение поставленных задач.
3. Дать понимание всем членам команды того, что каждый из них является ответственным лицом за свои обязательства перед командой.
4. Обеспечить отличные способы коммуникации между членами команды (регулярные встречи, оперативные звонки и письма с оперативными ответами, частое личное общение и т.п.).
5. Дать понимание того, что в некоторых случаях исполнитель должен проявлять инициативу.

Но создание команды – это треть дела! Самое главное – сохранить ее в процессе работы. Для этого необходимо поддерживать перечисленные выше задачи в актуальном состоянии, а так же выполнять дополнительную работу:

1. оперативно решать возникающие проблемы,
2. регулярно получать состояние о продвижении в решении поставленных задач,
3. мотивировать различными способами активную работу членов команды (часто хватает поднятия морального духа сообщением о реальных успехах команды и ее продвижением в работах, так же хорошо действует персональное развитие и обучение каждого члена команды),
4. постоянно мониторить психологическое состояние каждого члена команды, предупреждая возникновение внутренних и внешних конфликтов.

По данной теме советую так же почитать статью «Группа или команда?«.

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

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

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

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

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

Нефункциональные требования фиксируют параметры приложения, которые не относятся к выполняемым им функциям – это обычно какие-либо технические характеристики: ограничение на какую-либо операционную систему, технологию, требования к интерфейсу и т.п.

Функциональные требования описывают функции системы и определяют ограничения на них. Они строятся на основе ранее проведенного анализа и первоначально могут полностью соответствовать результатам модульного анализа.

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

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

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

Для начала необходимо выявить базовые требования, без которых невозможно будет построить базовую архитектуру приложения. Обычно эти требования фиксируются и практически не изменяются до момента выпуска версии. Изменение данных требований зачастую может носить фатальные последствия для приложения и проекта в целом.

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

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

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