Предлагаю обсудить одно из возможных решений проблемы изменяющихся требований, используемое в нашей компании.
Прежде чем перейти к описанию конкретных решений и инструментария, пара слов о политике в отношении новых требований. Пожалуй, самое важное что мы поняли, это то, что требования меняются всегда и вместо того чтобы «бороться со стихией» надо научится управлять изменяющимися требованиями. Конечно, есть ТЗ и бюджет, но часто переговоры о включении новых требований стоят дороже, чем сами изменения. С другой стороны нельзя делать все, что захочет заказчик — тогда проект вообще никогда не будет запущен. Поэтому, требованиями надо именно управлять.
Поскольку наша компания состоит из менеджеров и программистов, наше любимое занятие это организация процессов разработки и разработка средств автоматизации этой самой разработки.
Но вот уже как пару лет мы почти этим не занимаемся, хотя есть и время и средства. Все просто — после долгих поисков мы нашли решение, которое у нас стабильно работает. В рамках этого поста я не буду рассказывать обо всем — получится слишком много, а расскажу об одном из основных приемов в нашей работе. Мы называем его «базовые тикеты».
Не принципиально, какие средства автоматизации используются: трекер, эксель или стикеры. Первичны принципы и процессы организации. Итак, суть подхода очень проста — перед началом разработки составляется полный список задач проекта, этакий To-Do list на проект (по-научному это называется Work Breakdown Structure, WBS). Его удобнее всего делать в экселе, т.к. там есть автофильтры и иерархия. Важно, что бы WBS включал все задачи, которые нужно сделать для выполнения проекта (если появляются ранее не учтенные задачи, их также надо добавлять в список работ, можно с флагом “new”). Мы выбираем масштаб задач от 4 до 16 часов разработки. Нестрашно, если будет несколько сотен задач — их можно объединить в подпроекты и итерации.
А теперь главная хитрость — на каждую задачу из WBS создается тикет в нашем трекере с полной постановкой этой задачи (или в любой системе, где можно вести обсуждение по принципу 1 задача = 1 лента). Можно сказать, что это подход, основанный на Прецедентах (use case, user story). У нас, у тикетов есть индикатор – на чьей стороне задача в данный момент (опять же, можно это отмечать в экселе). По мере разработки задачи (тикеты) сдаются заказчику и уже в начале разработки мы получаем фидбэк от Заказчика.
Для руководителя такой подход позволяет оценить темпы и качество разработки в самом начале (например, если заказчику будут передавать некачественный результат он быстро это выскажет и будет возможность скорректировать ситуацию и получить новый отклик).
Но главное в «Базовых тикетах» это, конечно же, отслеживание изменяющихся требований. Вообще, изменяющиеся требования это одна из самых серьезных проблем IT проектов, и именно поэтому в них не работает принцип «водопада» (написал ТЗ — сделал) как, например, в строительстве. Те, кто говорит, что требования не изменяются, скорее всего просто не вели настоящих проектов. Можно даже сказать, что управление IT-проектом это и есть управление требованиями. Причем требования меняют все — и крупный корпоративщик, и внутренний заказчик и даже мелкая контора. Имея базовые тикеты всегда легко посмотреть первоначальную постановку.
Таким образом, мы получаем актуальные знания о состоянии проекта и требованиях к нему без отдельного ведения документов или wiki с актуальными требованиями. Обычно, отдельное ведение истории изменения требований не бывает актуальным или требует неадекватных усилий руководства на её поддержание. Состояние проекта также полностью реально, ведь задачи принимает заказчик (т.е. вместо абстрактных «у нас почти все готово», мы знаем, сколько задач приняты заказчиком, сколько отправлены на доработку, какие еще не передавались и т.д.)
Организуя наши процессы мы брали за основу разные методики (от RUP до XP), добавляя что-то свое. Естественно, наш подход не претендует на абсолютную истину (и новизну или оригинальность), но у нас он работает, поэтому кому-то еще он тоже может быть полезен. Если что-то осталось непонятным или есть встречные предложения, буду рад обсудить.
UPD:
Дополняю по справедливым замечаниям.
В этом посте я написал скорее про технический подход и не ответил на вопрос, как все-таки быть, когда требования меняются.
1) Изначально нужно закладывать небольшой запас (в бюджете, сроках) на изменение требований. Проект, принятый в работу «впритык» скорее всего уйдет в минус.
2) Перед внесением любых изменений нужно быть уверенным, что это изменение действительно нужно и сделает проект лучше (это можно и нужно обсуждать с заказчиком)
3) Изменения следует вносить только после отладки и сдачи приемки функционала по ТЗ
4) Естественно, процесс должен быть итерационным, пока итерация не выполнена, в нее нельзя вносить изменения. Пакет изменений оформляется в отдельную итерацию
5) Чтобы процесс был подконтрольным и заказчик вносил только действительно важные изменения, мы даем пул часов (например, 100) свободного назначения, которые заказчик может тратить. Естественно, обсуждая с заказчиком внесение тех или иных изменений, ему нужно объяснять, сколько это займет времени и сколько часов у него осталось.
В сложных проектах очень важно сначала получить стабильную версию, а уже потом вносить в нее изменения.
Если же говорить о стратегии, то нужно стремиться как можно скорее выпускать версию (открывать сайт в работу), потому что до открытия требования одни, а после месяца реальной работы, они совсем другие.
Прежде чем перейти к описанию конкретных решений и инструментария, пара слов о политике в отношении новых требований. Пожалуй, самое важное что мы поняли, это то, что требования меняются всегда и вместо того чтобы «бороться со стихией» надо научится управлять изменяющимися требованиями. Конечно, есть ТЗ и бюджет, но часто переговоры о включении новых требований стоят дороже, чем сами изменения. С другой стороны нельзя делать все, что захочет заказчик — тогда проект вообще никогда не будет запущен. Поэтому, требованиями надо именно управлять.
Поскольку наша компания состоит из менеджеров и программистов, наше любимое занятие это организация процессов разработки и разработка средств автоматизации этой самой разработки.
Но вот уже как пару лет мы почти этим не занимаемся, хотя есть и время и средства. Все просто — после долгих поисков мы нашли решение, которое у нас стабильно работает. В рамках этого поста я не буду рассказывать обо всем — получится слишком много, а расскажу об одном из основных приемов в нашей работе. Мы называем его «базовые тикеты».
Не принципиально, какие средства автоматизации используются: трекер, эксель или стикеры. Первичны принципы и процессы организации. Итак, суть подхода очень проста — перед началом разработки составляется полный список задач проекта, этакий To-Do list на проект (по-научному это называется Work Breakdown Structure, WBS). Его удобнее всего делать в экселе, т.к. там есть автофильтры и иерархия. Важно, что бы WBS включал все задачи, которые нужно сделать для выполнения проекта (если появляются ранее не учтенные задачи, их также надо добавлять в список работ, можно с флагом “new”). Мы выбираем масштаб задач от 4 до 16 часов разработки. Нестрашно, если будет несколько сотен задач — их можно объединить в подпроекты и итерации.
А теперь главная хитрость — на каждую задачу из WBS создается тикет в нашем трекере с полной постановкой этой задачи (или в любой системе, где можно вести обсуждение по принципу 1 задача = 1 лента). Можно сказать, что это подход, основанный на Прецедентах (use case, user story). У нас, у тикетов есть индикатор – на чьей стороне задача в данный момент (опять же, можно это отмечать в экселе). По мере разработки задачи (тикеты) сдаются заказчику и уже в начале разработки мы получаем фидбэк от Заказчика.
Для руководителя такой подход позволяет оценить темпы и качество разработки в самом начале (например, если заказчику будут передавать некачественный результат он быстро это выскажет и будет возможность скорректировать ситуацию и получить новый отклик).
Но главное в «Базовых тикетах» это, конечно же, отслеживание изменяющихся требований. Вообще, изменяющиеся требования это одна из самых серьезных проблем IT проектов, и именно поэтому в них не работает принцип «водопада» (написал ТЗ — сделал) как, например, в строительстве. Те, кто говорит, что требования не изменяются, скорее всего просто не вели настоящих проектов. Можно даже сказать, что управление IT-проектом это и есть управление требованиями. Причем требования меняют все — и крупный корпоративщик, и внутренний заказчик и даже мелкая контора. Имея базовые тикеты всегда легко посмотреть первоначальную постановку.
Таким образом, мы получаем актуальные знания о состоянии проекта и требованиях к нему без отдельного ведения документов или wiki с актуальными требованиями. Обычно, отдельное ведение истории изменения требований не бывает актуальным или требует неадекватных усилий руководства на её поддержание. Состояние проекта также полностью реально, ведь задачи принимает заказчик (т.е. вместо абстрактных «у нас почти все готово», мы знаем, сколько задач приняты заказчиком, сколько отправлены на доработку, какие еще не передавались и т.д.)
Организуя наши процессы мы брали за основу разные методики (от RUP до XP), добавляя что-то свое. Естественно, наш подход не претендует на абсолютную истину (и новизну или оригинальность), но у нас он работает, поэтому кому-то еще он тоже может быть полезен. Если что-то осталось непонятным или есть встречные предложения, буду рад обсудить.
UPD:
Дополняю по справедливым замечаниям.
В этом посте я написал скорее про технический подход и не ответил на вопрос, как все-таки быть, когда требования меняются.
1) Изначально нужно закладывать небольшой запас (в бюджете, сроках) на изменение требований. Проект, принятый в работу «впритык» скорее всего уйдет в минус.
2) Перед внесением любых изменений нужно быть уверенным, что это изменение действительно нужно и сделает проект лучше (это можно и нужно обсуждать с заказчиком)
3) Изменения следует вносить только после отладки и сдачи приемки функционала по ТЗ
4) Естественно, процесс должен быть итерационным, пока итерация не выполнена, в нее нельзя вносить изменения. Пакет изменений оформляется в отдельную итерацию
5) Чтобы процесс был подконтрольным и заказчик вносил только действительно важные изменения, мы даем пул часов (например, 100) свободного назначения, которые заказчик может тратить. Естественно, обсуждая с заказчиком внесение тех или иных изменений, ему нужно объяснять, сколько это займет времени и сколько часов у него осталось.
В сложных проектах очень важно сначала получить стабильную версию, а уже потом вносить в нее изменения.
Если же говорить о стратегии, то нужно стремиться как можно скорее выпускать версию (открывать сайт в работу), потому что до открытия требования одни, а после месяца реальной работы, они совсем другие.
