Семинар AgileRussia: Применимость agile-методик в in-house-разработке(Прочитано 18622 раз)
В пятницу, 16-го марта пройдёт очередной семинар AgileRussia. Тема встречи - разбор case'а - "Применимость agile-методик в in-house-разработке".

Ситуация:
* много разных проектов
* много разных технологий
* небольшой коллектив разработчиков

Я буду представлять интересы такого коллектива, эксперты по Agile - предлагать методики и обсуждать их применимость.

Подробности и записываться здесь - http://agilerussia.ru/index.php?option=com_content&task=view&id=32&Itemid=27



постараюсь быть
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



тоже думаю быть :-).
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Обсуждение состоялось. Были оживленные дискусси. Думаю Денис опубликует результаты (в связке с проблемамп). А я предствлю собственные размышеления на тему вопроса в ответ на эту публикацию.
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Ждем с нетерпением



Опубликовал 1-ю часть отчёта о семинаре - пока только формулировка кейса + краткие рекомендации.

Развернуть, почему именно такие рекомендации, как и на что они должны повлиять - пока не удалось :)



Извините за глупый вопрос, просто не встречался с таким термином, а в интернете не нашел достаточно понятного объяснения. Что такое in-house в данном смысле и вообще



Что такое in-house в данном смысле и вообще

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



В данном случае имеется в виду, что разработка идет не для стороненнего заказчика (software фирмы), а для своих внутренних нужд.

Я конечно так и подумал, но по переводу. Только найдя этот термин в википедия усомнился. Там приводится пример:

In-house refers to the production of some commodity or service, such as a television programme, using a company's own funds, staff or resources.

This is in contrast to production being outsourced (contracted out) to another company.

An example of this kind of production is the UK science fiction television series Doctor Who, which is produced in-house by BBC Wales for broadcast on BBC One. Since both are branches of the BBC, the production is considered in-house.



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

Что я думаю по этому поводу.
Summary по проблеме.
1. Для такого рода организаций характерна работа в стиле "стихийных бедствий" и "пожарной команды". Это в отчасти происходит из-за рассинхронизации потребностей бизнсеса и возможностей ИТ подразделения. Т.е. нет согласованности -- бизнес воспринимает ИТ как "обслуживающий персонал", от которого одни расходы.  И не воспринимается как полноценный партнер, который помогает бизнесу в достижении его целей.

2. Бизнес не понимает как в ИТ формируется бюджет и главное насколько эффективно этот бюджет расходуется (если конечно это интересно бизнесу). Эффективность работы ИТ подразделения измеряется «ощущениями» или только личными отношениями. Да и руководству ИТ можно поднять свой имидж если периодически совершать «подвиги» по реализации срочных проектов.

3. Из-за не восприятия бизнесом ИТ-подразделения как серьезного партнера или хотя бы как некий инструмент в достижении своих целей (со своими ограничениями – ну сложно забивать молотком сваи в землю, для этого нужны другие мощности), ИТ подразделение как правило ставят перед фактом что и когда должно быть сделано а не просят оценить и т.п. … А даже если таки просят оценить сроки/бюджеты реализации, то само руководство ИТ оценивает их исходя из тех же «ощущений», а не базируясь на метриках и статистических данных, которые характеризуют в целом процесс производства/поддержки ПО.

4. Политика и еще раз политика … распространена ситуация, когда в таких организациях «политики больше чем технологий». Этот фактор оказывает существенное влияние в т.ч. на деятельность ИТ-подразделения.

5. Кроме «внешних» факторов, есть очевидно и «внутренние» -- как то неслаженность работы различных подразделений (тех же ПМ и Аналитиков), которые, основываясь уже на собственных ощущениям и требованиям спущенным «сверху» вносят дополнительную энтропию. Они достаточно отдалены от реальной работы разработчиков и не факт, что отвечают за конечный результат.  И, как это часто бывает, создавая те же ТЗ – просто «перебрасывают их через стенку» разработчикам, искренне веря что свою часть работы они уже сделали. И они не воспринимают тех же разработчиков членами одной команды, а скорее «врагами» (утрирую конечно, но где-то так). Хотя наверняка у тех же разработчиков будет масса претензий к качеству документации требований. ПМ-ы скорее всего тоже существуют обособленно, не «держа руку на пульсе разработки». И их деятельность сводится к рисованию (и частому перерисвоыванию) диаграмм Ганта и вопросов разработчикам в стиле «как дела, какой прогресс» …

6. Все вышеперечисленное является «корневыми» проблемами. От которых происходят и те «производные» проблемы конкретных исполнителей.


Возможности по решению.
1.   Какое либо решение возможно при одном важном условии – осознание руководством ЧТО ПРОБЛЕМА СУЩЕСТВУЕТ и ее нужно решать. Часто в таких организациях предпочитают не изменять стиля работы а просто доплачивать исполнителями за «подвиги». И не обязательно это премирование .. это может быть просто хороший компенсационный пакет, ради которого исполнители готовы терпеть «неудобства». А если компенсируются хорошо именно «подвиги», то героизм становится просто выгодным экономически исполнителям, и большой заинтересованности в изменениях у них может и не быть, если только подвиги не приводят к нервному истощению.

2.   Всем очевидно, что идеальным был бы комплексный подход к решению указанных проблем. И этот комплексный подход на стыке ITIL – P&PM – R&D SEP. Т.е. можно разработать систему сбора метрик и руководству иметь на руках цифры, которыми можно уже оперировать в т.ч. в качестве доказательной базы для бизнеса. С бизнесом определенно имеет смысл говорить на его языке – т.е. на языке KPI и денег, имея на руках численные данные. Примеры таких уже решений есть, более того сейчас такое решение оформляется в виде консалтингового  продукта (я принимаю участие в этом). Практики ITIL позволят регламентировать отношения с бизнесом с т. з. качества и стоимости сервиса по разработке/сопровождению систем. Практики P&PM позволяют оценивать в т.ч. загрузку ресурсов, а Portfolio Management позволяет взглянуть на пул проектов в целом и оценить их «перспективность» в т.ч. с т.з. инвестиций в них. Третья составляющая – это собственно процессы разработки ПО, где возможно применение различных методологий и специфических практик (чуть не написал на автомате «специфических целей» … CMMI :-)). Все цели и практики Все это в комплексе позволит улучшить ситуацию.

3.   Так же очевидно, что такой комплексный подход, при всей его правильности вряд ли может быть реализован в одночасье да и не факт, что будет понят и поддержан руководством (хотя есть и положительные примеры). Но к этому имеет смысл стремится. Вполне можно разработать 2 направления улучшения процессов – «сверху вниз» и «снизу вверх». Первый путь использует руководство в качестве целевой аудитории, второй – непосредственных исполнителей, в данном случае разрботчиков и «иже с ними». Из общей стратегии следует сделать (движение «сверху вниз»):
a.   «Продать» идею улучшений руководству. Ее нужно грамотно спозиционировать, показать приемущества, которые можно получить в соотнесении с затратами. (Примечание. На обсуждении Дмитрий и Павел озвучили мысль, что «продавать» идею об улучшениях нужно именно в виде конкретных предложений, которые реально реализовать за короткое время.
b.   Написать концепцию комплексного улучшения процессов с явным указанием целей (чего хотим достичь), работами, рисками и мероприятиями по их устранению. Цели, задачи и мероприятия должны иметь явные связи друг с другом и с рисками. Желательно подать ее таким образом, чтобы руководство сказало «О, это как раз то что я хотел предложить, только руки все никак не доходили все это структурировать и изложить» :-).
c.   Активно пиарить идею об улучшениях. Причем очень желательно сделать несколько «quick win» чтобы иметь практическое подтверждение. Скорее всего эти «quick win» будут из области R&D (тут стыковка с направлением «снизу вверх»).
d.   Заручившись поддержкой руководства двигаться по обоим направлениям улучшений. Делая в первую очередь то, что позволит явно показать прогресс.

4.   Перейдем от «концептуального» уровня к более приземленным. В ходе обсуждения был высказан ряд рекомендаций, что можно попробовать сделать «здесь и сейчас». Я только хотел бы дополнить тем, что мне показалось возможным сделать:
a.   Проблема неравномерной загрузки разработчиков. По условиям – есть взаимосвязь м/у 1) технологиями 2) специалистами владеющими технологией 3) квалификацией специалиста в данной технологии 4) «востребованностью» конкретной технологии.  Чтобы решить проблему неравномерной загрузки разработчиков нужно как минимум перераспределить часть работ по конкретной технологии, но тут может выясниться что людей с такими знаниями нет – вот и мотивация чтобы отправить на курсы кого-нибудь поучиться технологии : -). Можно нарисовать матрицу Люди/Технологии … и обоснованно подходить к вопросу чтобы кол-во людей со знанием востребованных технологий было адекватным. Другой вопрос, что следует задуматься, а нужно ли в действительности такое разнообразие технологий при явной нехватке ресурсов? И кто вообще выбирает на какой технологии будет делаться конкретный (новый) проект?
b.   Проблема незнания «системы в целом» и частично «переключения контекста». Тут вопрос можно рассматривать в частности с позиции архитектуры. А именно, в идеале, нужно иметь роль Архитектора проекта, который будет как раз и иметь представление о всей системе. Великолепно, если получается применять разбиение на слои (GUI, Business Layer, Persistence Layer, Data Layer). Унификация даже на таком уровне позволяет существенно упростить представление о системе и переключатся становится проще и специализация не помеха. Что для этого нужно? В первую очередь выстроить внятно Разработку и управление требованиями (RDM), и Управление изменениями и конфигурациями (SCCM). В данном случае не важно на базе какой методологии это будет сделано. Второе – это, как минимум для новых проектов стараться использовать унифицированных архитектурный стиль. Наличие хорошо сформулированных требований и четкого дизайна системы (когда бизнес-логика не размазана по GUI и хранимым процедурам) существенно упростит жизнь и позволит быстрее подключать новых специалистов к проекту. Это конечно хороший и правильный совет, но не всегда он может быть выполнен :-). Хотя есть примеры, когда требования в организации восстанавливали для систем, иначе невозможно было их тестировать.
c.   Еще один, тоже прозвучавшая в ходе обсуждения рекомендация – разграничение ответственности. Тут кстати, в качестве формального представления может быть полезна т.н. матрица ответственности или RACI charts (см. COBIT 4.0).


Есть другой взгляд на  проблему, исходя из «объективной реальности». Примем, что системно/комплексно мы не можем подойти к вопросу улучшения процессов. Так же примем как данность, на которую мы не коим образом не можем повлиять, тот факт, что задачи сваливаются хаотично, что требования к системам низкого качества, и что есть разброс технологий. ПМ-ы и аналитики по сути наши прокси-заказчики и разработчики не имеют выход на реальных заинтересованных лиц. Считаем, что Аналитики никак не заинтересованы в результатах проекта в целом. Имеем в качестве исходных данных перечисленные Денисом проблемы. Что можно сделать в этом случае?
1.   Глобально – инкорпорировать ПМ-ов и аналитиков в единую команду – они должны плыть в одной с вами лодке и разделять успех/неуспех вместе с разработчиками.
2.   В условиях дефицита ресурсов нужно равномерно распределить нагрузку, в т.ч. по технологиям. Как это можно сделать уже обсуждалось. Добавлю, что нужно инвестировать в повышение квалификации разработчиков.
3.   Воспринимать поступающие ТЗ только как «исходные сырые материалы», и самостоятельно разрабатывать требования (пусть в виде списков фич или назовем это бэклогом, не столь важно) и включать эту активность и время на нее в планы работ. Для чего? Чтобы обратить внимание на то, что требования поступают ненадлежащего качества и приходится их перерабатывать, а на это уходит время и соответственно удлиняется разработка. Альтернатива – научить аналитиков делать внятные требования к софту и унифицировать документацию и принципы разработки требований и инкорпорировать их в проекты, чтобы они взяли на себя часть нагрузки.
4.   Регистрировать ВСЕ задачи, которые поступают и учитывать время их исполнения. Можно возложить на начотдела такую работу. Сдвигать графики в при возникновении срочных задач с уведомлением заказчиков о причинах. Это в т.ч. позволит обоснованно говорить о возможных сроках реализации – «приходите через полгода» (цитирую Дмитрия).
5.   И конечно же, как отметили многие присутствующие на этом обсуждении следует рассмотреть вопросы формирования команды. Эффективно работать в такой ситуации можно только со сформированной командой. Практики летучек, итераций эффективны либо при жестком управлении либо в сплоченной команде (результат примерно одинаков, но в самоорганизующейся команде это более эффективно и у всех положительные эмоции).
« Последнее редактирование: 21 Марта 2007, 22:53:21 от Юрий Булуй »
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Забавно ... я ожидал некой дискуссии на этот пост. Но тишина. Напрашивается вывод, что либо все несогласны, либо все согласны и добавит нечего (что странно), либо длинные посты просто не читают :-), либо одно из четырех :-). А так хотелось пообсуждать :-).
"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/



Еще акцентирую внимание на следующем:

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

2. Нет четкого планирования:
2.1. Нет плана разработки - что за чем идем и кто что контролирует. Т.е. програмеров контролируют тестеры, а кто контролирует аналитиков и архитекторов?. Нужен общий план/методология разработки ПО
2.2. Нет плана всех работ. Если бы он был, то лекго было бы сказать/понять при поступлении нового проекта - усе мощностей уже нет.
2.3. Нет детального плана на следующие пару итераций/недель. С этим и свзяано хаотичное перебрасование с одной задачи на другую.
2.4. Нет контроля - ну не сделал и хай с ним, сделал - хорошо.

3. Многие идеи Agile, которые я изложил здесь, можно лекго начать применять практически везде.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



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

Обычная практика такова, что бизнес требует предостваить такие оценки от самого ИТ ...

В свое время был свидетелем  успешного решения проблем "проведения формальной границы" не сверху, а снизу.

Можно делать и сверху и снизу, но лучше с обоих направлений, так эффективнее и быстрее.

Что делать:Все зависит от ситуации, мои акценты таковы: начни изменения с себя - это снизит усилия по продаже

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


"Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies" (c)
Мой блог
http://www.yurybuluy.blogspot.com/




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19