Иногда лучше жевать, чем говорить?

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

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

Тут приходит письмо от Иванова с вопросом: "Ты ничего не слышишала по телефону?"
Пишу ответ: "Нет, видимо проблемы с телефонией".

И тут приходит мне ответ от Иванова:
"Интересный у нас диалог вышел....
Звонок...
Поднимаю трубку: Иванов, слушаю
Из трубки : Ага, фиг тебе!
:)))))))"

Вот такая вот ситуевина:))))
Я даже не думала, что меня может быть слышно на другом конце провода. Я же не слышала никого. Ну, проверила пару тройку телефонов))). Интересно, а что ж остальным сказала, которые мой голос не узнали?..

Короткая история о женщине в проекте

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

Что случилось потом? А догадайтесь!

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

Такие люди играют роль Работник команды по классификации Р. М. Белбин.

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

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

А есть ли такие Работники команды в Вашем коллективе?..

Грибной сезон

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

Вот еще несколько удачных фоток с предыдущих грибных сезонов:
1. Притаившиеся лисички

2. Статный белый гриб

3. Сказочный мухомор, выглядит как будто не настоящий:)

4. И еще один мухомор.

Agile

Недавно была на тренинге по технологиям гибкой разработки (Agile). Проводил тренинг Асхат Уразбаев (Certified Scrum Master, лидер и вдохновитель сообщества www.agilerussia.ru и сообщества www.agileukraine.org). Что вам сказать? Узнала там, что некоторые вещи мы все-таки на практике делаем не так. Есть куда рости, куда усовершенствовать процесс и самих себя.

Для тех, кто не знаком с методологиями Agile, ниже короткий обзор данной технологии.

Из наиболее используемых сейчас технологий разработки наиболее популярными являются RUP и Agile.

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

Классическая водопадная модель выглядит так:

http://www.newrowley.com/images/blog/2006/waterfall.jpg

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

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

Уже сформировался наиболее общий Agile подход, включающий в себя практики SCRUM и XP.

Модель разработки SCRUM:

http://www.controlchaos.com/images/diagram/flow.gif

Коротко, процесс разработки по общему Agile подходу имеет следующий вид. Процесс разработки делится на итерации. Каждая итерация начинается с презентации предложений по функционалу на итерацию с приоритетами (Story Card Presentation).
Далее идет оценка данного функционала по приоритетам (Estimation). Потом формируется список задач на итерацию исходя из продуктивности команды и данных оценок (Iteration Backlog). Далее каждый день идет разработка. При этом проводятся Daily Scrum Meetings. По окончанию разработки проходит Ретроспектива (некий анализ процесса разработки) и заканчивается итерация демонстрацией сделанного функционала.
А дальше все по новой:)

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

Дополнительные ссылки на русском языке:

• Множество литературы и информации можно найти здесь.
• Статья о современных процессах разработки тут.

Самодисциплина

Хочу вам дать неплохую ссылочку по самодисциплине на русском языке. Это перевод знаменитого "в узких кругах" Стива Павлины. Англоязычный оригинал можно найти здесь.

Аналитики или как с ними бороться в ИТ проектах

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

Ага, точно, про аналитиков... Значится, это такие дяди и тети, которые после разговоров с клиентами могут объяснить и написать на бумаге, что же функционально, иногда даже интерфейсно и частично технически, нужно сделать разработчику. И это должно быть написано так, чтобы у разработчика возникло минимум вопросов и некое видение (vision) было корректно передано и понято. Такой документ называется требованием или спецификацией.

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

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

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

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

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

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

Нужны ли тренинги личностного роста?

Недавно была на одном из тренингов по тайм менеджменту (Time management). Вроде бы много читала литературы по личностному росту и с ним связанной, многое уже знала. Но нет, нашлось такое, что было для меня новинкой. Да и курс оказался выжимкой из книг, которые мне бы пришлось читать с учетом ограниченности времени моего досуга месяц-два. Эффективность на лицо, согласитесь.

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

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

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

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

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