что означает agile для программистов?
Alexey Krivitsky
по статистике из опросника, который я постил, в группе участвует 60%
программистов. а это значит, что большинству интересен agile с позиции
программиста, а не менеджера.
хотелось бы узнать у программистов:
что для вас означает agile?
что вы под этим понимаете?
какие критерии для вас определяют следует ли проект agile или нет?
вот мне кажется, что большинство понимают следованеи XP-шным
инженерным практикам: юнит тестирование, рефакторинг, парное
программирование.
при чем такие темы как кооперация с заказчиками, методы управления
командой... многих просто не интересуют... они ощущают, что это вне их
компетенции.
хотелось бы понять ошибаюсь я или нет.
хорошего дня, всем
а наших аджилисток - и с наступающим :)
леша
aizika
отдельных ее членов. Этот критерий должен быть единым для всех.
Если программисты, следуя лучшим практикам, быстро пишут
высококачественный код, который делает не то, что нужно заказчику, то
проект вряд ли будет успешным.
Александр
On Mar 7, 2:18 am, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
Max Pendyschtschuk
Для мене аджайл це
- [толерантні] відношення всередині команді, коли всі являються
рівними один перед одним;
- відсутність comand-control практики
- вся команда втягнута у процес і впливає на нього
- наявність представника замовника у команді і спілкування з ним
напряму, а не через проксі сервер у вигляді проджект менеджера який
трактує все по своєму (маю достатній досвід у цьому :) )
- ...
(маю зараз головну біль яка трохи заважає достатньо точно висловитися,
тому підсумую все так - мене в першу через цікавлять відносини між
усіма задіяними у процесі, наша взаємодія, а все решта - рефакторинг,
тестування я відношу на другий план. Якщо взаємодія із замовником
достатньо добра і продуктивна, ми витрачатимемо менше часу на
рефакторинг, тестування і процес адаптації буде набагато кращим.
Сподіваюся висловився чітко, щоб пояниси своє бачення аджайл)
І приєдуюся до привітань наших чаріних жінок, які надихають нас на
нові подвиги :)
Максим
On Mar 7, 12:18 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
Alexey Krivitsky
Я с тобой совершенно согласен.
Если искать критерии, то такие, которые бы описывали как можно более
высокоуровневое понятие "успеха проекта".
На сколько я понял, для тебя таким критерием является:
----
разработка высококачественного кода программного продукта, который
отвечает требованиям заказчика.
---
(тут "требования" имеют скорее более широкое значение, чем обычно,
которое включает в себя такие субъективные понятия как качество и
удовлетворение деловых, политических, эстетических и проч потребностей
заказчика).
Допустим. Но тогда к примеру команда, которая разрабатывает отличный
код по заранее подготовленным неизменным спецификациям (допустим есть
такие заказчики, которым могут все предусмотреть) отвечает нашим
критериям.
Значит такую команду можно назвать "agile командой", что мне кажется
не есть правильным с точки зрения сложившегося понимания этого
термина.
Но что ж тогда "agile-команда"?
Alexey Krivitsky
значит, ты ставишь на первый план человеческие отношения: отношения
внутри команды и отношения между командой и заказчиком.
было бы интересно узнать, какой процент программистов поддержит твоё
определение
agile-проекта.
удивительно, я тут подумал, а ведь такие важные факторы как мотивация
и профессионализм, их, выходит, тоже можно в таком случае тоже отнести
на второй план, - ведь не будет же хороших отношений, если заказчик не
доверяет команде, из-за того что она не в состоянии разработать
требуемый продукт?
также скорее и не сложатся отношения внутри команды, если уровень
мотивации её членов будет достаточно разным.
таким образом - по качеству отношений внутри команды, также между
командой и заказчиком, можно судить о степени "agility" в проекте.
здорово!
Alexander Aizikovsky
Я собственно хотел сделать упор не на содержании критерия, а на том,
что он - един для всех. Я хотел поддержать твою мысль, о том, что
перечисленные тобой практики не гарантируют успеха и не дают права
называть весь процесс каким-нибудь именем.
См также ниже:
On Mar 8, 12:47 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
> На сколько я понял, для тебя таким критерием является:
> ----
> разработка высококачественного кода программного продукта, который
> отвечает требованиям заказчика.
> ---
> (тут "требования" имеют скорее более широкое значение, чем обычно,
> которое включает в себя такие субъективные понятия как качество и
> удовлетворение деловых, политических, эстетических и проч потребностей
> заказчика).
желателльно что-нибудь измеримое:
понизить затраты на производство тапочек на 10%
повысить удержание клиентов с 3 до 5%
сократить время обслуживания клиента с 3 мин до 30 сек
...
заметь, что для этого может оказаться необязательно разрабатывать
программный продукт :)
>
> Допустим. Но тогда к примеру команда, которая разрабатывает отличный
> код по заранее подготовленным неизменным спецификациям (допустим есть
> такие заказчики, которым могут все предусмотреть) отвечает нашим
> критериям.
Теоретически. На практике 100% заказчиков с которыми мне приходилось
сталкиваться меняют свое мнение и находят упущения в спецификациях по
ходу работы.
Если бы такие заказчики существовали, никакой agile был бы не нужен.
> Значит такую команду можно назвать "agile командой", что мне кажется
> не есть правильным с точки зрения сложившегося понимания этого
> термина.
Раз agile не нужен, никого никак называть не надо.
Для меня способность команды реагировать на изменения в процессе
достижения хорошо определенной цели (включая, возможно, изменение
самой цели) и есть показатель ее динамизма (аджилизма :) )
Основополагающая книга Extreme programming explained by Kent Beck
имеет подзаголовок Embrace the
change.
Саша
Max Pendyschtschuk
> удивительно, я тут подумал, а ведь такие важные факторы как мотивация
> и профессионализм, их, выходит, тоже можно в таком случае тоже отнести
> на второй план, - ведь не будет же хороших отношений, если заказчик не
> доверяет команде, из-за того что она не в состоянии разработать
> требуемый продукт?
Палка з двома кінцями. Що краще, команда скажімо "не достатньо"
професійна але спілкування/взаємодія відбувається на 100%, чи команда
100% професіоналів і в той же час "егоїстів" (кожен витворяє що хоче
без вислуховування інших думок).
Тут треба шукати золоту середину. Але з вибору вище вказаного я б
вибрав перший варіант - як на мене то набагато простіше стати
професіоналом ніж навчитися вислуховувати одне одного... Та й взагалі
я не вірю, що людина може стати професіоналом, якщо вона не вміє
слухати (хіба шо вона народилася професіональним програмістом, але які
шанси на таке?).
успіхів
Alexander Aizikovsky
Ви цілком прави що відносно спілкування. Не може бути успіху, якщо
немає співробітництва. Також вірно, згідно з моїм досвідом, що досягти
профессіоналізму простіше, ніж навчитися слухати й розуміти своїх
коліг.
Не знаю, чи варто сперечатися, про те, що найкращого спілкування не
достатньо для успіху. Ще щось має бути присутнє.
Чи не могли б Ви назвати другу, треттю (і далі :)) важливу якість
успішної команди.
Чи ці якісті утворюють agile?
Чи є "успіх" та "agile" синонимами одне то одного?
Чи наява гарної команди є достатньою умовою успіху у розробці програм?
Яки б поради Ви дали до доброЇ команди, щоб допомогти їм досягти
успіху?
З повагою,
Олександр Айзіковський
PS Не знаю чи не варто було надіслати кожне з питаннь окремо? :)
On Mar 8, 11:39 pm, "Max Pendyschtschuk" <gotischer...@yahoo.de>
wrote:
Alexander Aizikovsky
Приношу искренние извинения всем кого задел (или рассмешил) и впредь
буду придерживаться русского.
Без каких-нибудь обещаний насчет качества последнего. :)
Max Pendyschtschuk
Звичайно що спілкування маловато, інакше ми могли б працювати у барі з
пивом замість того, щоб сидіти у офісі :)
Гарне запитання, я над ним ніколи не думав, чесно кажучи. Щось у мене
тут склалося як у Формулі-1: один з автогонщиків сказав, що другий -
це перший з тих що програли. От подібна ситуація виявилася і у мене -
я ганяюся поки що за встановленням добрих відносин... (але це явно, а
неявно, звичайно, борюся і за інше).
Отож спробую заповнити Вашу анкету:
> Чи не могли б Ви назвати другу, треттю (і далі :)) важливу якість
> успішної команди.
2. Здатність команди до адаптації. Приклад - клієнт дає свої вимоги
(позначимо це точкою Б), ми їх виконуємо і клієнт уточнює їх і дає
нові вимоги (точка В) і т.д. Напочатку проекту ми знаходимося у т. А.
(тут я більше про водопад, ніж про ітерації, коли місяцями ми
добираємося до т.Б. і т.д.). Команда повинна усвідомлювати, що
результат роботи - це не точка Б, і не точка В... А те, що
задовольнить клієнта на 100% (можливо це точка Я, яка представляє
собою зовсім вже інший проект, ніж був описаний у перших вимогах).
(Можливо невдало назвав пункт - "здатність до адаптації"..., тут знову
ж приймають участь відносини та спілкування, куда ж без них, але суть
другого призового місця - розуміння мети)
3. Не можу не написати, що і клієнт повинен розуміти "засоби" для
досягнення мети (клієнт ж також є частиною команди, але виношу в інший
пункт. можливо і не варто...). Скоріше поставив би на друге місце
поруч. Приклад - клієн дратується, коли різні програмери задають одне
і те ж запитання (можливо дещо іншими словами) і каже, що варто
спілкуватися через одну людину, що так простіше. Недолік патерну -
коли один програміст отримав відповідь на запитання, то як не крути, а
іншому він передасть своє бачення, а не істинне "клієнтське". Недолік
на лице.
4. Мабуть тут вже розташую професіоналізм, за відсутності інших
думок :) Повторюсь, але технічно грамотною/освітченою людиною стати
все ж таки простіше, ніж отримати розуміння пунктів вище...
Не буду спорити що цей список можна розширювати, просто запропоную
співпрацю з зацікавленими у цьому сторонами :-)
> Чи ці якісті утворюють agile?
Думаю що так, намагаюся мислити як agile developer :)
> Чи є "успіх" та "agile" синонимами одне то одного?
Scrum isn't Silver Bullet (перекладаючи прочитав у Майкла :-))
Сумніваюся, що можна сказати "якийсь процес є запорукою/синонімом до
успіху". Є компанії як Capgemini наприклад, які використовують RUP і
добиваються успіху. Тут скоріше до чого душа лежить...
> Чи наява гарної команди є достатньою умовою успіху у розробці програм?
Відсутність команди точно є умовою завалу проекту. А от чи вірне
обернене твердження? Щось не думаю... Хоча дивлячись що брати за
"гарну команду", dream team? :) Як каже мій шеф - деколи дивишся, як
щось прекрасно працює на заході; здираєш один в один, а у нас хоч убий
не працює :) Складне запитання.
> Яки б поради Ви дали до доброЇ команди, щоб допомогти їм досягти
> успіху?
Знал бы прикуп - жил бы в Сочи :) Сам шукаю поради.
найщиріші вітання,
Максим Пендищук.
PS. Мда, мова прикольна получилася :) Але головне бажання спілкуватися
на якісь мові. Не переживай, мій шеф з Голандії спілкується
українською ще гірше :))