Как стать автором
Обновить

Комментарии 37

Превосходная статья. Вы открыли мне мир аджайла под совершенно иным углом.
Спасибо, мы старались :)
Это просто п… праздник какой-то!
«Аджайл», «начальник скрама», «скрам-мастер», «десятиминутные стэндапы», «вайтборды», «4 пивота»… Я один не понимаю смысла всего этого набора букв?
Не правильнее ли было использовать русские значения или, в крайнем случае, писать используемые слова на английском?
Есть устоявшаяся терминология, нам она кажется естественной, может быть мы немного перегнули, но хороших русских эквивалентов словам agile и скрам-мастер я ей богу не знаю
В качестве ИМХО:
вместо agile вполне нормально говорить «гибкие методологии», хотя это не точно переводит слово agile
скрам-мастер — термин, не переводится
стэндап — коряво, но русский термин не сразу вспомнился
вместо «вайтборды» вполне можно говорить «маркерные доски»
«пивот» — совсем жаргонизм, надо заменять
Не один! Фраза «4 пивота» заставила меня подзависнуть. Если «to scram» переводится как «выметаться», то начальник скрама, простите, чем занимается?))
не скрэм, а скрам (от англ. scrum — схватка), соответственно начальник скрама — руководитель схватки, а скрам-мастер — хозяйн схватки.
Статья не рассчитана на тех, кто до ее прочтения ни разу не слышал слов: «скрам, аджайл и скрам-мастер», простите. Вот, я написал «простите», а не «сорри» :)
4 пивота, пожалуйста и сухарики с чесноком!
В своё время, выдав фразу «отрелизь таск, пожалуйста, а то у меня реквест залочен.», я стал задумываться над тем, чтобы использовать русский язык. Но если вайтборды и пивоты можно (и нужно!) заменить синонимами, то с методологией и её терминами ничего не поделаешь.
Спасибо, интересно. Слышал про аджайл в страховой компании и в консалтинге, видел в банке. Теперь буду знать, что и в бухгалтерском учете ему тоже есть место. Если не секрет, а можно парут-тройку формулировок задач с доски?
Чем больше просматриваю статьи про все эти аджайлы и прочее, тем больше понимаю, что мир создан для экстравертов. Всё слишком общественно во всех этих методиках…
Мир создан для экстравертов в тех областях человеческой деятельности, которые требуют коммуникаций. Например, у вас конвейер. Слаженно работает достаточно большая группа людей, при этом интроверты приветствуются. Но как только конвейер встает, приходят такие специально обученные люди, которые за минимальное время должны его запустить. Если они будут работать по одиночке, не коммутируя о обнаруженных проблемах, возможных вариантах решения и не согласуя свои действия, то будет печально. Вот этот мир создан для экстравертов.
Почему вы считаете, что интроверты не могут решать проблем? Вовсе не обязательно на каждый чих всем сразу всё рассказывать. Можно просто решить проблему и дать итоговое заключение, потом другой ответственный на своём участке решит проблему по итогам отчёта первого, и т.д.
А если вдруг коммуникация между такими экстравертами о найденных проблемах идёт некорректно? Скажем, один предположил что-то неправильное, не завершив свою часть работы — и значит пока в принципе не может понять что он косячит — но все остальные приняли этот вывод и начали косячить вместе с ним ещё сильнее?
Еще раз, вы описываете конвейер: «Можно просто решить проблему и дать итоговое заключение, потом другой ответственный на своём участке решит проблему по итогам отчёта первого, и т.д.». Я же написал, что для этого случая интроверты приветствуются. В ситуации когда несколько человек вынуждены решать параллельно одну или несколько задач(у) (ключевое слово параллельно). То им придется согласовывать свои действия. От того, насколько они будут хорошо это делать, зависит результат их совместной работы. И, да, людям которые умеют и любят взаимодействовать с другими людьми в этом случае будет проще. Кстати, ваш пример, как раз показывает проблему с коммуникацией. Вот «один предположил что-то неправильное», при правильном подходе к вопросу, он сообщил о принятом решении коллегам или руководителю. Их компетенция в этой или смежных областях позволит ускорить решение задачи, отказавшись от неправильного предположения. В случае с интровертом, получив задачу, он, сделав неправильные предположения, будет упираться до тех пор, пока не выйдет все отпущенное время на решение задачи.
Я не вижу необходимости параллельного решения задач в представленном вам примере с починкой конвеера, вот в чём дело.
При наличии слишком активной коммуникации но при этом если суть проблемы не будет вычленена руководителем или коллегами — выглядит, скажем, правдоподобно — то наоборот проблема будет лишь усугубляться её реализацией теперь уже группой людей.

