Отправляет email-рассылки с помощью сервиса Sendsay

Из программистов в руководители

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Бизнес с высокой прибылью" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Апрель 2005   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Автор
Симон Молдавский

Статистика

1.763 подписчиков
0 за неделю
←   Все выпуски   →

ИЗ ПРОГРАММИСТОВ В РУКОВОДИТЕЛИ #39: Новости, обзор технологий и глоссарий


Информационный Канал Subscribe.Ru
Из программистов в руководители
Выпуск 39: Новости, обзор технологий и глоссарий

Здравствуйте, уважаемые читатели нашей рассылки!

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

Сегодняшний выпуск рассылки получился легким и теплым, но при этом он не потерял своей актуальности и информативности. Вашему вниманию предлагается материал, который посвящен обновлению базы данных украинской индустрии ПО, и подробности про стратегическую игру "РАЗВИТИЕ ИНДУСТРИИ ПО", которую наша Ассоциация планирует провести 27-29 мая 2005 года в курортной зоне Конча-Заспа под Киевом.

Также сегодня мы расскажем Вам про Современные технологии разработки ПО.

Итак, приятного и легкого, весеннего чтения....

 

НОВОСТИ  
ОБНОВЛЕНИЕ БАЗЫ ДАННЫХ УКРАИНСКОЙ ИНДУСТРИИ ПО

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

В настоящее время в базе данных собрана информация о более чем тысяче организаций. Это и производители программного обеспечения, и иные организации, имеющие отношение к информационным технологиям.

Текущая версия базы данных доступна по адресу http://www.uaswd.org.ua/ru/db/

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

Для этого достаточно заполнить анкету в формате http://www.uaswd.org.ua/uaswd.doc и прислать ее в Украинской Ассоциации Производителей Программного Обеспечения (УАППО).

Всем остальным предоставляется шанс тоже поучаствовать в обновлении базы и даже получить призы от УАППО - каждый, кто пришлет в Ассоциацию информацию о софтверной компании, которой нет в базе данных, получит приз. Информация должна содержать название компании и адрес ее web-сайта.

Информацию об обновлении, заполненные анкеты и информацию о новых компаниях присылайте на адрес officeuaswd.org.ua

ПРОДОЛЖАЕТСЯ РЕГИСТРАЦИЯ НА СТРАТЕГИЧЕСКУЮ ИГРУ "РАЗВИТИЕ ИНДУСТРИИ ПО"

Продолжается регистрация на участие в стратегической игре "Развитие индустрии ПО", которая пройдет 27-29 мая 2005 года в курортной зоне Конча-Заспа под Киевом. Подробности об игре доступны на http://www.uaswd.org.ua/ru/news/222.html

По просьбам читателей о подробностях игры рассказывает исполнительный директор УАППО Симон Молдавский.

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

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

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

Зарегистрироваться можно по адресу officeuaswd.org.ua.
   

 

ОБЗОР ТЕХНОЛОГИЙ РАЗРАБОТКИ ПО

  

Беглый взгляд на XP

В мире программной инженерии существует масса методик разработки программного обеспечения. Среди них своей оригинальностью и несколько неформальным подходом выделяется экстремальное программирование (eXtreme Programming, XP).
Очевидно, что в рамках одной статьи невозможно подробно описать все тонкости методики, да и зачем, ведь для этого есть отличные книги Кента Бека (Kent Beck), основателя этой идеологии.

С чего начинается XP
XP начинается вовсе не с прыжков с парашютом, как может показаться из названия, а с простого понимания человеческих потребностей.

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

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

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

Как можно объединить все эти интересы воедино? Ведь времени всегда не хватает, менеджер рвет на себе волосы и угрожает уволить с работы, если “вот этот кусок архитектуры не будет готов до полудня и ни минутой позже”. Заказчик бледнеет при виде новой версии, которая, мало того, что опоздала на 3 недели, так еще и не содержит половины запланированной функциональности.

Ответ, который дает XP простой и вполне естественный: давайте будем работать так, как будто у нас есть неограниченное время. Вот что по этому поводу пишет сам Кент Бек:
“… если бы у вас было время, вы наверняка уделяли бы внимание разработке тестов; вы наверняка заново переделали архитектуру системы в случае, если пришли бы к выводу, что это необходимо; вы наверняка больше бы общались со своими соратниками-программистами, а также с заказчиком”.

Конечно, неограниченного времени у нас нет, но, прирост эффективности настолько велик, что использование XP – подхода оправдано даже в проектах с жесткими временными рамками.

XP – включаем форсаж
Почему же этот подход называется именно экстремальным программированием? Ведь предлагается противоположное – работать спокойно и размеренно.

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

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

Посмотрим поближе на компоненты XP:

Игра в планирование (planning game) – быстро определяет перечень задач, которые необходимо реализовать в следующей версии продукта.

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

Метафора (metaphor) – описание системы простым языком. Заказчику проще давать задание в терминах метафоры, а не в технических терминах.

Простой дизайн (simple design) – архитектура системы должна быть настолько простой, насколько это возможно. Если кто-то находит способ упростить дизайн – он немедленно пробует это сделать.

Тестирование (testing) – процесс кодирования начинается с разработки тестов. После того, как все возможные тесты написаны и предусмотрены все варианты поведения системы, задача сводится к тому, чтобы написать новый модуль так, чтобы он прошел все тесты.

Переработка (refactoring) – программисты постоянно пересматривают внутреннее устройство системы, не изменяя при этом ее внешнего поведения. Цель переработки – сделать систему проще, убрать дублирование кода или изменить нелогичную структуру, не повредив при этом общую целостность.

Программирование парами (pair programming) – весь код системы пишется парами, два программиста за одним компьютером.

Коллективное владение (collective ownership) – в любое время любой член команды может изменить любую часть системы.

Непрерывная интеграция (continuous integration) – система собирается постоянно, по несколько раз в день. Это происходит после завершения каждой задачи.

40-часовая рабочая неделя (40-hours week) – работать больше чем 40 часов в неделю строго запрещено. В принципе, можно сделать исключение, но работать сверхурочно две недели подряд нельзя ни при каких обстоятельствах.

Заказчик на месте разработки (on-site customer) – в состав команды входит представитель заказчика. Желательно, чтобы этот человек был будущим пользователем системы, т. е. чтобы он мог давать разработчикам дельные советы, как улучшить продукт.

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

Подготовил Бура Юрий
 

 

 ГЛОССАРИЙ   

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

Совет по контролю за конфигурацией (Configuration Control Board) Группа лиц, которая выступает в роли органа, принимающего решения по вопросам, касающимся содержимого базовой конфигурации.

 

 

http://subscribe.ru/
http://subscribe.ru/feedback/		 Подписан адрес:
Код этой рассылки: comp.soft.others.manager		 Отписаться
В избранное