agile и платформа
В последнее время столкнулся с одной проблемой, к которой не удается толком подступиться.Кратко проблему можно обозначить так, можно ли применять Agile при разработке комплексных систем/платформ.
Ключевой особенностью agile является получение фидбека на результат наискорейшим образом и в соответствии с фидбеком корректировать дальнейшую работу. И так по по циклу.
Сейчас на своей работе наша команда пытается создать новую платформу, которая придет на смену существующей платформе. Существующая платформа достаточно успешно существует уже более 6 лет, на ней построено почти десяток продуктов, суммарное количество инсталляций думаю зашкаливает за тысячи. Решение разрабатывать новую платформу (а не развивать относительно успешную старую) базировалось на наличии большого количество системных "недопроработок" и самобытности технологий используемых в старой платформе. И соответственно новая платформа должна быть более проработанной и базироваться промышленных технологиях.
И проблема заключается в том, как достичь проработанности в Agile. Скорейшее получение результата противоречит некоторой системности и проработанности, а вкладывание значительных ресурсов в проработку, без получения фидбека, противоречит идеям Agile.
В целом, несмотря на применение методологии SCRUM, проработка деталей платформы велась практически без использования элементов методологии. Мы не планировали структуру документов, тезисы разделов документов, аспекты, которые надо отразить в документации по платформе, хотя в кодировании прототипа и кодировании платформы уделяли и уделяем подобным вопросам значительную часть времени на планировании спринта. Отчасти, это объясняется тем, что разработка документов и программирование - разные направления деятельности. И большей части команды интереснее разработка, поэтому планирование документов не находило соответствующего энтузиазма.
Наверное, тут есть следующие проблемы:
- изначально целью ставилось проработать идеи платформы, а не развивать их постепенно, рассказывая и демонстрирую достижения на примере определенного продукта
- в команде совмещены аналитики, архитекторы, программисты, которые несколько на разных уровнях воспринимает детали своих задач и поэтому на планировании одни углубляются в одно, другие в другое.
- идеи сложно демонстрировать. Я не представляю как получить качественный фидбек на документации. (Представил себе, заказчика прочитавшего решения его проблем в виде документа, сделавшего ментальное усилие и представишего продукт, который получится, и после это воскликнувший ВАУ). Это нереально
В общем ищу решение.
Ключевой особенностью agile является получение фидбека на результат наискорейшим образом и в соответствии с фидбеком корректировать дальнейшую работу. И так по по циклу.
Сейчас на своей работе наша команда пытается создать новую платформу, которая придет на смену существующей платформе. Существующая платформа достаточно успешно существует уже более 6 лет, на ней построено почти десяток продуктов, суммарное количество инсталляций думаю зашкаливает за тысячи. Решение разрабатывать новую платформу (а не развивать относительно успешную старую) базировалось на наличии большого количество системных "недопроработок" и самобытности технологий используемых в старой платформе. И соответственно новая платформа должна быть более проработанной и базироваться промышленных технологиях.
И проблема заключается в том, как достичь проработанности в Agile. Скорейшее получение результата противоречит некоторой системности и проработанности, а вкладывание значительных ресурсов в проработку, без получения фидбека, противоречит идеям Agile.
В целом, несмотря на применение методологии SCRUM, проработка деталей платформы велась практически без использования элементов методологии. Мы не планировали структуру документов, тезисы разделов документов, аспекты, которые надо отразить в документации по платформе, хотя в кодировании прототипа и кодировании платформы уделяли и уделяем подобным вопросам значительную часть времени на планировании спринта. Отчасти, это объясняется тем, что разработка документов и программирование - разные направления деятельности. И большей части команды интереснее разработка, поэтому планирование документов не находило соответствующего энтузиазма.
Наверное, тут есть следующие проблемы:
- изначально целью ставилось проработать идеи платформы, а не развивать их постепенно, рассказывая и демонстрирую достижения на примере определенного продукта
- в команде совмещены аналитики, архитекторы, программисты, которые несколько на разных уровнях воспринимает детали своих задач и поэтому на планировании одни углубляются в одно, другие в другое.
- идеи сложно демонстрировать. Я не представляю как получить качественный фидбек на документации. (Представил себе, заказчика прочитавшего решения его проблем в виде документа, сделавшего ментальное усилие и представишего продукт, который получится, и после это воскликнувший ВАУ). Это нереально
В общем ищу решение.