Кажется с нефункциональными требованиями, приведенными на слайде, некоторая путаница. Нефункциональные требования не говорят о том, как должна быть реализована система, по сути они чаще задают ограничения на нее: нагрузка, скорость открытия страниц, возможные размеры файлов, цветовое решение, необходимость скрытия персональных данных, работа на определенной платформе и т.д. Сейчас там прописаны тоже функциональные требования. Думаю, об НФТ стоит почитать отдельно :)
Тимлид драйвит команду, ведет встречи, общается с заказчиком по вопросам, которые затрагивают будущее развитие проекта, консультирует другие команды, снимает с аналитиков нагрузку в части документирования архитектурных решений (по задачам аналитики веду доку самостоятельно).
Техлид общается с архитектором и другими техлидами (проект большой, команд много) по вопросам техдолга, дефектов и развития системы, готовит шаблоны сервисов, консультирует где и какую информацию и доступы получить. Ну и код пишет, конечно.
В паре получается миникоманда внутри команды, которая разруливает какие-то вопросы, чтобы остальным работалось комфортно и весело.
Хм... В некоторых моментах читала и вспоминала свои примеры, когда в ходе аналитики (а паралленьно уже началась и разработка) требования менялись и дополнялись не один раз только потому, что заказчик не выдал всю историю сразу, а вспоминал какие-то детали процесса по ходу пьесы.
Дополнила бы, пожалуй, тем, что аналитик должен учиться читать между строк, чтобы замечать мелочи (они же нестыковки). А для этого помогает читать получившееся описание требований e2e.
Знакомая ситуация: удаленка, команду по сути целиком видишь крайне редко, дейли раз в день, хочется пройтись по задачам и задать минут 5 на простой треп, чтобы коллеги почувствовали, что мы все здесь, рядом, готовы поддержать, но… приходит менеджер и говорит — это все хорошо, команду ставят в пример другим в компании, но вот дейли не по-православному, полчаса, ай-ай-ай, надо урезать до 20 минут…
Когда руководитель всухую выполняет свои обязанности и там, где можно мягко подтолкнуть, применяет по шаблону вот такие бутерброды, то здесь, как правило, и начинаются проблемы.
А если встать на сторону команды? Представьте ситуацию, когда компания на проект набрала команду, ребята работают, пилят софт. В этой среде естественным образом появится человек, который возьмет на себя роль неофициального лидера, потому что ему, первое, не все равно, второе, не сложно выполнять какие-то организационные обязанности, он драйвит команду, а команда отвечает взаимностью — приходит за помощью и советом. Это и есть неформальный лидер. Такое происходит в любой организации — от дворовой компашки до спортивных команд и ИТ.
А потом руководство решает внедрить что-то новое. Приводит человека со стороны и говорит: вот, он теперь будет вашим лидом.
Он может стать лидом или нет. Все зависит от его поведения и того, как примет его команда.
А первый, который уже по сути лид, действительно вырос из команды и правильнее назначить его на эту роль, если руководство вдруг решило выделить эту позицию официально.
А уж кто это будет — аналитик, разработчик, РО или еще кто-то не так важно.
Кажется есть небольшая путаница с тем — может быть аналитик лидом или нет. Настоящего лида не могут назначить, он вырастает изнутри команды, за счет небезразличного отношения к коллективу и работе берет на себя некоторые организационные моменты, несет в разных случаях экспертизу о процессах развития продукта, общения с контрагентами и т.д., и т.п. Это получается "само собой". Ну поставят РО лидом, а оно ему нафиг не надо… И кому от этого легче?
Если я правильно поняла, то собственно сам процесс (история как таковая), тут стоит над user story, а в user story, которые отдаются разработчикам, отражен конкретный шаг: 1) поступил документ — выполни проверку, 2) выполнил проверку — выбрал маршрут движения, 3) выбрал маршрут — отдал документ дальше.
А что касаемо предыстории — тут, пожалуй, мы все вольно или нет приходим к привлечению разработчиков к этапу аналитики, когда показываешь проработанный процесс, приходишь с ними к общему пониманию того, что должно быть сделано, дробишь на шаги (user story) таким образом, чтобы именно им было удобно, и уже потом отдаешь в работу. По крайней мере у нас в команде происходит нечто подобное, поэтому в какой-то степени начали подсаживаться на DDD.
Автор, за статью большое спасибо :) Обсудили среди команды, будем «покурить» что можно изменить в своем процессе.
Подскажите, а можно посмотреть на боевые обезличенные ТЗ, чтобы уж совсем проникнуться?
Возможно потому, что в первый год, даже при хорошем владении теорией, сложно построить процесс на практике, так как нужно время на его адаптацию к команде?
Автотесты априори должны внедряться с самого начала. Количество времени, затрачиваемое на тестирование, не влияет на количество времени, которое программист тратит на написание кода при корректной постановке задачи. Речь в данном случае, о скорости работы конкретного специалиста, а не команды.
Инструменты agile, в свою очередь, нужны нам, чтобы разложить процесс по полочкам, чтобы заказчик видел эффективность каждого из игроков, чтобы сама команда могла настроить поток передачи задач из рук в рук. В этом случае на скорость команды можно повлиять. Но только в том случае, когда команда умеет пользоваться инструментами, настраивает скрипку под оркестр, а не заставляет весь оркестр играть в тональности одной ненастроенной скрипки.
Вот чего я понять не могу — с чего вдруг методологии, технологии и иже с ними, которые призваны ОРГАНИЗОВАТЬ процесс для того, чтобы он был более прозрачен извне, как-то должны влиять на скорость работы? Скорость аналитики, разработки, тестирования, документирования задач зависит от собственных скилов/лени игроков в команде, адекватности контрагентов и того, насколько команда — это действительно команда, а не коллектив разрозненных сотрудников.
Кажется, что то, кому разработчик поклоняется, — скраму или канбану, никак не влияет на то, с какой скоростью он продумывает код и потом воплощает его в жизнь.
Если на работу над user story ушло больше времени, чем запланировано, то, блин, просто ее оценили неправильно. По причине собственной неопытности, из-за того, что не были известны все данные, или заказчик просто на ходу переобулся. Правильную оценку можно почувствовать со временем. Видишь задачу и ощущаешь как долго придется вокруг нее танцевать. Ошибиться можно всегда. И это нормально. И для тех, кто живет по scrum, и для тех, кто выбрал для себя канбан.
Но самое крутое и вкусное, когда команда создает нечто свое, свой гибрид, который учтет и взаимоотношения с заказчиком, и настроение, с которым принято работать, и аналитика, внезапно свалившего в отпуск, но достающего даже оттуда.
В это и кайф agile — мы выбираем какими нам быть и какие команды строить!
Кажется с нефункциональными требованиями, приведенными на слайде, некоторая путаница. Нефункциональные требования не говорят о том, как должна быть реализована система, по сути они чаще задают ограничения на нее: нагрузка, скорость открытия страниц, возможные размеры файлов, цветовое решение, необходимость скрытия персональных данных, работа на определенной платформе и т.д. Сейчас там прописаны тоже функциональные требования. Думаю, об НФТ стоит почитать отдельно :)
У нас в команде техлид и тимлид работают в паре.
Тимлид драйвит команду, ведет встречи, общается с заказчиком по вопросам, которые затрагивают будущее развитие проекта, консультирует другие команды, снимает с аналитиков нагрузку в части документирования архитектурных решений (по задачам аналитики веду доку самостоятельно).
Техлид общается с архитектором и другими техлидами (проект большой, команд много) по вопросам техдолга, дефектов и развития системы, готовит шаблоны сервисов, консультирует где и какую информацию и доступы получить. Ну и код пишет, конечно.
В паре получается миникоманда внутри команды, которая разруливает какие-то вопросы, чтобы остальным работалось комфортно и весело.
Хм... В некоторых моментах читала и вспоминала свои примеры, когда в ходе аналитики (а паралленьно уже началась и разработка) требования менялись и дополнялись не один раз только потому, что заказчик не выдал всю историю сразу, а вспоминал какие-то детали процесса по ходу пьесы.
Дополнила бы, пожалуй, тем, что аналитик должен учиться читать между строк, чтобы замечать мелочи (они же нестыковки). А для этого помогает читать получившееся описание требований e2e.
Когда руководитель всухую выполняет свои обязанности и там, где можно мягко подтолкнуть, применяет по шаблону вот такие бутерброды, то здесь, как правило, и начинаются проблемы.
А если встать на сторону команды? Представьте ситуацию, когда компания на проект набрала команду, ребята работают, пилят софт. В этой среде естественным образом появится человек, который возьмет на себя роль неофициального лидера, потому что ему, первое, не все равно, второе, не сложно выполнять какие-то организационные обязанности, он драйвит команду, а команда отвечает взаимностью — приходит за помощью и советом. Это и есть неформальный лидер. Такое происходит в любой организации — от дворовой компашки до спортивных команд и ИТ.
А потом руководство решает внедрить что-то новое. Приводит человека со стороны и говорит: вот, он теперь будет вашим лидом.
Он может стать лидом или нет. Все зависит от его поведения и того, как примет его команда.
А первый, который уже по сути лид, действительно вырос из команды и правильнее назначить его на эту роль, если руководство вдруг решило выделить эту позицию официально.
А уж кто это будет — аналитик, разработчик, РО или еще кто-то не так важно.
Кажется есть небольшая путаница с тем — может быть аналитик лидом или нет. Настоящего лида не могут назначить, он вырастает изнутри команды, за счет небезразличного отношения к коллективу и работе берет на себя некоторые организационные моменты, несет в разных случаях экспертизу о процессах развития продукта, общения с контрагентами и т.д., и т.п. Это получается "само собой". Ну поставят РО лидом, а оно ему нафиг не надо… И кому от этого легче?
А что касаемо предыстории — тут, пожалуй, мы все вольно или нет приходим к привлечению разработчиков к этапу аналитики, когда показываешь проработанный процесс, приходишь с ними к общему пониманию того, что должно быть сделано, дробишь на шаги (user story) таким образом, чтобы именно им было удобно, и уже потом отдаешь в работу. По крайней мере у нас в команде происходит нечто подобное, поэтому в какой-то степени начали подсаживаться на DDD.
Подскажите, а можно посмотреть на боевые обезличенные ТЗ, чтобы уж совсем проникнуться?
Инструменты agile, в свою очередь, нужны нам, чтобы разложить процесс по полочкам, чтобы заказчик видел эффективность каждого из игроков, чтобы сама команда могла настроить поток передачи задач из рук в рук. В этом случае на скорость команды можно повлиять. Но только в том случае, когда команда умеет пользоваться инструментами, настраивает скрипку под оркестр, а не заставляет весь оркестр играть в тональности одной ненастроенной скрипки.
Кажется, что то, кому разработчик поклоняется, — скраму или канбану, никак не влияет на то, с какой скоростью он продумывает код и потом воплощает его в жизнь.
Если на работу над user story ушло больше времени, чем запланировано, то, блин, просто ее оценили неправильно. По причине собственной неопытности, из-за того, что не были известны все данные, или заказчик просто на ходу переобулся. Правильную оценку можно почувствовать со временем. Видишь задачу и ощущаешь как долго придется вокруг нее танцевать. Ошибиться можно всегда. И это нормально. И для тех, кто живет по scrum, и для тех, кто выбрал для себя канбан.
Но самое крутое и вкусное, когда команда создает нечто свое, свой гибрид, который учтет и взаимоотношения с заказчиком, и настроение, с которым принято работать, и аналитика, внезапно свалившего в отпуск, но достающего даже оттуда.
В это и кайф agile — мы выбираем какими нам быть и какие команды строить!