Comments on: Краткое резюму об Agile методологиях http://yasinetskiy.com/2010/01/short-resume-about-agile-practice/ Thu, 15 Jul 2010 08:12:11 -0700 http://wordpress.org/?v=2.8.4 hourly 1 By: Andrey Yasinetskiy http://yasinetskiy.com/2010/01/short-resume-about-agile-practice/comment-page-1/#comment-2283 Andrey Yasinetskiy Thu, 04 Feb 2010 16:53:35 +0000 http://yasinetskiy.com/?p=122#comment-2283 все же опыт со временем приобретается. Кроме того, после активной работы в координаторской роле на крупном Agile проекте можно уже делать какие-то выводы. Но, я не хочу сказать что Agile это плохо. Наоборот, Agile отличный инструмент и кстати пришел совсем не из IT, который действительно стоит применять. Просто нужно понимать что и с зачем делается. все же опыт со временем приобретается. Кроме того, после активной работы в координаторской роле на крупном Agile проекте можно уже делать какие-то выводы.

Но, я не хочу сказать что Agile это плохо. Наоборот, Agile отличный инструмент и кстати пришел совсем не из IT, который действительно стоит применять. Просто нужно понимать что и с зачем делается.

]]> By: Denis http://yasinetskiy.com/2010/01/short-resume-about-agile-practice/comment-page-1/#comment-2278 Denis Fri, 22 Jan 2010 17:00:25 +0000 http://yasinetskiy.com/?p=122#comment-2278 Браво! А как вы со мной красиво дискутировали, поздравляю! Видно развитие! http://victorronin.com/2009/10/06/manifest-rabotodatelya/ http://victorronin.com/2009/10/07/agile-teoriya-protiv-praktiki/ Браво!
А как вы со мной красиво дискутировали, поздравляю! Видно развитие!

http://victorronin.com/2009/10.....todatelya/
http://victorronin.com/2009/10.....-praktiki/

]]> By: Shoo http://yasinetskiy.com/2010/01/short-resume-about-agile-practice/comment-page-1/#comment-2277 Shoo Fri, 22 Jan 2010 13:07:51 +0000 http://yasinetskiy.com/?p=122#comment-2277 То есть? Обычно ведь наоборот: бизнес ставит задачу в своих терминах, а затем она интерпретируется и разбивается разработчиками, причем часто бывает так что задачи уровня разработчиков сами по себе не имеют бизнес-ценности (например, логин не имеет ценности без регистрации и наоборот, а это обычно две разные задачи). Кстати, на мой взгляд, это неправильно. Любая задача должна нести бизнес-ценность. Если она при этом слишком большая - то ее нужно упрощать, но не разбивать. То есть? Обычно ведь наоборот: бизнес ставит задачу в своих терминах, а затем она интерпретируется и разбивается разработчиками, причем часто бывает так что задачи уровня разработчиков сами по себе не имеют бизнес-ценности (например, логин не имеет ценности без регистрации и наоборот, а это обычно две разные задачи).

Кстати, на мой взгляд, это неправильно. Любая задача должна нести бизнес-ценность. Если она при этом слишком большая – то ее нужно упрощать, но не разбивать.

]]> By: Shoo http://yasinetskiy.com/2010/01/short-resume-about-agile-practice/comment-page-1/#comment-2276 Shoo Fri, 22 Jan 2010 13:04:25 +0000 http://yasinetskiy.com/?p=122#comment-2276 Без особых потерь может прийти любой член команды, а не вообще любой программист. Новичку все равно придется некоторое время въезжать в структуру проекта и местные практики. Без особых потерь может прийти любой член команды, а не вообще любой программист. Новичку все равно придется некоторое время въезжать в структуру проекта и местные практики.

]]> By: Buddy http://yasinetskiy.com/2010/01/short-resume-about-agile-practice/comment-page-1/#comment-2275 Buddy Fri, 22 Jan 2010 12:15:42 +0000 http://yasinetskiy.com/?p=122#comment-2275 так или иначе, на конечной стадии дробления задачи она теряет свою ценность с технической точки зрение и приобретает ценность с точки зрения бизнеса. так или иначе, на конечной стадии дробления задачи она теряет свою ценность с технической точки зрение и приобретает ценность с точки зрения бизнеса.

]]> By: Buddy http://yasinetskiy.com/2010/01/short-resume-about-agile-practice/comment-page-1/#comment-2274 Buddy Fri, 22 Jan 2010 12:09:08 +0000 http://yasinetskiy.com/?p=122#comment-2274 и на его место может также прийти "любой" в прямом смысле слова. без особых потерь. и на его место может также прийти “любой” в прямом смысле слова. без особых потерь.

]]> By: Shoo http://yasinetskiy.com/2010/01/short-resume-about-agile-practice/comment-page-1/#comment-2273 Shoo Fri, 22 Jan 2010 12:06:18 +0000 http://yasinetskiy.com/?p=122#comment-2273 Мелкие задачи сложно сделать изолированными, поэтому требуют внешней координации, а значит - начинаются архитектурные митинги, а то и вообще разработчиков удаляют из процесса проектирования. Не агильно выходит. Мелкие задачи сложно сделать изолированными, поэтому требуют внешней координации, а значит – начинаются архитектурные митинги, а то и вообще разработчиков удаляют из процесса проектирования. Не агильно выходит.

]]> By: Ivankin http://yasinetskiy.com/2010/01/short-resume-about-agile-practice/comment-page-1/#comment-2272 Ivankin Fri, 22 Jan 2010 12:04:27 +0000 http://yasinetskiy.com/?p=122#comment-2272 Да, все верно Декомпозируем задачи так, что любой программист может быть уволен сразу после ретроспективы в конце спринта. Мечта бизнесмена. Да, все верно
Декомпозируем задачи так, что любой программист может быть уволен сразу после ретроспективы в конце спринта. Мечта бизнесмена.

]]> By: Buddy http://yasinetskiy.com/2010/01/short-resume-about-agile-practice/comment-page-1/#comment-2271 Buddy Fri, 22 Jan 2010 11:57:31 +0000 http://yasinetskiy.com/?p=122#comment-2271 Не требует, подразумевает. И так или иначе команда в скором сама к этому приходит. Так-как на более мелких задачах легче наблюдать динамику. Не требует, подразумевает. И так или иначе команда в скором сама к этому приходит. Так-как на более мелких задачах легче наблюдать динамику.

]]> By: Shoo http://yasinetskiy.com/2010/01/short-resume-about-agile-practice/comment-page-1/#comment-2270 Shoo Fri, 22 Jan 2010 11:47:41 +0000 http://yasinetskiy.com/?p=122#comment-2270 А разве Agile требует мелкого дробления задач? 1-5 дней на историю - вполне нормальные рамки и для крупных задач, особенно если процесс позволяет сосредоточиться конкретно на разработке. А разве Agile требует мелкого дробления задач? 1-5 дней на историю – вполне нормальные рамки и для крупных задач, особенно если процесс позволяет сосредоточиться конкретно на разработке.

]]>