Добрый день. Есть такой подход к управлению проектами как Scrum. Одним из элементов которого является ежедневный стендап (standup). На него планируется 10-15 минут. Исходя из названия он проходит стоя. У него очень жесткий регламент. Ведущий совещания (teamlead или scrum-master) задает каждому три вопроса: - Что сделано? (не что делаешь, а что сделано. Это позволяет оценивать прогресс проекта и мотивирует сотрудника что-то делать, т.к. один день не сказал что сделал, второй, на третий уже не понятно зачем ты на работу ходишь). - Что планируешь делать дальше? (чтобы все знали планы всех, чтобы за одну задачу не брались двое-трое). - Какие есть проблемы? (привлекает внимание руководителя и тех сотрудников которые могут помочь в решении проблемы). Нельзя ничего обсуждать сверх этих вопросов. Этакая синхронизация информационного поля в головах сотрудников. Работает весьма эффективно. Главной укладываться в лимит 15 минут и поддерживать регламент трех вопросов.
Почему дико? Есть список задач которые необходимо решить в рамках спринта. Любую из задач которая помечена "разработка" может взять любой программист. Следовательно, несколько человек могут посматривать в сторону одной задачи. Например, Ирина доделывает задачу А и хочет попробовать решить задачу Б. Но, т.к. она еще делает задачу А, то задачу Б она не занимает. Сирежа закончил все свои задачи и выбирает новую, ага, есть свободные Б и В. Но, помня про то что Ирина хотела взять Б, он возьмет В. И овцы целы (задачи решаются) и волки сыты (Ирина решает задачу которая ей интересна).
ага, спасибо я так понимаю, самое интересное начинается, когда вместо галантного Серёжи появляется Ольга, которая тоже хочет задачу Б. Пастуху всё равно придётся выйти
В Agile манифесте (на котором строятся все гибкие методики) есть такой пункт: "Люди важнее процессов". Да, если у вас люди так себе, то процессы не помогут. Но это уже, согласитесь, другая сказка. Еще раз, задача руководителя и процесса сделать разработку эффективной. Вполне возможно, что когда Ирина скажет: "Я планирую взять задачу Б", тимлид ей ответит: "Ирин, ты уже такие задачи решаешь как семечки, давая дадим ее порешать кому ни будь другому, с целью увеличения коэффициента грузовика". Как то так ;)
Задача руководителя процесса в сраме - это не эффективность работы в терминах результата, а эффективность загрузки работников в смысле "пусть слоники побегают". В большинстве случаев там даже нет времени на то, чтобы подумать над решением.
Очень печально, что у вас именно такой опыт знакомства со Scrum. Я не буду вас переубеждать, я просто расскажу пример из недалекого прошлого. Ко мне подошел руководитель команды разработчиков с просьбой помочь разобраться что у них не так с этим скрамом (они запланированную на спринт работу не могли закончить). На мой вопрос о том, как у них проходит планирование я узнал, что есть специальный человек, который оценивает элементы бэклога, берет их в спринт, разбивает на задачи, оценивает задачи и даже назначает их на исполнителей. Так вот, это не Scrum. У вас, видимо, был тоже не Scrum.
К сожалению, или к счастью, "серебряной пули" - нет. А про мозги, в том комментарии на который вы отвечали, есть фраза: "Люди важнее процессов". Если у вас есть толпа людей-снежинок (руки из жопы), то вы с самым замечательным процессом завалите самое простое дело. А вот с адекватными людьми, заинтересованными в результате, даже без формального процесса все у вас будет хорошо. Нет, процесс у вас все равно появится, т.к. будут возникать проблемы, потом какие то проблемы будут признаны типовыми, потом для этих типовых проблем будут разработаны устраивающее всех решения, так вы и будите строить свой процесс. Именно к этому, кстати, призывает Agile. Берете Scrum за основу (или не Scrum, а CMMI или Kanban), а потом смотрите какие из практик "ложатся" на вашу команду, ваши задачи и их оставляете. Те же, которые не эффективны, отметаете и заменяете более подходящими именно вам. Именно улучшение процессов идет одним из требований Agile в общем и Scrum в частности.
А про мозги, в том комментарии на который вы отвечали, есть фраза: "Люди важнее процессов".
Можно повторять любые мантры. Но ужасающее падение средней квалификации программистов - это печальный факт, от которого никуда не деться.
Если уж на то пошло, то agile бывает только третьего уровня. Всё остальное - закостенелая религия. (Включая и "правильный Scrum") Вот только, третий уровень - это уже не agile.
Э... Вы предлагает в связи с "падение средней квалификации программистов" их расстреливать? Вполне возможно, что я не прав, но моя задача как руководителя состоит за 4 частей
( ... )
1. Ну да, именно по этой причине в законодательстве нашей страны есть испытательный срок 3 месяца. Да, дорого, но это еще один шанс если вы сфейлили собеседование. 2. Ок. Может быть то что присылает заказчик не соответствует ГОСТ 34.602-89, но у него есть проблема и он согласен за ее решение заплатить деньги. Мне его прогонять? Стратегия, эх... А что вы понимаете под стратегией в отношении руководителя команды разработчиков? Если стратегию развития команды, то я про нее написал, если стратегию развития разрабатываемых систем, так это проблема не только руководителя, но и команды, которая должна делать все возможное чтобы облегчить себе жизнь... Или про что вы ?
Спасибо, вы имели в виду вот эту книгу: Alistair Cockburn - Agile Software Development или что-то другое?
Именно. Собственно по этим причинам я и указываю что входной контроль персонала является одной из основных задач менеджера. Я могу ошибаться, но у вопроса "что будет?" есть два варианта: "Что будет в краткосрочной перспективе?" и "Что будет в долгосрочной перспективе?". У менеджера нижнего звена, которым является руководитель команды разработчиков, более актуален первый вопрос, а это все таки не стратегия, а тактика. Да, тактическим планированием приходится заниматься, куда же без этого. Прогнозирование следующих итераций, анализ развития текущей итерации и принятие решений по предотвращению проблем в ней возникающих. Но это все не стратегия...
Есть такой подход к управлению проектами как Scrum. Одним из элементов которого является ежедневный стендап (standup). На него планируется 10-15 минут. Исходя из названия он проходит стоя. У него очень жесткий регламент. Ведущий совещания (teamlead или scrum-master) задает каждому три вопроса:
- Что сделано? (не что делаешь, а что сделано. Это позволяет оценивать прогресс проекта и мотивирует сотрудника что-то делать, т.к. один день не сказал что сделал, второй, на третий уже не понятно зачем ты на работу ходишь).
- Что планируешь делать дальше? (чтобы все знали планы всех, чтобы за одну задачу не брались двое-трое).
- Какие есть проблемы? (привлекает внимание руководителя и тех сотрудников которые могут помочь в решении проблемы).
Нельзя ничего обсуждать сверх этих вопросов. Этакая синхронизация информационного поля в головах сотрудников. Работает весьма эффективно. Главной укладываться в лимит 15 минут и поддерживать регламент трех вопросов.
Reply
Reply
Reply
я так понимаю, самое интересное начинается, когда вместо галантного Серёжи появляется Ольга, которая тоже хочет задачу Б.
Пастуху всё равно придётся выйти
Reply
Еще раз, задача руководителя и процесса сделать разработку эффективной. Вполне возможно, что когда Ирина скажет: "Я планирую взять задачу Б", тимлид ей ответит: "Ирин, ты уже такие задачи решаешь как семечки, давая дадим ее порешать кому ни будь другому, с целью увеличения коэффициента грузовика". Как то так ;)
Reply
Reply
Ко мне подошел руководитель команды разработчиков с просьбой помочь разобраться что у них не так с этим скрамом (они запланированную на спринт работу не могли закончить). На мой вопрос о том, как у них проходит планирование я узнал, что есть специальный человек, который оценивает элементы бэклога, берет их в спринт, разбивает на задачи, оценивает задачи и даже назначает их на исполнителей.
Так вот, это не Scrum. У вас, видимо, был тоже не Scrum.
Reply
Ни один процесс не может заменить отсутствие мозгов.
Reply
А про мозги, в том комментарии на который вы отвечали, есть фраза: "Люди важнее процессов". Если у вас есть толпа людей-снежинок (руки из жопы), то вы с самым замечательным процессом завалите самое простое дело. А вот с адекватными людьми, заинтересованными в результате, даже без формального процесса все у вас будет хорошо. Нет, процесс у вас все равно появится, т.к. будут возникать проблемы, потом какие то проблемы будут признаны типовыми, потом для этих типовых проблем будут разработаны устраивающее всех решения, так вы и будите строить свой процесс. Именно к этому, кстати, призывает Agile. Берете Scrum за основу (или не Scrum, а CMMI или Kanban), а потом смотрите какие из практик "ложатся" на вашу команду, ваши задачи и их оставляете. Те же, которые не эффективны, отметаете и заменяете более подходящими именно вам. Именно улучшение процессов идет одним из требований Agile в общем и Scrum в частности.
Reply
Можно повторять любые мантры. Но ужасающее падение средней квалификации программистов - это печальный факт, от которого никуда не деться.
Если уж на то пошло, то agile бывает только третьего уровня. Всё остальное - закостенелая религия. (Включая и "правильный Scrum") Вот только, третий уровень - это уже не agile.
Reply
Reply
В принципе, это тоже вариант.
1. Даже Гугл не может определить на интервью, хороший ли программист или плохой. Тем более, что критериев никто в мире не знает.
2. Если программисты не понимают, что хочет заказчик, то они просто неквалифицированные кодеры. И то, что требует перевода, не называется ТЗ.
Ещё замечательно, что среди 4 задач нет стратегии.
Что то я первый раз столкнулся с термином "agile третьего уровня
Вот так элементарные вещи становятся сакралными знаниями. Можно, например, посмотреть, что на эту тему написал Cockburn.
Reply
2. Ок. Может быть то что присылает заказчик не соответствует ГОСТ 34.602-89, но у него есть проблема и он согласен за ее решение заплатить деньги. Мне его прогонять?
Стратегия, эх... А что вы понимаете под стратегией в отношении руководителя команды разработчиков? Если стратегию развития команды, то я про нее написал, если стратегию развития разрабатываемых систем, так это проблема не только руководителя, но и команды, которая должна делать все возможное чтобы облегчить себе жизнь... Или про что вы ?
Спасибо, вы имели в виду вот эту книгу: Alistair Cockburn - Agile Software Development или что-то другое?
Reply
Стратегия - это всегда ответ на вопрос "что будет?" И цель должен указывать капитан, а не команда грести, куда каждому хочется.
Насколько помню, в той книжке это тоже есть.
Reply
Я могу ошибаться, но у вопроса "что будет?" есть два варианта: "Что будет в краткосрочной перспективе?" и "Что будет в долгосрочной перспективе?". У менеджера нижнего звена, которым является руководитель команды разработчиков, более актуален первый вопрос, а это все таки не стратегия, а тактика. Да, тактическим планированием приходится заниматься, куда же без этого. Прогнозирование следующих итераций, анализ развития текущей итерации и принятие решений по предотвращению проблем в ней возникающих. Но это все не стратегия...
Reply
Leave a comment