И мне непонятно, почему вы считаете, что интроверты способны только на конвеерную работу.

Даже больше, как показывают некоторые исследования, экстраверты склонны к выдвижению некорректных и быстрых решений чаще, чем интроверты. Интроверт может и затормозит процесс, но вероятней всего не уведёт его в совсем другую сторону.
Коллега, извините, но я нигде не писал, что «интроверты способны только на конвеерную работу». Я писал, что решение задач по принципу взял задачу, решил, передал дальше, очень хорошо получается именно у интровертов. Задачи могут быть творческие, могут быть конструкторские, да любые. Все люди разные и каждый должен уметь пользоваться своими особенностями. А руководитель должен уметь пользоваться особенностями своих подчиненных. Кого посадить на парное программирование, а от кого отойти и не мешать.
Теперь о конвейере. Это сложное техническое устройство, в котором может быть большое количество причин приведших к останову. На первом этапе необходимо быстро распределить, кто какие контрольные точки будет проверять (чтобы не было дублирования, а параллельность позволит сократить время поиска неисправности). Да, здесь можно возразить, что по техническому регламенту за каждым сотрудником должны быть закреплены конкретные точки контроля, но реальные производственные условия нельзя уложить в регламенты. Всегда кто-то заболеет, кто-то выйдет на подмену (и вместо КИПовца и электрика в смене окажется два КИПовца). Вот здесь может пригодится умение договариваться. И, в завершении, я знаю достаточно много интровертов, которые великолепно умели общаться с окружающими, просто им на развитие этого навыка пришлось затратить чуть больше времени. А так, с серебренной ложечкой во рту никто не рождается. Одни лучше программируют, други лучше пишут картины, третьи общаются с людьми. И именно в этом разнообразии и кроется вся прелесть.
Согласен.

К слову, что меня больше пугает, что тот же аджайл пытаются применить и к «интровертским» областям. Иногда мне кажется, что скоро останется лишь один большой «тимворк», и интровертам негде будет ужиться — ибо их будут насильно (прямо как в этой статье) затягивать в эти аджайлы. Надеюсь, я ошибаюсь.

PS: я считаю, что программирование как область экстравертов — одна большая ошибка, отсюда и аджайл конкретно в программировании — тоже. По мне так сюда гораздо лучше подходят интраверты — да даже вся архитектура слабо связанных модулей как бы говорит — пусть каждый пилит свой кусок кода. Сколько на той же хабре плачутся о том, как их отвлекают от «потока»!
Аджайл не панацея. Аджайл, к тому же, не методология. Вы можете наложить принципы Аджайл на… Да на что угодно. Например, принцип: «Работающее <в оригинале программное обеспечение, но можно подставить все что угодно>, важнее полной документации.» Ок, почему этим принципом не может воспользоваться интроверт при изготовлении эксклюзивных часов? Этот принцип ему помешает? Мало кто может рассказать на память аджайл манифест и еще меньше тех, кто живет и работает в соответствии с этими принципами…
Аджайл не один принцип, а совокупность, которая и приводит к тому, что экстравертам эти принципы ближе, чем интровертам. Нельзя вытащить кусок целого и сказать, что это и есть целое. Можно иногда вытащить кусок из целого, и оставшееся будет работать. Но кусок никогда не станет целым.
Простите, но у меня сложилось впечатление что вы не понимаете что такое Agile. Не надо делить его на область для ехтравертов либо интровертов — он бил создан еше в начале 90-х в противовес к Waterfall Methodology. Дело в том, что ИТ проектов продолжительностьию более года очень немного, соответственно применять WM не имеет смысла. по сравнению с WM Agile дает нам большую свободу деиствиы и намного меньше документации.

