Согласен полностью. Как раз один из шагов и был Совместное планирование. Но после объединение всех в одну команду, этот подход стал выполняться сам собой.
Наша команда закреплена надолго, точнее, в принципе не предусмотрено её переформирование, да и работаем мы над одним очень большим продуктом.
Поэтому бонусов от совместной работы мы имеем ещё больше.
Срок готовности сообщает команда. Это очень удобно для менеджера. Команда полностью ответственна за выпуск релиза — и разработка и тестирование и документирование и деплоймент — все делает одна команда.
Кстати, когда программисты и тестировщики стали работать вместе, они стали давать более реалистичные оценки.
Хотя, на самом деле, в последнее время мы почти отказались от оценок и сроков — поставляем фичи с той скоростью, с которой способны. И максимально часто. Нам повезло, заказчик нам доверяет.
Bug driven development не боимся. В одном из комментариев я уже ответил, что тестировщики теперь сконцентрированы все больше на написании автотестов, поэтому на ранних этапах им есть чем заняться.
Нет. Тестировщики концентрируются на написании автотестов, а их зачастую можно писать не дожидаясь разработчиков. А если даже и не получается, то тестовое окружение готовить заранее и тест планы писать на будущие задачи никто не запрещает.
Получается что-то вроде параллельной разработки. Да, к тому же мы работаем в потоке: закончил один тест, всегда есть следующий. Вопрос только в синхронизации, что бы ни программисты, ни тестировщики не убегали сильно вперед.
Нет, но кажется догадываюсь о чем это.
Читал о чем-то подобном в документах от Microsoft, про их философию разработки в TFS.
Буду признателен ссылке на книгу.
Нет, с теорией ограничений автор не был знаком. Спасибо, ознакомился.
Теперь можно на языке этой теории сказать, что в данном случае основной ограничивающий фактор был конфликт интересов. Его причина — различие целей. Убрав это ограничение случился прорыв.
Думаю, когда эйфория от этого прорыва пройдет, стоит заняться поиском следующего ограничения.
Спасибо ещё раз, мне приятнее думать на языке каких-то умных теорий, нежели на своем «велосипедном».
Да, было бы изумительно масштабировать эту идею на компанию в целом, поскольку «личные интересы отделов» порой действительно губительно сказываются на общем результате.
Кто знает, может быть через пару лет на хабре появится статься «Война миров: отдел на отдел!».
Безусловно, для реализации описываемого подхода, когда тестировщики и программисты работают в одной команде, требуется удовлетворение определенных требований. Некоторые из этих требований у нас были выполнены изначально, а вот для выполнения остальных пришлось потрудиться.
В этой статье я специально не стал углубряться в необходимые внешние условия (думаю, это может стать отдельной большой статьей), а заострил внимание именно на сути подхода, что главное, это общая цель!
А если все-таки говорить про то, в каких усовиях это работает у нас, то, например, денежное премирование у нас индивидуальное и основано на росте компетенций, а не на результате, команды достаточно однородны, спецы все крутые (а если нет, то быстро вырастают в крутых), создаваемый продукт один, вся команда сконцентрированна только на нем, проблемы с простаиванием не наблюдается, работаем в потоке, без итераций и почти не знаем слово «дедлайн».
А вот не все мои знакомые, которые называют себя QA, это понимают.
Наша команда закреплена надолго, точнее, в принципе не предусмотрено её переформирование, да и работаем мы над одним очень большим продуктом.
Поэтому бонусов от совместной работы мы имеем ещё больше.
Кстати, когда программисты и тестировщики стали работать вместе, они стали давать более реалистичные оценки.
Хотя, на самом деле, в последнее время мы почти отказались от оценок и сроков — поставляем фичи с той скоростью, с которой способны. И максимально часто. Нам повезло, заказчик нам доверяет.
Bug driven development не боимся. В одном из комментариев я уже ответил, что тестировщики теперь сконцентрированы все больше на написании автотестов, поэтому на ранних этапах им есть чем заняться.
Получается что-то вроде параллельной разработки. Да, к тому же мы работаем в потоке: закончил один тест, всегда есть следующий. Вопрос только в синхронизации, что бы ни программисты, ни тестировщики не убегали сильно вперед.
Читал о чем-то подобном в документах от Microsoft, про их философию разработки в TFS.
Буду признателен ссылке на книгу.
Теперь можно на языке этой теории сказать, что в данном случае основной ограничивающий фактор был конфликт интересов. Его причина — различие целей. Убрав это ограничение случился прорыв.
Думаю, когда эйфория от этого прорыва пройдет, стоит заняться поиском следующего ограничения.
Спасибо ещё раз, мне приятнее думать на языке каких-то умных теорий, нежели на своем «велосипедном».
Кто знает, может быть через пару лет на хабре появится статься «Война миров: отдел на отдел!».
Книжку отметил себе, спасибо.
В этой статье я специально не стал углубряться в необходимые внешние условия (думаю, это может стать отдельной большой статьей), а заострил внимание именно на сути подхода, что главное, это общая цель!
А если все-таки говорить про то, в каких усовиях это работает у нас, то, например, денежное премирование у нас индивидуальное и основано на росте компетенций, а не на результате, команды достаточно однородны, спецы все крутые (а если нет, то быстро вырастают в крутых), создаваемый продукт один, вся команда сконцентрированна только на нем, проблемы с простаиванием не наблюдается, работаем в потоке, без итераций и почти не знаем слово «дедлайн».