В прошлой статье Andrey Yasinetskiy сказал, что мой манифест работодателя противоречит Agile. Я так взял, взвесил agile практики, которые знаю, почесал в голове, отписал, что они не противоречат. А потом я полез и прочел Agile software development статью в wiki. и обнаружил, что большинство практик на самом деле противоречат первому же пукнту Agile манифеста.
Самый первый пункт манифеста — «Individuals and interactions over processes and tools«. Блин, да половина agile дисциплин основана именно на следовании процессов. Test driver development, continuous integration, code refactoring, iterative development — это же все процессы. Причем, если взять какие-нибудь уже готовые методики (а-ля того же SCRUM) то эти процессы там уже четко прописаны, описаны, роли, действия, артифакты и т.п. Да, естественно в каждой из них есть «individuals and interactions», но как только individual решать забить на процессы, которые им не нравятся — а-ля перестанут код класть в source control, остановят систему генерящую билды и перестанут делать итеративную разработку, вот тут как раз и придет пипец их попыткам работать Agile.
Кстати, аналогично насчет послднего пункта Agile манифеста «Responding to change over following a plan«. Это не значит, что надо нафиг забить на план. Это значит, что план должен изменяться в зависимости от внешних событий.
В целом, можете в меня хоть помидорами кидать, но Agile Manifesto в чистом виде — это радужные мечты богемы IT мира. Для всего же остального мира, Agile практика (которая таки требует процессов и изменчивого плана) кроет как бык овцу Agile теорию.
Ну мне кажется что вы несколько утрировали чтоли… и мы наверное… скорее всего… и даже очень может быть не совсем понимаем что именно кроется за фразой «Individuals and interactions over processes and tools»….
если её понимать буквально… то любой разработчик в команде, которая работает над php-проектом скажет: «а да за
е..надоел мне этот php — буду писать на паскале…»и шо!? — это явный пример Individuals over tools — но смысл то в нём какой?!…
это всё-равно что попробовать затянуться сигаретой перед тем как её поджечь… затянуться-то можно… смысла вот только никакого…
Хехе, а вы ожидали в рекламном документе (чем является манифест) прочесть стройные дельные мысли? ИМХО, в отличии от вашего, это маркетинговый инструмент и вашим и нашим, так что о никакой стройности и несамопротиворечивости речи там быть не может
Не думаю что манифест это рекламный документ.. но это и не свод правил — это скорее рекомендации, которым неплохо было бы следовать, с некоторыми дополнениями, уточнениями и толкованиями — и всё у вас будет хорошо…
сравните — заповедей тоже всего 10… хотя ходят упорные слухи что их было 20 — ненужные со временем «потерялись»… ну да ладно это не предмет этого разговора…
Так вот — заповедей 10… а толкований к ним… Ветхий завет, Новый, послания Петра, Павла и т.д. и т.д…. 2000-летняя история церкви… и всё только для толкования 10!!!! заповедей… :)))
точно так же и с этим манифестом — где написано что в первом пункте речь идёт о процессах и средствах разработки!? где!, ткните меня носом…. может речь совсем о других процессах и средствах!?…
про рекламу, хм, не был бы так уверен, я очень хорошо погружен в мир аджайл трениров, консалтинга и прочего булшита, так что тут ещё бабка на двое сказала 😉
пример с заповедями не рассматриваю: далеко от предмета разговора + все аналогии ложны.
это нигде не написано. Для построяния бизнес-консалтинга как раз и надо расплывчитость (в ответах на вопросы как?) + чёткость (таргетинг бизнеса на поставленые цели) = бизнес видет цель, ну а тренера конечно же помогут её достичь 😉
не.. так подождите… кстати тут заповеди, религия и церковь кстати очень сильно переплетаются с аджайлом….
мы говорим про использование методологий аджиль или про обучение !?
да.. аналогии…
есть вера (10 заповедей + моральные принципы) — а есть церковь+религия
есть аджиль манифест — а есть коучи+тренинги
похоже не правда ли?
для вас похоже, ну и хари кришна 🙂
простите, но я не веду диспутов на аналогиях
перед тем что что-то использовать эффективно нужен, в частности, процесс обучения, да (обычно это называется transformation into agile)
Согласен с Андреем. Это сейчас он стал рекламным документом. Тогда — это таки был манифест, так сказать крик души умных людей.
он есть рекламный документ. Здесь и сейчас с высшим приоритетом 😉 А что было тогда? Вы же тоже свечку не держали 🙂
Да, я действительно слегка утрировал. Просто для того, чтобы показать, что из манифеста не стоит создавать карго культа. И как раз подчеркнул, что реальные практики далеко ушли от изначальной мантры.
Перечитал вашу предыдущую статью ещё раз, это и есть манифест аджайла 🙂 только сказано конкретно и чётко
самое интерестное по поводу аджайла, так это и есть его двуличность (и, кстати, большинство разработчиков это чувствуют). А двуличность заключается в том, что инжинерам по-существу выдаётся ваш манифест, а по форме вот та красивая писулька, ну и конечно же аджайл-коуч прыгает и рассказывает как аджайл это круто для разработчика, хотя на самом деле аджйал высасывает все соки из него на пользу бизнеса (ну это так, к слову 🙂
Странный вы человек :)))) говорите что аджайл высасывает все соки… а «манифест работодателя» это суть тоже самое, только коротко и ясно…
Я вижу вы его не очень внимательно читали… я вам по простому напишу:
Правило N.0. Согласен работать на меня — добро пожаловать в рабство. Не согласен — пошёл на…
Правило N.1. Всё-таки согласен работать на меня — копать раб… солнце ещё высоко
Правило N.2. Накопался — отчитайся…
Правило N.3. Фрилансер… забудь это имя раб
Правило N.4. Работа у тебя готова на 95%.. ню-ню раб…
Правило N.5. Копай!!! (с) Галыгин
дальше выводы не нумеруются… но они тоже интересные
Вывод N.1. Платим похлёбкой и см правило N.0. вторую чать
Вывод N.2. Уступки при соблюдении первых пяти правил… я вот думаю интересно это какие!?.. в туалет бесплатно отпускают?
Автору манифеста… вы не подумайте что я с ним НЕ согласен… я в общем-то поддерживаю где-то даже его… это я всё расписал чтобы пАлАмАть розовые очки предыдущего комментатора
Вывод N.3. Конечно.. рабы которые хорошо копают нужны всем… это самый логичный из всех выводов….
смотрите пост ниже, промахнулся ссылкой
В корне не согласен. Выставление условий сотрудничества одной стороной не является рабством.
У вас сотовый есть? Не дай бог на контракте? В контракте есть добрых три десятка пунктов с требованиями.
Кредит на кваритру — добрых пол сотни пунктов.
Купили билет на поезд или самолет. Между прочим к этому тоже прикреплены требования.
Рабство — это когда ты являешься чьей-то собственностью и не вправе вообще принимать решений.
ну я тоже «слегка» утрировал :)))
Спасибо, конечно на добром слове 😉 Но все таки это НЕ манифест Agile. Сейчас поясню почему.
Мой манифест направлен на то, чтобы четко разграничить то, что можно и то что нельзя. Он применим не только к IT (чуть терминологию порезать программистскую только нужно) , он может быть использован с waterfall (что точно не agile).
Скажем так, мой манифест — это именно манифест работодателя. То, чего он ожидает от работника.
Возвращаясь к Agile. Если поглядеть то, что написано в Wiki, то это НЕ требование, а направления. Причем скорее для инженеров и менеджеров, а не для владельцев.
Насчет двуликости… Это сильно зависит от компании. Agile можно достаточно сильно модифицировать и из него можно сделать как потогонную систему (то о чем вы говорите), так и пытаться создать рай для программистов.
не для спора ради, знаете ли публичные блоги «инженеров и менеджеров» где они хвалят аджайл. Очень хочу видеть и читать такие положительные вещи где бизнес направлен на «рай для программистов» а не get things done.
Само собой такие долго не живут компании.
Вот тут моя статейка о том, как мечтал водворить такое в жизнь
http://victorronin.com/2008/07/15/biznes-eto-vam-ne-xixanki-xaxanki/
Хотя, как это не смешно звучит, есть достаточно большое количество компаний, где технический отдел рулит (в плохом понимании этого слова) компанией. Конечно не впрямую, но косвенно. И как раз в таких компаниях зачастую технические решения ставятся выше бизнес целей (ну и вы догадываетесь к чему это приводит).
я довольно давно читаю ваш блог, просто вот недавно закончил такой один аджайл проект и появилось свободное время 🙂
ага. Спасибо, что читаете 🙂
не спора ради — а вы знаете хоть один сайт где хвалят мясорубки… не рекламируют — а хвалят… да офигенно удобный инструмент… но и только…
зачем хвалить лопату — копает и пусть копает себе… но ведь в руках дурака та же лопата превращается во что угодно и используется как угодно… но только не по своему прямому назначению
Agile точно такой же инструмент… и в руках дурака… ну дальше сами догадаетесь :))
нет, не знаю, даже не знаю сайтов их рекламирующих 🙂
С религией не получилось, попробуем с домашней утворью? Вот видите как легко заблудится в споре, основанном на аналогиях.
Сказать, что что-то является инструментом для меня не достаточно. Всегда возникает вопрос: для чего? Расскажите для чего вы используете аджайл. Мне было бы интерестно почитать\подкаст.
Для чего аджайл является инструментом для меня, полагаю, понятно из предыдущих постов.
нет, не согласен, ни про рабов, ни про похлёбку, это есть только в вашем мире. Если вы без эмоций прочитаете и то и другое: это суть одно и тоже. Просто Виктор написал это по-армейске, а ребятам написали это по-маркетинговоски. Отсюда и есть ваше принятие или не принятие. Мне так кажется (перекрестился 🙂
вот только не надо про разные миры…
если ВЫ внимательно перечитаете оба манифеста то увидите… что аджиль неконкретен да… но манифест работодателя это «Я начальник — ты дурак» написанный простым армейским языком…
на это разговор закончим — бесмысленный разговор… человек который не понимает аналогий мягко говоря очень сложный оппонент… очень мягко говоря…
а оскорблять попросту неохота 🙂
всем спасибо.. всем удачи
я понимаю аналогии 🙂 вот только споры на аналогиях не веду. Ну да, вот такой, люблю конкретику.
благодарю вас за разговор. Всех вам благ и всего самого лучшего!
Манифест работодателя — это «Я начальник — ты подчиненный (не в коем случае не дурак).
Коллеги. Ну к чему такие споры? вполне такой аджайл документ. Там же есть пункт про уступки. Или про ответсвенного и честного сотрудника там не по аджайловски? И я уверен, что Виктор будет готов изменить какие-либо пункты после обсуждения с его членами команды в будущем, конечно если все придут к согласию, что что то не работает. Изменить все, если оно как то неэффективно. Не это ли настоящяя Гибкость, та суть, которая прячется за CSM, CSPO?
Естественно, это не заповеди выбитые в камне. С другой стороны, то, что я написал достаточно мало способов сделать гораздо эффективней.
Вряд ли позволение человеку не отчитываться и исчезать когда ему захочется сильно облегчит бизнес.
> но как только individual решать забить на процессы, которые им не нравятся — а-ля перестанут код > класть в source control…
в корне не верно.
1. команда должна _хотеть_ работать по agile и главное она должна понимать, что и зачем она делает.
2. все решения принимаются коллективно. Если хотя бы один член команды против, обсуждение либо начинается сначала, либо происходит поиск более убедительных аргументов в пользу перемен. Одним словом, до тех пор пока все члены команды не проголосуют, решение не может быть принято.
3. нужно помнить, что agile команда это в первую очередь самоорганизованная(имею в виду с высоким уровнем самоорганизации 🙂 ) и мотивированная команда.
> не для спора ради, знаете ли публичные блоги “инженеров и менеджеров” где они хвалят
> аджайл. Очень хочу видеть и читать такие положительные вещи где бизнес направлен на “рай >для >программистов” а не get things done.
что подразумевается под раем для программистов? любой бизнес направлен на get things done иначе какой тогда в нём смысл? Просто существуют методики, позволяющие сделать этот процесс более увлекательным и эффективным, ведь в идеале в agile команде все должны быть happy 🙂
рай для программистов — это термин Виктора, а не мой, он даже давал ссылку на свой пост.
вчера как-раз слушал подкаст про принятие решений в аджайл командах (коллективный, консенсусный, голосовательный и тд). Важно понимать, что пока нет единого эмоционального интеллекта в команде это ничего работать не будет.
Другой интерестный аспект — это аджайл в интерпрайз, когда у вас много команд. В частности, с различными уровнями прокачки эмоционального ителлекта.
Ещё более интерестный случай когда кастомер считает, что люди должны постоянно переходить из команды в команду (этак раз в 2-3 месяца).
То, что вы описали — это super easy уровень менеджмента разработки по аджайл.
Про направленность бизнеса на результат. Никто не спорит, только это не от методологии зависит 🙂 а от людей. Найми правильных людей, ИМХО поэтому я считаю, что манифест заказчика важнее манифеста любой методолгии (кстати, вы это подтверждаете своим первым пунктом — найди людей желающих работать по аджайл :). Уверен, что у вашего заказчика есть тоже свой манифест по инжиниринг практикам 😉 Хотя вроде как на вопрос «как делать» отвечает сама «самоорганизовывющиеся и высокомотивированная» команда. Андрей, снимайте розовые очки, «there is no spoon» (с)
Теперь про би хэппи, я бы в это не верил. Хэппи вас делает не методология, а чувство хорошо выполненой работы в команде (в сплоченном коллективе). Всё остальное — это вопросы как этого достичь. И аджайл этим не занимается. Аджайл призван повысить эффективность. Т.е. как бы чувство выполненной работы. Вот только зачастую работа как бы и выполнена по аджайлу, но выполнена самым быстрым, не маштабируемым и не переносимым методом.
по поводу эмоционального интеллекта в команде согласен.
>Ещё более интерестный случай когда кастомер считает, что люди должны постоянно >переходить из команды в команду (этак раз в 2-3 месяца).
у нас так происходит.
наш заказчик уникален тем, что платит нам за то, чтобы мы работали по agile. И делает всё для того, чтобы так и было. Мне не нужно снимать розовые очки, потому что мы ежедневно работаем так, как я описываю и ежедневно наблюдаем какую пользу это приносит. У нас команда «эволюционировала» в течении года и продолжает эволюционировать. И оглядываясь назад и смотря на то что есть сейчас это две большие несоизмеримые разницы. Поэтому я знаю о чем пишу.
В agile процесс у нас вовлечены порядка 70 человек.
>Вот только зачастую работа как бы и выполнена по аджайлу, но выполнена самым быстрым, >не маштабируемым и не переносимым методом.
Это зачастую возникает тогда, когда нет четких и выработанных engineering principles.
Вот привожу список наших, которым мы следуем. И каждый в команде следит за этим:
1. Always test first!
2. Always run tests before check-in and ensure they pass
3. Avoid code completion
4. Acceptance environments are healthy before work commences
5. Simple, clean, readable and concise code
6. All stories must be pre-estimated by the team who will play it
7. Working software is the primary measure of progress
8. Code quality comes from Paiting and Collaboration
Поверьте, используя эти 8 пунктов мы избавились от того, что вы написали. Поэтому я точно могу сказать, что такое может быть.
ну так Андрей, как насчёт того, что эти 8 правил решала не команда, а кастомер?
Мне очень интерестны ваши мнения по поводу пункта 7 и пункта про парное программирование из пункта 8. Можете в своём блоге.
Пункт 2 полностью опирается на то, что используется древняя SVN.
В пункте 3 вы, наверное, хотели написать code duplication.
То, что есть пункт 1 = TDD или у вас таки да есть люди которые могут хорошо протестировать все артефакты в проекте, начинаю с историй и journies?
Вообще-то эти правила вырабатывала команда. В процессе было собрано множество практик и предложений и выставлено на голосования. Наиболее важные по мнению команды, а также те, которые набрали больше всего быллов вынеслись на обсуждение и утверждение и в процессе были приняты.
я отдельно напишу об этом в своём блоге. а здесь могу коротко прокомментировать.
1. Все тесты у нас пишут разработчики. QA пишут только тест-кейсы и то не всегда. Чаще QA вместе с девелопером занимаются «пэйрингом» и пишут сразу аксептанс-тесты (в нашем случае в FittNess). В конце каждой стори прогоняется весь сьют.
2. причем тут svn? какая бы scm не была, вы всегда должны быть уверены, что тот код, который вы выпускаете — работает, а также то, что вы ничего не поломали из рабочего. Это касается не только Unit тестов, но и аксептанс тестов тоже.
7. да. вся команда нацелена и сфокусирована на успешный аксептанс той стори над которой работает. Соответственно, прогресс и результат измеряется в рабочем продукте по завершению каждой стори, так-как каждая из них несёт вполне конкретный business value.
8. С парным программированием у нас были трудности в начале, поскольку не все люди согласны с таким подходом. Однако постепенно, когда все увидели что это работает на практике и довольно эффективно разногласия закончились. Сейчас у нас все занимаются парным программированием. Для этого у нас созданы специальные пэйринг-станции с 2-мя мониторами, 2-мя клавиатурами и т.д. Весь день разработчики работают с этими станциями. Для каждой станции сделаны также аккаунты в Jabber и Skype.
команда или команды? как я понимаю там достаточно много команд. Кто окончательно принимал решения и считал баллы? Уверен, что всё это было на стороне кастомера.
СВН здесь очень даже причём. Очень меняется мировозрение на системы контроля. Я бы сказал становится на место. Потому как коммит это естественная операция, или вы хотите сказать, что можете себе позволить уйти домой не закоммитив что-то. А если ваш винт, не дай Ктулху, прикажет долго жить?
для проверки есть интеграционный контейнер, но опять таки это тяжело сделать без распределенных систем. Поэтому и гооврю, все эти ручные проверки идут из-за того, что:
1. Цнтрализованный репозиторий
2. Скорее всего все комитят в один транк.
Измерение подразумевает единицу (базис) измерения. Расскаите мне про такой базис, относительно «Working software».
Про парное програмимрование: лично вы парно-программируете? Если да, как относится ваш ко-пара к написанию комментов здесь.
команда. она у нас хоть и распределённая, но одна 🙂 баллы считались автоматически в surveymonkey. затем была общая ретроспектива, где всё это обсуждалось.
мы стараемся коммитить как можно чаще, но только такой код, который не ломает билд.
у нас настроены автоматические билды на аксептанс контейнере. пока трудностей не возникало.
у нас нет ручных проверок. Мы стараемся автоматизировать процессы. Я не говорю конечно, что у нас 100-е покрытие, однако то покрытие которое есть позволяет не тестировать руками.
Базисом измерения для нас является стори.
Лично я парно программирую тоже, поскольку я девлид. Парное программирование подразумевает периодический таймаут, когда можно пойти за свою машину и сделать то что тебе нужно. Что касается лично меня, то на работу я приезжаю обычно в 7:50 утра, поэтому у меня достаточно времени, чтобы позаниматься своими проектами и другими делами до прихода всей команды :).
смотрите комментарий ниже. Промахнулся ссылкой
Скажите, когда к вам новый человек приходит. У вас происходит полное переголосование? Что будет если человек НЕ согласиться с правилами?
Я имею в виду, что на каком-то этапе эти правила начнут активно навязывать даже тем, кому они не слишком нравятся.
То что было принято до прихода нового человека является решением той команды, которая сложилась до его прихода. Я бы не называл это правилами, а скорее выработанными подходами. Если человек с некоторыми не согласен, он может вынести вопрос на обсуждение и предложить что-то своё. А вдруг его предложение окажется действительно стоящим и команда его одобрит?
вопрос. что происходит в тот момент, когда человек не согласен?
давай-те я предположу, он говорит (может про себя), ладно, фиг с вами золотыми рыбками, будем делать по вашему.
Я имею в виду, что так или иначе у вас есть правила (да которые можно обсудить в виде голосования). У вас уже есть установившийся процесс.
Кстати, об этом я и писал статью, что процесс неизбежен.
>наш заказчик уникален тем, что платит нам за то, чтобы мы работали по agile.
Замечу одну вещь. Ваш заказчик тоже имеет свой манифест, только может его не озвучивает. Например в его манифест входит то, чтобы вы работали по agile.
И кстати, если в какой-то момент он найдет более эффективный метод чем agile, в этот же день agile закончиться.
Кстати, если ВСЯ ваша команда примет решение, что ничего не делать и только получать деньги от заказчика — самый прикольный метод, то Agile тоже закончиться.
Так, что ваш манифест — это манифест эффективной разработки. Мой манифест, который обсуждался в прошлой статье — это манифест эффективного сотрудничества (причем именно со мной).
так а я согласился с вашим манифестом :). я только уточнил для себя некоторые формулировки.
Согласен абсолютно по всем пунктам.
Андрей, то, что вы написали — это малореалистичный идеал
а) ВСЯ команда хочет работать по какой-то методологии
б) Никогда не находится хотя бы один человек, который упрется рогами
в) Все члены команды высокоинтеллектуальные, организованные и мотивированные люди.
Я за 10+ лет работы не видел ни одной такой качественной команды.
Не спорю — может существовать, но таких команд будет 1 из 100. А теперь главное… Возможно, что сбор такой команды с финансовой точки зрения окажется НЕ ВЫГОДНЫЙ. Так как завтраты времени и денег перекроют увеличение эффективности.
a. в этом суть
b. есть такое и даже в нашей команде. поэтому многие вопросы и инициативы всё еще висят в обсуждении и периодически поднимаются вновь.
Например совсем недавно несколько членов команды включая меня пытались предложить новый подход в написании FitNess тестов, однако несколько человек отказались его принимать. Поэтому решение так и не принято, мы вернулись к предыдущей схеме написания. И это не плохо. Если так решила команда, значит на данный момент это приемлемо и наиболее эффективно. Возможно через полгода этот вопрос поднимится вновь.
в. к этому нужно стремиться. у нас пока не так.
возможно по поводу перерасходов вы правы. однако наш заказчик слишком убеждён в процессе и он готов за него платить, даже если на первых порах это несёт перерасходы. Он верит, что в перспективе это принесёт бОлший value.
Суть может и в этом. Но, так или иначе есть метод принятия решения, как будет делаться. И то, что поддержано большинством потом навязывается остальным (как пример с тем самым новопришедшим).
Давай те поглядим на примере демократии, в которой таже задумка. Да, есть голосования, да вроде все выбирается большинством, но это не значит, что все просто пищат и тащятся с законов.
Ну и соотвественно, чем больше людей, тем меньше шансов, что все согласны.
Образуются активные группы, которые продавливают свои идеи и теории. В результате все равно все ведется небольшой активной группой.
на самом деле чаще бывает так, что некоторым членам команды вообще всё равно(у нас такая проблема еще частично осталась, но решается понемногу). Да, всегда есть группа энтузиастов жаждущих перемен, есть люди более спокойные, все мы разные. agile как раз о том, чтобы работать с людьми. и часто случается, когда выносится очередной вопрос на рассмотрение и некоторые просто воздерживаются или придерживаются концепции — зачем что-то менять, если и раньше вроде было неплохо. Это я говорю в дополнение к вашим словам, что всегда будут группы, продавливающие свои интересы. Остаётся решать как вовлекать безраличных(пофигистов быть не должно) и какие подходы искать к протестующим 🙂
отступая к высказыванию о демократии. в масштабах государства трудно выслушать каждого, поэтому всегда будут недовольные. В небольшой команде такая возможность есть. И даже если человек не проявляет активность, не принимает участие в голосовании чаще всего причина не в его безразличии к вопросу, а совсем в другом, поэтому всегда нужно беседовать и докапываться до истины.
так у вас небольшая команда? или 80 человек как вы говорили?
кол-во человек принимающих участие в agile процессе — 80. но эти 80 человек раздроблены еще на под-проекты (которые являются частями одного большого продукта).
Ну, честно говоря на размерах 80 человек. Я себе представляю следующее.
Есть с десяток лидеров, от которых идут 90% всех предложений и изменений. Есть еще где-то 20 человек которые активно участвуют в обсуждениях (большинстве обсуждений).
Остальные 50 человек вероятнее всего либо редко влезают в обсуждения, либо вообще этого не делают. Ну, максимум что — полосуют, да и то не все.
К чему я собственно говоря веду. Ни в коем случае, я не хочу сказать, что у вас что-то плохо. На самом деле, судя по описанию — у вас интересно и хорошо.
Что я хочу сказать, что люди главнее процессов работает на 5 человеках, с трудом рабоет на 20 человеках, к 50 человекам — процессы уже руководят людьми, хотя хоть можно еще процессы поменять. На 500 человеках, процессы уже жестко руководят людьми и поменять их ну очень мало шансов. На 5000 процессы — это все, а люди — это маленькие винтики в машине перемалывающей их в деньги.
Да, собственно говоря, я хотел сказать, чот agile manifesto лукавит в том, что люди всегда должны быть важнее процессов. Может они и должны (и лучше было бы), но как не организовывай коллектив, при больших размахах есть люди, которые важнее процессов (лидеры), а остальные работают внутри процессов и либо сами, либо их запихивают в уже работающий процесс.
браво! Именно поэтому я так дотошно выяснял вопрос команд-команды.
простите, но я не верю, что у вас одна команда 🙂 У вас есть свой проект, есть свой ПМ (скрум-мастер) — вот это и называется команда.
Прислано было кастомером т.к. уверен, что вашего инпута на ретроспективе он-сайт не было.
стори не могут быть базисом т.к. они не являются однородными. Если они таковые, то мои поздравления, на практике это случается не часто.
к процессу коммита:
— коммитеть как можно чаще
— комитеть не ломая, довольно часто вступают в противоречие (особенно если кто-то другой поломал транк свои коммиттом, вы не сможете закоммитеть дабы проблемы не наславивались)
Прошу прощения, я не имел в виду отчёта с вашей стоороны. Достаточно было сказать, что вы практикуете т.н. смешанное парное программирование.
мы стремимся, чтобы она была у нас одна и во многом приуспели. рестроспективы у нас не всегда общие, однако неоднократно поднимался вопрос, как с их стороны так и с нашей, чтобы хотя бы чаще их проводить совместно.
инпут был общий, голосования проводилось в surveymonkey. обсуждение тоже, так-как была общая ретроспектива, где и было принято окончателное решение.
по поводу стори. изначально они небыли однородными, однако в течении года мы и кастомер «эволюционировали». 🙂 До недавнего времени наши стори могли иметь до 5-ти поинтов, однако сейчас мы стараемся внедрить новый подход дробить их вплоть до 1-го поинта, максимум 2 и полностью отказаться от тасков, которые по сути только дублировали аксептанс критерии. Что из этого выйдет я буду описывать у себя блоге.
прошу прощения, опять промахнулся ссылкой 🙁 см пост ниже.
Андрей, по-правде сказать, я достаточно старый и помню светлое будщее СССР, по этому когда вижу слово общий = ничей. А фраза про неоднократно поднимался вопрос = серьёзная неэффективность. Но вопрос был не про ретроспеки, а про принятие решений.
Про команды вы так и не ответили. Я не верю вам, что вы работаете по аджайлу одной
командой в 70 человек (как вы это писали ранее).
Теперь про дробление сторий: стори это юнит бизнес-функционала, полезного кастомеру, который может автоматически уйти в деплой, поэтому оно и называется юзер-стори. Я с трудом представляю как они могут быть подроблены на 1-2. Ведь тогда это работа не техникал тим, а скорее БА и Трус. Для меня это очень подозрительно, когда техи начинают что-то дробить.
По поводу команды, если быть точным то почти 80, включая Трусов. Я к сожалению ничем не могу доказать этот факт.
Про принятие решений, мы обсуждаем и корректируем до тех пор, пока не удастся найти компромисс устраивающий всех. Конечно не всегда так получается, поэтому когда действительно становится сложно сойтись во мнении мы единогласно даём последнее слово нашему ПМ-у(он же скрам-мастер).
По поводу стори. Правильно, каждая из них некий бизнес юнит. Однако, вы всё равно дробите стори на таски и по сути (как было у нас), таски повторяют аксептанс критерии слово в слово. Какой смысл их дублировать? Но, если стори имеет комплексити — 5, то убрав таски вы рискуете зависнуть на ней минимум на всю неделю и даже завершив ее успешно на графике для бизнеса будет не очевидно куда ушло столько времени. В тоже время, разделив стори с комплексити 5 на 3 истории по 2 и 1 вы продимонстрируете весьма динамичный burnup(down) график. Таким образом у вас не будет дублирующих критерии тасков и график прогресса будет также меняться. Главное чтобы эту концепцию заэпрувил ваш трус или кастомер.
Теперь как это внедряем мы. Когда приходит очередная стори, мы решаем можем или нет мы ее раздробить и на сколько. Максимальное число комплексити для стори — 2. Далее мы предлагаем это Трусу. Пока небыло случаев, когда мы получили бы несогласие, хотя внедряем это мы всего 2-ю итерацию :).
Андрей, на этой же странице вы согласились со мной
—————————————-
по поводу эмоционального интеллекта в команде согласен.
>Ещё более интерестный случай когда кастомер считает, что люди должны постоянно >переходить из команды в команду (этак раз в 2-3 месяца).
у нас так происходит.
——————————————
а теперь говорите, что у вас одна команда. Что-то где-то не сходится.
Хм, интерестно, это только показывает, что БА и Трусы не умеет эффективно разбивать истории. Если для вашего заказчика нормально, что техникал занимаются работой Бизнес анализа, то у меня есть большие вопросы о какой эффективности идёт речь?
я не уточнил. 80 человек это размер всей команды внутри которой есть несколько направлений работы. тобишь несколько под-команд и несколько под-проектов. напрмер, команда работающая над проектов А и команда проекта Б, но в сумме А+Б на выходе один большой проект.
Мы не занимаемся работой бизнес-анализа. Мы лишь вносим свои предложения. Ведь бизнес и девы рассматривают стори с разных сторон, поэтому здесь важно найти компромисс.
Я могу привести такой пример. Допустим бизнес создал историю — «Поиск пользователей». Допустим в аксептанс критерии описаны поля поиска, какие результаты поиска мы должны видеть и правила валидации полей. Моя команда предложила бы разбить бы это минимум на 2 истории:
1. Поиск с отображением результатов (эту стори можно было бы еще разбить если бы я конкретизировал вид отображаемых результатов)
2. Валидация полей поиска
зайдём по другому. Наверняка используется какой-дь аля скрум с утренним стэнд-апом. Сколько стэнд-апов в организации проходит с утра = кол-во команд.
примерно 8. однако наш стендап со своей командой мы проводим вечером.
про это и речь. Значит у вас много команд. Благодарю.
т.е. вы хотите сказать, что вы можете пойти в деплой только со второй историей, где есть валидация, но поиск не работает?
вполне возможно, но маловероятно что такое может случится. в любом случае не вижу в чем здесь проблема.