Здравствуйте
Наверное, вопрос касается общей темы — как продвинуть себя
Дело такое.
Заметил, что процесс у нас не отвечает никаким методологиям/фреймуоркам, ну может немного смахивает на водопад
3-4 месяца интересуюсь Agile методоглогиями, тема понравилась, читаю и смотрю много чего, записался на курс CSM. И всё потому, что тема мне нравится. А не для того, чтобы кому-то что-то...
Представил начальнику примерную схему и объяснил что к чему
Как только это произошло и манагер начал шевелиться, один товарищ, более приблеженный к нему, начал брать тему в свои руки, не понимая ничего и отвечая на вопросы начальника с помощью поиска ответов в IPhone. Не буду загрязнять пост особенностями "товарища".
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, zfima, Вы писали:
Z>>Наверное, вопрос касается общей темы — как продвинуть себя 0>А ты с какой целью хочешь это сделать?
Мне просто это интересно и хотель бы развится в этом направлении.
Наверное, внутренне, был бы горд за себя, если бы мог улучшить процесс.
Здравствуйте, zfima, Вы писали:
Z>Мне просто это интересно и хотел бы развиться в этом направлении. Z>Наверное, внутренне, был бы горд за себя, если бы мог улучшить процесс.
Ок, а что или кто тебе мешает принимать участие в этом процессе в инициативном порядке?
Здравствуйте, zfima,
Z>Заметил, что процесс у нас не отвечает никаким методологиям/фреймуоркам, ну может немного смахивает на водопад Z>3-4 месяца интересуюсь Agile методоглогиями, тема понравилась, читаю и смотрю много чего, записался на курс CSM.
1. Какие проблемы ты хочешь решить с помощью [некоей методологии]?
2. Ты уверен, что эти проблемы представляются существенными не только тебе, но и руководству/владельцам компании? Обзор/обсуждение возможных путей решения проблем проводились?
3. Почему именно [некая методология]? Какие у тебя есть аргументы кроме "тема понравилась"?
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, zfima, Вы писали:
Z>>Мне просто это интересно и хотел бы развиться в этом направлении. Z>>Наверное, внутренне, был бы горд за себя, если бы мог улучшить процесс. 0>Ок, а что или кто тебе мешает принимать участие в этом процессе в инициативном порядке?
Потому как мне не хочется носить футболки со звездными войнами и слушать любимые группы начальника и прибегать к всяким уловкам
Должно быть, наверное, по другому
Кроме того, так, думаю кросс-функциональную команду не построишь
Здравствуйте, zfima, Вы писали:
Z>Потому как мне не хочется носить футболки со звездными войнами и слушать любимые группы начальника и прибегать к всяким уловкам Z>Должно быть, наверное, по другому Z>Кроме того, так, думаю кросс-функциональную команду не построишь
Я не сильно понял пассаж про футболки
Поясни.
Z>Пока просто дезайню и программирую
Так ты процесс не поменяешь
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, zfima,
Z>>Заметил, что процесс у нас не отвечает никаким методологиям/фреймуоркам, ну может немного смахивает на водопад Z>>3-4 месяца интересуюсь Agile методоглогиями, тема понравилась, читаю и смотрю много чего, записался на курс CSM.
V_S>1. Какие проблемы ты хочешь решить с помощью [некоей методологии]? V_S>2. Ты уверен, что эти проблемы представляются существенными не только тебе, но и руководству/владельцам компании? Обзор/обсуждение возможных путей решения проблем проводились? V_S>3. Почему именно [некая методология]? Какие у тебя есть аргументы кроме "тема понравилась"?
1. Проблему простоя или гонок. Проблему, что клиент видит продукт в конце девелопмента, т.е. через пол-года. Проблему, что на 5000 солюшенов нет ни одного юнит теста. Проблему, что нет команды, сроки кидаются в воздух, мысль о парном программировании вводить коллег в ужас. В принципе, клиент у нас находится внутри компании... так что и так пойдёт.
2. Обсуждение я начинал с начальником недели 3 назад. Постепенно визуализировая процесс и нахождения пути.
3. Ну, с чего то надо начать. В скраме не так много ограничений, хотя если и их будет слишком много, можно дискуссировать о канбане, например. Аргументы — хочу сделать процесс лучше.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, zfima, Вы писали:
Z>>Потому как мне не хочется носить футболки со звездными войнами и слушать любимые группы начальника и прибегать к всяким уловкам Z>>Должно быть, наверное, по другому Z>>Кроме того, так, думаю кросс-функциональную команду не построишь 0>Я не сильно понял пассаж про футболки 0>Поясни.
Фууу, не люблю это. Ну ладно...
Ну, на пример ты начальник. Любишь музыку самоа, картины художника П. и фильмы о тасмании. Чудесным образом мне тоже всё это нравится!
Z>>Пока просто дезайню и программирую 0>Так ты процесс не поменяешь
Здравствуйте, zfima, Вы писали:
Z>Фууу, не люблю это. Ну ладно... Z>Ну, на пример ты начальник. Любишь музыку самоа, картины художника П. и фильмы о тасмании. Чудесным образом мне тоже всё это нравится!
Ну и что?
Мне как-то ни разу не приходилось подмазываться к начальству таким образом, чтобы поучаствовать в решении проблем проекта.
Может быть ты всё усложняешь и ищешь трудного подхода там, где можно просто поговорить?
Z>1. Проблему простоя или гонок. Проблему, что клиент видит продукт в конце девелопмента, т.е. через пол-года. Проблему, что на 5000 солюшенов нет ни одного юнит теста. Проблему, что нет команды, сроки кидаются в воздух, мысль о парном программировании вводить коллег в ужас. В принципе, клиент у нас находится внутри компании... так что и так пойдёт. Z>2. Обсуждение я начинал с начальником недели 3 назад. Постепенно визуализировая процесс и нахождения пути. Z>3. Ну, с чего то надо начать. В скраме не так много ограничений, хотя если и их будет слишком много, можно дискуссировать о канбане, например. Аргументы — хочу сделать процесс лучше.
прочитал это и скажу тебе одно: хреновый у тебя началъник или ты один программист в отделе сбыта?
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, zfima, Вы писали:
Z>>Фууу, не люблю это. Ну ладно... Z>>Ну, на пример ты начальник. Любишь музыку самоа, картины художника П. и фильмы о тасмании. Чудесным образом мне тоже всё это нравится! 0>Ну и что? 0>Мне как-то ни разу не приходилось подмазываться к начальству таким образом, чтобы поучаствовать в решении проблем проекта. 0>Может быть ты всё усложняешь и ищешь трудного подхода там, где можно просто поговорить?
Здравствуйте, pik, Вы писали:
pik>Здравствуйте, zfima, Вы писали:
Z>>1. Проблему простоя или гонок. Проблему, что клиент видит продукт в конце девелопмента, т.е. через пол-года. Проблему, что на 5000 солюшенов нет ни одного юнит теста. Проблему, что нет команды, сроки кидаются в воздух, мысль о парном программировании вводить коллег в ужас. В принципе, клиент у нас находится внутри компании... так что и так пойдёт. Z>>2. Обсуждение я начинал с начальником недели 3 назад. Постепенно визуализировая процесс и нахождения пути. Z>>3. Ну, с чего то надо начать. В скраме не так много ограничений, хотя если и их будет слишком много, можно дискуссировать о канбане, например. Аргументы — хочу сделать процесс лучше.
pik>прочитал это и скажу тебе одно: хреновый у тебя началъник или ты один программист в отделе сбыта?
Здравствуйте, zfima, Вы писали:
Z>Вполне возможно, я не объективный
В таком случае рекомендую спокойно прикинуть спектр своих возможностей по влиянию на процесс.
Z>Ну, наверное собирает требования и пришпиливает их программерам. Z>Ну, и в конце проекта ездит в штаты и презентует. Z>Вообще, он нормальный, только может просто не объективный
так я ещё не понял, если вас много то у вас началъника отдела по программистам нету?
Здравствуйте, pik, Вы писали:
pik>Здравствуйте, zfima, Вы писали:
Z>>Ну, наверное собирает требования и пришпиливает их программерам. Z>>Ну, и в конце проекта ездит в штаты и презентует. Z>>Вообще, он нормальный, только может просто не объективный
pik>так я ещё не понял, если вас много то у вас началъника отдела по программистам нету?
Извините, может я плохо объяснил.
У нас есть начальник отдела программеров. У него в подчинение находится примерно 30 программеров.
И он ПОНИМАЕТ, что процесс отстой
Здравствуйте, zfima, Вы писали:
Z>И он ПОНИМАЕТ, что процесс отстой
Дык? Если он понимает, и если обсуждение с ним уже проводилось, — в чем проблема-то? Тогда поговори с ним уже конкретнее: "Вот есть [некая методология], она позволит решить такие-то и такие-то проблемы, за такой-то срок. Я готов взяться за внедрение этой методологии. Считаю, что в такие-то сроки будут достигнуты такие-то показатели качества разработки. Мне нужна административная поддержка от Вас такая-то."
Здравствуйте, zfima, Вы писали:
Z>Извините, может я плохо объяснил. Z>У нас есть начальник отдела программеров. У него в подчинение находится примерно 30 программеров. Z>И он ПОНИМАЕТ, что процесс отстой
ну вернулисъ мы назад, после того что ты тут написал вывод может бытъ один — он не соответсвует своей должности и гнатъ его надо в шею, разве это не очевидно?
Здравствуйте, pik, Вы писали:
pik>Здравствуйте, zfima, Вы писали:
Z>>Извините, может я плохо объяснил. Z>>У нас есть начальник отдела программеров. У него в подчинение находится примерно 30 программеров. Z>>И он ПОНИМАЕТ, что процесс отстой
pik>ну вернулисъ мы назад, после того что ты тут написал вывод может бытъ один — он не соответсвует своей должности и гнатъ его надо в шею, разве это не очевидно?
Ну, 1-е: я этого не могу
2-е: в теории, он готов к изменениям
V_S>это, конечно же, очевидно, но думаю, что "гнать его в шею" находится вне полномочий ТС.
ну это как посмотретъ на ситуацию. если он начал "воду мутитъ" а началъник отдела совсем "не в теме" то естъ вариант что он может вышестоящему руководтсву о ситуации доложитъ, сделатъ предложения, показатъ как надо как должно бытъ ну и если убедит то занятъ позицию НО
Здравствуйте, pik, Вы писали:
pik>Здравствуйте, Vlad_SP, Вы писали:
V_S>>это, конечно же, очевидно, но думаю, что "гнать его в шею" находится вне полномочий ТС.
pik>ну это как посмотретъ на ситуацию. если он начал "воду мутитъ" а началъник отдела совсем "не в теме" то естъ вариант что он может вышестоящему руководтсву о ситуации доложитъ, сделатъ предложения, показатъ как надо как должно бытъ ну и если убедит то занятъ позицию НО
Здравствуйте, zfima, Вы писали:
pik>>ну это как посмотретъ на ситуацию. если он начал "воду мутитъ" а началъник отдела совсем "не в теме" то естъ вариант что он может вышестоящему руководтсву о ситуации доложитъ, сделатъ предложения, показатъ как надо как должно бытъ ну и если убедит то занятъ позицию НО
Z>И сразу можно апдейтить резюме
Лично я не вижу в этом желании никакого смысла. Лучше апдейтить резюме высококлассным продуктом.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, zfima, Вы писали:
Z>>Заметил, что процесс у нас не отвечает никаким методологиям/фреймуоркам, ну может немного смахивает на водопад
Pzz>А есть какие-то проблемы, кроме несоответствия процесса методологиям и фреймворкам?
Ну, я писал...
" Проблему простоя или гонок. Проблему, что клиент видит продукт в конце девелопмента, т.е. через пол-года. Проблему, что на 5000 солюшенов нет ни одного юнит теста. Проблему, что нет команды, сроки кидаются в воздух, мысль о парном программировании вводить коллег в ужас."
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, zfima, Вы писали:
Z>>И он ПОНИМАЕТ, что процесс отстой
V_S>Дык? Если он понимает, и если обсуждение с ним уже проводилось, — в чем проблема-то? Тогда поговори с ним уже конкретнее: "Вот есть [некая методология], она позволит решить такие-то и такие-то проблемы, за такой-то срок. Я готов взяться за внедрение этой методологии. Считаю, что в такие-то сроки будут достигнуты такие-то показатели качества разработки. Мне нужна административная поддержка от Вас такая-то."
Наверное, самая подходящее решение.
У меня только нет опыта в этой отрасли.
Но есть много мотивации
Здравствуйте, zfima, Вы писали:
Z>[1]" Проблему простоя или гонок. [2]Проблему, что клиент видит продукт в конце девелопмента, т.е. через пол-года. [3]Проблему, что на 5000 солюшенов нет ни одного юнит теста. [4]Проблему, что нет команды, [5]сроки кидаются в воздух, [6]мысль о парном программировании вводить коллег в ужас."
1 — существует в каком-то виде при любом процессе. Проблема в том, что люди не машины, и их производительность колеблется в широких пределах. Кроме того, не существует точных методик оценки трудоемкости того или иного задания, до того, как это задание исполненно.
2 — покажите ему промежуточные версии вашего продукта. Независимо от методик, они существуют. Не может быть так, чтобы вы полгода писали, а что-то работающее появилось только за неделю до релиза
3 — это, заметьте, само по себе проблемой не является. Проблема, это когда много ошибок в софтварии, или софтварий разваливается при попытке в нем что-то изменить и т.д. и т.п.
4 — что это значит?
5 — что это значит?
6 — меня она тоже приводит в ужас, если честно. Вернее, в недоумение. Парно хорошо детей делать и двуручной пилой пилить, а не программы писать.
Здравствуйте, zfima, Вы писали:
Z>Ну, я писал...
Первый Ваш пост был слегка сумбурный и содержал много очень разных мыслей.
И продвижение себя и налаживание процесса и проблемы взаимотношений с начальством и "товарищем" итд.
А вот по поводу перечисленных Вами проблем все уже гораздо понятнее.
Z> Проблему простоя или гонок.
Это больше похоже на плохое планирование. И эта проблема может существовать при любой методологии.
Z> Проблему, что клиент видит продукт в конце девелопмента, т.е. через пол-года.
Ну если есть чего показать раньше, то кто мешает. А если нечего показать, то методология не поможет.
Про короткие итерации с рабочим продуктом в конце я знаю, но встречал подобное в командах, которые и слова Agile не слыхали.
Z> Проблему, что на 5000 солюшенов нет ни одного юнит теста.
Вообше то юнит тесты можно добавить вне зависимости от методологии. И более того, никакая методология сама их не добавит.
Z> Проблему, что нет команды,
Если я правильно понял, то плохо с командной работой. С взаимодействием внутри команды.
Это бывает, но методология эту проблему не решает.
Мне даже кажется что успех любой методологии будет сильно зависить от того, как сработаются люди в команде.
Z> сроки кидаются в воздух,
Ну проблема сроков она всегда актуальна.
Просто когда в результате разработки выходит качественный продукт, то всегда находится вариант, который и заказчика и исполнителей устраивает.
Z> мысль о парном программировании вводить коллег в ужас."
Само по себе парное программирование — это очень специфичная методика и наверно если есть желание внедрить это, то надо начинать издалека.
Например с коллективного владения кодом, применения общих стандартов кодирования, улучшения взаимодействия между членами команды.
А вот если этого всего достичь, то и ужасом парная работа уже казаться не будет да может оказаться что и без нее все хорошо
В общем я совсем не противник скрама или чего другого. Возможно что в Вашем случае это даст положительный эффект.
Но главное не ожидать от методологии волшебного решения всех проблем.
Ожидать, что их решит начальник, тоже не стоит.
А уж станете ли Вы скрам мастером или старшим разработчиком, или лидом — это уже совсем не так важно
Проектирование велосипедов для слепых жирафов
Re: Продвижение себя в качестве скрам мастера
От:
Аноним
Дата:
31.07.13 15:10
Оценка:
Здравствуйте, zfima, Вы писали:
Z>Как быть? Дать им всё завалить?
Можешь дать им завалить.
Судя по всему у вас там программеров раз два и обчелся и потому наверное приходится заниматься мышинной вознейю.
Можешь сменить работу где программеров побольше и где простора соответственно больш.
У нас, к примеру, больше десятка команд. Скрам мастерами точно не все хотят быть
и порой приходится искать кто бы взял на себя эту роль.
Никакой магии в этом нету. При нормально поставленном скраме обычный девелопер
имеет ровно столько же позможностей повлиять на процесс,
как и скрам мастер. скрам мастер — это точно не пуп земли, даже в масштабах одной команды.
Он ничего решает и никому не приказывает. Роль у него очень четкая и даже странно слышать,
что об этой роли кто-то может мечтать и за обладание этой ролью приходится конкурировать
Здравствуйте, zfima, Вы писали:
Z>1. Проблему простоя или гонок.
Это реально есть или в книжке прочитано?
Z>Проблему, что клиент видит продукт в конце девелопмента, т.е. через пол-года.
Это стало реальной проблемой для бизнеса или в книжке прочитано?
Z>Проблему, что на 5000 солюшенов нет ни одного юнит теста.
Это не проблема
Z>Проблему, что нет команды, сроки кидаются в воздух,
Это стало реальной проблемой для бизнеса или в книжке прочитано?
Z>мысль о парном программировании вводить коллег в ужас.
И это тоже не проблема. Вообще, использование Agile или RUP, использование табов или пробелов, использование svn или git или perforce, будь он неладен, а так же то, что начальник слушает музыку Самоа и смотрит фильмы про Тасманию — всё это не проблемы.
Z>3. Ну, с чего то надо начать. В скраме не так много ограничений, хотя если и их будет слишком много, можно дискуссировать о канбане, например. Аргументы — хочу сделать процесс лучше.
Что значит "лучше"? Разверните, а то получается как в анекдоте про армянское радио: "Армяне лучше чем грузины. — Чем лучше? — Чем грузины."
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, zfima, Вы писали:
Z>>[1]" Проблему простоя или гонок. [2]Проблему, что клиент видит продукт в конце девелопмента, т.е. через пол-года. [3]Проблему, что на 5000 солюшенов нет ни одного юнит теста. [4]Проблему, что нет команды, [5]сроки кидаются в воздух, [6]мысль о парном программировании вводить коллег в ужас."
Pzz>1 — существует в каком-то виде при любом процессе. Проблема в том, что люди не машины, и их производительность колеблется в широких пределах. Кроме того, не существует точных методик оценки трудоемкости того или иного задания, до того, как это задание исполненно.
Ну, мы вообще производительность не измеряем никак.
Pzz>2 — покажите ему промежуточные версии вашего продукта. Независимо от методик, они существуют. Не может быть так, чтобы вы полгода писали, а что-то работающее появилось только за неделю до релиза
Именно так. И почему то есть предпочтение, чтобы клиент вообще не знал, чем мы занимаемся.
И ещё раз — презентация раз в пол-года.
Pzz>3 — это, заметьте, само по себе проблемой не является. Проблема, это когда много ошибок в софтварии, или софтварий разваливается при попытке в нем что-то изменить и т.д. и т.п.
Если система большая и не покрыта тестами, и ее не писали трансформеры — ошибок будет много.
Думаю, что это является проблемой. Так как люди считают, что это лишнее (код, время)
Pzz>4 — что это значит?
Называемся команда. Не являемся командой — нет передачи знаний, нет (или избегается по возможности) интеракции между разработчиками и т.д.
Pzz>5 — что это значит?
Никто никак не расчитывает сколько времени возьмет что-то большое.
В конце не успеваем и выкидываем разную функциональность.
Pzz>6 — меня она тоже приводит в ужас, если честно. Вернее, в недоумение. Парно хорошо детей делать и двуручной пилой пилить, а не программы писать.
Поэтому у нас (и наверное у вас) есть люди, которые если уйдут в отпуск, работа в их сфере остановится, т.к. никто не знаком с их сферой. Ну и вообще, я встречал только позитивные фидбэки о парном программинге.
Здравствуйте, zfima, Вы писали:
Z>Ну, мы вообще производительность не измеряем никак.
А почему это тебя волнует? Проекты не проваливаются? Заказчик платит деньги? Если да — то с точки зрения менеджмента все ок.
Далее, как ты собираешься ее измерять? Т.е. через месяц-два как ты сможешь утверждать, что производительность "повысилась" или "понизилась", если не можешь ее измерить? И самое главное, как это повлиялет на ход проекта в целом?
Z>И ещё раз — презентация раз в пол-года.
Во многих случаях этого достаточно. Заказчику совершенно не интересны внутренние технические "потроха" вашего софта. А соответствие софта требованиям Заказчика — эта задача должна решаться аналитиками, путем постоянного отслеживания требований Заказчика, их актуальности и соответствия софта требованиям. Непонятно только, если ваши аналитики мышей не ловят — чем здесь может помочь именно Agile, а не любая другая методология? Если исходные требования неверны, неполны или неактуальны, — любая методология, включая Agile, приведет к выдаче в релиз софта, не соответствующего требованиям Заказчика.
Z>Если система большая и не покрыта тестами, и ее не писали трансформеры — ошибок будет много.
У тебя есть факты (статистика, плотность ошибок и др.)? Или это только теоретические рассуждения?
Как ты собираешься измерять плотность ошибок, покрытие кода тестами и пр.? Иначе без фактических данных как ты сможешь утверждать, что покрытие тестами "улучшило" софт или "ухудшило"?
Z>Называемся команда. Не являемся командой — нет передачи знаний, нет (или избегается по возможности) интеракции между разработчиками и т.д.
Так вот эта проблема и является ключевой. Не понимаю только, чем тут поможет именно Agile, а не любая другая методология? Любой приличный PM знает:
"Четыре основных правила менеджмента:
1. Найти нужных людей.
2. Дать им ту работу, для которой они лучше всего подходят.
3. Не забывать о мотивации.
4. Помогать им сплотиться в одну команду и работать так дальше.
Все остальное — административная ерундистика."
(с)
Здравствуйте, artem.komisarenko, Вы писали:
AK>Здравствуйте, zfima, Вы писали:
Z>>1. Проблему простоя или гонок. AK>Это реально есть или в книжке прочитано?
Реально.
Z>>Проблему, что клиент видит продукт в конце девелопмента, т.е. через пол-года. AK>Это стало реальной проблемой для бизнеса или в книжке прочитано?
Реально — они ожидают другого. С клиентом я не контактирую, т.к. он хер его знает кто и хер его знает где
Z>>Проблему, что на 5000 солюшенов нет ни одного юнит теста. AK>Это не проблема
...а проблема в том, что есть баги? поэтому они и есть.
Z>>Проблему, что нет команды, сроки кидаются в воздух, AK>Это стало реальной проблемой для бизнеса или в книжке прочитано?
реально.
А ещё есть поддержка 7-и разных версий продукта у разных клиентов.
Z>>мысль о парном программировании вводить коллег в ужас. AK>И это тоже не проблема. Вообще, использование Agile или RUP, использование табов или пробелов, использование svn или git или perforce, будь он неладен, а так же то, что начальник слушает музыку Самоа и смотрит фильмы про Тасманию — всё это не проблемы.
Фильмы и музыка — это был пример "самопроталкивания".
Ну мы же не комманда — поэтому люди этого шугаются
Z>>3. Ну, с чего то надо начать. В скраме не так много ограничений, хотя если и их будет слишком много, можно дискуссировать о канбане, например. Аргументы — хочу сделать процесс лучше.
AK>Что значит "лучше"? Разверните, а то получается как в анекдоте про армянское радио: "Армяне лучше чем грузины. — Чем лучше? — Чем грузины."
Здравствуйте, zfima, Вы писали:
Pzz>>6 — меня она тоже приводит в ужас, если честно. Вернее, в недоумение. Парно хорошо детей делать и двуручной пилой пилить, а не программы писать. Z>Поэтому у нас (и наверное у вас) есть люди, которые если уйдут в отпуск, работа в их сфере остановится, т.к. никто не знаком с их сферой. Ну и вообще, я встречал только позитивные фидбэки о парном программинге.
Парное программирование полезно только когда надо "срастить" части программы, сделанные разными людьми. Вот тут они садятся вдвоем и быстренько все делают. И все.
А то, о чем ты говоришь, решается другими средствами.
Ведение документации, комментарии в коде, периодические доклады разработчиков о поддерживаемых ими частях программы.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Здравствуйте, zfima, Вы писали:
Pzz>>>6 — меня она тоже приводит в ужас, если честно. Вернее, в недоумение. Парно хорошо детей делать и двуручной пилой пилить, а не программы писать. Z>>Поэтому у нас (и наверное у вас) есть люди, которые если уйдут в отпуск, работа в их сфере остановится, т.к. никто не знаком с их сферой. Ну и вообще, я встречал только позитивные фидбэки о парном программинге.
SVZ>Парное программирование полезно только когда надо "срастить" части программы, сделанные разными людьми. Вот тут они садятся вдвоем и быстренько все делают. И все. SVZ>А то, о чем ты говоришь, решается другими средствами. SVZ>Ведение документации, комментарии в коде, периодические доклады разработчиков о поддерживаемых ими частях программы.
Станислав, может вы и правы.
Никогда не практиковал, хотя очень хотелось бы
Не практиковал — потому как в 5-6 фирмах, которых я работал, никто этого не хотел. Так же как TDD и т.д.
Документация — в принципы, если только необходима.
Комментарии — после нескольких чисток становятся мусором
Доклады? Ну было бы хорошо, но нету
Прямо начинаешь сомневаться — а кто то этим вообще пользуется?...
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, zfima, Вы писали:
Z>>Ну, мы вообще производительность не измеряем никак.
V_S>А почему это тебя волнует? Проекты не проваливаются? Заказчик платит деньги? Если да — то с точки зрения менеджмента все ок. V_S>Далее, как ты собираешься ее измерять? Т.е. через месяц-два как ты сможешь утверждать, что производительность "повысилась" или "понизилась", если не можешь ее измерить? И самое главное, как это повлиялет на ход проекта в целом?
Z>>И ещё раз — презентация раз в пол-года.
V_S>Во многих случаях этого достаточно. Заказчику совершенно не интересны внутренние технические "потроха" вашего софта. А соответствие софта требованиям Заказчика — эта задача должна решаться аналитиками, путем постоянного отслеживания требований Заказчика, их актуальности и соответствия софта требованиям. Непонятно только, если ваши аналитики мышей не ловят — чем здесь может помочь именно Agile, а не любая другая методология? Если исходные требования неверны, неполны или неактуальны, — любая методология, включая Agile, приведет к выдаче в релиз софта, не соответствующего требованиям Заказчика.
Z>>Если система большая и не покрыта тестами, и ее не писали трансформеры — ошибок будет много.
V_S>У тебя есть факты (статистика, плотность ошибок и др.)? Или это только теоретические рассуждения? V_S>Как ты собираешься измерять плотность ошибок, покрытие кода тестами и пр.? Иначе без фактических данных как ты сможешь утверждать, что покрытие тестами "улучшило" софт или "ухудшило"?
Z>>Называемся команда. Не являемся командой — нет передачи знаний, нет (или избегается по возможности) интеракции между разработчиками и т.д.
V_S>Так вот эта проблема и является ключевой. Не понимаю только, чем тут поможет именно Agile, а не любая другая методология? Любой приличный PM знает: V_S>"Четыре основных правила менеджмента: V_S>1. Найти нужных людей. V_S>2. Дать им ту работу, для которой они лучше всего подходят. V_S>3. Не забывать о мотивации. V_S>4. Помогать им сплотиться в одну команду и работать так дальше. V_S>Все остальное — административная ерундистика." V_S>(с)
Здравствуйте, zfima, Вы писали:
SVZ>>Парное программирование полезно только когда надо "срастить" части программы, сделанные разными людьми. Вот тут они садятся вдвоем и быстренько все делают. И все. SVZ>>А то, о чем ты говоришь, решается другими средствами. SVZ>>Ведение документации, комментарии в коде, периодические доклады разработчиков о поддерживаемых ими частях программы.
Z>Станислав, может вы и правы. Z>Никогда не практиковал, хотя очень хотелось бы Z>Не практиковал — потому как в 5-6 фирмах, которых я работал, никто этого не хотел. Так же как TDD и т.д.
Z>Документация — в принципы, если только необходима.
Я с этим сталкивался в нескольких компаниях.
Это получается как необходимость. Документировались алгоритмы, описания конечных автоматов, архитектура серверов.
Самое сложное — поддерживать документацию в актуальном состоянии. Это получается только если состав разработчиков более-менее стабилен, т.е. те, кто принял решение вести документацию, остаются в коллективе. Если разработчики сменяются каждые полгода, то такие соглашения проживут недолго.
Z>Комментарии — после нескольких чисток становятся мусором
Только если никому не нужны. Опять же убедился, что хорошее комментирование кода коллегам нравится и они начинают тоже его применять.
Комментарии правятся одновременно с кодом.
Лучше всего получается, если сперва пишется комментарий (что собираешься сделать/получить) а потом набивается код. Тогда комментарии получаются дополнительным источником информации при CodeReview.
Z>Доклады? Ну было бы хорошо, но нету
На прошлой работе коллегиально решили периодически рассказывать о своих частях программы. Потому что были проблемы с ревью. Формальный ревью результатов не давал, а углубляться в код и выяснять правильность правок было слишком затратно по времени.
Z>Прямо начинаешь сомневаться — а кто то этим вообще пользуется?...
"Жить захочешь, не так раскорячишься" (с)
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, zfima, Вы писали:
Pzz>>1 — существует в каком-то виде при любом процессе. Проблема в том, что люди не машины, и их производительность колеблется в широких пределах. Кроме того, не существует точных методик оценки трудоемкости того или иного задания, до того, как это задание исполненно.
Z>Ну, мы вообще производительность не измеряем никак.
Ну, измерите, а дальше что?
Z>Именно так. И почему то есть предпочтение, чтобы клиент вообще не знал, чем мы занимаемся.
Это — вопрос отношений между вашими sales и клиентом. Тонкая политика. Не лезте в это, это вне вашей компетенции. Целее будете.
Pzz>>3 — это, заметьте, само по себе проблемой не является. Проблема, это когда много ошибок в софтварии, или софтварий разваливается при попытке в нем что-то изменить и т.д. и т.п.
Z>Если система большая и не покрыта тестами, и ее не писали трансформеры — ошибок будет много. Z>Думаю, что это является проблемой. Так как люди считают, что это лишнее (код, время)
Так их, ошибок, много или немного? У вас bug tracking-то есть? Если нет, заведите немедленно. И source control тоже заведите, если его до сих пор у вас нет.
Типичная норма для индустрии — одна ошибка на 50 строк кода. Если у вас их больше этого показателя, надо что-то делать. Если нет, не парьтесь. Все равно, сильно лучше ваш код не станет.
Pzz>>4 — что это значит?
Z>Называемся команда. Не являемся командой — нет передачи знаний, нет (или избегается по возможности) интеракции между разработчиками и т.д.
В смысле, вы сидите надувшись и между собой не разговариваете?
Pzz>>5 — что это значит?
Z>Никто никак не расчитывает сколько времени возьмет что-то большое. Z>В конце не успеваем и выкидываем разную функциональность.
У вас слишком большие этапы. Планируйте разработку циклами размером 1-2 недели.
Pzz>>6 — меня она тоже приводит в ужас, если честно. Вернее, в недоумение. Парно хорошо детей делать и двуручной пилой пилить, а не программы писать. Z>Поэтому у нас (и наверное у вас) есть люди, которые если уйдут в отпуск, работа в их сфере остановится, т.к. никто не знаком с их сферой. Ну и вообще, я встречал только позитивные фидбэки о парном программинге.
Чтобы разработчики были в курсе задач друг друга, вовсе не обязательно делить одну клавиатуру на двоих.
Здравствуйте, zfima, Вы писали:
Z>Потому как мне не хочется носить футболки со звездными войнами и слушать любимые группы начальника и прибегать к всяким уловкам Z>Должно быть, наверное, по другому
На подхалимстве прочного авторитета не заработаешь.
За все время работы я ни разу не носил любимые майки начальника и не слушал его группы. Собственно, я понятия никогда не имел, какую музыку мое начальство слушало, а мои подчиненные слушали другую музыку чем я. Кроме как если разве я кого из них домой на машине подвозил — тогда у них выбора не было И мне это никогда не мешало.
Z>Кроме того, так, думаю кросс-функциональную команду не построишь
Что такое кросс-компилятор, я понимаю. А что такое кросс-функциональная команда?
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, zfima, Вы писали:
Pzz>>>1 — существует в каком-то виде при любом процессе. Проблема в том, что люди не машины, и их производительность колеблется в широких пределах. Кроме того, не существует точных методик оценки трудоемкости того или иного задания, до того, как это задание исполненно.
Z>>Ну, мы вообще производительность не измеряем никак.
Pzz>Ну, измерите, а дальше что?
Ну наверное, чтобы можно было бы пообещать заказчику сколько дров за периуд времени мы можем нарубить. Или наколоть
Когда ты покупаешь вещь, которая имеет некоторый перфоменс, тебе наверное хотелось бы знать сколько-чего она умеет делать за какое то время.
Z>>Именно так. И почему то есть предпочтение, чтобы клиент вообще не знал, чем мы занимаемся.
Pzz>Это — вопрос отношений между вашими sales и клиентом. Тонкая политика. Не лезте в это, это вне вашей компетенции. Целее будете.
Понял
Pzz>>>3 — это, заметьте, само по себе проблемой не является. Проблема, это когда много ошибок в софтварии, или софтварий разваливается при попытке в нем что-то изменить и т.д. и т.п.
Z>>Если система большая и не покрыта тестами, и ее не писали трансформеры — ошибок будет много. Z>>Думаю, что это является проблемой. Так как люди считают, что это лишнее (код, время)
Pzz>Так их, ошибок, много или немного? У вас bug tracking-то есть? Если нет, заведите немедленно. И source control тоже заведите, если его до сих пор у вас нет.
Pzz>Типичная норма для индустрии — одна ошибка на 50 строк кода. Если у вас их больше этого показателя, надо что-то делать. Если нет, не парьтесь. Все равно, сильно лучше ваш код не станет.
Есть RTC со всеми вытекающими.
Проблема, что во время изменений вносятся доп. баги. Если бы всё было покрыто тестами — было бы, думаю, чище.
Pzz>>>4 — что это значит?
Z>>Называемся команда. Не являемся командой — нет передачи знаний, нет (или избегается по возможности) интеракции между разработчиками и т.д.
Pzz>В смысле, вы сидите надувшись и между собой не разговариваете?
Да нет. Просто никто никому помогать не хочет. У каждого только своя узкая специализация и другого не хочет.
Pzz>>>5 — что это значит?
Z>>Никто никак не расчитывает сколько времени возьмет что-то большое. Z>>В конце не успеваем и выкидываем разную функциональность.
Pzz>У вас слишком большие этапы. Планируйте разработку циклами размером 1-2 недели.
Pzz>>>6 — меня она тоже приводит в ужас, если честно. Вернее, в недоумение. Парно хорошо детей делать и двуручной пилой пилить, а не программы писать. Z>>Поэтому у нас (и наверное у вас) есть люди, которые если уйдут в отпуск, работа в их сфере остановится, т.к. никто не знаком с их сферой. Ну и вообще, я встречал только позитивные фидбэки о парном программинге.
Pzz>Чтобы разработчики были в курсе задач друг друга, вовсе не обязательно делить одну клавиатуру на двоих.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, zfima, Вы писали:
Z>>Потому как мне не хочется носить футболки со звездными войнами и слушать любимые группы начальника и прибегать к всяким уловкам Z>>Должно быть, наверное, по другому
Pzz>На подхалимстве прочного авторитета не заработаешь.
Pzz>За все время работы я ни разу не носил любимые майки начальника и не слушал его группы. Собственно, я понятия никогда не имел, какую музыку мое начальство слушало, а мои подчиненные слушали другую музыку чем я. Кроме как если разве я кого из них домой на машине подвозил — тогда у них выбора не было И мне это никогда не мешало.
Z>>Кроме того, так, думаю кросс-функциональную команду не построишь
Pzz>Что такое кросс-компилятор, я понимаю. А что такое кросс-функциональная команда?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, zfima, Вы писали:
Z>>Как быть? Дать им всё завалить?
А>Можешь дать им завалить. А>Судя по всему у вас там программеров раз два и обчелся и потому наверное приходится заниматься мышинной вознейю. А>Можешь сменить работу где программеров побольше и где простора соответственно больш. А>У нас, к примеру, больше десятка команд. Скрам мастерами точно не все хотят быть А>и порой приходится искать кто бы взял на себя эту роль. А>Никакой магии в этом нету. При нормально поставленном скраме обычный девелопер А>имеет ровно столько же позможностей повлиять на процесс, А>как и скрам мастер. скрам мастер — это точно не пуп земли, даже в масштабах одной команды. А>Он ничего решает и никому не приказывает. Роль у него очень четкая и даже странно слышать, А>что об этой роли кто-то может мечтать и за обладание этой ролью приходится конкурировать
Хочу попробовать себя в качестве скрам мастера или другого Agile-мастера, только потому что есть желание улучшить/убыстрить/упорядочить процесс, не увеличивая человеческих ресурсов.
Думаю, у девелопера меньше способов повлиять да и многим из них это не нужно.
Не хочу быть пупом земли, приказывать и т.д.
Здравствуйте, zfima, Вы писали:
Pzz>>Ну, измерите, а дальше что?
Z>Ну наверное, чтобы можно было бы пообещать заказчику сколько дров за периуд времени мы можем нарубить. Или наколоть Z>Когда ты покупаешь вещь, которая имеет некоторый перфоменс, тебе наверное хотелось бы знать сколько-чего она умеет делать за какое то время.
Это не работает даже у Мелкософта. Обратите внимание, что они не выпустили не одного major release в заявленный срок.
Проблема в том, что производительность зависит от сложности задачи, а пока вы не погрузились в задачу с головой, вы не знаете всех проблемных мест. А поэтому, не можете с приемлимой точностью оценить сложность.
Исключение, если вы делаете стандартные, типовые, похожие друг на друга задачи. Например, клепаете веб-сайты по шаблону, пишете драйвера или клепаете формочки, похожие друг на друга. Но и то, предлетная область может подкинуть неожиданную подлянку.
Z>Есть RTC со всеми вытекающими. Z>Проблема, что во время изменений вносятся доп. баги. Если бы всё было покрыто тестами — было бы, думаю, чище.
Так сколько у вас ошибок на самом деле? И что такое RTC?
Pzz>>В смысле, вы сидите надувшись и между собой не разговариваете?
Z>Да нет. Просто никто никому помогать не хочет. У каждого только своя узкая специализация и другого не хочет.
Это — вопрос человеческих взаимоотношений. Процессом не лечится.
Здравствуйте, zfima, Вы писали:
Pzz>>Что такое кросс-компилятор, я понимаю. А что такое кросс-функциональная команда?
Z>Это когда все взаимозаменяемые, наверное Z>http://en.wikipedia.org/wiki/Cross-functional_team
Как говорит одим мой очень хороший знакомый, бывший когда-то моим начальником, есть два типа работы: ручку крутить и в высоту прыгать. Все взаимозаменяемы бывают только на работе типа ручку крутить.
Здравствуйте, zfima, Вы писали:
Z>У нас есть начальник отдела программеров. У него в подчинение находится примерно 30 программеров. Z>И он ПОНИМАЕТ, что процесс отстой
Это очень много, 30 подчиненных на одного начальника. Должна быть какая-то иерархия. Скажем, у него в подчинении находится несколько старших программистов, а они уже возглавляют свои небольшие командочки.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, zfima, Вы писали:
Pzz>>>Ну, измерите, а дальше что?
Z>>Ну наверное, чтобы можно было бы пообещать заказчику сколько дров за периуд времени мы можем нарубить. Или наколоть Z>>Когда ты покупаешь вещь, которая имеет некоторый перфоменс, тебе наверное хотелось бы знать сколько-чего она умеет делать за какое то время.
Pzz>Это не работает даже у Мелкософта. Обратите внимание, что они не выпустили не одного major release в заявленный срок.
Pzz>Проблема в том, что производительность зависит от сложности задачи, а пока вы не погрузились в задачу с головой, вы не знаете всех проблемных мест. А поэтому, не можете с приемлимой точностью оценить сложность.
Pzz>Исключение, если вы делаете стандартные, типовые, похожие друг на друга задачи. Например, клепаете веб-сайты по шаблону, пишете драйвера или клепаете формочки, похожие друг на друга. Но и то, предлетная область может подкинуть неожиданную подлянку.
Z>>Есть RTC со всеми вытекающими. Z>>Проблема, что во время изменений вносятся доп. баги. Если бы всё было покрыто тестами — было бы, думаю, чище.
Pzz>Так сколько у вас ошибок на самом деле? И что такое RTC?
Система фирмы IBM. Чтото типа TFS микрософта.
Там и баг-трекинг, и Source control, и много чего заточенного под Agile — но всем этим мы не пользуемся
Pzz>>>В смысле, вы сидите надувшись и между собой не разговариваете?
Z>>Да нет. Просто никто никому помогать не хочет. У каждого только своя узкая специализация и другого не хочет.
Pzz>Это — вопрос человеческих взаимоотношений. Процессом не лечится.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, zfima, Вы писали:
Z>>У нас есть начальник отдела программеров. У него в подчинение находится примерно 30 программеров. Z>>И он ПОНИМАЕТ, что процесс отстой
Pzz>Это очень много, 30 подчиненных на одного начальника. Должна быть какая-то иерархия. Скажем, у него в подчинении находится несколько старших программистов, а они уже возглавляют свои небольшие командочки.
Да нет никакой особой иерархии. Я больше с ним на прямую работаю чем с кем-то кто типа мой "наставник".
"Наставник" получает задачу от начальника и дает мне. Ничего сам не делит
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, zfima, Вы писали:
Z>>Наверное, самая подходящее решение. Z>>У меня только нет опыта в этой отрасли. Z>>Но есть много мотивации
Pzz>Тогда от вас отмахнутся, как от надоедливого комара. Мотивация без опыта никому не нужна.
Блин, в полне возможно.
Наверное, надо изучить досконально чего нибудь, типа канбана, сделать презентацию, объяснить что к чему, показать почему это поможет и сделать симуляцию.
Здравствуйте, zfima, Вы писали:
Z>Система фирмы IBM. Чтото типа TFS микрософта. Z>Там и баг-трекинг, и Source control, и много чего заточенного под Agile — но всем этим мы не пользуемся
У него, небось, такой интерфейс, что проще удавиться, чем научиться им пользоваться.
Поставьте себе простой и понятный source control и простой и простой и понятный bug tracking. И начните уже ими пользоваться. У вас должны ВСЕ исходники проходить через source control (и никаких "пошли мне исходник по почте" или "запиши на флешку"), и абсолютно ВСЕ задания, как "сделать такую-то фичу", так и "починить такую-то багу" проходить через bug tracking. И информация там должна быть исчерпывающей и актуальной. В т.ч., описание задания, на кого оно назначено, логи в source control'е и т.п. Для начала этого более чем достаточно, с точки зрения организации процесса.
Я думаю, необходимость внедрения этих двух инструментов будет гораздо проще обосновать, чем всякие там новомодные слова-методологии.
Здравствуйте, zfima, Вы писали:
Z>Да нет никакой особой иерархии. Я больше с ним на прямую работаю чем с кем-то кто типа мой "наставник". Z>"Наставник" получает задачу от начальника и дает мне. Ничего сам не делит
Невозможно одному человеку иметь 30 человек в непосредственном подчинении. Если с каждым в день надо хоть раз поговорить, это получается по 15 минут на человека, если только этим и заниматься. Прям как у участкового терапевта, то-то они такие вздрюченные.
Разумный вариант организации: проект разбивается на несколько относительно изолированных подзадач, на каждую назначается ответственный, ему в подчинение даются несколько программистов. Главный программистский начальник работает напрямую только с этими ответственными, вопросы взаимодействия между частями проекта утрясаются ответственными за эти части между собой, а вопросы реализации — уже между ответственными и подчиненными ему программистами. В небольших группах сразу и коммуникация людей между собой наладится.
И очень важно, чтобы никто через чью-то голову не пытался работать. Скажем, главный начальник не должен напрямую командовать программистами, через голову ответственного за подзадачу, и программисты не должны к нему лезть со своими повседневными вопросами.
Здравствуйте, zfima, Вы писали:
Z>Блин, в полне возможно. Z>Наверное, надо изучить досконально чего нибудь, типа канбана, сделать презентацию, объяснить что к чему, показать почему это поможет и сделать симуляцию.
Нет. Если бы у меня в группе завелся какой-нибудь птенец неоперившийся, который в бою не бывал, а командира учит, я бы предпринял осмысленные усилия, чтобы направить его энергию в мирное русло, а если бы это не помогло, постарался бы от него избавиться. Это потому, что я добрый, либеральный и демократичный, и вообще, людей расстраивать не люблю. Другой бы на моем месте сразу бы уволил нахрен, чтобы не баламутил команду.
Z>Тогда реально получить эту тему?
Я привержнец той теории, что авторитетом среди людей пользуются граждане, которые могут в мирной жизни дать дельный совет, в нужный момент (а не бегать вокруг и жужжать со своими непрошенными предложениями), а в бою прикрыть спину.
Тут важны такт, умения и опыт, а не багаж прочитанных книжек и заученных модных слов.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, zfima, Вы писали:
Z>>Система фирмы IBM. Чтото типа TFS микрософта. Z>>Там и баг-трекинг, и Source control, и много чего заточенного под Agile — но всем этим мы не пользуемся
Pzz>У него, небось, такой интерфейс, что проще удавиться, чем научиться им пользоваться.
Pzz>Поставьте себе простой и понятный source control и простой и простой и понятный bug tracking. И начните уже ими пользоваться. У вас должны ВСЕ исходники проходить через source control (и никаких "пошли мне исходник по почте" или "запиши на флешку"), и абсолютно ВСЕ задания, как "сделать такую-то фичу", так и "починить такую-то багу" проходить через bug tracking. И информация там должна быть исчерпывающей и актуальной. В т.ч., описание задания, на кого оно назначено, логи в source control'е и т.п. Для начала этого более чем достаточно, с точки зрения организации процесса.
Pzz>Я думаю, необходимость внедрения этих двух инструментов будет гораздо проще обосновать, чем всякие там новомодные слова-методологии.
Здравствуйте, zfima, Вы писали:
Z>Думаю, у девелопера меньше способов повлиять да и многим из них это не нужно.
Смотря что это за девелопер и как к нему относится команда. Z>Не хочу быть пупом земли, приказывать и т.д.
Без этого никак.
Здравствуйте, zfima, Вы писали:
Z>Есть RTC со всеми вытекающими. Z>Проблема, что во время изменений вносятся доп. баги. Если бы всё было покрыто тестами — было бы, думаю, чище.
Чище было бы. Но вы бы тратили больше времени на разработку и делали бы меньше функциональности. Грубо говоря, за то же время вы бы делали в 1,5-2 раза меньше, чем раньше (зато с меньшим количеством багов).
С большой вероятностью у вас там проблемы в первую очередь в архитектуре (или отсутствии оной). Вот как раз чистка и исправление архитектуры могут кардинально улучшать ситуацию и требовать гораздо меньше времени. Правда в этом случае тесты скорее даже мещают, чем помогают (потому что становятся неактуальны часто).
Что интересно, с большой вероятностью именно документация была бы полезнее в данном случае. Часто причиной регрессии бывает нарушение неявных контрактов метода. Документация делает контракты явными. И при изменении контракта нужно проверять пользователей методов. А еще документация очень хорошо выявляет артефакты архитектуры. Банальный вопрос "а как контракт метода относится к контракту класса" заставляет о многом задуматься.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, zfima, Вы писали:
Z>>Блин, в полне возможно. Z>>Наверное, надо изучить досконально чего нибудь, типа канбана, сделать презентацию, объяснить что к чему, показать почему это поможет и сделать симуляцию.
Pzz>Нет. Если бы у меня в группе завелся какой-нибудь птенец неоперившийся, который в бою не бывал, а командира учит, я бы предпринял осмысленные усилия, чтобы направить его энергию в мирное русло, а если бы это не помогло, постарался бы от него избавиться. Это потому, что я добрый, либеральный и демократичный, и вообще, людей расстраивать не люблю. Другой бы на моем месте сразу бы уволил нахрен, чтобы не баламутил команду.
Z>>Тогда реально получить эту тему?
Pzz>Я привержнец той теории, что авторитетом среди людей пользуются граждане, которые могут в мирной жизни дать дельный совет, в нужный момент (а не бегать вокруг и жужжать со своими непрошенными предложениями), а в бою прикрыть спину.
Pzz>Тут важны такт, умения и опыт, а не багаж прочитанных книжек и заученных модных слов.
Кто же тогда становится Ageile-технологом? Менеджеры и т.д?
Помоему, менеджер не захочет им стать, выглядит типа downgrade. Нет?
Или выпускники менеджмента?
И вообще, есть тут Agile-мастеры, которые могут рассказать, как стали таковы?
Здравствуйте, zfima, Вы писали:
Pzz>>Тут важны такт, умения и опыт, а не багаж прочитанных книжек и заученных модных слов. Z>Кто же тогда становится Ageile-технологом? Менеджеры и т.д?
Могут менеджеры, может сама команда. Agile — это всего лишь один из способов управления проектами. Причем у Agile в целом много разновидностей и некоторые разновидности можно еще вручную тюнинговать под конкретную ситуацию. Я плохо представляю, кто такой Agile-технолог. Наверное, это все же слишком узкая специализация в рамках управления проектами.
Если рассматривать Scrum-мастера, это вообще скорее "формальная роль". Какой-то долгой специальной подготовки она не требует. Да и времени на нее обычно нужно мало (пара часов за неделю может наберется). Иногда приглашают внешнего человека, который уже вел скрам и тренируются при нем. Фактически это ускоспециализированный внешний консультант.
Z>Помоему, менеджер не захочет им стать, выглядит типа downgrade. Нет?
Так Agile-технолога на полный рабочий день не наберется. Это будет как раз менеджер со знанием Agile, выполняющий некоторые роли из этого Agile.
Могут быть разные ситуации в конкретной команде. Особенно если отходить от "чистого" Agile/Agile по книжке. Например, менеджер может выступать в качестве аналитика/представителя заказчика (было, команда была маленькая). Может заниматься какими-то согласованиями (политические в основном) с другими техническими командами. Или просто координация задач в нетехнической части (художники, аниматоры, звукорежиссеры).
Вообще, нужно задать вопрос: а кто решил делать Agile и почему им понадобился мастер? Грубо говоря, человек, решивший, что нужен Agile, либо сам может им руководить (это менеджер решил, что команда хорошо подходит), или планировал процесс с учетом конкретного лидера (т.е. кандидатура уже есть).
Z>Или выпускники менеджмента?
Интересная идея, кстати. Но только их на подобные "процессные" роли все равно нужно ставить под контролем более опытных товарищей. Т.е. уже есть какой-то человек, который решил, что "будет Agile".
Z>И вообще, есть тут Agile-мастеры, которые могут рассказать, как стали таковы?
Agile-мастер — это такой buzzword, с помощью которого человек пытается продать свои услуги. Не больше и не меньше. Основное время у него уходит на поиск клиентов и разъезды по ним. Вы тоже можете сделать свой сайт и заявлять сбея Agile-мастером. Только вот я, например, в случае необходимости скорее всего не будут искать Agile/Scrum/прочих мастеров. Я буду искать специалиста по управлению проектами. И пусть он уже решает, какой процесс применять.
Так что вопрос "как стать" — сложный. На самом деле вам нужно убедить других в том, что "нужен agile". Не мене важно также убедить всех в том, что за процессом внедрения вы готовы следить, корректировать его при необходимости (т.е. основные проблемы и подводные камни знато тоже должны сразу). Ну и быть готовы отказаться от внедрения при неудачен. Это people skills и все, что с ними связано. И авторитет, и политика (в зависимости от сложившихся условий) и все остальное.
Здравствуйте, maxkar, Вы писали:
M>Здравствуйте, zfima, Вы писали:
Pzz>>>Тут важны такт, умения и опыт, а не багаж прочитанных книжек и заученных модных слов. Z>>Кто же тогда становится Ageile-технологом? Менеджеры и т.д? M>Могут менеджеры, может сама команда. Agile — это всего лишь один из способов управления проектами. Причем у Agile в целом много разновидностей и некоторые разновидности можно еще вручную тюнинговать под конкретную ситуацию. Я плохо представляю, кто такой Agile-технолог. Наверное, это все же слишком узкая специализация в рамках управления проектами.
M>Если рассматривать Scrum-мастера, это вообще скорее "формальная роль". Какой-то долгой специальной подготовки она не требует. Да и времени на нее обычно нужно мало (пара часов за неделю может наберется). Иногда приглашают внешнего человека, который уже вел скрам и тренируются при нем. Фактически это ускоспециализированный внешний консультант.
А вот тут написано, что по-нормальному у мастера куча обязанностей:
http://agiletrail.com/2011/11/14/42-tasks-for-a-scrum-masters-job/
Z>>Помоему, менеджер не захочет им стать, выглядит типа downgrade. Нет? M>Так Agile-технолога на полный рабочий день не наберется. Это будет как раз менеджер со знанием Agile, выполняющий некоторые роли из этого Agile.
M>Могут быть разные ситуации в конкретной команде. Особенно если отходить от "чистого" Agile/Agile по книжке. Например, менеджер может выступать в качестве аналитика/представителя заказчика (было, команда была маленькая). Может заниматься какими-то согласованиями (политические в основном) с другими техническими командами. Или просто координация задач в нетехнической части (художники, аниматоры, звукорежиссеры).
M>Вообще, нужно задать вопрос: а кто решил делать Agile и почему им понадобился мастер? Грубо говоря, человек, решивший, что нужен Agile, либо сам может им руководить (это менеджер решил, что команда хорошо подходит), или планировал процесс с учетом конкретного лидера (т.е. кандидатура уже есть).
Z>>Или выпускники менеджмента? M>Интересная идея, кстати. Но только их на подобные "процессные" роли все равно нужно ставить под контролем более опытных товарищей. Т.е. уже есть какой-то человек, который решил, что "будет Agile".
Z>>И вообще, есть тут Agile-мастеры, которые могут рассказать, как стали таковы? M>Agile-мастер — это такой buzzword, с помощью которого человек пытается продать свои услуги. Не больше и не меньше. Основное время у него уходит на поиск клиентов и разъезды по ним. Вы тоже можете сделать свой сайт и заявлять сбея Agile-мастером. Только вот я, например, в случае необходимости скорее всего не будут искать Agile/Scrum/прочих мастеров. Я буду искать специалиста по управлению проектами. И пусть он уже решает, какой процесс применять.
M>Так что вопрос "как стать" — сложный. На самом деле вам нужно убедить других в том, что "нужен agile". Не мене важно также убедить всех в том, что за процессом внедрения вы готовы следить, корректировать его при необходимости (т.е. основные проблемы и подводные камни знато тоже должны сразу). Ну и быть готовы отказаться от внедрения при неудачен. Это people skills и все, что с ними связано. И авторитет, и политика (в зависимости от сложившихся условий) и все остальное.
Ну давайте разберем. Но вы немного не правы. Это не совсем "обязанности". И сам автор не прав, это не "tasks". Больше всего туда подходит название "activites".
Сначала еще немного вводных слов. Я не совсем понял, он "agile по книжке" рассматривает? Т.е. команда совсем взаимозаменяемых профессионалов? Ну да, там будут провалы в определенных местах наблюдаться. Ну так проще процесс потюнинговать, нанять бизнес-аналитика или менеджера (с функциями бизнес-аналитика). И работать "в духе agile". А еще у меня местами возникают вопросы, Scrum ли это или уже пошли вариации на тему. Вообще, автор пытается обосновать, почему же его такого хорошего (и других аналогичных), которые не умеют производить реальный value, все же стоит брать и платить ему полную ставку.
А теперь спискота.
* Митинги. В митингах участвуют все роли. И готовятся тоже. Чего такого специального готовит scrum-мастер? Переговорку заказывает? Модерация — да, роль в течение митинга. Постобработка — да, может быть полезна (зависит от конкретики). А может, можно секретаршу взять и потом попросить все решения занести в wiki. Ретроспективы ничем принципиальным не отличаются.
* Coaching имеет много смыслов. В смысле "give (someone) instructions as to what to do or say in a particular situation" — это уже фейл менеджера/руководителя. Не нужно доводить до таких ситуаций. Во всех остальных значениях попытки coaching'а — это объявление войны. Чтобы нетехнический специалист (который кодом задачи не занимается) указывал мне, как делать мою работу? Это безобразие и страдание фигней. Пусть лучше скажет, что делать и ответит на нужные вопросы. Правда, для ответов на вопросы есть заказчик рядом.
* Разрешение конфликтов. В технических конфликтах мастер ничем помочь не может. Ну не знает он внутренних деталей, он другими делами занят. А в нетехнических (т.е. личностных) достаточно практически любого человека с лидерскими качествами. Ну да, в команде желательно наличие лидера (можно не одного, если они смогут уживаться друг с другом). Почему этим человеком не может быть кто-то другой из команды —
* Принятие решений... Каких? Когда? И вообще, это два раза посчитано. Его основная задача — борьба с impediments. Так что этот пункт вычеркиваем.
* Развитие самоорганизации... Это тоже странный пункт. Если команда самоорганизуется, зачем тогда scrum-мастер? Или все-таки команду нужно организовывать, чтобы складывалась видимость самоорганизации?
* "Mediating the general conflict". А это вообще не его дело. Это его косяк в организации всей работы команды. Окончатеное право голоса по этим вопросам у stakeholder. Да, они должны в определенной степени доверять техническим специалистам (оценка последствий, сложности, и т.п.). И разработчики должны не испытывать проблем с таким решением (все возникшие проблемы — это проблемы стейкхолдеров). При нормальной организации это автоматически работает. Гайдлайны (побыстрее/понадежнее) устанавливаются перед проектом. Конкретные решения (если мы сделаем это быстро, потом придется переписать) принимаются по месту. Заказчик то рядом.
* Просиживание на форумах, конференциях. Чтение художественной литературы на тему agile. Писание в ЖЖ-шке. Да уж... Важная деятельность. Только вот связь ее с выполняемым проектом совершенно не понятна.
* Консультация команды по Agile... Вот интересно, сколько на это времени уходит. И не проще ли члену команды задать вопрос на форуме, чем держать целого консультанта рядом?
* Поддержание information radiator. Да, нарисовать на доске картинку — это сложно, блин. Почему-то наша команда сама рисовала на досках нужные диаграммы (и фотографировала их на память). Причем ведь даже не "поддержание", а "помощь команде в поддержании"! Это он что, под руководством команды стрелочки рисует? И не лучше ли, чтобы член команды потратил свое время (он и так его уже тратит, см. оказывать помощь) и создать качественный радиатор.
* Какой он feedback хочет давать команде? Для этого можно пару раз внешних консультантов пригласить (если по процессу feedback), они в отличие от scrum master будут лицами незаинтересованными. Для другого feedback есть представитель заказчика.
* Про релизы и прочие инструменты просто вранье. В крупной компании инструменты поставит и настроит специально обученная команда системных администраторов. А в маленькой команде сложные инструменты не нужны. One-click delivery — это разовая инвестиция на старте проекта. Ну да, можно отдельного человека взять на один раз (на неделю-две), чтобы он настроил delivery. В общем, при правильных людях это задача одноразовая и не слишком долгая. Нет там никакого huge.
* Про challenge team не совсем понял. Вполне возможно, это объявление войны наподобие coaching (вместо решения продуктивных/конкретных вопросов занятие ерундой).
* Посещение курилок и треп с коллегами. Тоже очень важная задача. Прямо наравне с посещением форумов. А вот разработчик не справится с такой задачей. И вооще, они в курилках не сидят и форумы не посещают (иначе — всего лишь еще один форум и еще одна тема для общения).
* Экскурсии на территорию заказчика. Не понятно только, почему это нельзя совместить разработчику? Тем более, разработчику то это будет полезнее. Он сам увидит ситуацию а не будет получать информацию через посредника.
* User stories — да, хорошая штука. Только под эту роль можно ведь и аналитика/менеджера завести (у которого будет и ряд функций по модерации собраний). Прощай, чистый agile. Но работать то схема будет, а чистый agile — не самоцель.
* Прочее из product. Везде helping. Сам он ничего не делает. Так что никаких затрат при отказе от scrum manager по этому пункту мы не получим. Такой мальчик на побегушках, кстати, полезная функция, но к scrum отношения не имеет и может совмещаться для нескольких команд без других обязанностей "scrum master".
* "Being familiar with the team’s work (i.e. the product)." Ну правильно. Как же без этого. Иначе самоорганизовавшаяся команда (см. выше) его выгонит как лишний балласт. Кстати, а разработчикам и owner'у это не нужно? Т.е. они не знают, что команда делает? Или эту функцию можно прекрасно совместить с остальными и не тратить на нее лишнее время?
* Сводничество (в команде и не только). В небольшой команде это и так не проблема. Люди знают, с кем общаться. В больших/сложных командах это может быть отдельная роль (человек по связям с общественностью). Т.е. роль совсем не обязательная.
* Общение со stakeholder. Стоп, а зачем митинги тогда? Давайте скажем, что это — менеджер, а процесс — вариации на тему agile (и даже не scrum). А вообще, некоторые вариации вообще требуют представителя stakeholder'а в рабочей комнате (не знаю, относится ли к ним scrum). И вот роль этого представителя точно не может соединяться с ролью scrum master.
* Еще пара helping. Кстати, там где-то появился management, которому нужно отчеты делать. Это вообще что за зверь в agile? И почему тот менеджмент не может выполнять работу scrum master'а (точнее, ее часть вроде управления фичами/качеством)?
* Внедрение Agile во всей организации. Это какая-то террористическая организация получается. Организация нуждается в "нужных и полезных практиках", а не в Agile. Ну да, такими практиками может быть agile, но само по себе agile — не самоцель.
* Организация конференций. Не понятно, кому, зачем и в каком виде нужно. Чем отличается от простого "в следующую пятницу собираемся в кабаке"? А в больших организациях (и даже в средних) есть отдельные люди, которые этим занимаются. Им нужно правильно сформулировать задачу, и они организуют конференцию. Не нужно держать человека в каждой команде. Ну а про одну команду я уже сказал, она и сама хорошо организуется (кстати, да, есть же самоорганизация).
* Опять бложики. Вроде же было про это выше. Кстати, а owner/developer бложики не имеют права вести? А если имеют, какую полезную информацию можно подчеркнуть из блога scrum master'а? Т.е. что он может написать лучше, чем знающий тему разработчик/заказчик?
* Еще один раз упомянуто про консультацию по Agile. Если процесс так часто требует консультации, может, в топку этот процесс? Много где можно подобрать процесс, где консультаций "по процессу" не требуется.
* Еще одна религия. Опять "внедрять Agile"... Причем в рабочее время (хотя в некоторых случаях это оправдано).
* impediments. С этим спорить не буду. Но их не должно быть много. Если их слишком много, это повод задуматься над всем процессом. Может, нужна другая методолгия. Или другая команда. Или вообще проект стоит заморозить на время.
* Метрики как катализатор изменений — это смешно. Метрики, конечно, будут катализировать изменения. Направленные на накручивание этих метрик и больше ничего. А вообще обычно метрики используются как индикатор "туда ли идем" и скорости изменений. Это инструмент мониторинга, а не управленя.
* "Reflecting Agile and Scrum values to the team." А у команды на это время есть? Может, обойтись без рефлексии по поводу Agile и потратить это на какую-нибудь другую обязанность из списка (вроде организации совместных посиделок).
* "Reminding the team of their arrangements (e.g. policies)." Представил себе scrum-master'а с дубинкой, стоящего в центре общей комнаты команды. Вообще, первично определение нужных policy и мониторинг их актуальности. А "напоминать квалифицированным профессионалам их место в команде" — это какое-то странное занятие.
* Улучшение процесса. Да, в какой-то степени. Но часть вещей прекрасно можно совмещать с другими занятиями. Хотя тут спорная ситуация. Часть проблем лучше видна изнутри, часть — снаружи.
* За постановку "открытых вопросов" можно и по лицу получить. Команде больше делать нечего кроме этого.
* Проверять модели — странное занятие. Наверное, это потому, что в команде только недавние выпускники и разницы между реальным миром и моделями не видят. Или потому что блоги и конференции надоели, кодом заниматься квалификация не позволяет, команда работает хорошо, вот и приходится какое-нибудь занятие выдумать.
* Отвлечение внешних раздражителей на себя — полезная вещь. Но если их слишком много, нужно принимать некоторые радикальные меры вплоть до переезда команды в здание без телефонов в другом районе города. Да и откуда у scrum-команды много внешних раздражителей (кроме scrum master'а, напомниающего о месте в команде и необходимости сохранять vision).
* Про инструменты же было уже один раз. Куда у scrum master'а уехал фокус?
* Да, помощь product owner'у. Почти аналитик. А может, ну его, этот scrum, взять одного аналитика и работать дальше?
В общем, там почти все спорное. Особенно постулат про необходимость scrum. В принципе, многие активности может выполнять "просто менеджер" (совмещая управление с должностью аналитика, достаточно частый вариант). Вот если этот менеджер осознанно выбрал scrum, то может быть и scrum master'ом. А может посоветовать взять аналитика (для определения vision, definition of done и поездок на производство к заказчику), например. Я опять повторюсь, лучше взять "универсального менеджера", чем узкого специалиста по scrum. Пространство для маневра больше. Да и часть обязанностей из списка выше достаточно часто отдается именно менеджерам.
Здравствуйте, Pzz, Вы писали:
Pzz>Нет. Если бы у меня в группе завелся какой-нибудь птенец неоперившийся, который в бою не бывал, а командира учит, я бы предпринял осмысленные усилия, чтобы направить его энергию в мирное русло, а если бы это не помогло, постарался бы от него избавиться. Это потому, что я добрый, либеральный и демократичный, и вообще, людей расстраивать не люблю. Другой бы на моем месте сразу бы уволил нахрен, чтобы не баламутил команду.
Странное поведение для руководителя. Почему-бы такому мудрому и опытному не помочь своей мудростью и опытом молодому? Или сакральные знания нельзя передавать дальше? ИМХО руководитель на то и руководитель, чтобы прогнозировать и поощрять рост своей команды. А если инициативу гнобиьт со словами: "мал еще, не дорос" и т.п. можно инициативных и талантливых людей потерять.
Задумайтесь, откуда человек может получить опыт, если ему не дают его получить? Что, все сразу стали руководителями, тим-лидерами, скрам-мастерами? Нет, они шли, набивали шишки, искали пути. ИМХО автору топика надо посоветовать идти к руководству и пробивать идею дальше, особенно, если и его руководитель понимает, что их процесс гуано полное. И здесь неважно, кто будет главным — важно, кто будет инициативу проявлять.
2Автор темы:
Если руководитель до сих пор сам не решился что-то изменить, значит надо понять, почему. Он или боится развалить команду или боится еще больше ухудшить показатели. Сделайте не просто предложение, а с четким планом, со сроками, с детальными действиями. Если он в Вас сомневается, посоветуйте ему нанять консультантов по Agile, они помогут сделать первые шаги. А далее, старайтесь не выпускать инициативу из своих рук, но так, чтобы руководитель не чувствовал, что Вы его подсиживаете. Пусть он будет главный за весь процесс перехода, пусть ему достанется вся слава. Вам же нужно сейчас получить опыт скрам-мастера, а не почет. С другой стороны — вы должны понимать, что если что-то пойдет не так, то все шишки на Вас повесят и уволят . Но... волков боятся — в лес не ходить.
Z>Заметил, что процесс у нас не отвечает никаким методологиям/фреймуоркам, ну может немного смахивает на водопад Z>3-4 месяца интересуюсь Agile методоглогиями, тема понравилась, читаю и смотрю много чего, записался на курс CSM. И всё потому, что тема мне нравится.
Стало быть, вам просто интересно "прокачать скиллы" (С)
У вашего работодателя (или начальника, или кого-то еще) могут быть другие планы и ожидания, идущие вразрез с вашими. Возможно, по этой причине вам не дадут качать скиллы за счет работодателя.
Еще одна инетерсная особенность, самостоятельное изучение хоть и дает знания, но не дает опыт. А без опыта и шишек вряд ли у вас получится правильно отвечать на вопросы, которые неизбежно возникают при внедрении любых новшеств.
Здравствуйте, zfima, Вы писали:
Z>Здравствуйте Z>Наверное, вопрос касается общей темы — как продвинуть себя
Z>Дело такое. Z>Заметил, что процесс у нас не отвечает никаким методологиям/фреймуоркам, ну может немного смахивает на водопад Z>3-4 месяца интересуюсь Agile методоглогиями, тема понравилась, читаю и смотрю много чего, записался на курс CSM. И всё потому, что тема мне нравится. А не для того, чтобы кому-то что-то...
Z>Представил начальнику примерную схему и объяснил что к чему
Z>Как только это произошло и манагер начал шевелиться, один товарищ, более приблеженный к нему, начал брать тему в свои руки, не понимая ничего и отвечая на вопросы начальника с помощью поиска ответов в IPhone. Не буду загрязнять пост особенностями "товарища".
Z>Как быть? Дать им всё завалить?
Ну, вы уже догадались, чем всё закончилось?
Нет?
Товарищ под эгидой манагера начал проводить небольшие лекции на которые были приглашены только девелоперы, находящиеся с ним в хороших отношениях
Меня через 2-3 встречи после пары моих замечаний по поводу перестали приглашать
M>Сначала еще немного вводных слов. Я не совсем понял, он "agile по книжке" рассматривает? Т.е. команда совсем взаимозаменяемых профессионалов? Ну да, там будут провалы в определенных местах наблюдаться. Ну так проще процесс потюнинговать, нанять бизнес-аналитика или менеджера (с функциями бизнес-аналитика). И работать "в духе agile". А еще у меня местами возникают вопросы, Scrum ли это или уже пошли вариации на тему. Вообще, автор пытается обосновать, почему же его такого хорошего (и других аналогичных), которые не умеют производить реальный value, все же стоит брать и платить ему полную ставку.
Отдельное спасибо за эту фразу. В компаниях разрабатывающих софт добавочную стоимость создают программисты. Наемный управленец добавочной стоимости не создает, но может влиять на процесс ее создания. К сожалению, немногие менеджеры способны "экономически" объяснить свою пользу и являются, скорее глашатаями того или иного карго-культа (в том числе и scrum). Интересно, что некоторые оказываются неспособны объяснить свою необходимость даже команде, которой они управляют. Вопрос, а зачем вы нужны этой команде ставит их в тупик, т.к. они привыкли мыслить в парадигме "зачем мне нужна эта команда".
Вообще, это очень интересная тема для дискуссии. Она затрагивает и размер команды, и квалификацию программистов и даже необходимость тестировщиков в проекте. Последнее время я все больше склоняюсь к тому, что небольшие команды (до 5 человек) сильных специалистов являются наиболее эффективной моделью разработки софта для гораздо большего спектра задач, чем это принято считать. А если это так, то и архитектура разрабатываемых систем и процессы внутри компании должны быть подчинены этой модели.
Здравствуйте, zfima, Вы писали:
Z>Здравствуйте Z>Наверное, вопрос касается общей темы — как продвинуть себя
Z>Дело такое. Z>Заметил, что процесс у нас не отвечает никаким методологиям/фреймуоркам, ну может немного смахивает на водопад Z>3-4 месяца интересуюсь Agile методоглогиями, тема понравилась, читаю и смотрю много чего, записался на курс CSM. И всё потому, что тема мне нравится. А не для того, чтобы кому-то что-то...
Z>Представил начальнику примерную схему и объяснил что к чему
Z>Как только это произошло и манагер начал шевелиться, один товарищ, более приблеженный к нему, начал брать тему в свои руки, не понимая ничего и отвечая на вопросы начальника с помощью поиска ответов в IPhone. Не буду загрязнять пост особенностями "товарища".
Z>Как быть? Дать им всё завалить?
Здравствуйте, zfima, Вы писали:
Z>Ну, на пример ты начальник. Любишь музыку самоа, картины художника П. и фильмы о тасмании. Чудесным образом мне тоже всё это нравится!
Почему бы не объяснить ситуацию начальнику и прямо не предложить решение? Почему мешают фильмы о тасмании?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
