> Основная цель любой коммерческой организации — не развитие, а прибыльность, не бывает ориентации на развитие.
Существует временное состояние как-раз развития для того, чтобы продаться как можно дороже. Но это редко связано с внутренними проектами, в основном внешние.
> Правильнее найти компромисс между Product Owner и командой. Например, через согласованное снижение количества функциональности, которое планируется реализовать на новой итерации для реализации каких-то технических историй.
По-моему это не очень сложно, если команда сможет количественно оценить необходимость конкретной технической истории. Это возможно как при падении velocity, так и просто посчитать, что, при введении той или иной технической истории, компания будет экономить определённе количество финансов. Далее, при оценке историй на выручку / трудозатраты, техническая история может попасть в спринт. Если не может, значит она там и не должна быть, за некоторыми исключениями.
Могу написать немного про документацию. В организации, где я работаю, используется ITIL, однако в моей команде разработчиков — Scrumbut (до настоящего Скрама ещё не дошли, однако прилагаю все усилия для этого). Так вот, на несколько систем есть огромные документы, где досканально расписано, что и как работает. Так как команда разработчиков не совсем профессиональна, то половина вообще не открывала данный документ, вторая же почитала в первые несколько дней и потом лишь в очень редких случаях.
При разработке уже полгода-год документация не обновлялась. Оно и понятно, программистам сложно заставить себя открыть огромный документ, найти в нём место, что они меняли и обновить. Потом отправить на проверку, где начнутся дополнительные вопросы и уточнения. Такими темпами реальной разработки будет сделано мало, зато документация будет свежая.
После достаточно продолжительной борьбы с руководством, был найден компромис — к каждому заданию у нас прилагается документ с указанием, какие пакеты были изменены, прошедшие unit тесты и скрипты для базы данных. Так вот, добавив всего один параграф «High level documentation», программист тратит максимум 5 минут, чтобы написать, что же было изменено, да добавить скриншот. В итоге все довольны, хотя огромный документ и не обновляется, но главное тут — отвести глаза от «недокументированности», которую можно будет исправить, выделив человека и дав список заданий, следанных за определённый промежуток времени, благо все мелкие документы фиксируются.
> Интересно, что техническим партнером Twitter в отношении нового фото и видеохостинга является Photobucket.
Очень интересует, где именно фотографии будут храниться, так как до сих пор бывают ситуации, когда Twitter показывает кита с сообщением «Twiiter is over capacity». Если ещё фотографии будут на тех же серверах, то данное сообщение можно будет видеть ещё чаще, что не очень хотелось бы.
Не соглашусь с автором. Вернее, методика действительно поможет работникам развиваться, если они не потратят всё свободное время на игры в соц. сетях.
Проблема в том, что супервизору необходимо следить за выполнением работ каждым сотрудником и планировать, когда давать новые; — то есть у каждого разработчика есть нянька, которая за него думает, когда и сколько делать. В итоге у разработчика никакого «права выбора» — дали одно задание — делай. Когда есть список задач, можно их спланировать, также спланировать своё время — если это Скрам, то сделать все задания за 3 дня из дома и потом заниматься собственным развитием, либо спокойно по 8 часов кодить.
Да, головной боли у разработчика становится меньше, но он превращается таким образом в бездумное одноклеточное.
Данный метод хорошо сочетается с существующими рабочими процессами. Он может увеличить производительность труда как отдельных работников, так и всей компании в целом.
Данный метод скорее уменьшит производительность, особенно, если супервизор заболеет — сразу же должна появиться другая нянька и давать задания. Тогда уж лучше ввести Скрам или хотя бы частичку его и давать задания на неделю.
П.С.: У нас заданий всегда больше, чем разработчиков. А если, вдруг, заданий меньше, то можно придумать что-нибудь полезное, вроде тренингов, рефакторинга, оптимизаций. Время — деньги и многие люди не умеют правильно распоряжаться им, посему надо направлять людей.
Спасибо, не смотря на достаточную очевидность написанного, очень полезное напоминание, а также база для будущих руководителей проектов.
Очень часто при планировании действительно сложно выудить у заказчика, что важнее, что нет, звучит постоянно «Надо это. И это надо. И это. Вы можете сделать только одно? Надо всё и сразу!». А со временем оказывается, что некоторые задания могут год никем не делаться, а заказчик успешно забыл, так как появилось множество других, таких же важных заданий. Это, конечно, плохо, но говорит о том, что заказчики не могут адекватно оценить, что на самом деле надо, а что — нет. И тогда на помощь приходит [i]business case[/i]. Вычисление занимает какое-то время, но с данной оценкой куда проще расставлять приоритеты и показывать заказчику, что он сам оценивает некоторые «важные» вещи в копейку.
Я хоть и начинающий ScrumMaster и тренинг на сертификацию будет лишь в следующем месяце, но пару собак уже съел и, по-моему, вашему ScrumMaster'у было бы очень полезно прочесть данную книгу. Читается очень легко, не смотря на английский и даже присутствует юмор.
Конкретные советы давать не берусь, так как ситуация видна не целиком, а лишь часть её и, возможно, лишь плохие стороны.
Очень плохо относятся. Но я не вижу смысла не работать, когда это доставляет удовольствие и слегка снижает нагрузку в рабочее время, чтобы можно было иногда смотаться по своим делам в рабочее время.
Отличная статья, благодарю!
Наконец-то получил «волшебный пинок» для того, чтобы повесить доску в доступное место и визуализировать процесс. Осталось подобрать приложение для того, чтобы удалённые разработчики видели похожую доску, а именно — список задач. Пока используется agilo, но есть мысли уйти от него.
Продуктами пользуются множество компаний по всему миру. Красношапки под крылом США, следовательно, последним выгодно, чтобы некоторые дыры, обнаруженные внутренними сотрудниками и не разглашённые, не латались. В итоге в случае конфликтов спецслужбы смогут парализовать те машины противника, которые работают под определённой ОС.
Грубый пример, конечно, но очень даже реальный, если ошибку очень трудно обнаружить и она специфична для конкретной ОС / дистрибутива.
Видете ли, АНБ преследует прежде всего национальную выгоду. Или, по вашему, АНБ принесёт в open source что-то гениальное и системы станут защищены от всего? Для этого надо изолировать сервера и физически отключать от сети.
Существует временное состояние как-раз развития для того, чтобы продаться как можно дороже. Но это редко связано с внутренними проектами, в основном внешние.
По-моему это не очень сложно, если команда сможет количественно оценить необходимость конкретной технической истории. Это возможно как при падении velocity, так и просто посчитать, что, при введении той или иной технической истории, компания будет экономить определённе количество финансов. Далее, при оценке историй на выручку / трудозатраты, техническая история может попасть в спринт. Если не может, значит она там и не должна быть, за некоторыми исключениями.
При разработке уже полгода-год документация не обновлялась. Оно и понятно, программистам сложно заставить себя открыть огромный документ, найти в нём место, что они меняли и обновить. Потом отправить на проверку, где начнутся дополнительные вопросы и уточнения. Такими темпами реальной разработки будет сделано мало, зато документация будет свежая.
После достаточно продолжительной борьбы с руководством, был найден компромис — к каждому заданию у нас прилагается документ с указанием, какие пакеты были изменены, прошедшие unit тесты и скрипты для базы данных. Так вот, добавив всего один параграф «High level documentation», программист тратит максимум 5 минут, чтобы написать, что же было изменено, да добавить скриншот. В итоге все довольны, хотя огромный документ и не обновляется, но главное тут — отвести глаза от «недокументированности», которую можно будет исправить, выделив человека и дав список заданий, следанных за определённый промежуток времени, благо все мелкие документы фиксируются.
Очень интересует, где именно фотографии будут храниться, так как до сих пор бывают ситуации, когда Twitter показывает кита с сообщением «Twiiter is over capacity». Если ещё фотографии будут на тех же серверах, то данное сообщение можно будет видеть ещё чаще, что не очень хотелось бы.
Проблема в том, что супервизору необходимо следить за выполнением работ каждым сотрудником и планировать, когда давать новые; — то есть у каждого разработчика есть нянька, которая за него думает, когда и сколько делать. В итоге у разработчика никакого «права выбора» — дали одно задание — делай. Когда есть список задач, можно их спланировать, также спланировать своё время — если это Скрам, то сделать все задания за 3 дня из дома и потом заниматься собственным развитием, либо спокойно по 8 часов кодить.
Да, головной боли у разработчика становится меньше, но он превращается таким образом в бездумное одноклеточное.
Данный метод хорошо сочетается с существующими рабочими процессами. Он может увеличить производительность труда как отдельных работников, так и всей компании в целом.
Данный метод скорее уменьшит производительность, особенно, если супервизор заболеет — сразу же должна появиться другая нянька и давать задания. Тогда уж лучше ввести Скрам или хотя бы частичку его и давать задания на неделю.
П.С.: У нас заданий всегда больше, чем разработчиков. А если, вдруг, заданий меньше, то можно придумать что-нибудь полезное, вроде тренингов, рефакторинга, оптимизаций. Время — деньги и многие люди не умеют правильно распоряжаться им, посему надо направлять людей.
Очень часто при планировании действительно сложно выудить у заказчика, что важнее, что нет, звучит постоянно «Надо это. И это надо. И это. Вы можете сделать только одно? Надо всё и сразу!». А со временем оказывается, что некоторые задания могут год никем не делаться, а заказчик успешно забыл, так как появилось множество других, таких же важных заданий. Это, конечно, плохо, но говорит о том, что заказчики не могут адекватно оценить, что на самом деле надо, а что — нет. И тогда на помощь приходит [i]business case[/i]. Вычисление занимает какое-то время, но с данной оценкой куда проще расставлять приоритеты и показывать заказчику, что он сам оценивает некоторые «важные» вещи в копейку.
Конкретные советы давать не берусь, так как ситуация видна не целиком, а лишь часть её и, возможно, лишь плохие стороны.
Желаю удачи с внедрением!
Наконец-то получил «волшебный пинок» для того, чтобы повесить доску в доступное место и визуализировать процесс. Осталось подобрать приложение для того, чтобы удалённые разработчики видели похожую доску, а именно — список задач. Пока используется agilo, но есть мысли уйти от него.
Грубый пример, конечно, но очень даже реальный, если ошибку очень трудно обнаружить и она специфична для конкретной ОС / дистрибутива.
Видете ли, АНБ преследует прежде всего национальную выгоду. Или, по вашему, АНБ принесёт в open source что-то гениальное и системы станут защищены от всего? Для этого надо изолировать сервера и физически отключать от сети.
Не трожьте красношапок! Да и остальных тоже не надо. У данных компаний и без АНБ операционки куда защищённее форточек.
Кажется, что это как-раз сбор информации о пользователях. Вводишь имя, фамилию и мыло и получаешь в ближайшем времени тонну спама и не только.