В этом году я осуществил свою мечту – начал кататься на горных лыжах (на картинке не я 
).
Прошлой зимой (начало 2009 года) у меня Дальше…
Итак, архитектура системы создана. Теперь необходимо воплощать полученные идеи в жизнь. Но торопиться здесь тоже не стоит.
Первоначально необходимо определить последовательность реализации требований. Первыми пойдут требования для построения разработанной архитектуры – будем строить скелет системы. Далее должны идти требования от наиболее важных к наименее важным. Для каждого требования должны быть созданы задачи на реализацию, а для каждой задачи должна быть проставлена оценочная трудоемкость реализации.
При планировании реализации не следует убеждать себя в том, что мы реализуем все требования в первой версии системы. Часто бывает, что появляются неучтенные факторы, которые отодвигают выпуск системы. К тому же часто заказчик системы на этапе сбора требований не всегда четко представляет конечный результат, а проверка реализации дает коррективы в требования. Так же возникают ситуации, когда требования меняются, например, из-за изменений в законах.
Чтобы упростить процесс разработки следует разбить весь проект на итерации. При этом каждая итерация должна продолжаться от одной до четырех недель (в зависимости от сложности подлежащих реализации требований). По итогам каждой итерации должно выполняться тестирование, а для ключевых выпусков (beta, release candidate) осуществляться демонстрация заказчику в целях получения отзывов о системе.
Теперь вернемся к программированию. Каждый программист получает задачу и приступает к ее реализации. Первоначально программист должен еще раз проверить оценочную трудоемкость и при необходимости откорректировать ее. Далее он должен реализовывать задачу в максимально короткие сроки с наивысшим качеством.
Что значит «реализовывать задачу в максимально короткие сроки с наивысшим качеством»? А значит это следующее:
Итак, задача реализована. Что дальше? Дальше наиболее оптимальным вариантом является проверка написанного кода тим-лидером или другим программистом (желательно, более опытным для проверки эффективности реализации, а менее опытному для повышения уровня). По результатам проверки задача может быть отправлена на доработку по замечаниям.
После реализации задачи она должна передаваться на документирование и функциональное тестирование.
Документирование подразумевает создание как минимум двух документов:
Функциональное тестирование состоит из:
По результатам проводимых тестов задачи могут отправляться на доработку или приниматься решение о выпуске стабильного или промежуточного дистрибутива системы.
Вот этот пост Андрея Колесова натолкнул меня на рассуждения о наших программистах.
Я уже достаточно давно начал руководить разработкой, но начинал простым программистом. По прошествии многих лет все ощущения от работы как программиста и как руководителя успели систематизироваться. Думаю, что сейчас я готов поделиться ими.
На самой заре 90-х прошлого века я занялся программированием как хобби. Это было интересно, увлекательно. Этакий драйв. Информации по программированию было недостаточно. Были программистские журналы, были какие-то книжки, но они давали лишь пример решения каких-то специфичных задач, а зачастую вообще ничего не давали – авторы писали «мусор». Поэтому у меня все задачи, которые я себе ставил, носили скорее исследовательский характер. При решении этих задач я часто изобретал «велосипед».
Следует отметить, что желание стать профессиональным программистом сподвигло меня на поиск интересной специальности для обучения в институте (на самом деле, в университете). Мне как раз стало интересно направление систем автоматизированного проектирования (САПР) – перспективное, сложное и интересное направление. Реклама сотрудников института сработала и я поступил на соответствующий факультет. Но правда жизни оказалась не такой радужной – на факультете САПР готовили не программистов, а инженеров, которые иногда могут автоматизировать свои расчеты в этих системах САПР. Какое же это было разочарование для меня! Итогом этого разочарования стало то, что я просто бросил институт, не окончив обучения.
Ближе к концу 90-х я занялся программированием профессионально. Это не значит, что до этого я был ламером – наоборот, технические знания были достаточно высокие. Просто я стал получать деньги за то, что так нравится.
Итак, устроившись на работу я попал в коллектив программистов. Вполне понятно, что ранее полученные знания были лоскутными и не давали полной картины, как можно их применять в реальной работе на реальных проектах. Именно эту информацию мне хотелось получить у своих коллег. К сожалению, ни достаточной культуры ведения проектов, ни хороших технических знаний я не нашел – все были почти такими же зелеными юнцами, как и я (при этом контора была одним из лидеров на рынке). В других организациях ситуация была, а зачастую и остается до сих пор такой же плачевной.
В этот момент я принял два ключевых решения для себя: продолжить обучение в институте именно по направлению программирования и самостоятельно обучаться всем премудростям программирования на основе открытых источников (книги и Интернет). Сказано – сделано: восстановился в институте, но на другом факультете, и начал впитывать и анализировать информацию отовсюду, откуда только было можно.
Обучение в институте показало, что в институте не готовят профессиональных программистов. Да, были занятия, которые корелировались с программированием (правда, в таком убогом виде, что это невозможно применять в реальности), а по методологиям разработки, можно сказать, вообще ничего не было (за исключением одного из предметов, но там было все настолько обще и скудно в теории, что на практике это, опять же, невозможно применять). В итоге, успешно окончив институт, я отказался от предложения поступить в аспирантуру – не видел, что она могла бы мне дать, да и что я мог бы принести реально полезное в нашу «науку». Ну а разочарование в нашей системе образования оказалось настолько огромным, что сильно сказывается и сейчас.
С самообразованием повезло значительно лучше – я профессионально вырос, мог выполнять работу архитектора. При этом изучил различные методологии (класса Agile и Rigorous – строгие), которые стал применять и адаптировать в своей команде. Как мне кажется, я получил очень хорошие знания и научился применять на практике знания от технических до методологических. Как это часто бывает с самообразованием, часто приходилось учиться на своих ошибках, но это лучше, чем ничего.
В процессе работы я часто сталкивался с тем, что в команду приходят новые люди. Зачастую, они оканчивали хорошие институты, да еще и с хорошими оценками. Но мое понимание текущей ситуации в образовании не позволяло все принимать за чистую правду – ни красный диплом, ни громкое имя ВУЗа не давали гарантии того, что реклама соискателя на рабочее место окажется правдой. В итоге приходилось выбирать наиболее адекватных (с необходимыми техническими знаниями, со способностью обучаться и с возможностью легко и бесконфликтно встроиться в рабочий коллектив). Ну а дальше начинался долгий процесс обучения и тонкой настройки.
Отдельно расскажу о тех, кто приходил ко мне на собеседования и не получил «счастливый билет». Самооценка у соискателей очень завышена (возможно, что в этом тоже виноват миф об «отличных русских программистах»). Зачастую, приходят совершенно неподготовленные люди, получившие базовые знания о языке программирования и верящие в то, что они могут творить чудеса. При этом они не могут выполнять работу в коллективе, не могут проанализировать задачу и затребовать недостающую информацию. Так же очень часто (около 90% от общего количества) встречаются и те, кто при недостатке информации или наличии противоречий в задании выбирает собственное решение, которое не согласовывает с коллегами (иногда после такого приходится очень долго выправлять ситуацию, чтобы устранить результаты такого «творчества»).
Исходя из выше сказанного я могу отметить основные параметры, по которым можно оценивать разработчиков, а начинающим (а иногда и профессиональным) разработчикам готовиться к взрослой жизни:
Видите, что я описал параметры для разработчиков, а не программистов? Дело в том, что разработчиком может быть как программист, так и тестировщик и архитектор, одним словом, создатель системы. Ну а данные параметры применимы ко всем – они универсальны.
Постоянно сталкиваюсь с такой проблемой: разработчики очень часто придумывают дополнительные задания для поставленных задач зачастую «додумывая» что-то вместо заказчика. При этом на такие дополнительные работы уходит иногда приличная доля времени.
Вот правила, которые я стараюсь донести до каждого члена команды разработки:
Очень часто я встречаю непонимание различий между командой и группой. В то же время эти различия принципиальны.
Итак, что же такое группа? Группа – это некоторое количество людей, выделенных для решения какой-то одной задачи. В группе каждому исполнителю может ставиться индивидуальная или групповая подзадача, которая входит в основную. Зачастую, каждый член группы ощущает себя индивидуалом и стремиться к решению поставленных перед ним задач.
Команда базируется на понятии группы, но каждый член команды осознает, что поставленные перед ним задачи важны не столько для него самого, сколько для решения единой общей задачи, поставленной перед командой.
Очень часто руководители ограничиваются созданием группы и не мотивируют создание единой команды. Это зачастую чревато огромной неэффективностью работы членов группы из-за плохой мотивированности на результате. В результате возможны срывы сроков, плохая коммуникация, неудовлетворительный результат и т.д.
Одной из главных задач руководителей является создание команды, т.е. мотивирование каждого члена группы на достижение поставленных задач именно перед группой. В данном случае личные результаты каждого члена группы будут менее приоритетны по сравнению с результатами группы (команды).
Что же необходимо сделать для создания команды?
Но создание команды – это треть дела! Самое главное – сохранить ее в процессе работы. Для этого необходимо поддерживать перечисленные выше задачи в актуальном состоянии, а так же выполнять дополнительную работу:
По данной теме советую так же почитать статью «Группа или команда?«.
Построение архитектуры следует начинать с анализа базовой функциональности (базовых требований). На основе этого необходимо определить наиболее подходящую модель архитектуры (обычно N-уровневая – N-layer, часто распределенная – N-tier). При этом следует учитывать, что Дальше…
Следующим шагом после анализа является фиксирование требований к системе и управление ими. Требования могут быть функциональные и нефункциональные.
Нефункциональные требования фиксируют Дальше…
Саша Ложечкин в своем посте «Массовый психоз Ajax» поднял вопрос о том, стоит ли использовать AJAX.
Не отрицаю, аббревиатура AJAX стала новым buzzword (модное маркетинговое словечко). Но в то же время, за ширмой этого buzzword все-таки присутствует довольно мощная технология, которая позволяет сделать сайт более привлекательным для пользователя.
К сожалению, аббревиатура AJAX не всегда правильно используется, часто AJAX-ом называют просто некоторую динамику на странице (мода, однако). Думаю, что есть необходимость дать некоторые пояснения по этой технологии.
Во-первых, что из себя представляет AJAX? AJAX – это возможность обращаться за данными без перезагрузки страницы. Для примера возьму страницу выбора страны и города в стране. Тут есть 3 способа реализации:
В результате получается небольшая нагрузка на веб-сервер, страницы быстрее работают и грузятся.
Во-вторых, AJAX предназначен для работы с данными: заполнение различных динамических форм, операции с данными на сервере. Если Вы используете AJAX для отображения какого-либо контента, то позаботьтесь о том, чтобы можно было получить доступ к данным и традиционным способом – через URL (например, версия для печати, которая будет открываться в отдельном окне с указанием URL прямого доступа и без динамики на странице).
В-третьих, AJAX использует технологии, которые часто достаточно сильно отличаются не только у различных производителей браузеров, но и в различных версиях браузера одного производителя. Позаботьтесь о пользователе, сделайте статичную версию страниц (у Google есть динамическая AJAX и статическия версии работы с почтой).
Пока присутствует война браузеров и отсутствует единое понимание производителей браузеров об объектной модели документов и применяемых технологиях, на AJAX можно ориентироваться лишь второстепенно. Основным способом разработки все-еще остается старая добрая технология работы через отправку запроса веб-серверу без использования AJAX.
PS: Саша упомянул в конце поста о смартклиентах, как об основной альтернативе AJAX в плане обеспечения динамичной работы. На мой взгляд, некорректно сравнивать две разные технологии, которые не пересекаются. Да, они несколько похоже решают некоторый задачи обработки данных, но основа у них разная, разные задачи они решают: веб-среда позволяет получить доступ с любого компьютера и работать с некоторыми ограничениями, а Win-среда позволяет сделать rich-интерфейс (функционально наполненный), но не всегда легко переносимый.
После разделения системы на модули и определения функциональной наполненности каждого модуля, необходимо понять, каким образом будет действовать каждый модуль.
Для каждого модуля описываются процессы, происходящие при выполнении каждой функции, описываются взаимодействия с другими функциями этого модуля и другими модулями системы, определяются роли пользователей, их отношение к функциям модуля.
Процессы, происходящие при выполнении каждой функции, должны описываться стандартным текстом (usecase) и могут сопровождаться рисунками и диаграммами, поясняющими происходящие действия.
При создании рисунков и диаграмм я советую рисовать помимо самого процесса еще и взаимодействие пользователя с системой (указывается роль, воздействующая на систему или получающая воздействие от системы) и документы или другие бизнес-сущности (входящие, исходящие, модифицируемые внутренние).
Если при анализе становится понятным, что какие-то функции дублируются в рамках системы в целом, то это верный признак необходимости реорганизации (оптимизации) бизнес-процессов в организации.
После проведения анализа должны получиться следующие результаты:
Нашел достаточно занятный каталог схем баз данных для конкретных решений. Если предметная область неизвестна или мало известна, но хочется посмотреть имеющиеся реализации, то вам туда.