p.s. Scrum is a methodology, Agile isn't.
Первое, что сказал Jeff McKenna на тренинге CSPO – «Если вы думаете, что в Agile меньше документации, чем в WM, вы ошибаетесь. Её там существенно больше, просто она пишется не за один приём».
Разве дополнительные 10 минут в день поговорить с командой — это такая ужасная пытка для интроверта?
«Мир не идеален, а сделать идеальным бухбаланс вообще невозможно.»
Прочитав эту фразу на IT ресурсе понял что он еще как не совершенен. Собственно почему невозможно?
Мир не идеален, а сделать идеальным бухбаланс вообще невозможно. Важно помнить о том, что действительно важно, и следовать правилу Парето: доначисление пары сотен рублей волнует только бухгалтера, не стоит выносить мозг всем вокруг из-за минимальной вероятности понести минимальные убытки.

Минимальные убытки, говорите? Это фантастика, сынок (С). Баланс штука бинарная — он или сходится или нет. Третьего не дано. За не сходящийся рубль можно огрести таких штафов при проверке, мало не покажется никому. Хотя конечно зависит от страны.
Я, если честно, также не понял причем тут Парето.
Парето тут вот при чем: если вы уделяете внимание важным вещам, то получаете 80% результата за 20% усилий. Остальные штуки иногда можно вообще проигнорировать с минимальным риском (например сбор документов на 200 рублевые расходы)
Каких конкретно штрафов при проверке можно огрести за не сходящийся рубль? Описана конкретная ситуация: вы закупили что-то на несколько сотен рублей, при этом первичных документов не собрали. Решение которое должен принять бухгалтер — отнести это на расходы не собирая документ или не относить. Теперь давайте посчитаем в чем риск первого решения. У вас малый бизнес, вероятность проверки компании из малого бизнеса, если она сдает хоть какую-то отчетность вовремя очень не велика. Теперь предположим проверка все таки пришла. Какова вероятность того, что она будет проверять документы для операции в 200 рублей? Очень маленькая, потому что гораздо разумнее проверять крупные платежи, там есть чем поживиться. Теперь умножте эти 2 вероятности друг на друга и получится еще более маленькое число.
Но предположим, что все таки кошмар Мордора реализовался и проверка нашла документ на 200 рублей. Что произойдет такого, что «мало не покажется никому»? :) Да просто доначислят НДС, 18% от 200 рублей. А если у вас упрощенка с доходов, то вообще ничего не произойдет.

Еще один пример: спросите у своего бухгалтера уверен ли он в том, как рассчитана среднесписочная численность вашего предприятия и что до этого точно нельзя докопаться?

Актив с пассивом конечно сходиться будет, даже у студента. Но будет ли это всегда подтверждено правильными документами? Вот о чем речь
Прямо таки захотелось познакомиться с двумя девушками на фото. Надо оформить подписку и попросить именно их прикрепить :-)
Какие хорошие у вас названия команд!
Статья, интересная, но из неё непонятно:
1. Какие причины всё-таки побудили выбрать agile
2. Из каких вариантов управленческих концепций выбирали
3. Какие практики, кроме стэндапов, используются:
3.1 Бэклог есть? Что туда входит? пример?
3.2 Итерации есть? Какой длины?
3.3 Сессия планирования? Командная оценка задач?
3.4 Ретроспектива?
3.5 Бёрндаун?
3.6 Таскборд вижу на фото
Бёрндаун тоже вижу на фото
1. Мы так жили года 3 в других проектах, в которых была чистая разработка, по другому не хотелось :)
2. См. пункт 1.
3. Презентация, ретроспектива, планирование итерации.
3.1. Бэклог есть, он разбит по категориям, например: разработка, заявки, обслуживание клиентов… Входят задачи как обычно, предварительно приоритезированные.
3.2. Итерация длиной 2 недели
3.3. Сессия планирования происходит после презентации, сначала предварительное планирование в группах, потом сводимся вместе. Командная оценка задач не во всех группах, в разработке есть, в ux есть, в продвижении нет
3.4 См. 3 :) Ретроспектива в группах, потом общая
3.5 Берндаун только у разработчиков, у бухгалтеров нет
2. ну т.е. для управления бухгалтерами вы выбирали из методик разработки? мощно, из серии «ищем под фонарём» :)

3.2. зачем бухгалтерам итерации? почему не канбан?
Я считаю, что для того чтобы бороться с потерями или перепроизводством нужно сначала получить процесс, в котором ты уверен. Поэтому не канбан
Зато Kanban Boards используете :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий