Я очень ленив, чтобы серьезно заниматься риск-менеджментом. Всегда считал это полной чушью, созданной неудачниками для отмазок в стиле: «А! Мы же говорили, что у вас ничего не получится!» Вон из моего проекта!

Кроме того — мы применяем аджайл. Мелкие итерации. И наши риски, и риски клиентов — ничтожно малы! А еще у нас есть типовые и четко очерченные в договорных отношениях этапы (не путать с agile-итерациями ;). Каждый раз, когда мы сталкиваемся с неопределенностью — мы разбиваем задачу на несколько мелких этапов и наши риски снижаются. Это же просто! Да? А теперь плохая новость:

Снижая риски добавлением этапов, мы снижаем рентабельность* всего проекта.

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

Итак, у нас есть абсолютно типовые этапы:

Ни для кого не секрет, что лучший способ научиться что-то хорошо делать — это постоянная практика. Так же обстоят дела и с оценками работы на проекте. Но мало просто оценивать. Надо потом отслеживать реальный результат, анализировать его и делать выводы, чтобы ваша методика оценивания постоянно совершенствовалась. Без этого важного компонента вы никогда не научитесь оценивать классно. Но что если найти некий способ тренироваться в оценках «на кошках»? Причем, как можно чаще и интенсивнее. О таком способе и пойдет речь в статье…

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

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

Итак, с чем в итоге пришлось столкнуться:

Ниже несколько, во многом очевидных, тезисов, которые могут помочь новичкам в Scrum

Немного о проекте и о командах.

Описанный проект — первый, на котором мы решили применить Scrum в полной мере.
До этого работали по итерациям, но без Stand-up митингов, Ретроспектив и Демок.

Работы над проектом ведут две команды.

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

Из-за этого в определенных итерациях мы пересекаемся и сильно зависим друг от друга

Итак.

Наша компания занимается разработкой web-приложений на заказ. Не сайтов-визиток, а именно приложений. Чаще всего — для внутрикорпоративного использования.

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

4-6 июня 2013 года в Москве международный эксперт д-р Питер Хрущка проведет 3-х дневный мастер-класс «Архитектура ПО». Данный мастер-класс является базовым курсом для подготовки к международной сертификации iSAQB.

Справка:
Доктор Питер Хрущка – учредитель Atlantic Systems Guild, международной известной группы экспертов (www.systemsguild.com), в которую входят Том ДеМарко и Тим Листер. Входит в редакционный совет IT журналов, в том числе учредитель и член Международного Совета по Разработке Требований (IREB) и Международного Совета по Квалификации Архитектуры Программного обеспечения (ISAQB). Основатель Agile-сообщества в Германии. Один из разработчиков шаблона архитектурной документации систем ARC42. Первопроходец в области инструментов моделирования для структурных и объектно-ориентированных методологий. Частый спикер на IT конференциях, консультант, среди его клиентов многие компании из списка Fortune 500. Автор многочисленных статей и 9 книг по программной инженерии и человеческому фактору, в том числе соавтор знаменитой «Балдеющие от адреналина и зомбированные шаблонами».

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

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

Дополнительная информация и регистрация на сайте careerlab.ru/education/guru-academy/hruschka/sem1/

Друзья!

11-12 апреля 2013 года проходит одно из самых значимых событий в мире разработки ПО — юбилейная международная конференция Software People. В этом году, конференция проходит в пятый раз, собирая под одной крышей высококлассных специалистов в области разработки ПО.

Думаю, что большинство тех, кто внедрял у себя в командах тот или иной инструмент (особенно, если он родом из страны с другой ментальностью) согласиться, что внедрение не всегда проходит гладко. Однажды один академик мне сказал: «Ну а как ты хотел? Внедрение — это по определению вторжение чужеродного объекта в тело. Должно быть оСВОЕние. Делание своим!». С тех пор, для меня осознание того, что инструмент работает не совсем так, как задумывалось — является лучшим признаком освоения. Команда или сотрудник модернизировали по своему и начали использовать. И еще лучше, когда команда берет два разных инструмента и сама комбинирует их. Так произошло и в этот раз.

Из названия топика и картинки суть идеи будет сразу понятной. Ну а за подробностями, и связью с управлением продуктом, прошу под кат…

По разным причинам Scrum получил очень широкое распространение среди IT компаний. Многие компании и отдельные команды начали внедрять Scrum в своих проектах. У одних это получается, у других не очень. Грамотный и опытный специалист перед внедрением чего-то нового всегда задумывается о метриках. Как убедиться, что внедрение Scrum идет по плану? Улучшается ли производительность команды? Нет ли каких-то проблем? Если вы тоже задавались этими вопросами, добро пожаловать под кат.

Технология CRUD-матрицы — это хороший инструмент для каждого члена Agile-команды на протяжении всего жизненного цикла продукта. CRUD-матрица позволяет наладить адекватный диалог с клиентом и выявить дублирование функционала, а также устранить противоречивость модели. Что касается оценки времени, то в этом моменте CRUD-матрица значительно уступает такому инструменту, как “planning poker”, который позволяет провести адекватную оценку с учетом объективных причин.