Почему канбан НЕ поможет вам при ведении проекта?

В очередной раз на форуме RSDN.RU возник спор про гибкие методологии и, в частности, канбан. Некоторое время назад я опубликовал статью "Халтура.Ру: Как халтурят отечественные ИТ-консультанты?".

Сегодня мне бы хотелось привести дополнительные аргументы.

Что нужно сделать при старте нового проекта?

Прочитал статью Титова А.А. «Двадцать основных принципов, без которых нельзя обойтись при создании надёжного программного обеспечения». Появились такие выводы:

1.      Статья носит декларативный, а не процедурный характер.

2.      Сведения, изложенные в статье, известны и преподаются в любом вузе, обучающем специальности «программное обеспечение вычислительной техники и автоматизированных систем».

3.      Проблемы с внедрением процессов разработки ПО связаны не с тем, что люди не знают, ЧТО нужно делать. Они связаны с тем, что люди не понимают, КАК это нужно делать.

4.      Чтобы статья была полезной, она должна содержать методики и конкретные примеры применения изложенного в статье материала. Иными словами, статья должна отвечать на вопрос «КАК», а не «ЧТО».

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

Как сделать грубый estimate?

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

Задание

Рынки

Целевые Группы

Ожидания

Концепция

Грубая оценка

Источники

Грубая оценка

После создания концепции продукта технический руководитель или ведущий инженер делает грубую оценку проекта. Для оценки используется таблица, в строках которой указываются features и sub-features, а в столбцах — зависимости.

В качестве зависимостей могут выступать:

Как подготовить концепт-документ для продукта?

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

1. линейного продюсера;
2. креативного директора;
3. арт-директора;
4. дизайнера интерфейса;
5. звукового дизайнера;
6. и т.д.

Рассмотрим, как следует готовить концепцию продукта на примере интерактивной примерочной. Это очередная статья из серии. С предыдущими статьями вы можете ознакомиться по ссылкам:

Задание

Рынки

Целевые Группы

Ожидания

Концепция

Грубая оценка

Источники

Проектирование интерактивной примерочной. Часть 2

Задание

Рынки

Целевые Группы

Ожидания

Концепция

Грубая оценка

Источники

Ожидания

После выявления целевых групп необходимо составить список их ожиданий. “NASA System Engineering Handbook” такой процесс называет stakeholder expectations definition. Ожидания можно выявить путём опросов представителей целевых групп, например, по следующей методике. Опросы должен проводить не руководитель отдела разработки, а маркетолог.

Для наших целевых групп были выявлены такие ожидания:

Проектирование Интерактивной Примерочной. Часть 1

Как-то на одном из собеседований на должность руководителя отдела разработки мне дали тестовое задание по организации работы над продуктом «Интерактивная Примерочная». Тестовое задание я написал, но обстоятельства сложились так, что я пошёл работать на аналогичную должность в другую компанию.

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

Задание

Рынки

Целевые Группы

Ожидания

Концепция

Грубая Оценка

Источники

Халтура.Ру: Как "халтурят" отечественные ИТ-консультанты?

У меня складывается впечатление, что модные словечки типа "аджайл", "скрам", "канбан", "гибкие методологии" постепенно становятся ругательными в профессиональной среде. У такого положения вещей есть несколько объективных причин:

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

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