Форум QAClub.com.ua

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

У нас используется скрам - вот только недавно . Новая команда, и компания тестирует скрам впервые. С августа 2008 - пока не провалили ни одного спринта (итерациии) - так что пока успешно. Что касается моего личного мнения - при выборе методологии было бы круто, как по мне, чтобы команда была не вновь организованная и все новички, а притертая уже, которая склонна к самоорганизации, либо чтобы хотя бы скрам мастер уже работал бы в этой компании до этого.
Хотя если команда работала уже как команда в рамках другой методологии - то возможны трудности при переходе от одной методологии к другой.

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

Maria, а у вас уже есть конкретные вопросы к консультанту?
Я думаю, что если, например, здесь задавать четкие вопросы, то найдутся люди, которым есть что сказать.

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

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

YuriY писал(а):Maria, а у вас уже есть конкретные вопросы к консультанту?
Я думаю, что если, например, здесь задавать четкие вопросы, то найдутся люди, которым есть что сказать.

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

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

Спасибо за ответ и сочуствие. Это очень важно. Литература прочитанная есть, но...
мой директор задает мне вопрос "а зачем мне каждый день 10 минутные сборы? я считаю это не нужным", все, что я ему отвечяю, есть теория прочитанная из книжки, и она не убедительна.
Мы думали, что бы пригласить человека, работающего со СКРАМ к нам в офис, рассказать о наших проектах, и посоветоваться с ним, о методологии внедрения. Четких вопросов, наверное, нет (может читали мало). со своей стороны тоже согласны прийти к кому то, если можем помочь чем то

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

На счет ежедневного митинга: можно попробовать исходить из того, что СКРАМ - это техника тайм-менеджмента, которая применяется для [командной] разработки ПО. А практически любая техника тайм-менеджмента (в частности, крайне популярные GTD, тайм-драйв Архангельского, система Стивена Кови) включают в себя ежедневное планирование работ. Если директор интересуется тайм-менеджментом, то параллель может помочь). Хотя все-таки мне кажется, что на данный момент это не самый главный вопрос. Важнее, чтобы все согласились, что нужно что-то менять...

Если моя гипотеза не верна, поправьте, пожалуйста).

YuriY писал(а):Наблюдается неединодушие с высшим руководством). В таких условиях делать нововведения крайне непросто... без поддержки сверху...
С другой стороны, изменения должны быть оправданы, в том числе с экономической точки зрения.
Я так понимаю, что вы считаете, что изменения нужны. А руководство так считает? Может, директор предлагает другие варианты? Или ничего не хочет менять? В этом случае сначала необходимо показать, что имеется проблема с текущим процессом, и только потом предлагать возможные решения... А пока проблему видите только вы, диалог не состоится в принципе. Так нас учил Саша Орлов) и я очень с этим согласен.

На счет ежедневного митинга: можно попробовать исходить из того, что СКРАМ - это техника тайм-менеджмента, которая применяется для [командной] разработки ПО. А практически любая техника тайм-менеджмента (в частности, крайне популярные GTD, тайм-драйв Архангельского, система Стивена Кови) включают в себя ежедневное планирование работ. Если директор интересуется тайм-менеджментом, то параллель может помочь). Хотя все-таки мне кажется, что на данный момент это не самый главный вопрос. Важнее, чтобы все согласились, что нужно что-то менять...

Если моя гипотеза не верна, поправьте, пожалуйста).

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

Тогда хочется задать такие вопросы:
1) Как (схематично) выглядит текущий итеративный процесс разработки
2) Что в нем не нравится и почему не нравится (ответ на вопрос "почему" часто позволяет понять как хочется чтобы было)

Что нам с вами дают ответы на эти вопросы:) : мы понимаем где мы сейчас находимся и куда хотим прийти, т.е. исходное состояние и целевое состояние. Когда мы это поняли, мы можем определить ряд шагов, которые необходимо постепенно выполнить для достижения цели (например, какие "правила поведения" внедрить или убрать...). В частности, вполне возможно, что вы предпримете еще ряд некардинальных в принципе изменений в своем текущем процессе и подберетесь ближе к тому, что называют СКРАМом...

Необязятельно ведь одним махом вводить все практики СКРАМа (я так думаю)... Некоторые специалисты по тайм-менеджменту, например, рекомендуют растягивать внедрение GTD (по сути, тот же СКРАМ) на несколько месяцев... лишь бы наверняка внедрить).

Если есть желание, можем вместе поразмышлять. Может получиться интересно).

YuriY писал(а):Необязятельно ведь одним махом вводить все практики СКРАМа (я так думаю)... Некоторые специалисты по тайм-менеджменту, например, рекомендуют растягивать внедрение GTD (по сути, тот же СКРАМ) на несколько месяцев... лишь бы наверняка внедрить).

Если есть желание, можем вместе поразмышлять. Может получиться интересно).

Давайте, поразмышляем вместе. спасибо! Как Вам будет удобно?

По поводу необзятельности внедрения всех : надо хорошо разбираться в модели, что бы понимать, чем можно пожертвовать, а чем нет. Со своей стороны мы это сделать не можем

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

И более конкретные вопросы:
- Какова средняя продолжительность проекта и количество людей в команде?
- Команда распределенная или все вместе?
- Заказчик далеко или близко? Как вы с ним общаетесь и как часто и быстро он доступен?
- На чьей стороне выполняется изначальное планирование проекта?
- В каком виде требования к продукту существуют? На чьей стороне находится аналитик или человек, которые поддерживает требования?
- Часто ли меняются требования? Или они аппрувятся в начале проекта, а все изменения - за отдельные деньги потом, в виде Change Request'ов проходят?
- В случае, если Ваша компания решит что-то менять в процессе, с заказчиком проблем не возникнет или у него тоже имеется видение того, по какому процессу Вы должны работать? Сфера его бизнеса, в частности, не накладывает ограничений на процесс разработки ПО?

P.S.

чтобы понимать, чем можно пожертвовать

- я не думаю, что придется чем-то жертвовать. Предлагаемые в СКРАМ практики в принципе своем здравы и полезны практически в любой деятельности... Другое дело, что одним махом все не поменяешь. Можно "захлебнуться" и дружно решить, что СКРАМ (или какая-то другая технология) - отстой, не работает и все такое... Так что начинаем потихоньку)).

Первым делом хочу сказать, что не все так плохо у нас. О применении СКРАМ мы задумываемся, дабы оптимизировать, улучшить процесс, а в итоге качество продуктов.

YuriY писал(а): - Попробуйте описать несколько примеров (хотя бы 2-3), которые показывают, почему Вы захотели что-то менять. Какие проблемы у Вас возникают при работе по текущему процессу?

Мои проблемы :
1. кол-во ошибок в версиях сдаваемых на тестирование;
2. небольшое время на дебаг и на тестирование;
3. огромное кол-во срочных нововведений от заказчика;

YuriY писал(а):- Какова средняя продолжительность проекта и количество людей в команде?

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

YuriY писал(а):- Команда распределенная или все вместе?

Зависит от проекта, чаще всего, все вместе

YuriY писал(а):- Заказчик далеко или близко? Как вы с ним общаетесь и как часто и быстро он доступен?

Заказчик доступен, общаемся каждый день

YuriY писал(а):- На чьей стороне выполняется изначальное планирование проекта?

На общей Заказчик с нами обсуждает. он высказывает свои идеи, дает юзкейсы, мы даем примерную оценку времени и ресурсов

YuriY писал(а):- В каком виде требования к продукту существуют? На чьей стороне находится аналитик или человек, которые поддерживает требования?

Требования к продукту существуют в виде юзкейсов, Аналитика нет, поддерживает требования человек на нашей стороне

YuriY писал(а):Часто ли меняются требования? Или они аппрувятся в начале проекта, а все изменения - за отдельные деньги потом, в виде Change Request'ов проходят?

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

Вот, вроде на все вопросы ответила. Интересно узнать, как с этими же вопросами обстоит дело в других конторах

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

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

Что касается проблем, которые Вы назвали.

1. кол-во ошибок в версиях сдаваемых на тестирование;

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

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

2. небольшое время на дебаг и на тестирование;

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

3. огромное кол-во срочных нововведений от заказчика;

Относительно этого вопроса мне нравится позиция Agile-движения... хотя, по сути, любой итеративный подход "думает" также. Итерации должны быть достаточно короткими, чтобы можно было достаточно часто анализировать ситуацию, "оглядываться", корректировать планы... При этом важно договориться с продакт оунером (который есть клиент или представляет клиента), что во время итерации нельзя менять скоп, т.е. договорились что-то сделать за 2 недели -значит делаем и все. А между итерациями можно вносить изменения в бэклог, т.е. учитывать срочные пожелания клиента. Если получится так договориться с клиентом, то проблема, наверное, будет решена или минимизирована.
Вот. Такие мысли).

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

Скоро вернусь из командировки. Буду готов продолжить обсуждение).