Всем добрый день!
Данный короткопост будет ходить около вопросов проектного управления, сдобрив это прототипом реализации идеи совмещения канбана и водопада.
Преамбула
Неоднократно сталкивался с картиной: от менеджера требуют сказать конечный срок и дают в руки трекер задач. Решение бывает такое — план проекта в MS Project/TeamWork или в каком-то привычном для Waterfall инструменте, а для трекинга кастомизированная Jira/Trello или что-то еще. Глядел я на мучения менеджеров с актуализацией туда-сюда, и родилась идея поженить Waterfall и Kanban: методически и практически (в рамках наколенно-доморощенной реализации на Gtk#).
Амбула как бы
Методически
Канбан — это в первую очередь анализ изменения статуса задач. Привычный waterfall — это анализ последовательности задач. В этом плане на первый взгляд пересечения никакого нет — запланированные задачи могут менять статус (и даже в MS Project или хоть где). Однако прогноз канбана строится на времени прохождения задачи до конечного статуса, и статусы меняют исполнители самостоятельно, чем создают факт, в то время как водопад дает нам плановые сроки. Чтобы объединить это в одно, достаточно примитивно дать возможность исполнителям гонять по канбан-дорожкам задачи водопада в любую сторону. Привычная задача менеджера после создания водопадного плана сведется к анализу отклонений от него — в то время как привычное дело разработчиков и других исполнителей проекта сведется к изменению статусов задач.
Ничего волшебного, если бы не одно но. Существуют задачи, изменение статуса которых должно сбрасывать состояние её последователей — например если начали переделывать реализацию фичи, то статус тестирования мог бы уйти в ноль по-хорошему. Задание таких связей я без долгих раздумий назвал созданием «сильных связей» между задачами.
Таким образом, канбан и водопад вполне совместимы друг с другом, и задачу отслеживания можно упростить с помощью сильных связей.
Практически
Для практической реализации был выбран C# и Gtk# (поскольку я linux-пользователь, а хотелось кроссплатформенности). Реализацию (опять же не думая долго) назвал я PlanTrack, и текущее её состояние — прототип.
Ссылка на windows-сборку (прочтите readme!).
Постамбула
О чем пост — может и не о идее, и точно не о реализации (мои упражнения по Gtk# вряд ли кому сгодятся).
Пост скорее о том, что создание своих инструментов может себя оправдать. Я не раз и не два делал (в качестве PM'a) разные решения по управлению проектами, местечковые — в тех местах где работал. Даже на 1С приходилось. И знаете что?.. Оно того стоит. Заточенный под себя инструмент позволяет забивать гвозди сразу прямо, а не натягивать свою работу под чьи-то размышления о том, как надо бы.
Все эти подходы по управлению проектами, все эти решения по управлению проектами… их надо знать — но только для того, чтобы выбрать то, что подходит в данной ситуации в данное время. Я сторонник адаптации методов к работе, а не адаптации работы к методам.
В этом и водораздел. Нельзя, пожалуй, верить в то, что мы возьмем RUP/XP/Scrum/<Список длинный> и теперь заживем. Нет, не заживем, а поимеем проблем. Нет, нельзя взять MS Project и Jira и сказать — вот теперь мы в них трекаем и планируем, тогда всё будет хорошо. Нет, хорошо не будет.
Хорошо будет тогда, когда кто-то возьмет, например, Excel, и на макросах VBA сделает то, что подходит вашему бизнесу. Было дело я работал в одной крупной компании (вращающейся на Лондонской бирже) — и там никто не заказывал переделку SAP. Оценка и отслеживание проектов были сделаны под себя, под свои проекты, под свои методы. И в Excel. Работал я и в компаниях в 500 раз (без преувеличения) меньше — и там создание своих проектных решений себя оправдывало. Почему?
Если создание решений по управлению проектами под свои нужды — не компетенция компании, то тогда проекты — не приоритетны для компании, и не являются преимуществом для бизнеса.
Всё примитивно. Будущее проектной компании обеспечивается процессом планирования этого будущего. Если инструмент диктует правила планирования, какими бы не были хорошими заложенные в него практики — будущее не будет гибким, оно не будет соответствовать обстоятельствам вашего бизнеса. Оно будет соответствовать обстоятельствам того бизнеса, который за вас подумал, как нужно управлять вашими проектами.
Хороших праздников и удачных проектов!
В итоге мысль такая: свой молоток с изолентой лучше купленной кувалды, а пример моих трёхдневных стараний, изложенных выше, возможно убедит кого-либо в том, что это вполне реально. Спасибо всем кто дочитал.
Данный короткопост будет ходить около вопросов проектного управления, сдобрив это прототипом реализации идеи совмещения канбана и водопада.
Преамбула
Неоднократно сталкивался с картиной: от менеджера требуют сказать конечный срок и дают в руки трекер задач. Решение бывает такое — план проекта в MS Project/TeamWork или в каком-то привычном для Waterfall инструменте, а для трекинга кастомизированная Jira/Trello или что-то еще. Глядел я на мучения менеджеров с актуализацией туда-сюда, и родилась идея поженить Waterfall и Kanban: методически и практически (в рамках наколенно-доморощенной реализации на Gtk#).
Амбула как бы
Методически
Канбан — это в первую очередь анализ изменения статуса задач. Привычный waterfall — это анализ последовательности задач. В этом плане на первый взгляд пересечения никакого нет — запланированные задачи могут менять статус (и даже в MS Project или хоть где). Однако прогноз канбана строится на времени прохождения задачи до конечного статуса, и статусы меняют исполнители самостоятельно, чем создают факт, в то время как водопад дает нам плановые сроки. Чтобы объединить это в одно, достаточно примитивно дать возможность исполнителям гонять по канбан-дорожкам задачи водопада в любую сторону. Привычная задача менеджера после создания водопадного плана сведется к анализу отклонений от него — в то время как привычное дело разработчиков и других исполнителей проекта сведется к изменению статусов задач.
Ничего волшебного, если бы не одно но. Существуют задачи, изменение статуса которых должно сбрасывать состояние её последователей — например если начали переделывать реализацию фичи, то статус тестирования мог бы уйти в ноль по-хорошему. Задание таких связей я без долгих раздумий назвал созданием «сильных связей» между задачами.
Таким образом, канбан и водопад вполне совместимы друг с другом, и задачу отслеживания можно упростить с помощью сильных связей.
Практически
Для практической реализации был выбран C# и Gtk# (поскольку я linux-пользователь, а хотелось кроссплатформенности). Реализацию (опять же не думая долго) назвал я PlanTrack, и текущее её состояние — прототип.
Ругань по поводу текущей реализации
Как выяснилось, Gtk# не настолько кроссплатформенный, насколько хотелось (под Windows нужно затащить кучку библиотек). Во-вторых, выбор базы Sqlite тоже был достаточно наивным — нужны разные сборки под разные платформы. Те, кто захочет собрать проект под linux, должны будут сменить в коде три строчки (в DBHelper.cs: System.Data.SQLite --> Mono.Data.Sqlite, и в том же файле в двух местах SQLiteConnection --> SqliteConnection).
Более того, на сладкое. Мои извинения за код впопыхах, времени у меня как всегда в обрез (работаю даже на праздниках), но даже дело не в этом. Выглядит всё интерфейсное хозяйство под Linux и под Windows больно уж по-разному.
Более того, на сладкое. Мои извинения за код впопыхах, времени у меня как всегда в обрез (работаю даже на праздниках), но даже дело не в этом. Выглядит всё интерфейсное хозяйство под Linux и под Windows больно уж по-разному.
Скриншоты
Ссылка на windows-сборку (прочтите readme!).
Постамбула
О чем пост — может и не о идее, и точно не о реализации (мои упражнения по Gtk# вряд ли кому сгодятся).
Пост скорее о том, что создание своих инструментов может себя оправдать. Я не раз и не два делал (в качестве PM'a) разные решения по управлению проектами, местечковые — в тех местах где работал. Даже на 1С приходилось. И знаете что?.. Оно того стоит. Заточенный под себя инструмент позволяет забивать гвозди сразу прямо, а не натягивать свою работу под чьи-то размышления о том, как надо бы.
Все эти подходы по управлению проектами, все эти решения по управлению проектами… их надо знать — но только для того, чтобы выбрать то, что подходит в данной ситуации в данное время. Я сторонник адаптации методов к работе, а не адаптации работы к методам.
В этом и водораздел. Нельзя, пожалуй, верить в то, что мы возьмем RUP/XP/Scrum/<Список длинный> и теперь заживем. Нет, не заживем, а поимеем проблем. Нет, нельзя взять MS Project и Jira и сказать — вот теперь мы в них трекаем и планируем, тогда всё будет хорошо. Нет, хорошо не будет.
Хорошо будет тогда, когда кто-то возьмет, например, Excel, и на макросах VBA сделает то, что подходит вашему бизнесу. Было дело я работал в одной крупной компании (вращающейся на Лондонской бирже) — и там никто не заказывал переделку SAP. Оценка и отслеживание проектов были сделаны под себя, под свои проекты, под свои методы. И в Excel. Работал я и в компаниях в 500 раз (без преувеличения) меньше — и там создание своих проектных решений себя оправдывало. Почему?
Если создание решений по управлению проектами под свои нужды — не компетенция компании, то тогда проекты — не приоритетны для компании, и не являются преимуществом для бизнеса.
Всё примитивно. Будущее проектной компании обеспечивается процессом планирования этого будущего. Если инструмент диктует правила планирования, какими бы не были хорошими заложенные в него практики — будущее не будет гибким, оно не будет соответствовать обстоятельствам вашего бизнеса. Оно будет соответствовать обстоятельствам того бизнеса, который за вас подумал, как нужно управлять вашими проектами.
Хороших праздников и удачных проектов!
В итоге мысль такая: свой молоток с изолентой лучше купленной кувалды, а пример моих трёхдневных стараний, изложенных выше, возможно убедит кого-либо в том, что это вполне реально. Спасибо всем кто дочитал.